Skip to Content
Technical Articles
Author's profile photo Avinash Vaidya

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

Assigned Tags

      6 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Alessandro Cagnetti
      Alessandro Cagnetti

      Hi,

       

      Are you going to cover Advanced Event Mesh as it has been released summer 2022 and cover many more use cases (integration and deploy to hybrid environments and more Enterprise grade features like Event Portal)?

      Author's profile photo Avinash Vaidya
      Avinash Vaidya
      Blog Post Author

      Hello @acagnetti

      Currently I am focussing only on Event Mesh and Integration Suite. But in future yes, I will be exploring advanced event mesh as well.

      Author's profile photo Lamia FARHAT
      Lamia FARHAT

      Hello Avinash Vaidya

       

      This is an excellent article actually ..

      However I guess the part of S4 Hana communication with Event Mesh is missing .. What would be your recommondation for such a complete architecture if we are in S4 on premise version 2021 ? And we need to send/receive  "Custom" data event for S4 Hana ?

      I have used rest calls but not sure if it's the optimat way .

       

      Kindest Regards

      Lamia

      Author's profile photo Avinash Vaidya
      Avinash Vaidya
      Blog Post Author

      Thanks Lamia.

      As per documentation, AMQP and REST both should be fine to use if you are securing your endpoints with proper security.

      MQTT is more light weight designed for low bandwidth.

      There is a blog series which I thought will be helpful to you - https://blogs.sap.com/2021/05/31/business-events-in-s-4hana-on-premise-system-triggering-custom-change-pointers-and-custom-event-on-custom-table-part-1/

      Author's profile photo Lamia FARHAT
      Lamia FARHAT

      Hello Avinash

       

      Thanks a lot for your reply

      That blog is useless since we are in 2021 why ? because simply we cannot create custom topics in S4 hana it's something I guess added in the cloud version and on the premise one starting from 2022 .

      For the rest it's fine right but the thing is that S4 hana should be always checking if new data arrived in event mesh and handle it which is somehow ressource consuming ..

      Kindest Regards

      Lamia

      Author's profile photo Saurabh Kumbhare
      Saurabh Kumbhare

      Standard Event driven is fine.. Can I create custom events? Yes, this is also fine... Can I use FEH yes, so this is also fine. What about custom FEH... SAP says you need to pay for using custom FEH. Has SAP thought of providing each and every functionality as a standard? No.. So the customers want to implement custom functionality and they want to implement custom FEH.. What should they do.. SAP has left only one option I. E customers pay or implement half baked functionality.

      Where I am getting to is - SAP needs to make sure the product is atleast 80-90% fine without asking for money for implementing custom FEH..

       

      I know this is not well explained but you get the point if you know what I mean.. ....