SAP helps you to build an intelligent enterprise by providing the freedom and flexibility to build, manage, and deploy your applications with tailored integration capabilities. One of these capabilities is Enterprise Event Enablement for the development of event driven applications.
This blog is the first post from a blog series to introduce events in enterprise architecture, and the possible ways to produce and consume an event in SAP BTP ABAP Environment. With the release 2208, all steps from raising to consuming events can be carried out on the ABAP Platform directly. Here, I will start with the basics of event-based communication. Then, in the upcoming blogs, I’ll explain in detail how you can produce an event using a natively integrated RAP application, supporting all RAP qualities like extensibility and testability also consuming an event using the event consumer wizard embedded in ABAP Development Tools for Eclipse (ADT).
An "event" is a data record expressing a significant change in state and its surrounding context. Events will contain two types of information: the event data representing the occurrence and context metadata providing contextual information about the occurrence. Events are routed from an event producer (the source) to interested event consumers. The routing can be performed based on information contained in the event, but an event will not identify a specific routing destination.
A single occurrence may result in more than one event notifications. The producer has no expectation of how the events are handled and consumer decide what to do with the notification. For example, a change of a business object such as business partner, can be indicated by raising a business event. An interested party having subscribed to this event, can consume, and process it.
CloudEvent is a common standard way of describing events. It is the specification for describing event data in a common way by the cloud native computing foundation (CNCF) serverless working group of developers across the computing industry creating standards for more compatible services.
Imagine a new event is created, like a new message has arrived. There would be questions about the event being delivered to my system, like what kind of event it is (type), when it is sent (time), who sent it (source), what the event’s unique identifier (id) is, and so on. By answering these questions and adding the contextual data we get the cloudevent.
As said, an event can be made of two parts, the event header, and the event body. The event header might include information such as event name, time stamp for the event, and type of event. The event body provides the details of the state change detected. An event body should not be confused with the pattern or the logic that may be applied in reaction to the occurrence of the event itself.
SAP events like any CloudEvents, have a set of required and optional attributes. Some of the required ones are id, source or type and optional ones like data, subject or time. We have business content data as well. As you know business objects (BOs) can be huge and additional parts must be added too.
For example, an SAP “sales order changed” event can look like as follows:
The whole journey of generating the event, channeling and processing is called Event-Driven Architecture (EDA). An event-driven architecture may be built on four logical components, starting with the sending of an event, proceeding to the creation of its technical representation in the form of an event structure and ending with a non-empty set of reactions to that event. This could look like this:
The first logical component is the event producer, which raises the event such as a business change and represents it as an event message. As an example, an event producer could be an application in an SAP S/4HANA Cloud system. Converting the data collected from such a diverse set of data sources to a single standardized form of data for evaluation is a significant task in the design and implementation of this first logical component.
This is the second logical component. An event channel is a mechanism of propagating the information collected from an event producer to the event sink. Several event channels can be opened at the same time. Usually, because the event processing machinery must process them in near real time, the event channels will be read asynchronously. The events are stored in a queue, waiting to be processed later by the event consumer.
The third component is the message broker which in our case, is SAP Event Mesh. Event Mesh is a service in BTP which help us to distribute events in an efficient fast & simple consumable way without affecting any other consumers. It replaces traditional point-to-point communication by introducing a central message broker. While point-to-point communication is fine for sharing data between a limited number of senders and receivers, scalability can quickly become an issue. SAP Event Mesh solves this issue and ensures messages can be exchanged reliably between senders and multiple receiver’s at large scale. In addition, through the introduction of a message broker, you decouple communication between applications, services, and systems so that messages can be sent asynchronously (non-blocking). Asynchronous communication improves performance and scalability since senders are not slowed down or blocked while they wait for individual receivers to be online to receive direct messages.
Since SAP Event Mesh is responsible for message delivery, senders do not need to know which applications, services or systems will receive which data.
If you already subscribed to the Event Mesh service, you can open it from SAP BTP cockpit under service, instances and subscriptions, and then clicking on Event Mesh service:
Here, you can see for example the instances which is created to subscribe later to an event.
SAP Event Mesh enables applications to communicate with each other through message queues. A sending application sends a message to a specific named queue. There’s a one-to-one correspondence between a receiving application and its queue. The message queue retains the messages until the receiving application consumes it. You can manage these queues using the SAP Event Mesh dashboard. For example, for the Event Mesh instance pmev1, I created several queues to use each of them in different applications:
A message client allows you to connect to the SAP Event Mesh service using its own unique credentials to send and receive messages. The client can run within SAP Business Technology Platform or outside of it. The namespace is a unique prefix that defines all the queues or topics that have been created in the context of a particular message client. When you manage queues or topics in SAP Event Mesh, the namespace allows message clients to identify the queues or topics for communication.
Topics are named logical channels to which messages are published. SAP Event Mesh enables a sending application to publish messages and events to a topic. Applications must be subscribed to that topic and be active when the message is sent. Topics do not retain messages. This method can be used when each message needs to be consumed by several receiving applications. By clicking on action menu, you can see the queue subscriptions:
and add topics you are interested in
To be able to consume an event, you need to create a queue for the event mesh instance. For more information see the Create Queues and Queue Subscription for SAP Event Mesh.
On top and as a last component, there is a consumption component. Based on this, you can create an extension application or an integration API to consume the event. The event consumer typically interprets the event data and triggers an according action.
By means of enterprise event enablement, you can connect different consumers & producers of events. As said, an event provider could be for example SAP S/4HANA Cloud. There are already delivered subevents like the creation of a business partner. With integration of RAP business events in steampunk, it is also possible to send SAP events or customer events from steampunk system to the SAP Event Mesh. The solution will be offered for S/4 inhouse development, partners and customers in OP, Steampunk and S/4 HANA Cloud (Embedded Steampunk). This is also available in SAP S/4HANA On-premise. You could also have third party applications participating in enterprise event enablement.
Any customer can subscribe to the service and connect existing products by using events. One of the main aspects is you can define subscription based on topics and inside the topic you can define which BO you are interested in and which activities of this BO you are interested in, from where it comes from depends on how we define the events and how we communicate between these events based on standards we use.
In the next post, I will explain step by step how you can you can Create RAP Business Events , then i show you a efficent way to consume an event using Event Consumption Model within a Business Application in SAP BTP ABAP environment, so, stay tuned!
This blog is the first post from a blog series to introduce events in enterprise architecture, and the possible ways to produce and consume an event in SAP BTP ABAP Environment. With the release 2208, all steps from raising to consuming events can be carried out on the ABAP Platform directly. Here, I will start with the basics of event-based communication. Then, in the upcoming blogs, I’ll explain in detail how you can produce an event using a natively integrated RAP application, supporting all RAP qualities like extensibility and testability also consuming an event using the event consumer wizard embedded in ABAP Development Tools for Eclipse (ADT).
What is an Event?
An "event" is a data record expressing a significant change in state and its surrounding context. Events will contain two types of information: the event data representing the occurrence and context metadata providing contextual information about the occurrence. Events are routed from an event producer (the source) to interested event consumers. The routing can be performed based on information contained in the event, but an event will not identify a specific routing destination.
A single occurrence may result in more than one event notifications. The producer has no expectation of how the events are handled and consumer decide what to do with the notification. For example, a change of a business object such as business partner, can be indicated by raising a business event. An interested party having subscribed to this event, can consume, and process it.
CloudEvent is a common standard way of describing events. It is the specification for describing event data in a common way by the cloud native computing foundation (CNCF) serverless working group of developers across the computing industry creating standards for more compatible services.
CloudEvents Format
Imagine a new event is created, like a new message has arrived. There would be questions about the event being delivered to my system, like what kind of event it is (type), when it is sent (time), who sent it (source), what the event’s unique identifier (id) is, and so on. By answering these questions and adding the contextual data we get the cloudevent.
As said, an event can be made of two parts, the event header, and the event body. The event header might include information such as event name, time stamp for the event, and type of event. The event body provides the details of the state change detected. An event body should not be confused with the pattern or the logic that may be applied in reaction to the occurrence of the event itself.
SAP events like any CloudEvents, have a set of required and optional attributes. Some of the required ones are id, source or type and optional ones like data, subject or time. We have business content data as well. As you know business objects (BOs) can be huge and additional parts must be added too.
For example, an SAP “sales order changed” event can look like as follows:
Event-Driven Architecture
The whole journey of generating the event, channeling and processing is called Event-Driven Architecture (EDA). An event-driven architecture may be built on four logical components, starting with the sending of an event, proceeding to the creation of its technical representation in the form of an event structure and ending with a non-empty set of reactions to that event. This could look like this:
Event Producer
The first logical component is the event producer, which raises the event such as a business change and represents it as an event message. As an example, an event producer could be an application in an SAP S/4HANA Cloud system. Converting the data collected from such a diverse set of data sources to a single standardized form of data for evaluation is a significant task in the design and implementation of this first logical component.
Event Channel
This is the second logical component. An event channel is a mechanism of propagating the information collected from an event producer to the event sink. Several event channels can be opened at the same time. Usually, because the event processing machinery must process them in near real time, the event channels will be read asynchronously. The events are stored in a queue, waiting to be processed later by the event consumer.
Message Broker
The third component is the message broker which in our case, is SAP Event Mesh. Event Mesh is a service in BTP which help us to distribute events in an efficient fast & simple consumable way without affecting any other consumers. It replaces traditional point-to-point communication by introducing a central message broker. While point-to-point communication is fine for sharing data between a limited number of senders and receivers, scalability can quickly become an issue. SAP Event Mesh solves this issue and ensures messages can be exchanged reliably between senders and multiple receiver’s at large scale. In addition, through the introduction of a message broker, you decouple communication between applications, services, and systems so that messages can be sent asynchronously (non-blocking). Asynchronous communication improves performance and scalability since senders are not slowed down or blocked while they wait for individual receivers to be online to receive direct messages.
Since SAP Event Mesh is responsible for message delivery, senders do not need to know which applications, services or systems will receive which data.
- Sending applications are not slowed down by waiting for a non-critical response from receivers that might be offline and unable to receive and respond to a message as it is published.
- Receiving applications can subscribe to messages of business importance and ensure to receive all relevant updates and can consume these messages at their own pace.
How to Get Access to SAP Event Mesh
If you already subscribed to the Event Mesh service, you can open it from SAP BTP cockpit under service, instances and subscriptions, and then clicking on Event Mesh service:
Here, you can see for example the instances which is created to subscribe later to an event.
Messaging Concepts
Queues
SAP Event Mesh enables applications to communicate with each other through message queues. A sending application sends a message to a specific named queue. There’s a one-to-one correspondence between a receiving application and its queue. The message queue retains the messages until the receiving application consumes it. You can manage these queues using the SAP Event Mesh dashboard. For example, for the Event Mesh instance pmev1, I created several queues to use each of them in different applications:
A message client allows you to connect to the SAP Event Mesh service using its own unique credentials to send and receive messages. The client can run within SAP Business Technology Platform or outside of it. The namespace is a unique prefix that defines all the queues or topics that have been created in the context of a particular message client. When you manage queues or topics in SAP Event Mesh, the namespace allows message clients to identify the queues or topics for communication.
Topics
Topics are named logical channels to which messages are published. SAP Event Mesh enables a sending application to publish messages and events to a topic. Applications must be subscribed to that topic and be active when the message is sent. Topics do not retain messages. This method can be used when each message needs to be consumed by several receiving applications. By clicking on action menu, you can see the queue subscriptions:
and add topics you are interested in
To be able to consume an event, you need to create a queue for the event mesh instance. For more information see the Create Queues and Queue Subscription for SAP Event Mesh.
Event Consumer
On top and as a last component, there is a consumption component. Based on this, you can create an extension application or an integration API to consume the event. The event consumer typically interprets the event data and triggers an according action.
Summary
By means of enterprise event enablement, you can connect different consumers & producers of events. As said, an event provider could be for example SAP S/4HANA Cloud. There are already delivered subevents like the creation of a business partner. With integration of RAP business events in steampunk, it is also possible to send SAP events or customer events from steampunk system to the SAP Event Mesh. The solution will be offered for S/4 inhouse development, partners and customers in OP, Steampunk and S/4 HANA Cloud (Embedded Steampunk). This is also available in SAP S/4HANA On-premise. You could also have third party applications participating in enterprise event enablement.
Any customer can subscribe to the service and connect existing products by using events. One of the main aspects is you can define subscription based on topics and inside the topic you can define which BO you are interested in and which activities of this BO you are interested in, from where it comes from depends on how we define the events and how we communicate between these events based on standards we use.
In the next post, I will explain step by step how you can you can Create RAP Business Events , then i show you a efficent way to consume an event using Event Consumption Model within a Business Application in SAP BTP ABAP environment, so, stay tuned!
- SAP Managed Tags:
14 Comments
