Event Driven Architecture with Event Mesh – Part-1

Introduction

This is the continuation of my previous blog, where I explained how to create entity relationships in CAP/CDS with a working example of a very useful scenario observed in enterprise applications.

In this blog, I will take the same use case further by enhancing and integrating it SAP Event Mesh.

What is Event-Driven-Architecture (EDA) and Why we need it?

As enterprises grow in size, there arises a need to cater to varied software applications, systems and processes to perform daily tasks in an automated and optimized way. As number of software applications grow, organization must develop a communication strategy but without overhead on the systems and the underlying infrastructure. As systems evolve, point to point communication can become bottleneck in many scenarios. Decoupled/Asynchronous communication helps to improve the performance and scale the software landscape.

That is where the event-driven-architecture comes to the rescue.

I will highly recommend going through this 10 minutes tutorial. to understand the basics of EDA.

A typical use case in an organization can be diagrammatically explained below

Figure-1

In the above diagram,

1. A change in S/4 HANA creates a data event.
2. Event is queued in Event Mesh.
3. Business application consumes the event from the queue to get data updates.

All this is event driven and helps to reduce the business applications to constantly poll or request for data irrespective of any change. Think about it from a large scale perspective and you will empathize the benefits.

What is an Event and what are the types of events?

Event is a change in the state of the business entity in a software system.

Types:

1. Notification Events – In this type of event, source system triggers a notification which indicates data change and the target system which is interested in this change, will then invoke a API call to get the complete set of data from source system.
2. Data Events – In this type of event, source system publishes the complete data set of the business entity which has changed which is used by the target system.

Of course, there are some pros and cons of the above two approaches. One should take a calculated decision based of the use case to choose any one of the above event strategy.

For the scope of this blog, I am going to showcase a data event.

Now as we had a brief introduction about event driven architecture, purpose and types, let us dive into our hands on part of the blog.

Let us break down the tasks which I am going to perform.

1. Design thinking.
2. Create an event mesh instance on SAP BTP and create a queue.
3. Quick test with POSTMAN.
4. Integrate event mesh with CAP project and send payload.

Sounds cool right?

Task-1: Design thinking

Take a look at a simple high level integration diagram.

Figure-2

I have divided the complete use case in 3 parts. We are going to perform parts A and B in this hands on.

Part-A: Integrating event mesh instance in CAP project.

Part-B: This is the pre-cursor for Part-A, where we will set up event mesh service on cloud and make it ready to be consumed by consumer (in this case it is the CAP project)

Part-C: I will enhance this project to create a consumer for the messages and that will be an API exposed from Integration Suite. Part-C is future scope. So, STAY TUNED for my next blog.

Task-2: Create an event mesh instance on SAP BTP and create a queue

1. Login to your sub account.
2. Go to your dev space
3. On right hand side pane, select “Service Marketplace” under “Services”
   

   Figure-3

4. Click “Create”.
5. Add the below service descriptor with unique namespace, topic and queue rules.

   {
       "options": {
           "management": true,
           "messagingrest": true,
           "messaging": true
       },
       "rules": {
           "topicRules": {
               "publishFilter": [
                   "${namespace}/*"
               ],
               "subscribeFilter": [
                   "${namespace}/*"
               ]
           },
           "queueRules": {
               "publishFilter": [
                   "${namespace}/*"
               ],
               "subscribeFilter": [
                   "${namespace}/*"
               ]
           }
       },
       "version": "1.1.0",
       "emname": "taskmanager-events",
       "namespace": "sap/taskmanager-events/event-mesh"
   }​

6. This will create a message client with taskmanager-events as the instance name.
7. Once the instance is created, it will show up in your dev space. Do not forget – Create a service key.
   

   Figure-4

8. Once the service key is created, open the event mesh dashboard and you will be able to see a message client with the name – taskmanager-events
   

   Figure-5

9. Now event mesh instance is set. Let us create queue.
10. Go to the Queues tab. Click on Create button and enter the queue name. For example – use-registration . For now keep the rest of the settings as default.
    

Figure-6

All set! You have successfully provisioned event mesh instance and created a custom queue.

Task-3: Quick test with POSTMAN

1. Open the service key which you created in task-2.
2. Serach for protocol – httprest
3. Use the token endpoint for fetching the oauth token.
   • grant_type=client_credentials
   • response_type=token
   • In the Authorization tab, select type as Basic Auth
   • Enter Username as the clientid from the service key for protocol httprest
   • Enter Password as clientsecret from the service key for protocol httprest
4. Once you get the token, use it as Bearer token while sending the request.
5. Create a new POSTMAN request.
6. Use the uri from the service key for the protocol httprest 
7. Append with “/messagingrest/v1/queues/<name of the queue>/messages“
8. Remember to replace / in the queue name with “%2f”
9. Add and test JSON request.
10. You should see the message in the event mesh queue as shown below
    

Figure-7

Task-4: Integrate event mesh with CAP Rest Service

