SAP BTP Advanced Event Mesh : SAAS Applications
In last decade, APIs have become a core component in integrating different systems (Internal or External). Adoption of APIs has reduced the need for point-to-point integrations. The one-time development efforts behind APIs are more efficient and use of APIs has enabled automation to reduce manual interventions.
Organizations are now leveraging APIs and adopting Event based architecture as a value generating method. Events consumption helps to maximize the potential of APIs by reducing unwarranted GET calls. Consumers decide what data to consume and when that happens, can possibly orchestrate / (or) automate processes in near real time.
Along with my colleague Umang Mehta, I received opportunity to understand, explore and implement an Event based Pub-Sub model using SAP BTP Advanced Event Mesh (AEM). SAP BTP service offerings are maturing and are in better shape since they were introduced early in this decade. The BTP services like SAP Cloud Integration, Fiori, and ABAP runtime promote efficiency & productivity, and the new innovations that are part of the SAP roadmap are exciting.
With S/4 Hana, we understand that SAP recommends adopting an event-driven architecture. Most organizations are planning and will perform S/4 Hana upgrades between 2025 and / or 2027. This is a good opportunity to release the value of APIs and implement the event- based Pub-Sub model for new integration requirements or to refactor the old point to point integrations.
We are sharing two integration scenarios/patterns which are likely part of an event-based architecture from the SAP perspective:
- SaaS applications
- On-premises applications
Pattern 1: SAAS Applications
I will focus on our experience using AEM between SaaS applications. In the scenario that we are implementing, a SAP SaaS product is a producer or publisher of events. These events will be consumed by one or more non-SAP SaaS applications.
SaaS applications from SAP (like SuccessFactors, Ariba, Concur, and Fieldglass) can generate events that we can use to notify downstream systems using SAP AEM. These SaaS applications can directly connect and publish events on SAP AEM.
If there are limitations to publish events directly or a limited event count, the SAP Cloud Integration (CI) service can be utilized to consume events from SaaS applications and publish them on SAP AEM topics. SAP CI can push events using a REST endpoint or an AMQP connection into SAP AEM.
A developer must perform two types of configurations based on the usage: Topics and Queues.
Topics help us to classify the information that is part of the event message, such as name, employee identification, country, etc.
Queue can be defined for each consuming application that will receive the event message associated with respective Topic. Queues can subscribe to more than one topic and will receive messages for all topics matching their subscriptions.
The naming convention to define Topics and Queues are an important consideration when performing the configuration in AEM. The convention used will help during exception- or error-handling processes. The dead letter queue or replay mechanism (explained later in section ) will be easier to handle and can more readily reprocess events if a naming convention is followed diligently.
Consuming App Connectivity Options
Using AEM, the event notifications can be pushed or pulled by subscribing to the queue. We can push data using a REST or a Webhook connection to the subscribing consumer apps. Other protocols that can be used to consume events by apps are AMQP, JMS, and MQTT.
Exception- and Error-Handling Mechanisms:
When events are received by AEM, while a consuming app is down, we can configure a dead letter queue, which can hold the events. This will ensure events are not lost due to issues at the consumer end. Queue size should be configured judiciously, to address overload situations during long downtime.
A good feature that AEM has is the replay mechanism, which enables us to replay events based on their timestamp or from the dead letter queue. With this capability, error- or exception-handling scenarios can be addressed.
Multiple Cloud Providers
If consuming applications are deployed on different cloud providers like Azure, AWS, or GCP, the event broker will play a very important role. The event broker receiving events (on SAP AEM) will share details of topics and queue with other brokers available in the landscape. Any event received by the respective event broker, will be routed to other relevant event brokers available near the cloud provider where the application is hosted. If any event broker is down due to some issue, other brokers will act and receive the events, which, in turn, can be routed as per the configuration.
The multiple event brokers in the landscape will help to create a mesh, and thus follows the suite of Event Mesh concept.
Listed below are some advantages and disadvantages we have seen in using event-driven architecture.
-The consumer applications hold the power to decide what data to consume and when to do so.
-It is eliminating the continuous API polling by consumer application.
– The architecture limits the use of point-to-point integrations in the landscape, thereby lowering development and support costs.
-Improved Scalability by combining the event & API capabilities.
-Transformation or business logic (simple) must be implemented by consuming applications.
-Based on the licensing model, the queue size will be limited to hold notification events.
Blog by Umang Mehta on Integration pattern II: Trigger Events from On Premise ERP system:
This topic was presented at SAP Inside Track event at Kolkata on 17th June 2023. This event was organized by Moumita Saha(LN), Pradipto Kumar Saha, Sandeep Mukherjee, & SUBHASREE GHOSH with the support of many volunteers.
For more details of event refer: https://blogs.sap.com/2023/06/30/3.-sap-btp-at-sap-inside-track-kolkata-2023/