[Blog Post] Enable SAP Cloud Integration Suite to Consume Messages from SAP Event Mesh Service

Authors: Vipul Khullar & Ayush Kumar

Previous blog posts in this series:

Introduction

In the previous blog posts, we saw how we can communicate between different CAP-based microservices using the SAP Event Mesh service to achieve true asynchronous communication and how the CAP framework facilitates the same.
In this blog post, we will try to achieve the same by leveraging SAP Cloud Integration Suite by acting as a middleware between the two microservices, which will be useful, especially in cases where specific event handling is not desired within the 2nd microservice (communication is intended via API only).

Prerequisites:

To execute the following scenario, you need.

  • BTP account (trial account would also work).
  • Event Mesh subscription for your subaccount.
  • Service key for the Event Mesh instance.
  • Cloud Integration Suite subscription for your subaccount.
  • Local Setup for CAP JAVA (if you already have a CAP application initialized upgrade the CDS service version to 1.22.1 or higher, else you might face runtime errors complaining about bean error).

Scenario:

Architecture%20Diagram%20for%20Event%20Mesh-based%20Communication%20Between%20two%20microservices%20via%20SAP%20Integration%20Suite

Architecture Diagram for Event Mesh-based Communication Between two microservices via SAP Integration Suite

In this scenario, we have created two CAP-based microservices on BTP and we have tried to set up an event-based communication between the services with the help of Event Mesh and SAP Cloud Integration Suite. We have tried to leverage the AMQP adaptor in cloud integration flow to listen to the event raised by the first microservice and then leveraged the API endpoint in 2nd microservice to replicate the data to the same.

Steps in SAP Event Mesh:

  • Open the SAP Event Mesh Message Client UI.
  • Select your instance (Message Client).
  • Create a queue with any name of your choice.
    • Note: you can use the default queue as well which is generated by the CAP Application at run time.

Note: For demo purposes, we will use the queue name as emDataMappingQueue and subscribe to the same topic as used in the previous blogs.

  • Now run the event-producer application which we have created in the previous blog. In the Event Mesh UI now you will see the messages are incremented in both the queues that are the CAP-created queue and the queue created by us.

Steps in SAP Cloud Integration:

Integration%20Flow

Integration Flow

  • Open the SAP Cloud Integration Suite and navigate to security material. Create an oAuth2.0 client Credentials using the SAP Event Mesh instance key created in the previous blogs. (We will use this credential configuration to connect to the Event Mesh)
  • Create a new artifact.
  • Now connect the sender to the start using AMQP->WebSocket adapter.
  • Now again open the key and under the AMQP section, you will find all the values which are required to configure AMQP.

Event%20Mesh%20Instance%20Service%20Key

Event Mesh Instance Service Key

In the Processing section:

Event%20Mesh%20Configuration%20in%20Cloud%20Integration%20Flow%20%u2013%20Processing%20Section

Event Mesh Configuration in Cloud Integration Flow – Processing Section

In the Connection Section:

Event%20Mesh%20Configuration%20in%20Cloud%20Integration%20Flow%20%u2013%20Connection%20Section

Event Mesh Configuration in Cloud Integration Flow – Connection Section

  • Create an XSLT mapping to change the data in the format expected by the consumer.

Input:

Now run the Event Producer application and create a post request to post student details as done in the previous blog post.

Post%20Request%20to%20Create%20a%20Student%20Record

Post Request to Create a Student Record

Output:

Now, let’s check the trace corresponding to the event raised, in Cloud Integration Suite.

Incoming%20Event%20Payload

Incoming Event Payload

Payload%20After%20Mapping%20to%20the%20New%20Data%20model

Payload After Mapping to the New Data model

Reading%20Consumer%20Microservice%20After%20Update

Reading Consumer Microservice After Update

We observe that now the data has been mapped according to the consumer microservice which can now consume this information without knowing the data model of the event producer.

Conclusion:  In this blog post, we presented a use case where we can enable multiple microservices which may or may not have similar data models to communicate with each other without having to modify anything within the microservices. We achieved this with the help of SAP Event Mesh and SAP Cloud Integration Suite.

In the next few blog posts, we will cover how we can raise and consume business events from an SAP S/4HANA system using SAP Event Mesh and how we can consume them in SAP Cloud Integration Suite or any other application on BTP.

Please do like the blog post if you find the content helpful. Also, do share your comments and inputs, if any.