Using Enterprise Messaging for Extensions with Node Part 2

In this part, let’s create the customer update application and the orchestrator service which calls this update application.

Ok before we create an orchestrator let’s create a application which can update some data about customers.

Customer Update Service

Imagine a scenario where when a Business Partner in S/4HANA is updated, you want to also update some information about the business partner but on SAP Cloud Platform (A simple side-by-side Extension).

So again I have created this application using Node. But this time let’s try doing this on Visual Studio Code.

Step 1: Generate Package.json

Open the command prompt in administrator mode and go to project root folder. Execute the below command.

npm init –yes

This will generate a the initial package.json file in the root folder.

Step 2: Let’s install the required dependencies

In the same folder, run the below commands.

npm i -g @sap/cds-dk

This will install the SAP CDS package which we will help us create a DB module and service module and also deploy as a MTA on cloud foundry.

Run the command CDS V to make sure it has been installed correctly, you should get a result similar to below screenshot.

Step 3: Initialize project

Run the command cds init customerInfo

This command creates a project customerInfo similar the CAP projects that you created for Sender Service.

Step 4: Define Data Model

Open the project in Visual Studio Code.

This defines entities and attributes which will ultimately be deployed on HANA service in SAP Cloud Platform.

Step 5: Let’s add some mock data

Now CDS automatically scans for a folder called CSV under DB folder. If it finds a file with same name as the entity, it automatically uploads the data to the binded database and respective tables.

So create a file named my.customerInfo.customerBasic.csv

Create an another file my.customerInfo.profiles.csv

Step 6: Create a service to expose data

Let’s create a service to expose these data.

Step 7: Let’s add SQLite3 for testing locally

Open the command prompt and run the command npm i sqlite3 -D

This will install sqlite3 and also adds it as a Devdependency in package.json

Step 8: Test Locally

To test a CDS application locally. Run command CDS Watch in the project root folder.

You should be able to see the Node uploading the data to sqlite and also the services should be generated.

By default, you will see that our Application is listening on localhost:4004.

Special Note: CDS Watch is similar to Nodemon, it watches for any changes in your project folder and automatically restarts the server. So you can actually run CDS Watch when you begin the project itself.

Now, if you open a browser and go to http://localhost:4004 you should be able to see resources available.

Now let’s test a POST method using Postman.

Launch Postman application or the add-on on Chrome.

Step 9: Deploy to SAP Cloud Platform

This step requires CF CLI to be installed. I hope you have already done it.

Since we will be using HANA and not SQLite when we deploy, we need to add that dependency to our project.

Run the command npm add @sap/hana-client –save

Finally, we are now ready to deploy the application.

Create a hana service instance using command

cf create-service hanatrial hdi-shared customerinfo-db

Now, run the below commands

cds build –production

cf push -f gen/db

cf push -f gen/srv –random-route

The first command builds your application. This generates a separate module for db and srv

The second command creates a application which binds to the hana service .

The third command creates a application which exposes the services similar to what we tested earlier.

Special Note: Login to your CF account and make sure these applications are binded properly and started. If not, you would have to sometimes bind the instance manually and restart the service.

Let’s now create the Orechestrator Application which will call the above POST API when it receives a message from the sender application.

The Orchestrator

If you check our architecture again you would notice that one of the critical service we need is the Orchestrator. The Orchestrator service is responsible to direct the calls from Message broker to respective applications.

So let’s begin to create this service. Similar to sender Service I have used NodeJS to demonstrate because of the simplicity service creation in Node.

Step 1: Login to SAP Cloud Platform Trial Account

If you are launching after a day, you will notice the your dev space would be stopped. Start the service again and then click on the space.

Step 2: Create a CAP Application

In the welcome tab, click on Create project from template

Select CAP Project and click on Start. Then enter a project name as capreceiver.

This should create an empty project with different CAP modules such as db, srv

Step 3: Edit the project

Just like the sender application prepare the project dependencies. Click on the file package.json

This application would need additional dependency called “axios” which we would use to call the REST APIs of the customer update application .

Axios is a HTTP client which provides us APIs to call REST services in a easy and standard manner.

Create Services

Since we are only creating a service which will in turn call APIs, we don’t need any persistency and hence the db module is not required in this application.

Create a new file under folder srv called receiver-service.cds

This file creates a service called ReceiverService

Create a new file under folder srv called receiver-service.js

This particular code gets called on event when message is received in the queue /customer/created.

Please note: To replace your host name in the axios.post function call.

Once, the message is received, a call is made using the Axios.post API to the customer profile update application.

Based on the queue you can make several calls to different applications and orchestrate your whole integration scenario in this manner.

Add MTA File

Let us add the MTA.yaml file and build it.

You can follow the same steps as sender service to create the MTA file.

Now right click on the MTA.YAML file and select Build MTA.

This will generate the mta_archives folder with the .mtar files which will be used to deploy on cloud foundry.

Deploy to Cloud Foundry

Expand the folder mta_archives and right click on capreiver-srv.mtar file and select Deploy MTA Archive.

Verify the cloud foundry space to make sure the instance is running.

Make sure the Enterprise messaging instance is bind to the application.

Final Testing of the whole scenario

Ok so now that we have all the applications and their instances ready, let’s test the full scenario

Make sure all the instances of your applications are running.

Open the capsender-srv and run the sender URL.

Now open Postman and do a GET on the ProfilesValue resource. You should be able to find the customer_id: 101 with a profile value as “Munich”.

Ok this sounds very simple!! But in the background what happened is, when you called the send() function it send a message to the Broker(You can check the messaging dashboard) and our Orchestrator which was listening to the queue received the message.

Once it received it called a POST request of our Customer Update application which finally updated the Profile value.

As you see, all the applications we developed talk to each other asynchronously and doesn’t require much interface mapping at all.

Now, Imagine if we could orchestrate all the events in an enterprise and break up applications to talk to each other in this way. Not only are we reducing the footprint of fat applications, but also making our development teams more agile.

This in my opinion is the power of Enterprise Messaging!

Additionally you could also configure S/4HANA to be your sender application to orchestrate the business events that happens in your core ERP.

I will try to soon write a blog on that part too.