Introducing the Node.js Module

The following list describes Node.js:

• Node.js is a server-side runtime environment for JavaScript.

• Node.js is built on Google’s V8 JavaScript engine.

• Node.js uses an asynchronous, event-driven programming model

• Node.js is single threaded and highly scalable

• Node.js is best suited for web applications

• Node.js is open-source with a huge community

• Node.js is has many available libraries (Node Modules) via NPM library

The Node run-time environment includes everything that you need to execute a program written in JavaScript.

Node.js is an extension of Javascript running in the browser to run on your machine as a standalone application.

Both your browser JavaScript and Node.js run on the V8 JavaScript runtime engine. This engine takes your JavaScript code and converts it into a faster machine code. Machine code is low-level code that the computer can run without needing to first interpret it.

Watch this video to learn about Synchronous versus Asynchronous processing.

Node.js uses an asynchronous and non-blocking programming model.

The event loop executes tasks from the event queue and starts the callbacks.

If the queue is empty, the event loop process stops and gives back system resource.

Node modules run in an asynchronous mode by default. If you need synchronous processing, you can use the Node library.

When using the SAP Business Application Studio to create an SAP Cloud Application Programming Model Project, the initial screen provides the run times option for Java and Node.js.

Selecting Node.js enables the use of Node.js for Application Development. Adding Node.js installs the required libraries during the creation of the project for further use.

The build, deployment, and runtime dependencies of a JavaScript application are described in the package.json file. The package.json file is mandatory for JavaScript applications and it is located in the general section of the project.

As well as the application name and version, dependencies to other Node.js modules, the Node.js version, run scripts, and the main program are configured.

The scripts section contains the different run commands, which are executed for different tasks.

The application package descriptors are as follows:

• name

  The name of the JavaScript application whose package prerequisites and dependencies are defined in this package description.

• description

  A short description of the JavaScript application, whose package prerequisites and dependencies are defined in this package description.

• private

  Use the private property to indicate if access to the package specified in name is restricted. Private packages are not published by npm.

• version

  The version of the JavaScript application, whose package prerequisites and dependencies are defined in this package description.

• repository

  The absolute path to the repository used by the JavaScript application, whose package prerequisites and dependencies are defined in the package description.

• dependencies

  A list of dependencies that apply to the JavaScript application, whose package prerequisites and dependencies are defined in the package description.

• engines

  The runtime engines used by the application specified in the name property.

• scripts

  The script containing the command used to start the JavaScript application, along with any additional (required) options and parameters.

When defining dependencies and runtime engines in the package description, you can specify a range of versions. For example: >1.0.3, <=1.2.5, ^1.0.5 (compatible with version 1.0.5), or 1.2.x (any 1.2 version), or 1.1.0 - 1.3.12 (any version including or between the specified versions).

Applications are deployed to the target platform by using the push operation of the platform API. For this reason, in Cloud Foundry parlance, applications are "pushed" to the platform. Pushing an application works as follows:

1. The application files are uploaded to the platform.
2. Buildpacks are executed to create archives, that create the self-contained and ready-to-run executable applications (downloading any required libraries and other dependencies, configuring the application). Different buildpacks exist for the different target runtime environments, such as Java or JavaScript/ Node.js.
3. Applications are started as separate processes. At runtime, the applications need the connection information for the service instances to which they are bound. The applications obtain this information from process-specific environment variables, which are resolved by the platform in a process known as service wiring.

   Bindings can only be created between applications and service instances in the same space.

Below are the two methods to run a Node.js module using Business Application Studio.

The node module can be run from the terminal window. Terminalcds run

The build process completes automatically when starting the module. It is not necessary to execute it separately.

The node module can be run from the terminal window. Terminalcds watch

The build process completes automatically when starting the module. It is not necessary to execute it separately.

cds watchcommand monitor changes to the files and completes the build process automatically and starts the module.

Run Configurations : In the SAP Business Application Studio run configurations, the start scripts are available for you to execute, different run configurations can be used in the SAP Business Application Studio to start the node application.

Note

By default, the run configuration is created for the "development" profile. If you configured an additional profile for your application, you can create a run configuration that activates and uses this profile.

The dependencies of the application are calculated according to the profile selected.

A new configuration is added to the launch.json file.

In addition to the launch.json file that is created as part of the new configuration, an environment file is added when creating a run configuration.

The environment configuration file is referenced from your Launch configuration as seen in the image.

In the Run Configurations view, you can see the available dependencies as defined in the package.json file. You can bind or unbind these dependencies to a specific Cloud Foundry service instance or to your local database.

Note

The following Cloud Foundry service types are supported for binding:

• hana ( managed-hana is not supported)
  • PSA-based SAP HANA
  • HaaS (if configured as "Available for all IPs")
  • SAP HANA Cloud (if configured as "Available for all IPs")
• xsuaa
• auditlog
• application-logs

You can also bind directly to a destination.

Binding to Local database : ,

• If you are binding to an SQLite service, a new connection is added to the SQLTools view where your tables and data are displayed.
• Clicking Bind creates a Deploy task (or triggers it if it already exists). You can redeploy the database at a later stage by running this task again.

Binding to SAP HANA Cloud Database : ,if you are binding to SAP HANA Cloud DB , the deploy task is created, you may be prompted to deploy. You can deploy manually by running the Deploy task.

Binding to Cloud Foundry service : ,if you are binding to Cloud Foundry service ,

If not already logged in, you are prompted to log in to Cloud Foundry.

A list of all available services that match your dependency type are displayed in the command palette

if you are binding to external OData service ,

If not already logged in, you are prompted to log in to Cloud Foundry. A list of all available destinations from your subaccount is displayed in the command palette.

To mock all OData services that are not bound to a destination:

Turn on the property to mock external OData services. All dependencies of type OData that are not bound to a destination appear in the Run Configuration tree marked as mocked.