Do you know that you can take your existing Request-Reply(Sync) scenarios and extend them with Event Driven (Sync+Async together) while keeping the original setup and opening a gate to various scenario options with a very little effort :
Advanced Event Mesh with its MicroGateway feature enables you to do so.
In my previous blog post I showed how easy it’s for Advanced Event Mesh to receive HTTP(REST) based requests and publish to multiple subscribers and consumer applications with multiple protocol possibilities. This is a way of async communication when (usually) the producers do not expect a response other than an acknowledgement of receipt of message back from the consumers(in fact the broker).
Additionally there exists a Request-Reply (Sync) world with distinct advantages and disadvantages. Both of these approaches exist for specific reasons, so it is advisable to leverage the advantageous aspects of each one-possibly together.
It’s possible to have an architecture while our producer and consumer communicates synchronously; we can utilize the same mechanism to add more consumers to the scenario (in fact creating various different use-cases) effortlessly and without compromising the initial objective of request-reply(sync) communication. This is made possible by using Advanced Event Mesh, specifically through the configuration of broker’s Microgateways mode.
Microgateway Mode
With microgateway mode, Advanced Event Mesh allow clients to send their REST requests to the REST providers via Request-Reply and routing back the responses to the originating clients by being an intermediary (gateway) between them.
You shouldn’t obviously expect to have all the capabilities that API Gateways provide due to the fact that Advanced Event Mesh is not meant for that; however this doesn’t mean that you do not have many additional capabilities that leads you to answer multiple use-cases as a solution & technical architect.
Except for the ones that I will be describing in this blog below, (and more to come later), you will have features like Authentication, Authorization of your REST calls, having higher performance via different mechanisms, combining the request-reply based calls with pub-sub eventing and having multiprotocol message delivery to different types of subscribers / consumers. We’ll come to those step by step later in this and following blogs..
In this blog, I will show you in two parts, with a scenario;
Part A - How Advanced Event Mesh handles requests as a gateway for REST based microservices
Part B - Once done, how to extend these scenarios with additional capabilities that Event Driven Architecture and Advanced Event Mesh provides
In order to focus on the technical aspects of Advanced Event Mesh, I will keep the scenarios very simple and demonstrate only the necessary parts.
MicroGateway Scenario
In part A of the scenario, we have our fictional manufacturing company, having an S/4HANA system. Once materials are produced, an external warehouse management system (named WM007) is informed with the item produced and the quantity-produced via a REST based service call(steps 1a,1b below). WM007 then returns back with a status and a confirmation number to S/4HANA.(2a, 2b) As we avoid point-to-point connections from/to our S/4HANA system to the other applications, we should consider using an Integration Broker, A Gateway for this traditionally. In our case we’ll use Advanced Event Mesh in order to achieve this and extend our options beyond that.
FIGURE 1 – Advanced Event Mesh as a Gateway
How are requests handled in Microgateway Mode and turned into topics
Whenever Advanced Event Mesh receives REST request (if microgateway is enabled), request is handled by adding HTTP method to the beginning of the topic and converted to an internal message that way.
For instance in messaging mode, when you make a POST request to <AEM_URL>/mytopic/level2/level3 it converts to a topic as “/mytopic/level2/level3 while in microgateway mode it corresponds to a topic POST/mytopic/level2/level3 which your endpoints should subscribe to.
Enabling Gateway Mode
In order to use microgateway feature, you should enable REST Gateway mode in the Message VPN as below.
Go to Message VPN > Services switch to Edit mode, find and change the “REST Service Mode” to Gateway (default is Messaging)
FIGURE 2 – Changing Service Mode to “Gateway”
Then you need to configure the outbound REST components for the broker.
This part is similar as in my previous blog when I describe REST Connectivity.
Advanced Event Mesh has Multiple Ways for Publishing/Consumption: REST is just an example
For REST delivery you would require:
- A REST Delivery Point (RDP)
- A Queue where RDP is bound to (via Queue Binding)
- A REST Consumer which defines where and how request is sent to the destination (host)
STEPS
- Create a queue named q/msgw/stage/wm007
FIGURE 3 – Queue for Rest Delivery Point
- Add a subscription to this queue
!! Pay attention the the part “POST” as a part of topic name
FIGURE 4 – Topic Subscription for the Queue
- Create a RDP
FIGURE 5 – Rest Delivery Point
- Create a REST consumer and enable
FIGURE 6 – Rest Consumer
- Create a queue binding for your queue
FIGURE 7 – RDP Queue binding
FIGURE 8 – Path and other attributes of binding
In the end operational state would be like below if your consumer and queue binding parameters are correct.
FIGURE 9 – RDP Summary
After changing the message VPN service mode to Gateway, the same service call to the path : /msgw/prodorder/completed/v1/uk will lead to below topic name. As mentioned now our topic (subscription) should be like below.
FIGURE 10 – Topic subscription for the queue (for gateway mode)
TESTING OF THE SCENARIO
We can trigger the scenario from S/4HANA via various alternatives (starting with an event, from a program(report)..and make a REST call inside.). I do not go to details for this part as there are various nice posts / blogs about making a REST call from ABAP.
Reminder: in our scenario, Advanced Event Mesh endpoint is protected via TLS + Basic Authentication. REST call should be configured considering this.
I trigger the scenario from an ABAP program/report sending the below payload:
FIGURE 11 - Payload from S/4HANA request
And in my report(program) in S/4HANA, I get a response back with confirmation number and status, meaning our REST service from WM007 responded back to our sync request with status code 200.
FIGURE 12 – Response back from the REST service (WM007 App)
Voilà! We use Advanced Event Mesh as a Gateway (in this case passing the message to the WM007 application (enabling the Sync use-case).
Although we only use authentication as an additional feature in this “pass-through” scenario; in fact Advanced Event Mesh brings more value than only enabling a REST-to-REST sync communication, such as storing the message in the queue and calling target system again in case of errors in communication, with options to dynamicly build topics / URLs etc. I am planning to describe other additional things that you can do with other features of Advanced Event Mesh in the following blog posts but for now let’s focus on how easy to extend our scenario to async pub-sub model and multiple other consumers.
PART B - Extending Request-Reply scenario to Request-Reply + Publish Subscribe
In part B, as the next step, we’ll extend the scenario with very minimal effort and without changing the flow of the original scenario (and without any changes in the existing consumer and/or producer). We’ll notify multiple additional applications, at the same time with having options to dynamicaly route messages only to the interested applications, handle the errors, increasing the perfomance while doing these with event-driven approach and Advanced Event Mesh capabilities.
Now our additional objective is to inform multiple additional subscribers(consumer applications). While doing this, we will have the ability to dynamically route only the messages being interested and only to the interested applications based on the filters, address connectivity issues as we store the messages with retry capabilities(not in this post) and performance improvements as we can register multiple consumers to our queues if we require to do so. All of them would be accomplished through an event-driven approach and leveraging the Advanced Event Mesh capabilities.
Extended Scenario Flow & Architecture
FIGURE 13 – Architecture for Extended Scenario (One sync consumer, multiple async consumers and subscribers)
Business use case for extended scenario
Assume that we have another application (E-Commerce application called ECOM123), which wants to be notified as well once the production order is completed. (Because they want to remind their customers). Should we create another point-to-point scenario, another integration scenario over an integration broker?
The answer is “No”. The only thing that we need to do is creating a queue for them in Advanced Event Mesh and they will receive exactly the same information once the production order is completed if they subscribe to the correct topic. We can even filter the notifications very easily by country as we put the country code to the URL / topic that we used. (just create a queue, create a topic subscription and let ECOM123 application to connect to that queue or you can push the data to their endpoint)
Steps to extend the scenario
Create a queue named : q/out/ecomm123/prodorder for ECOMM123 to subscribe to.
FIGURE 14 – Queue for E-Commerce Application
The subscription might be one of below
POST/msgw/prodorder/*/v1/>
POST/msgw/prodorder/*/v1/uk
FIGURE 15 – Subscriptions for the queue
Now we are interested in not only completed productions orders but the products with other statuses as well.
remember our topic published was POST/msgw/prodorder/completed/v1/uk but it could also be POST/msgw/prodorder/started/v1/uk and still in this case ECOMM123 application is interested if it’s published by S/4HANA.
Then lets send the production order data from the S/4HANA.
And we observed that 2 things have happened:
- S/4HANA received a response back from WM007 application again with the new confirmation number. (because now it’s another production order)
- . Our queue for ECOMM123 application gets the same message and it’s ready to be consumed asynchronously.
FIGURE 16 – A copy of the message is received by E-Commerce Application (before pushing it to the Application end-point)
How easy & extensible it is, isn’t it?
Once the consumer (ECOMM123) application subscribes to the queue/topic, it will start receiving these orders directly. (or in our case architecture we push the information to the application via webhook)
Nothing is changed in the previous scenario where S/4HANA is calling the WM007 application synchronously as usual. S/4HANA, at the same time is also publishing the production orders to the subscribers without doing anything (and without even knowing who is interested in – how many consumers etc.) which is the idea of publish – subscribe pattern of event driven architecture.
That means you can add more consumers similarly with the same approach. For instance you can have an iFlow in BTP Cloud Integration to subscribe* to a queue and receive the same information, in order to later enrich it for further steps with different variations, still original publisher being loosely coupled with the consumers. (pub-sub architecture)
*This subscription could be done to the same or similar topic and the data could be received through AMQP Adapter from an iFlow(as shown in the architecture). I do not provide the details of this in the blog as there are very good blogs giving more details for AMQP Adapter.
In this post, with a basic scenario; I tried to combine the microgateway feature of Advanced Event Mesh with its well-known messaging and routing capabilities in order to show how easy & with limitless options the use-cases could be realized. As mentioned within almost the similar architecture, there are several other features that you can also use together. I intend to explore these features in detail in my upcoming blog posts.
- SAP Managed Tags:
