Understanding SAP Integration Suite, advanced Event Mesh in the Event-Driven Architecture

Before you get a deep dive into the actual components and capabilities of SAP Integration Suite, advanced mesh, let’s build the bridge from what you have learned in unit 1 about messaging and events, and SAP Integration Suite, advanced event mesh.

As messaging enables computer systems to exchange data without needing a direct link or knowledge of each other’s location, you can compare this to postal and shipping services. Just like how you entrust the carrier with your letter or package for delivery, your systems pass on data to the messaging service, which then delivers it to the necessary applications.

Therefore, in its simplest form, messaging consists of:

1. Publisher: The party that sends or communicates the message (also known as a producer)
2. Message: The data the publisher wants to relay. Messages often contain event information, but can also include queries, commands, and more.
3. Messaging system: The infrastructure that accommodates the message transmission.
4. Subscriber: The ultimate recipient of the message (also called a consumer).

In an event-driven architecture, messages commonly have a destination that serves as a segregation between the publisher and the subscriber. In sophisticated event mesh systems, like the one provided by SAP Integration Suite, advanced event mesh, this destination can typically be a topic endpoint or a queue, managed by event brokers.

Topic endpoints are adopted when a message is meant for multiple subscribers. For example, the figure below illustrates event messages being broadcasted to various subscribers through a topic endpoint.

Thus, a topic endpoint attracts messages published to a single topic for which the topic endpoint has a matching subscription. Any topic endpoint whose topic subscription matches the topic on the incoming messages will receive those messages.

On the other hand, queues are employed when the message is directed towards just one subscriber.

Event broker queues work similar like those in most messaging queue systems. First, senders dispatch guaranteed messages to the event broker, followed by the messages being stored in the queue. Then, If the receiving client is online and connected to the network, the messages get delivered; otherwise, they remain in the queue until the client connects. Receiving clients are required to confirm receipt of the message after successful processing, leading to its removal from the queue.

Durable queues persist unless intentionally removed. They accumulate the messages irrespective of the client's online or offline status. Offline clients receive all accumulated messages once they reconnect.

On the other hand, temporary (or non-durable) queues align with the lifecycle of a client’s connection. These temporary queues and their corresponding topic endpoints continue as long as the client’s session remains active. Any disconnection triggers the automatic removal of these temporary queues by the event broker while disallowing message accumulation during client offline periods.

Now, that you know how event brokers get event data from the publishing application to the clients that want to know about it, let’s explore which message types are available for use within SAP Integration Suite, advanced event mesh, and how messages are structured.

As explained before, there are different types of messages available for use in event-driven architectures (event messages, queries, commands). The primary message type in SAP Integration Suite, advanced event mesh is event messages. These messages communicate specific information from one application to others. This forms a series of messages known as an event stream, which is released as events occur. Examples include pricing streams and trade streams in capital markets. The terms event and message are often used interchangeably due to their close association in this context.

In terms of message construction, a message typically consists of three components:

• Header
• Properties
• Body

Here is a brief overview:

Let’s take a look, what each of the components means:

Header

The Header serves as a guide for the event broker to properly direct messages throughout the system. Some fields in the header like the Destination and Delivery Mode are obligatory, while others, like the reply-to topic, are optional and only necessary for certain types of messaging. In the case of Request-Reply messaging, the replier needs to know where to send responses, thus requiring the reply-to topic.

Properties

Apart from the Header, the message can also include properties specified by applications. The event broker does not interfere with these, instead, they aid in enhancing communication between applications. Some APIs have standard properties, for instance, JMS has properties such as JMSXUserID and JMSXAppID that serve to identify the sender of the message. Beyond predefined standard properties, applications may also include their own. For example, an Order ID which an Order Management System uses to uniquely track all messages linked to a particular order.

Body

The Body of the message, sometimes referred to as the "payload" or "attachment", contains application-specific data which is transported by the event broker without any alterations. It could be raw binary data, or structured data, such as text, streams, or maps. Regardless of the type, it's crucial that both the sender and receiver agree on the payload format for the data to be correctly interpreted. In event messages, a schema is used to define this payload format.

If you want to learn more about the basic concepts of events and messaging, please visit this page.

Let’s dive into the components and capabilities of SAP Integration Suite, advanced event mesh, now.