Introduction:

What is SAP 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. Events are associated with a topic to achieve the publish-
subscribe model. Topics are managed through queue subscriptions. SAP or non-
SAP applications can subscribe to the topic via queue subscriptions to access
messages from the event source. SAP Event Mesh enables a sending application to
publish messages to a topic that directly sends the message to the queue to which it
is bound.

Event Mesh Use Cases

Microservices Integrations, E-commerce, Customer Support, Financial Services, IoT

Connectivity.

Business Benefits Of Event Mesh

• Real-Time Responsiveness

• Improved Customer Experience

• Reduced Operation Costs

• Developer Productivity
 Event Mesh Flow Chart

Event Mesh Setup

Required:

• SAP BTP (It can be no longer used on a trial account)

1- On SAP BTP Cockpit, we must search and select Event Mesh from Service
Marketplace.
 Service Marketplace

2-Later, create subscriptions of the Event Mesh.

Subscriptions
3-After creating subscription, we need to define the roles of Event Mesh to our user.

Security--> Role Collections

Role Collections

4-Now, we will go to : Security--> Entitlements

• Then, search Event mesh and add as "service plan".

 Entitlements

5-Create Instance of Event Mesh

• We must click "Create" button.

 Instance

• Click on next and put instance descriptor JSON.

{
"emname": "S4S",
"namespace": "sap/S4HANAPB/S4S",
"options": {
"management": true,
"messaging": true,
"messagingrest": true
},
"resources": {
"units": "10"
},
"rules": {
"queueRules": {
"publishFilter": [
"${namespace}/*"
],
"subscribeFilter": [
"${namespace}/*"
]
},
"topicRules": {
"publishFilter": [
"${namespace}/*"
],
"subscribeFilter": [
"${namespace}/*"
]
}
},
"version": "1.1.0"
}
• Click on Create and you will have created Instance.

Instance View

Instance of Event Mesh

6-Now, we click on the Event Mesh under Subscriptions.

Click on Go To Application

7-You will access the as name of S4S that we created on a new page.

Message Clients

8-From here, we will take steps to ensure that the Event Mesh can send requests to
CPI. First we need to create a queue.
Create Queues step 1

Create Queues Step 2

 Create Queues step 3

9- I indicated that the interaction between Event Mesh and the CPI can be facilitated
using either HTTP or AMQP. We will proceed with HTTP. To enable this, CPI will
also establish Event Mesh communication over a designated CPI link. This CPI link
must also be specified within the Communication Scenarios of S/4 Hana(module-
side). This is because it will gain access to the established queues through Event
Mesh Communication Scenarios.

• Now, we will create "Webhooks Subscriptions".

Create Webhook Step 1

 Create Webhook Step 2

• Then we will click Create.

Once the webhook is created, the event Mesh process is completed. What's
important after that is integration development. After triggering Event Mesh from S/4
Hana, how the structure will reach CPI should be observed. We will proceed with an
example scenario.

You can take a look at this blog for detailed information about Webhook and Queue
parameters.
CLOUD PLATFORM INTEGRATION
Certainly, let's create a scenario for sending information from S/4 HANA to a 3rd-
party system via CPI when a new product is created or modified.

Scenario: Sending Product Updates from S/4 HANA to a 3rd-Party System via
CPI

1. Event Trigger: Whenever a new product is created or an existing product is

modified in S/4 HANA, an event is triggered.

2. Event Mesh Integration: The Event Mesh is utilized to capture this event and
its associated data.

3. Webhook Notification: The Event Mesh sends a webhook notification to the

Cloud Platform Integration (CPI) service, containing relevant product
information such as Material, BillOfMaterial and any other pertinent details.

4. CPI Data Processing: Upon receiving the webhook, CPI processes the data.
This may involve data transformation and mapping to format it in a way that
the 3rd-party system can interpret.

5. Integration with 3rd-Party System: The transformed data is then relayed to

the 3rd-party system. This can be accomplished through an API call or other
suitable integration methods supported by the 3rd-party system.

6. Acknowledgment: The 3rd-party system processes the incoming data and, if

necessary, sends an acknowledgment back to the CPI service to confirm the
receipt and processing of the product information.
 7. Error Handling: CPI should have mechanisms in place to handle any
potential errors or issues that may occur during the integration, such as data
validation errors or connectivity problems.

8. Logging and Monitoring: Throughout the process, it's important to log and
monitor the data flow and any potential errors or delays to ensure the
integration operates smoothly.

This scenario outlines the flow of information from S/4 HANA to a 3rd-party system
through CPI when a new product is created or modified. It's crucial to configure S/4
HANA, Event Mesh, and CPI appropriately and ensure that data mappings and error
handling are well-defined for a successful integration process.

S/4Hana-Event Mesh-CPI relations

First, I mentioned the need to generate a link in CPI for S/4 HANA to be able to
trigger it. You can start by creating an empty flow in CPI solely for the purpose of
generating the link. Then, you can observe what structure is received when S/4
HANA triggers it. In our scenario, the material number is the information sent from
S/4 HANA. Based on this information, an OData link is expected to be provided to
the CPI, where CPI will make a GET request to S/4 HANA based on the received
material number through the Products service.
Example Structure:

{
"type":
"sap.s4.beh.billofmaterial.v1.BillOfMaterial.Created.v1",
"specversion": "1.0",
"source": "/default/sap.s4.beh/--",
"id": "--",
"time": "2023-10-02T14:19:35Z",
"datacontenttype": "application/json",
"data": {
"BillOfMaterial": "00000034",
"BillOfMaterialCategory": "M",
"BillOfMaterialVariant": "1",
"BillOfMaterialVersion": "",
"EngineeringChangeDocument": "",
"Material": "1001008",
"Plant": "",
"BillOfMaterialHeaderUUID": "194ead30-cb27-1ede"
}
}

Based on the data received from S/4 HANA, a call will be made to S/4 HANA via
OData using the material number. This call will retrieve information related to that
specific material. From the retrieved information, the necessary data will be
forwarded to the 3rd-party system.The information retrieved via the GET method will
be sent to the 3rd-party system using the PATCH method, facilitated by a REST link.
It's important to ensure that proper data mapping is performed if needed. It should be
noted that the key focus here is to ensure that when a product is created or modified,
this information is instantly sent to the 3rd-party system for real-time updates.

For example, let's assume the 3rd-party fields are as follows:

 3rdParty fields

Note: In the mentioned scenario, the 3rd-party service (receiver service)

authenticates using a bearer token. Therefore, a separate flow for the token service
has been developed, and this service uses the token as a global variable

CPI Flow

Firstly, in order to capture the 'Material' field from the request coming from Event
Mesh, we use 'JSON to XML' conversion. The reason for holding this field as an
XPath is to dynamically extract the value of 'Material' when making a GET request to
S/4 HANA.
 Content Modifier_Headers

OData-Get Method

Considering the structure of the 3rd-party system, not all fields from the response are
needed when making a GET call. Therefore, fields should be selected based on the
3rd-party system's requirements. As 'Material' is a dynamic value, it should be
provided as a property.
 Processing Parameters

In this example scenario, a Filter has been used. The reason for this is that after
making a GET call, some unwanted fields are present in the response. These
unwanted fields were causing a 400 error when accessing the 3rd-party service.
Therefore, the issue has been resolved using a Filter.

Filter

Subsequently, mapping was performed with the sample structure of the 3rd-party
service to match the fields. After mapping, as the structure was still held in XML, an
XML to JSON converter was used since the service expected the data in JSON
format.

The final step involved storing the response headers from the GET in the
GetResponseBody Content Modifier.

Content Modifier GetResponseBody

Content Modifier GetResponseBody- Message Body

 Patch Method to 3rdParty Service

The Groovy script for Error Handling:

import com.sap.gateway.ip.core.customdev.util.Message;