1. Open your CAP project in Business Application Studio.
2. Open manifest.yml and add taskmanager-events, event mesh service. This will create a binding of our CAP project with the event mesh service

   applications:
   - name: task-manager
     path: srv/target/task-manager-exec.jar
     random-route: true
     services:
     - taskmanager-hana
     - taskmanager-xsuaa
     - taskmanager-events
   ​

3. Add enterprise messaging dependency in the pom.xml as shown below

   <dependency>
       <groupId>com.sap.cds</groupId>
       <artifactId>cds-feature-enterprise-messaging</artifactId>
       <version>${cds.services.version}</version>
   </dependency>​

4. Add messaging service in the application.yaml as shown below

   ---
   spring:
     config.activate.on-profile: cloud
   cds:
     datasource:
       auto-config.enabled: false
     security:
       mock:
         users:
           - name: taskmanager
             password: admin123
     messaging:
       services:
         name: "taskmanager-events"
         kind: "enterprise-messaging"
         queue: 
           name: "user-registration"
   ​

5. Push the application to cloud foundry.
6. You should see a binding created for the task-manager application under taskmanager-events event mesh service.
7. You can also see the details by executing the command – cf env task-manager
8. Open the UserService handler service which we created in previous blogs. Observe the methods carefully. I have refactored and enhanced it.

   import com.nimbusds.jose.shaded.json.JSONObject;
   import com.sap.cap.taskmanager.util.TaskManagerUtil;
   import com.sap.cds.services.cds.CqnService;
   
   import com.sap.cds.services.handler.EventHandler;
   import com.sap.cds.services.handler.annotations.After;
   import com.sap.cds.services.handler.annotations.Before;
   import com.sap.cds.services.handler.annotations.ServiceName;
   import com.sap.cds.services.messaging.MessagingService;
   
   import org.slf4j.Logger;
   import org.slf4j.LoggerFactory;
   import org.springframework.beans.factory.annotation.Autowired;
   import org.springframework.beans.factory.annotation.Qualifier;
   import org.springframework.stereotype.Component;
   
   import cds.gen.adminservice.User;
   import cds.gen.adminservice.User_;
   
   @Component
   @ServiceName("AdminService")
   public class UserService implements EventHandler{
       
       Logger logger = LoggerFactory.getLogger(UserService.class);
   
       private static final String PASSWORD_PREFIX = "Welcome";
   
       @Autowired
       @Qualifier("taskmanager-events")
       MessagingService messagingService;
       
   
       @Before(event = CqnService.EVENT_CREATE , entity = User_.CDS_NAME)
       public void beforeCreate(User userData) {
   
           String otp = PASSWORD_PREFIX + String.valueOf(TaskManagerUtil.generateRandomNumber()) ;
   
           userData.setOtp(otp);
   
           logger.info("Generated default otp for {}", userData.getFirstName());
   
       }
   
       @After(event = CqnService.EVENT_CREATE , entity = User_.CDS_NAME)
       public void afterCreate(User userData) {
           
           JSONObject payload = new JSONObject();
   
           JSONObject jsonObject = new JSONObject();
   
           jsonObject.put("firstName", userData.getFirstName());
           jsonObject.put("otp", userData.getOtp());
   
           payload.put("data", jsonObject);
   
           logger.info("Sending message to the queue");
   
           messagingService.emit("sap/taskmanager-events/event-mesh/user-registration-topic", payload);
   
       }
       
   }
   ​

9. If you observe the above handler class, I have
   • Injected messaging service
   • Used the emit method to send message to the topic with name – user-registration-topic
   • Coded beforeCreate() method which generates OTP.
   • Coded afterCreate() method which sends the OTP to the topic.
10. You might be thinking, how the message will reach our queue as we are sending it to a topic. (This is a very common scenario where S/4 HANA events can only be sent to topic)
11. The solution to it is – Queue Subscription
12. Go to the event mesh dashboard and eventually to the queue which we created.
13. Click on the Actions.
14. Here you can enter the subscribed topic name as shown in the below diagram
    
15. That is it. Test the Rest API by creating a new user as demonstrated in blog. Sample request is shown below

    {
        "firstName": "John",
        "lastName": "Doe",
        "email": "john.doe@remindme.com",
        "phone": "9803099878",
        "userRole_name": "Admin"
    }​

16. This will create a user is USERS table with OTP and then send first name and OTP to the message queue
    

Figure-9

Conclusion

This blog will surely help you understand the concepts of event mesh, how hassle free it is to set up SAP event mesh on BTP sub account and start implementing it as one of the important communication strategy in the enterprise application landscape.

In continuation of understanding event mesh, I plan to integrate SAP Integration suite as a consumer of the messages from event mesh. Stay curious! Keep learning!

To get more updates about this topic follow the below pages

1. Blogs
2. Q&A

Feel free to “like“, “Share“, “Add a Comment” and to get more updates about my next blogs follow me – Avinash Vaidya