INTRODUCTION
When it comes to the process of publishing and receiving events, Advanced Event Mesh offers support for multiple protocols. This feature provides publishers with various options. On top of this, Advanced Event Mesh provides various features (one of them mentioned in this blog) for making your scenarios as flexible – dynamic as possible if being used effectively.
As one of the primary source systems for event-driven scenarios, this kind of features allows publishers/subscribers like S/4HANA, multiple options during and after publishing of the events and messages. With different methods for capturing/triggering the events/changes (differentiated by the system), this features enriches the possibilities being used in the event driven scenarios.
I won’t discuss these details for triggering the events, as these are already mentioned in various blog posts readily accessible from the community pages. In this post; instead, I’ll concentrate on other aspects of Advanced Event Mesh where it takes over from that point and use the published information effectively for the later stages.
Implementing integration scenarios is important but it is also very crucial to design these scenarios in a versatile manner to ensure that future maintenance and the addition of new use-cases can be handled more easily.
S/4HANA is just one of the upstream (source) applications- a very important one- in the event-driven space; from an enterprise perspective there are different types of producer applications as the source / publishers and consumer applications as the targets. Therefore, the Event Broker should provide capabilities to handle all scenarios dynamically once it receives messages from the source applications, being protocol/source independent as much as possible.
In this blog, I will explain and demonstrate the usage of one of these features, in conjunction with the multiprotocol capabilities of Advanced Event Mesh, by illustrating an example where S/4HANA dynamically publishes messages to target applications.
To be more specific; I will simulate S/4HANA’s publishing of messages to Advanced Event Mesh via REST and demonstrate/show, how Advanced Event Mesh can help you flexibly use this message combining multi-protocol capabilities and substitution expressions feature with the below high level design.
FIGURE 1- High Level Architecture
SCENARIO – STEPS & FLOW
In our imaginary scenario we’ll have one domain object (product) to be published to one consumer application having a REST API to process the messages.
Flow would be as follows in the scenario:
Source Application (S/4HANA)
- A product is created in S/4HANA and an event/change is triggered
- Change/Event is captured via custom logic / code in S/4HANAa. Payload is createdb. Topic Determination (topic string creation) happensc. Publishing to Advanced Event Mesh happens via REST
Event Broker (Advanced Event Mesh)
- Using event & data (topic & payload) to publish to subscribers.a. Call the REST Endpoints statically. (one per each queue and binding)b. Add another endpoint and invoke all of dynamically (1.. n) (with one configuration, dynamically)
The objective for us in this blog post is to show Advanced Event Mesh’s capabilities therefore we’ll be focusing on the steps after step 2c. which is from and after the publishing of the event to Advanced Event Mesh and the process later.
I will be simulating the REST call from S/4HANA to Advanced Event Mesh via Postman. (formulating this REST call – URL structure is explained in the previous blog)
DETAILS
Scenario starts with product data’s being created (step 1) which triggers the change in S/4HANA.
In step 2 the emitted event/change is captured. This is where you can do many things before publishing the information. At this point we have information regarding the changed /created/deleted object (product in our case) which will give you an option to make your scenario more specific in step 2a and add additional logic. Lets assume that we have created a payload like the one below within our S/4HANA code.
{
“ProductID”: “ABCD123”,
“Product”: “XYZ”,
“ProductType”: “ABC”,
“GrossWeight”: “100”,
“WeightUnit”: “DEF”,
“NetWeight”: “90”,
“ProductGroup”: “GHI”,
“CountryOfOrigin”: “TR”
}
in step 2b before publishing it to Advanced Event Mesh, we would create a dynamic topic.This topic is critical metadata which will be used by Advanced Event Mesh to determine the consumers (you can refer to my previous blog where I mentioned how to design a topic structure).
Dynamic topic structure would be like this (we’re keeping it simple for now)
out/s4hana/{domain}/{verb}/{country}/{objectID}
where parts in {} are dynamic based on the object.
in our case the topic will be
out/s4hana/product/created/tr/ABCD123
in step 2c Payload will be published to Advanced Event Mesh. There are various options and protocols that can be used as mentioned. In this case we will use REST (http).
Advanced Event Mesh is capable of handling the “rest”, if we send the payload and (optionally required headers) with a specific URL structure. Send your payload with the below information and your message is published to the event broker.
Host : {YOUR_ADVANCED_EVENT_MESH_HOST}
Port: 9443 (usually)
Path: /{YOUR_TOPIC_STRING}
Payload:{YOUR_PAYLOAD}
Below is the final result. Just replace <YOUR_SYSTEM_SPECIFIC_VALUE> with your system values and POST to
https://mr-connection-<YOUR_SYSTEM_SPECIFIC_VALUE>.messaging.solace.cloud:9443/ out/s4hana/product/created/tr/ABCD123
FIGURE 2 – REST Request (Simulation) from Postman
If you publish this from S/4HANA, the ABAP code to post to an http endpoint is pretty standard as this is a regular POST request.
In step 3 – Advanced Event Mesh receives the message and based on the URL it resolves the topic.
We’ve created a queue (specific to product). Based on its subscription it receives the message from S/4HANA.
Queue : bb/product
Subscription: out/s4hana/product/>
FIGURE 3- Message Stored in Product Queue
This message is published to Consumer’s Queue specific to products objects (Queue named: bb/product).
Once received, we would like the message to be pushed to the REST API’s specific endpoint(product handler endpoint) provided by that application. For this, we should create an RDP, a REST Consumer and a queue binding that links our queue to the target application’s endpoint.
Details could be found in my previous blog post
Rest Delivery Point : rdpDynaAPI
Rest Consumer : rcDynaAPI
And with the queue binding configuration below we’ll have our end-to-end scenario ready from S/4HANA to Consumer Application for the product object.
FIGURE 4- Queue binding for product queue and product endpoint
With this setup whenever we publish a product from S/4HANA(to the product related topics), it will be handled by our downstream application’s product handler.
But this is only for one kind of business domain (use-case). In real life cases, we would have multiple scenarios, multiple domain objects like this (such as Customer, Order, GeneralLedger..).
Do we need to replicate the scenario and whole configurations again. The answer is a positive : “no”
With the help of substitution expressions, we have the option to call endpoints dynamically.
Lets make a topic design where we require additional domain objects, such as customer object. But in this case we would like to have a design as:
Whenever we publish from S/4HANA with customer data, we would like it to be handled by the correct endpoint (handler). It should be a different end-point from the product. We also don’t want to create queues and queuebindings “for each” domain, as we want to manage them easily once the numbers grow to tens of different domain objects in the future.
Here are the steps to reach that:
First, create a common queue subscribed to both topics, meaning it will receive both customers’ and products’-and for other future objects’ data (Only one queue for the consumer).
Still I would like them to be handled differently without affecting the target system and have the possibility to add future objects dynamically.
How could the queue (AEM) know which object to push which target endpoint?
The magic is the dynamic configuration that is provided by “substitution expressions”.
To start with, we’ll have 2 topic subscriptions like below:
out/s4hana/product/>
out/s4hana/customer/>
And we’ll have one common queue replacing the product queue.
Queue Name : bb/common
With the below configuration in Queue Binding AEM parses the topics and dynamically call the target API with the correct path (+ if you want with some parameters dynamically). I have the domain name in the 3rd segment of the topic and use it in a generic queue binding in my RDP. The 6th segment of my smart topic is the object ID.
FIGURE 5 – Dynamic Queue Binding with Substitution Expressions
Post Request Target : /rest/${topic(3)}?qs_parameter_objectID=${topic(6)}
In this example function ${topic(3)} parses the topic’s 3rd segment as the domain.
Our topic was :
out/s4hana/customer/created/tr/ABCD123
and also we get the object ID from the topic and send it as querystring parameter.
Then my target API /rest with different endpoints like customer, product, order will be invoked dynamically with below paths. (even by adding querystring parameters if required)
https://YOUR_TARGET_HOST:PORT/rest/customer?qs_parameter_objectID=ABCD123
https://YOUR_TARGET_HOST:PORT/rest/product?qs_parameter_objectID=ABCD123
This way you would end up with a dynamic design like the one in the below figure.
FIGURE 6 – Dynamic topics to multiple dynamic endpoints
To extend the scenario with new endpoints & domain objects; the only steps required would be publishing to the correct topics from S/4HANA and create a new endpoint in the target application.
In this blog I tried to demonstrate how to call REST endpoints dynamically via using the topics published from upstream(source) applications such as S/4HANA.
With substitution expressions, you have multiple ways to dynamically generate URLs to invoke target systems. For this, Advanced Event Mesh provides options like user-properties and using predefined parameters via parsing them with Substitution Expression Functions like we do in this post.