Getting Started with SAP Event Mesh: Concepts, Setup, and Best Practices

What Is SAP Event Mesh?
SAP Event Mesh allows applications to communicate through asynchronous events.

SAP Event Mesh is a fully-managed service to connect applications, services, and systems so they can interact with each other through messages and events.

• Publish business events
  Publish business events from SAP and non-SAP sources across hybrid landscapes from the digital core to extension applications through event-driven architecture.
• Connect seamlessly
  Achieve reliable data transmission for extension and integration scenarios through decoupled communication.
• Consume business events
  Consume business events from SAP and non-SAP sources throughout SAP’s event-driven ecosystem including SAP Extension Suite, SAP Integration Suite, and selected inbound enabled SAP backends.
• SAP Event Mesh supports standard messaging protocols to connect applications, services, and systems across hybrid landscapes.

Some Messaging Protocols

• Advanced Messaging Queuing Protocol (AMQP) 1.0 over WebSocket is an open standard protocol for messaging between applications or organizations.
• The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security.
• Message Queuing Telemetry Transport (MQTT) 3.1.1 over WebSocket is a lightweight messaging protocol designed for low bandwidth, high latency. It is the recommended protocol for use by applications not running in the cloud.
• HTTP 1.1 REST support allows to expose messaging capabilities using REST APIs.
• Messages can be published to and consumed from queues and topics via HTTP REST calls.
• You can use the AMQP 1.0 over WebSocket libraries and MQTT 3.1.1. over WebSocket libraries for node.js.
• SAP Event Mesh also supports protocol-agnostic libraries that can be used at application configuration level for Java and Node.js.

What are Events?

Events are occurrences that signify a change in the state of data.

In the terms of information technology, events can range from a sensor detecting a shift in temperature, clicking a button in an application or creating or changing a Sales Order, modification of database record, completion of Bank transaction.

What is Messaging?

Messaging is a method by which applications communicate data to one another through a structured system of messages.

This system enables the exchange of information without requiring the applications to be directly connected or aware of each other’s specific locations.

Key Participants in Messaging

1. Publisher: Also known as the producer, this is the source that originates and dispatches a message.
2. Message: This is the content dispatched by the publisher, which may include event details, enquiries, directives, and various other data. 
3. Event Broker: The framework responsible for conveying the message from the publisher to the subscriber.
4. Subscriber: Also referred to as the consumer, this is the final recipient of the message.

In EDA Event Driven Architecture, messages are directed to specific destinations that differentiate the sender (publisher) from the receiver (subscriber).
Within the SAP Advanced Event Mesh, these destinations are commonly topic endpoints or queues, both of which are coordinated by event brokers.

• Queues ensure messages are received by no more than one subscriber.
• Topic endpoints facilitate the delivery of messages to multiple subscribers.

 Event Driven Architecture (EDA)

Message Exchange Patterns

Dictate how messages are dispatched and retrieved, each serving distinct scenarios and
requirements

1. Publish-Subscribe:

• This pattern is frequently used for events. Producers publish messages to a central hub without specifying a particular consumer.
• The event broker then disseminates these messages to all the subscribers who have shown interest in that type of message.
• It’s particularly effective for sending out widespread notifications, such as alerting multiple parts of a system to a user’s action.

Publish-Subscribe

2. Point-to-Point/Exclusive Consumption:

• Messages in this pattern is directed to a specific queue and consumed by only one recipient.
• This ensures that a single consumer processes each message, which is crucial for tasks where one, and only one, process must handle the message, such as order processing.

Point-to-Point/Exclusive Consumption

2.1. Non-Exclusive Consumption:

• Consumer groups can be applied to enhance the classic point-to-point messaging framework.
• They allow several consumers to collectively use a single queue that acts as the unique conduit for messages emanating from the producer.
• Even though there may be numerous consumers within the receiving application, each message is guaranteed to be delivered to just one endpoint.

Non-Exclusive Consumption 

What are Event Brokers?

• An event broker in an event-driven architecture (EDA) is an intermediary that routes messages from producers to consumers based on subscriptions.
• Applications publish events to the broker, which then distributes these messages to interested clients.
• This broker can be a physical device, on-premises software, or a cloud-based service.
• It supports various exchange patterns like publish/subscribe and integrates with different systems, including SAP Integration Suite, Solace, and Kafka.
• By enabling an event mesh, it ensures efficient, targeted communication across diverse environments, acting as a centralized system for managing event-driven messaging.

SAP Event Mesh supports central messaging concepts:

1. Queues

• A queue is a collection in which the entities in the collection are kept in order and the main operations on the queue are the addition of entities to the rear terminal position and removal of entities from the front terminal position.
• 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.

2. Topics

• Topics are named logical channels to which messages are published.
• Subscribers in a topic-based system receive all messages published to the topics to which they have subscribed.
• All subscribers to a topic receive their own copy of the same message.

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 a number of receiving applications.

