Introduction
What is Event Mesh?
SAP Event Mesh allows applications to communicate through asynchronous events. Experience greater agility and scalability when you create responsive applications that work independently and participate in event-driven business processes across your business ecosystem. In this decoupled integration the producers of the events will not know the consumers of the events.
Publish business events from SAP and non-SAP sources across hybrid landscapes from the digital core to extension applications through event-driven architecture. Consume business events from SAP and non-SAP sources throughout SAP’s event-driven ecosystem including SAP Extension Suite, SAP Integration Suite, and selected inbound enabled SAP backends. Achieve reliable data transmission for extension and integration scenarios through decoupled communication.
What is Websocket?
WebSocket is a stateful protocol used in the client-server communications used to enable the application you are using to receive the data without requesting it from the server like two-way communication. It means the connection between client and server will keep alive until it is terminated by either party (client or server). Data is sent and received much faster than HTTP as HTTP has a 2000-byte overhead whereas WebSocket has only a 2-byte cost. WebSockets supports multiple data types. In SAP CI AMQP adapter supports the websocket transport protocol.
What is Webhook?
Webhooks are stateless, meaning that each event notification is independent and carries all the necessary information about the event. Webhooks are for server to server communication. Web-hooks are commonly used to perform smaller requests and tasks on top of standard API calls. Webhooks are suitable for POST/PUSH mechanism. In the Event Driven Architecture when the Producer publish the events to the respective topics, then the Queues subscribed to those topics will trigger the event data to the consumer using the Webhook instead of consumer trying to pull the events.
What is Queue?
A queue is used to store a message until it’s received by the subscribed consumer. Queue cannot process message, it is first consumer and just store message/event. If any events are published in the Queue then only one subscriber to that Queue received a message. Queues are managed and persistent. When there are no consumers to a queue, messages are stored in the queue.
What is Topic?
Topics are not managed and not persistent. A topic is created on the go when we start publishing messages to a topic, and destroyed when there are no consumers listening to that topic. If the consumer to a topic is not running when a message is published to the topic, that event will not be received. One Event Producer can publish to one Topic. One Topic can be connected to multiple queues. Multiple queues can be subscribed to one topic.
Prerequisites:
- BTP cockpit access with Event Mesh subscription.
- S4 HANA access in tcodes STRUST and SPRO
- SAP BTP IS Tenant Access with required roles/roles collection having Enterprise Messaging*.
Step-1: Add Service Plans in the Entitlements of subaccount for Event mesh along with creation of instance and subscription.
Select the standard and default service plans for the Event Mesh in the Entitlement
“Standard” for Event Mesh subscription and “default” for instance creation
In the Instances and Subscription, create the “standard” event mesh subscription and “default” instance creation on top of the cloud foundry space and runtime environment.
While creating the service instance creation the Instance Name and EMNAME in JSON file should be same along with the Namespace in required format e.g. a/b/c
Step-2: Creation of Service Key for eminstance created
The clientid, clientsecret,tokenendpoint, protocol and uri should be noted for further configurations
Step-3: Creation of new Queue in Instance of Event Mesh
Step-4: Test publishing and consuming messages on a queue. [Optional]
Select the queuename and message client name for publishing and consuming the messages.
Step-5: Creation of OAuth2 client credentials in Security Material of Integration Suite
Use the TokenEndPoint URL and ClientID and Client Secret from the Event Mesh service Key created.
Step-6: Produce the events from SAP CI into Event Mesh
A new IFlow needs to be created with either HTTPS as sender for triggering from Postman or timer based event with some message in content modifier and AMQP as receiver.
For Demo purpose we will use the HTTPS as sender and AMQP receiver with WebSocket message protocol. Host will be the URI from the service key. Port:443 Path will be the protocol from service key. Credential Name from the security material.
We can publish on topics or the queue from the AMQP(Websocket) of CI.
For topic, topic:topicname(this topicname should be subscribed on the queue created in event mesh) and for queue, queue:queuename
Test from Postman with deployed IFLOW endpoint with the clientid and clientsecret of the Process Integration Runtime service key. This is to understand how the event are published. Not a realtime scenario.
Check the CI Message Monitor for successful message to Event Mesh
Check in the Event Mesh Queue with messages count increased from 0 to 1 along with queue size.
Step-7: Consume the events from Event Mesh into CI
Consuming the events from Event Mesh into CI can be done either with websocket(AMQP) or webhook.
In this case will create a websocket(AMQP) connection by configuring a new IFLOW with HOST, Path from Event Mesh service key, Port:443 and Credential Name from Security Material.
The queue name as queue:queuename. While consuming the Events from CI its always best to consume from queue rather the topic as topic are not persisted and queues are persisted which we can use for guaranteed delivery. As the message will be consume in JSON format we can convert it into XML as required.
Once deployed the message in the queue will be consumed by the CI IFLOW
Step-8: Create Topic and upload the certificate to produce the Events from S4 HANA onto Event Mesh
The overall design for S4 HANA to publish and CI to consume can be done in two ways
A. Websocket Communication
B. Webhook Communication
Websocket is already explained in the previous steps. Will check now the Webhook communication.
On top of the created Queue in Event Mesh we need to subscribe to a Topic
Download the certificate from the Token Endpoint along with clientid and clientsecret generated from the Event Mesh Service Key
Upload the certificate in S4 HANA STRUST in SSL Client SSL Client(Standard) and add to certificate list
Step-9: Create a AMQP Channel in SPRO tcode
Goto SAP Reference IMG=>ABAP Platform=>Enterprise Event Enablement=>Administration=>Channel Connection Settings=>Manage Channel and Parameters
Use the service key option to create the AMQP channel
Check the connection and activate the channel
Step-10: Create outbound binding on the created AMQP channel
Select the created channel and click on outbound binding and provide the topic name.
Step-11: Create webhook in the SAP Event Mesh
In order to create the webhook we need any HTTPs URL to be build and deployed. In our case we will create a new IFLOW with HTTPS as sender in CI itself.
Create a webhook with queue name, CI deloyed IFLOW endpoint and authentication with client id and client secret of the CI Process Integration Runtime
Testing:
Testing the Event from S4 HANA onto Event Mesh which will push through the WEBHOOK on CI.
Goto SAP Reference IMG=>ABAP Platform=>Enterprise Event Enablement=>Test Tools=>Produce Test Events
Select the channel name created and trigger the Event.
Check the CI Monitoring whether the event triggered from S4 HANA to Event Mesh was pushed onto CI through Webhook
Question 1??? What happens for triggered event from S4 HANA(Producer) is published on one topic in Event Mesh and there are both Websocket Queue Consumer to CI and Webhook Queue Consumer to CI with same topic/queue details.(Ideally it will not be the case in realtime but for testing will explore that case here)
Answer!!! As the queue consumer will be in continuous consumption mode it will be more quick to take the message in rather waiting for the webhook to trigger the message to the configured HTTPs endpoint.
Evidence***
The deployed consumer IFLOW is in continuous consumption mode. Also the consumer should be subscribed from Queue instead of Topic for persistence.
Question 2??? What happens when there are some errors(mapping/runtime) during the consumer receiving messages from the Event Mesh Queue? Will the message be deleted from Queue immediately or it will persist till the successful consumption?
Answer!!! The message in the queue will be present till the consumer receives and process it successfully. During that time the consumer will continuously retry.
Evidence***
When the consumer IFLOW intentionally failed for some content exception the message in the queue was still persisted and the IFLOW was automatically retried almost 8770 times in less than a minute.