def Message processData(Message message) {

// get a map of iflow properties

def map = message.getProperties();

// get an exception java class instance

def ex = map.get("CamelExceptionCaught");

if (ex!=null) {

// an http adapter throws an instance of

org.apache.camel.component.ahc.AhcOperationFailedException

if
(ex.getClass().getCanonicalName().equals("org.apache.camel.component
.ahc.AhcOperationFailedException")) {

// save the http error response as a message attachment

def messageLog =
messageLogFactory.getMessageLog(message);

messageLog.addAttachmentAsString("http.ResponseBody",
ex.getResponseBody(), "text/plain");
 // copy the http error response to an iflow's property

message.setProperty("http.ResponseBody",ex.getResponseBody());

// copy the http error response to the message body

message.setBody(ex.getResponseBody());

// copy the value of http error code (i.e. 500) to a

property

message.setProperty("http.StatusCode",ex.getStatusCode());

// copy the value of http error text (i.e. "Internal

Server Error") to a property

message.setProperty("http.StatusText",ex.getStatusText());

return message;

}
Through Error Handling, we can catch any error returned from the service.

Now we can test the service. We can request the SAP consultant to trigger it from
the module, or we can trigger it ourselves using the request we have in Postman.

Trace
 Exchange Properties

Header

S4 To Event Mesh :

Creation of SM59 destination on S/4

S/4HANA needs details such as hostname and port to connect to EMIS. These
details are specified in the sm59 destination.

Kindly execute the following transaction:

/nsm59

Choose ‘Create’
Provide a destination name and choose connection type as ‘HTTP connection to
external server’
Save.

Now, refer to the service key created using SAP Integration Suite, Event Mesh –
‘message client’ instance.

You need to refer to this service key to provide the details in the sm59 destination.
The hostname can be obtained from the ‘uri’ section under ‘messaging’

The port should be ‘443’ and path prefix ‘/protocols/amqp10ws’ for AMQP. (the first
release of EMIS only supports AMQP protocol for messaging)

In the logon and security tab, set ‘SSL’ to ‘Active’ as shown below -
Save.

Creation of Oauth client for S4

S4HANA authenticates with EMIS using Oauth2.0.

You need to execute the below transaction:

/nOA2C_CONFIG

Choose ‘Create’ and provide the necessary details.

The OAuth2.0 Client Profile as shown above needs to be ‘IWXBE/MGW_MQTT’
even for AMQP based messaging.

You can provide any configuration name, the Oauth 2.0 client ID can be found from
the service key created above under the ‘oa2’ section in ‘messaging’.

Choose OK.

Provide the client secret, authorization and token endpoint from the service key.

The authorization endpoint is not directly provided in the service key, but it is same
as the token endpoint, except that it ends with ‘/authorize’ as show below.

The Access Settings are mentioned below:

Client Authentication: Form Fields

Resource Access Authentication: Header Field

Selected Grant Type: Client Credentials

For complete details on configuring the Oauth client, kindly refer to this doc.

Creation of a channel using form fields on S/4

Kindly execute the below transaction to configure the channel:

/n/IWXBE/CONFIG

Create a new channel (without service key).

At this point, it is not possible to configure this using the ‘Create Channel via Service
Key’ option.

This is currently a gap and will be addressed in an upcoming release. Please refer
to SAP Note 3461547 for any updates.

It is important to note that the above gap is only applicable for Event Mesh in
Integration Suite (EMIS).
For Event Mesh (default), the recommended way is to use 'Create Channel via
Service Key' option on S4.
Choose ‘Default’ or ‘SAP Event Mesh’.

Now the following details need to be provided –

You can provide any name to the channel.

The destination needs to be the name of the sm59 destination as created above.

The topic space needs to correspond to the topic subscription on the Queue.

The Oauth 2.0 Configuration needs to be the name of the Oauth2.0 client
configuration as created above.

Save.

Activation of Channel & Connectivity Check

Click on ‘Activate’ followed by ‘Check Connection’ to ensure that connection to Event
Mesh is successful.

Sending a Test Event using Event monitor

Kindly execute this transaction,

/n/IWXBE/EEE_SUPPORT

Choose ‘Produce Test Events’ followed by the channel.

Execute the transaction.

You can now navigate back to Event Mesh in Integration Suite, head over to the
Queues section and find the message queued! (unless there is active consumer)