Queue Subscriptions

• With queue subscriptions SAP Event Mesh enables a sending application to publish messages to a topic.
  The topic sends the message directly to the queue to which it is bound. For example, events from an SAP S/4HANA system (event source) can only be sent to a topic.
• A queue subscription ensures that the message is retained until it is consumed by the receiving application.

Topics with Event-Driven Architecture (EDA)

• Topics within an Event-Driven Architecture (EDA) function as a method for categorizing event messages.
• They resemble directories that channel similar events into specific streams.
• Events are associated with topics by publishers, and endpoints, or subscribers, choose topics to receive
  relevant events.

Subscriptions to Topics: Subscriptions are formulated using strings that may include wildcard characters to
capture a broad selection of topic messages.
The wildcards * and > are typically used for this purpose.
* This symbol acts as a placeholder that can represent any value at a specific level within the topic.

Message Delivery Modes

• In SAP Integration Suite with advanced event mesh supports two primary types of message delivery, each serving different use cases based on the requirements for speed and reliability:
  1. Direct Messaging
  2. Guaranteed Messaging

1. Direct messaging is a form of communication in event-driven systems designed for scenarios that require fast and efficient message delivery, but where it’s acceptable that some messages might not be delivered in cases of congestion or failure.

2. Guaranteed messaging or persistent messaging is a reliable message delivery system used in applications where it’s critical that no messages are lost.

The main features of guaranteed messaging include:

• Durable Subscriptions: Topic subscriptions are tied to a stable endpoint within the event broker, not
  directly to the transient clients. This ensures continuity and message integrity over time.
• Message Persistence: Once the event broker confirms (acknowledges) receipt of a message, the
  message is considered safe and will not be lost, even in the event of system failures.
• Message Retention: Messages are stored at a durable endpoint within the broker until a client
  retrieves and processes them, regardless of the client’s connection status.
• Acknowledged Delivery: When a message is successfully delivered and processed by a client, the
  client sends back an acknowledgement to the broker, confirming receipt.

Hands-on 

1. Create account on Solace.com 
2. Go to Solace->Click on Cluster manager 

       3. Click on Create Service 

• Same page below – we have an Advance Connection Options here we can port of all the adapters like  , 

• Creating the Queue, 

• Default below image, and click and apply top right corner

• Now, we are going to create iflow in SAP CPI. 

• We need to give the host name of the event broker (solace host name) 

• In Solace, Go to Cluster and Open the Connect tab,

• Connection details below mentioned the screenshot, 

• We have sent 1 message through postman and received the solace in queue below image, 

   

  

   

• Second iflow creating for Event_Mesh_Receiver, 

  Usecase:1 

  We have stored using 1st iflow in queue now we are trying to fetch the message in queue using 2nd iflow. 

  

   

  

   

  

   

  

   

  

   

• After running the iflow data has been stored in Data store below, 

SAP Event Mesh Sending Messages using REST API

• Now, we are going to send data from Postman to Solace (Event Broker).

API URL

For Queue:

https://mr-connection-dwwfdwq848z.messaging.solace.cloud:9443/queue/SalesOrderQueue 

For Topic:

https://mr-connection-dwwfdwq848z.messaging.solace.cloud:9443/topic/SalesOrderQueue 

Trigger from postman its directly went through event broker (Solace)—From solace—we are fetching the data through CPI and store on datastore. 

• Now , we are using topic to post the data, 
• Click here the queue , and then go to subscription and then create topic,

• Sender is postman for this scenario, 

• Go to CPI change to consumer mode is Direct and added the Topic Subscriptions, 

• We are posting: 
• POSTMAN—>Solace–>CPI–>Datastore 

SAP EVENT MESH Publishing Messages using AMQP 

• Go to solace->Connect->choose(protocol)–>Go to AMQP–>Select AMQP open source API.

Conclusion

This blog provides a comprehensive guide to integrating SAP Event Mesh with Solace Event Broker to enable robust, event-driven communication between distributed systems. Theoretically, it introduces the concept of SAP Event Mesh as a messaging infrastructure that facilitates asynchronous data exchange using queues and topics, supporting protocols like REST and AMQP. Solace is used as the event broker to manage message routing and delivery. The hands-on section walks through the practical steps of setting up a Solace account, creating services, queues, and topics, and configuring SAP Cloud Platform Integration (CPI) to send and receive messages. Two iFlows are developed—one for publishing messages to Solace and another for consuming them and storing the data in a datastore. The guide also demonstrates sending messages via Postman using REST APIs and AMQP, showcasing how messages flow from external sources through Solace to CPI. Overall, the document effectively bridges theory and practice, illustrating how SAP Event Mesh and Solace can be used together to build scalable, decoupled, and real-time integration scenarios.

  Read More Technology Blog Posts by Members articles 

#abap