Table of Contents

  1. Table of Contents
  2. The Big Picture
  3. Quick Glance to set up SAP system
  4. Set up in BTP
  5. Set up in AEM
  6. Set up in Integration Suite
  7. Revisiting the big picture
  8. Preparing to Test the set up

The Big Picture

Based on what we have understood so far in last blog, to publish an event and subscribe to an event we will be using REST endpoints (HTTPS).

Lets lay out our technical Demo landscape.

ERP System (the publisher) - It will be used to create a Sales Order and publish Sales Create/Change Event.

SAP Integration Suite (The subscriber) - It will be used to consumer the Sales Order Events and also publish the event to a new cusomer queue which is not created in AEM before hand.

So from AEM perspective:

SAP will send a Sales order notification to the broker on Event mesh. The broker will publish such events to our Integration suite endpoint which will be exposed by us.

Integration Suite will then publish this Sales Order event to a dummy queue to demo how can we publish events to AEM. We will monitor this dummy queue on AEM which will be open to subscription (optional).

This will complete our visibility on both fronts, subscribing and publishing events to AEM.

Quick Glance to set up SAP system

For set up in SAP for AEM you can check the blog for reference:

SAP S/4HANA integration with SAP Integration Suite, Advanced Event Mesh | SAP Blogs

Othter than installing different package and installating components, one important configuration is the HTTP destination you maintain in SM59 to the broker.

You have to maintain same destination in SPRO configuration for add on.

If you test this connection you will get below, which is “OK”:

Set up in BTP

In BTP you need to subscribe enable the AEM service as shown below. Do check out licensing and costs before enabling the service.

Also you will need to create a separate identity provider to autheticate over AEM service. Morever you need to add this identity provider in your “Trust Configuration” in the BTP.

Do take help of your BTP admin (if you are not one) when doing these configuration to get a visiblity on cost and licensing of each new component or service being enabled and then configured.

Set up in AEM

In AEM we will first create a queue to which our application will be listening. Go to Broker Service -> Manage -> Queue->

Click “+ Queue” button on top right.

Give it name:

Next we will add subscriptions to this queue. This means what type or category of notifications/event will be published on this queue.

Now we will subscribe to “Sales ORder Create” event.

Note that the consumer tab is not populated at this moment as it is populated after we bind this queue to a consumer, as shown next.

Next we will create an RDP client. This is referece object of each consumer to which you are trying to publish an event.

Select Client from navigation pane on left, click on “+ REST Delivery Point”

Give it a name:

Next we will create a consumer inside this RDP, this is an actual asset which contains all the information about host port of consumer and its authorization details.

Go to “REST Consumers” tab of the newly created RDP and and click “+ REST Consumer” and give it a name “REST_CONSUMER”

For next step you will need below four values:

Your Integration Suite Host, Client ID, Client Secret and Authorization URL. To get these values, go to your BTP cockpit and to the “Process Integration Runtime” Instance, and then to keys:

In here just the select the key you want to use and copy the details as shown below:

Once you have the above information, fill in an “apply”

Next we will go back to our RDP asset and bind the previously created queue to this consumer in “Queue Bindings”.

Fill in the queue which you want to bind and then fill in the REST Resource path details, where the event of this queue need to be published once connected to consumer.

Note down this Request Target Path, as we need to configure same on our exposed REST (HTTP) endpoint in our iFlow in Integration Suite.

Now lets go back to our RDP asset and check the status, all should be in “Up” status, else we will need to troubleshoot each object with status “Down”. Here you can see all relevant “Assets” we have build to connect RDP to our Integration Suite endpoint.

Now we will go back to our “Queue” we created and set its owner to this RDP. It is important as all underlying assets will align based on the owner RDP.

We are almost done with AEM set up.

One last step, where we want to be able to receive events from Integration Suite into AEM. Integration Suite will publish events to a dynamic topic. We need to create a queue “CITestSalesOrder” and add this topic subsciption under it.

This Queue doesnt need to have any consumer. If you want a consumer to listen to this queue, it will follow similar RDP configuration which we have done for IS.

Set up in Integration Suite

In Integration We will create two iFlows.

Consumer iFlow - In this one we will expose the endpoint where AEM will publish the events. The same endpoint configured in RDP above.

It is plain iFlow which just receives event paylaod from AEM.

Here we are exposing our REST Endpoint.

We will enable trace to look at the received SO.

2. Publisher iFlow - In this iFlow we will publish an event to AEM to a dummy queue, created at runtime. We will use a topic to publish this event.

In this case we will modify first iFlow where we receive an event. The modification will allow us to publish the event on a dynamic topic.

The dynamic endpoint is defined on receiver HTTP adapter configuration. It is:

{AEMBrokerHost:Port}/{DynamicTopic}

We use a combination of JSON-XML converter and then content modifier to cature each of the value required to fetch the dynamic topic params. You can use groovy/javascript parse JSON directly and create topic inside code. For visualization purposes I am using content modifier.

As we are exposing and consuming HTTP services directly there is no additional set up needed in Integration suite for this demo. However, if you plan to use AMQP or MQTT for same purpose you will need to look over relevant “protocol” based endpoint details in AME broker service.

Revisiting the big picture

Now we have AEM ready to publish the events to Intgration Suite path “/socreate”, our iFlow is ready to receive events at “/socreate”.

There is a queue which has subcription to the “SO Create Event” and RDP which has all the information needed to connect to SAP-IS.

Our Second iFlow is ready to publish events to the dynamic Topics, which are subscribed under queue “CITestSalesOrder”.

We have created the Queue, added subscriptions, created RDP + REST Consumer, the Queue Bindings. Now we are ready for testing.

Preparing to Test the set up

to test the scneario End to End, you will need:

  1. To be able to create Sales Order in ERP.
  2. To be able to Change Sales Order (optional)
  3. To have postman installed. (optional, in case you want to simulate SO creation but doesnt have enough permissions or access to an ERP system.)

Note: Though you can see we have two broker services in our AEM, we will be using only one broker service. if you want to publish events to a different broker, all you need to do is change host connection params, no other information changes.

This also brings us to a small but important “technical observation” in a mesh called “Dynamic Message Routing” (DMR).

In a nutshell, DMR forwards and propagates events from one broker to another automatically as long as they are on same mesh. DMR enables connected event brokers, or nodes, to automatically determine how to forward event messages to other nodes that have subscribers connected to them.

Note: As I have written and explained most of the concept in the way I understand them and worked for me, feel free to builld your own framework of understanding differnt topics.

Thank you and I will see you in next blog.