Event-Driven

Architecture

Version – 1.0.0
Version Details – Initial
Author – Jaspreet Bagga

Revision History
Date Version Description Author
20 August
0.1 Draft Jaspreet Bagga
2024

Document Details
Project Name CBS - Consulting
Release Reference 1.0
Client Name CBS - Consulting
Client IT Specialist
Document Owner Jaspreet Bagga
Document Reviewer
Table of Contents

1. What is Event-Driven Architecture?.................................................................5

1.1. What is an Event?.................................................................................... 5
1.2. What is Messaging?................................................................................. 6
1.2.1. Types of Messages................................................................................ 6
1.3. Message Exchange Patterns.....................................................................7
1.4. What are Event Brokers?..........................................................................8
1.5. How does event-driven architecture work?..............................................8
1.6. What are Topics?...................................................................................... 8
1.6.1 How to Define Topics............................................................................9
1.6.2. Topic Hierarchies of SAP AEM...............................................................9
1.7. Topic Endpoints and Queues..................................................................10
1.8. What is Event-driven architecture patterns?..........................................11
1.9. Event-driven architecture use cases and examples...............................11
1.10. Benefits of Event-Driven Architecture....................................................12
2. SAP and Event-Driven Architecture...............................................................13
3. SAP Advanced Event Mesh vs Event Mesh....................................................14
4. Kafka VS SAP Advanced Event Mesh.............................................................15
5. Pros and Cons of SAP Advanced Event Mesh.................................................16
6. Pros and Cons of Event Mesh........................................................................17
7. Advanced Event Mesh and Event Mesh Use Cases........................................18
8. Pricing of SAP Advanced Event Mesh vs Event Mesh.....................................19
9. What Is SAP Integration Suite, Advanced Event Mesh?.................................20
9.1. Subscription Services in SAP Integration Suite, Advanced Event Mesh..21
10. Accessing SAP Integration Suite, Advanced Event Mesh...........................22
10.1. Login to Cloud Console..........................................................................22
10.2. Create your First Event Broker Service...................................................23
10.3. Try Out Your Event Broker Service..........................................................25
9.3.1 Subscribe to a Topic............................................................................25
9.4. Create your First Queue.........................................................................26
9.4.1. Map a Topic to a Queue......................................................................27
9.4.2. Publish a message in a Queue............................................................27
9.4.3. Confirm message is in the Queue.......................................................28
9.5. Consume Message from Queue.............................................................29
 9.6. Design your Event-Driven Architecture..................................................30
9.6.1. Create an Application Domain............................................................30
9.6.2. Create an Event.................................................................................. 31
9.6.3. Create Applications............................................................................. 31
9.6.4. Import Objects.................................................................................... 32
9.7. Create a Model of Your Event-Driven Architecture.................................33
9.7.1. Create Modelled Event-Mesh..............................................................33
9.7.2. Add Event Brokers to Your Modeled Event Mesh.................................34
9.7.3. Add Applications to a Modeled Event Mesh........................................35
10. Features of SAP Advance Event Mesh........................................................37
11. Security in SAP Integration Suite, Advanced Event Mesh..........................38
12. Sample AEM sender and receiver..............................................................40
13. Steps to Configure SAP Event Mesh..........................................................41
1. What is Event-Driven Architecture?
Event-driven architecture (EDA) is a software design approach that reacts
to significant occurrences or state changes, known as events. With EDA,
systems can respond to events like transactions, website visits, or user
activities in real-time or almost real-time, unlike typical request-response
systems that wait for explicit requests. This asynchronous approach
encourages loosely coupled parts and makes processing massive amounts
of data more effective.
"Asynchronous" communication is a term frequently used to describe
event-driven architecture. As a result, neither the sender nor the recipient
must wait for the other to do their next assignment. Not all systems rely
on a single message. A phone call, for example, is seen as synchronous or
more in keeping with the conventional "request/response" design. When
you get a call from someone asking you to perform something, you wait
for the respondent to finish the assignment before hanging up. Text
messaging is an example of an asynchronous system. You send a
message, sometimes without knowing who to send it to or whether
anyone is listening, and you don't wait for a reply.

1.1. What is an Event?

A change in the status of a crucial business system is referred to as an
event. For example, a product is purchased, a flight is checked in by
someone else, or a bus is running late. If one stops to consider it, events
happen all the time and everywhere, regardless of the industry. They are
ubiquitous in any industry. Anything that generates a message through
production, publication, detection, or consumption is considered an event.
The message is the traveling notice communicating the occurrence,
whereas the event is the actual event. For this reason, the event and
message are distinct from one another. An event in an event-driven
architecture will likely cause one or more processes or actions to be
triggered in response.
When an event notification is received in an event-driven architecture, the
system detects that something has happened, such as a state change,
and it waits to reply to the requester whenever it makes it. The application
that got the message has two options: respond immediately or wait until
the desired state change has happened.
Systems based on event-driven architecture make digital business
applications more responsive, scalable, agile, and contextual possible.

1.2. What is Messaging?

In technological contexts, messaging allows computer systems to share
information without the need for direct connections or knowledge of each
other's locations. This process is akin to postal or shipping services: just as
you entrust a letter or package to a carrier to deliver it to the intended
recipient, applications pass data to a messaging system that routes it to
the appropriate destination.
At its fundamental level, messaging involves several key participants:
 Publisher (Producer): The entity that sends or publishes a
message.
 Message: The content or information the publisher wants to
transmit. Messages can include event data, queries, commands, or
other types of information.
 Messaging System: The infrastructure responsible for transmitting
messages between publishers and subscribers.
 Subscriber (Consumer): The end recipient of the message.
In an Event-Driven Architecture (EDA), messages typically have
destinations that decouple publishers from subscribers. Within the SAP
Integration Suite's Advanced Event Mesh, a destination is usually a topic
endpoint or a queue. These are managed by event brokers, which
facilitate the flow of messages.

1.2.1. Types of Messages

SAP Integration Suite's Advanced Event Mesh supports three primary
message types:
 Event Message: Conveys information about an occurrence that an
application needs to share with others. An event stream is a
sequence of such messages published as events happen. Examples
include pricing streams or trade streams in capital markets. Due to
 their interconnected nature, the terms "event" and "message" are
often used interchangeably.
 Query: A message that requests information, similar to performing
an HTTP GET or HEAD request. Queries expect a response from the
recipient.
 Command: Instructs another application to perform a specific action
or change its state, akin to using HTTP POST, PUT, or DELETE
methods. Commands also require a response.

1.3. Message Exchange Patterns

Most messaging applications commonly use the following patterns:
1. Publish-Subscribe: A model where messages are sent to multiple
subscribers from a single publisher. Events typically use this pattern,
as it broadcasts information to various consumers.

2. Point-to-point: This pattern is used for one-to-one communication,

where a message is sent to a specific receiver. It is also used for
tasks like commands.

3. Request-Reply: This involves a sender requesting information and

receiving a response. It is often used for queries where an
immediate reply is required.
Each pattern serves distinct messaging scenarios.

1.4. What are Event Brokers?

An event broker is a middleware that facilitates communication between
producers and consumers by routing event messages. It supports various
messaging patterns like publish-subscribe, point-to-point, and request-
reply. In an event-driven architecture (EDA), applications publish events to
the broker, which then distributes them to subscribers. Event brokers can
be hardware, software, or SaaS-based, and they provide the core
messaging infrastructure in an EDA. Advanced Event Mesh in SAP
Integration Suite supports multiple event broker types, including Solace
and Kafka brokers.

1.5. How does event-driven architecture work?

In an event-driven architecture, Applications function as either event
producers (those that create or record events) or event consumers (those
that process and respond to events). Producers use a broker, also known
as messaging-oriented middleware, to send events in real time to
consumers. After the event has been processed, users can initiate further
events, workflows, or actions.
Brokers may be optional in a fundamental architecture, such as one with a
single producer and one consumer communicating directly. But in most
businesses, events are being sent out by several sources to numerous
recipients, necessitating a broker or even a network of brokers (referred to
as an "event mesh"), and employing an event mesh or broker results in a
"loose coupling" of applications.
1.6. What are Topics?
In an event-driven architecture (EDA), events are sent to topics, which
serve as channels for communication. Subscribers can register to one or
more topics to receive events from various publishers. Essentially, topics
are strings structured in levels and added as metadata within message
headers, allowing publishers to categorize their messages and subscribers
to specify which messages they want to receive. This publish-subscribe
model enables event brokers to route messages to their intended
destinations using topics.
However, a topic is more than a routing mechanism; it also represents a
hierarchical categorization of an event's subject matter. Topics not only
direct messages to the correct recipients but also help define and describe
the nature of the event. A well-designed topic structure can include
specific details about each event instance, enabling subscribers to receive
only relevant information. This eliminates the need for subscribers to sift
through irrelevant messages, enhancing efficiency. Thoughtful topic
design can make the system smarter by ensuring targeted and relevant
communication.

1.6.1How to Define Topics

A topic is a string formatted as a/b/c/.../n, where each segment (a, b, c,
etc.) represents levels in a hierarchy that you design to categorize and
describe your events. For example, if you're publishing events for
Example Airline (EA), you might create topics like
flight/boarding/ea1234/jfk or flight/departed/ea321/yow to organize the
events.
You can make your topics more dynamic by defining one or more topic
levels using variables. These variables are placeholders that get replaced
with specific properties when the event occurs. This allows your topic to
represent the actual event data, not just a category. For instance, instead
of hardcoding specific values, you can use a topic like
flight/[status]/[flightNumber]/[origin], which can dynamically represent
events such as flight/boarding/ea1234/jfk and flight/departed/ea321/yow
by filling in the values of status, flight number, and origin during the
event.

1.6.2. Topic Hierarchies of SAP AEM

Smart topics and subscriptions offer several benefits within an event
mesh, especially when combined with a rich topic hierarchy:
 1. Event Routing - Event brokers use the event’s topic and consumer
subscriptions to make routing decisions. Brokers can match the
topic to the consumer’s subscription to determine which data the
consumer is interested in. This method avoids the need to
understand the event’s payload, making routing efficient and
straightforward.
2. Event Filtering - Subscriptions allow consumers to filter incoming
data with fine-grained precision, receiving only the necessary
information. Consumers can subscribe to the exact events they
need when used with a rich topic hierarchy. This prevents data
overload, eliminating the need to discard unnecessary data or re-
publish filtered streams, demonstrating how Solace topics act as
"smart" filters.
3. Event Access Control - Access Control Lists (ACLs) enable
administrators to manage which events can be published or
consumed. By leveraging a detailed topic hierarchy, administrators
can strictly control data flow based on topic descriptions, preventing
unauthorized applications from accessing privileged data or
performing restricted actions.
4. Event Handling Policy - Event brokers can apply policies to topic
subscriptions, influencing how events are handled, such as
prioritizing messages, making them eligible for replay, or replicating
them. Using a rich topic hierarchy, administrators can ensure that
the correct messages are copied or added to replay logs while also
controlling how different events are routed based on pre-defined
policies.
These features enhance scalability, security, and performance within an
event mesh.

1.7. Topic Endpoints and Queues

Topic Endpoints and Queues are storage points for guaranteed
messages on the event broker, with two key types:
1. Queues:
 Queues are endpoints that are configured with topic
subscriptions. Messages can be published to the queue and
consumed by clients.
 They can subscribe to multiple topics and receive messages
that match any of those subscriptions.
 Queues offer flexibility in terms of access:
  Exclusive access for one consumer.
 Shared access for multiple consumers, where
messages are distributed among them.
 Queues are versatile and recommended for most applications
as they support multiple topic subscriptions and offer a range
of configurations to meet different needs.
2. Topic Endpoints:
 A topic endpoint stores messages published to a single topic
with a matching subscription.
 Messages are attracted to topic endpoints if the topic
subscription matches the incoming message’s topic.
 Topic endpoints are less flexible than queues and are mainly
suited for JMS applications.
How Queues Work:
 Producers send guaranteed messages to the event broker.
 Messages are stored in the queue and delivered to consumers when
they are online, or held until they reconnect.
 Consumers acknowledge messages after processing them.
 The event broker then removes the message from the queue.
Types of Queues:
 Durable Queues:
 Exist until removed administratively.
 Store messages even when clients are offline, delivering
accumulated messages once the client reconnects.
 Temporary (Non-Durable) Queues:
 Exist only during the client’s connection session.
 Useful for temporary message persistence while clients are
online.
 Automatically removed when the client disconnects, and no
messages accumulate when clients are offline.
Queues provide flexibility and durability, making them ideal for various
messaging needs, whereas topic endpoints are specialized for JMS use
cases.
1.8. What is Event-driven architecture patterns?
In an event-driven architecture, publish/subscribe, and event streaming
are the two primary paradigms for event transmission.
In an event-driven architecture, publish/subscribe, and event streaming
are the two primary paradigms for event transmission.
 Publish/subscribe, often known as "pub/sub," allows attendees of
events to subscribe to channels and messages that event producers
post. When an event is published, a broker sends it to every
subscriber. The broker destroys events once they are consumed to
prevent duplication.
 Event streaming: Producers submit full streams of events to a broker
via this method. Customers can read from any section of the stream
after subscribing, absorbing only the pertinent events. This
approach allows the broker to keep events even after they are
consumed.

1.9. Event-driven architecture use cases and examples

Event-driven architectures have many applications in every sector,
including retail and finance. Here's an illustration from the restaurant
business:
 A college student places a pizza order using a meal delivery app like
Uber Eats. The application records his name, address, payment
details, and order before publishing the "pizza order" event.

 The pizza place broadcasts its "order ready" event back to the food
delivery service after customers subscribe to the event and
complete the order.
 After that, the service assigns a delivery driver, sets up an ETA, and
notifies the client that his pie will arrive soon.
An e-commerce example of an EDA:
 An e-commerce website receives an online shopper's credit card
information and publishes the event "payment submitted."

 After processing the payment and issuing its own "payment

processed" event to indicate success or failure, the payment system
subscribes to the event, processes the money, and returns it to the
website UI.

 The user interface informs the client of their payment status and
suggests actions.
1.10. Benefits of Event-Driven Architecture
 Workflows in real time and promptness. An EDA can keep an
eye on events and respond swiftly to them. RPA is frequently used to
speed up processes and instantly initiate subsequent actions. This is
particularly important during periods of high demand, such as
holidays or significant sales occasions. Every day (i.e., off-peak)
workflows can also benefit from this responsiveness, with
improvements possible in areas such as fraud detection and supply
chain automation.

 Asynchronous communication. Asynchronous communication

occurs between applications in an EDA when producers publish
event messages without waiting for consumers to receive them.
This streamlines integration and allows programs to continue
working without waiting for them.

 De- and loose coupling. Applications in an EDA are loosely or

decoupled from one another and do not rely on one another's
availability. They are independent and can be tested, updated, and
used. Additionally, they can fail independently, making the
architecture more resilient and long-lasting than conventional
models. Decoupling also removes the need to develop new code
every time there is a change, making it simple to add additional
publishers and consumers as needed.
2. SAP and Event-Driven Architecture
SAP, a leading enterprise software provider, has recognized the potential
of Event-Driven Architecture (EDA) in transforming business operations.
EDA's capacity to manage events in real-time and promptly initiate
actions meets the demands of contemporary, dynamic organizations.
SAP's Integration Suite is a cornerstone for implementing EDA. It provides
an extensive framework for managing, monitoring, and streaming events.
Essential elements consist of:
 Event Mesh - One of the main elements of SAP's Integration Suite
is Event Mesh. It serves as the foundation for tying together various
apps and systems so they may share events instantly. Consider it an
event-traffic highway. Delivery, transformation, and event routing
are essential features.

 SAP Advanced Event Mesh - This is an improved version of Event

Mesh with more sophisticated functionality for intricate EDA
situations. It offers a full-featured platform for managing,
broadcasting, and tracking events. It has tools for assuring data
quality, evaluating event data, and visualizing event flow. It enables
real-time, asynchronous communication between applications in
dispersed environments with a fully managed cloud service that
facilitates event-driven architectures.

 Kafka - Kafka is a distributed event streaming platform that is vital

in enabling Event-Driven Architectures (EDA) across industries. It
was initially developed at LinkedIn and later open-sourced as an
Apache project. Kafka is designed to handle real-time data feeds
with high throughput, fault tolerance, and scalability, making it ideal
for managing events in large-scale, dynamic systems.
3. SAP Advanced Event Mesh vs Event Mesh

SAP Advanced Event Mesh provides strong event management features

beyond simple integration. It gives you the ability to:
 Monitor the events as they occur, ensuring the data is accurate and
compliant.
 Create, share, and find events, encouraging cooperation and reuse.
 Flexibly deploy on-premises, at the edge, or across various public
clouds (AWS, Azure, GCP).
 Use event transactions to preserve data consistency.
 Play back notifications for new apps or troubleshooting.
 Able to manage substantial payloads and storage for rigorous use
cases
SAP Event Mesh offers a straightforward option for the main event
streaming and integration. In the following scenarios, it would be a terrific
choice:

 Accessible possibilities for integration within the SAP ecosystem

 Implementation at a reasonable cost using usage-based pricing
 Simple implementation of SAP Business Technology Platform

The key Differences between the two are:

SAP Advanced Event Mesh SAP Event Mesh

SAP AEM handles more intricate Event Mesh focuses on more

event-driven structures straightforward integrations.

For control and compliance, AEM Event Mesh does not give priority
gives event management priority. to event management.

AEM offers broader deployment

Event Mesh resides within SAP BTP.
options

AEM can store and handle bigger

Event Mesh can handle message
payloads for prolonged data flows.
sizes up to 1 MB with a storage
AEM Can handle message size up
support of 10 GB
to 30 MB with a storage of 6TB
4. Kafka VS SAP Advanced Event Mesh
Kafka provides robust real-time event streaming and processing
capabilities. It gives you the ability to:
 Handle high-throughput, distributed event streams across various
platforms.
 Store and replay event streams, providing event persistence and
fault tolerance.
 Efficiently process real-time data feeds for applications such as real-
time analytics, event-driven microservices, and IoT.
 Scale horizontally to handle millions of events per second across
distributed systems.
 Offer strong durability with persistent storage, enabling replay of
historical events for auditing or troubleshooting.

SAP Advanced Event Mesh (AEM) offers a more comprehensive event

management platform with features such as:
 Monitoring events as they occur to ensure accurate and compliant
data.
 Creating, sharing, and finding events to foster collaboration and
reuse within an organization.
 Flexible deployment options across on-premises, edge
environments, and multiple public clouds (AWS, Azure, GCP).
 Preserving data consistency through event transactions and
replaying notifications for new applications or troubleshooting.
 Managing larger payloads and providing significant storage capacity
for rigorous use cases.

The key Differences between the two are:

SAP Advanced Event Mesh SAP Event Mesh

Kafka handles high-throughput, Kafka handles high-throughput,
real-time event streaming across real-time event streaming across
distributed systems. distributed systems.
Kafka prioritizes scalability, fault Kafka prioritizes scalability, fault
tolerance, and high-throughput tolerance, and high-throughput
event handling. event handling.
Kafka is designed to integrate with Kafka is designed to integrate with
various systems but requires various systems but requires
manual setup and management. manual setup and management.
Kafka supports persistent storage Kafka supports persistent storage
for event replay, handling large for event replay, handling large
volumes of events and logs. volumes of events and logs.

5. Pros and Cons of SAP Advanced Event

Mesh
Pros of SAP Advanced Event Mesh

1. Robust Event Management - With features like runtime discovery

and event cataloguing, Advanced Event Mesh (AEM) offers extensive
event management capabilities that enable businesses to efficiently
plan, oversee, and manage their event-driven architecture (EDA).

2. Scalability - With a storage capacity of 6 TB and the ability to

handle message sizes of up to 30 MB, AEM is well-suited for
significant data flows. It also supports vast data volumes and
payloads.

3. Flexibility in Deployment - AEM can be used in various settings,

such as on-premises configurations and public and private clouds,
allowing businesses to select their infrastructure.

4. Advanced Features — AEM features include message replay,

which lets users retrieve misplaced messages and improves event
processing dependability.

5. Intuitive Interface - The platform facilitates the design,

deployment, and monitoring of event-driven systems by providing a
standard interface for controlling event streaming services.

Cons of SAP Advanced Event Mesh

1. Complexity - Compared to more straightforward solutions like SAP

Event Mesh, AEM's sophisticated features and capabilities may add
complexity, making it harder for organizations to install and
administer.

2. Cost - Because of its many features and volume of data processed,

AEM's pricing model may be more expensive than smaller
businesses or use cases with more straightforward requirements.
 3. Learning Curve - Users may encounter a high learning curve
because of the advanced features and the requirement for a deeper
comprehension of the principles of event-driven architecture.

4. Resource Intensive - To effectively utilize AEM's potential,

deploying and maintaining it can require a significant investment in
resources, including competent staff and a robust infrastructure.

5. Potential Overhead—AEM's complex features may create

unnecessary overhead for organizations with smaller integration
needs, making it less appropriate for essential event-driven
connections.

6. Pros and Cons of Event Mesh

Pros of Event Mesh
1. Decoupled Communication - SAP Event Mesh makes loose
connectivity between apps and services possible, increasing system
dependence and flexibility. This decoupling reduces the effect of
changes in one application on other applications while improving
system agility.

2. Scalability - The platform is appropriate for high-performance

scenarios and mission-critical applications because it effectively
manages many events. Event-driven services allow organizations to
scale as needed without seeing a noticeable drop in performance.

3. Reliability - SAP Event Mesh ensures reliable event delivery across

different services. This dependability is crucial for sustaining
business continuity and preserving system availability.

4. Performance Optimization - The service is designed to lower

system latency and boost throughput, allowing businesses to run
their event-driven apps more efficiently. This is crucial for
responsiveness and real-time data processing.

5. Security Features - SAP Event Mesh includes robust security

features like end-to-end encryption and intelligent access control to
ensure that only authorized users may access events and services.

Cons of SAP Event Mesh

1. Complexity of Implementation - Even though SAP Event Mesh

has many sophisticated features, organizations may find it difficult
to set up and maintain, especially if they have little expertise with
event-driven systems.
 2. Cost Considerations—The cost of SAP Event Mesh can be
higher than that of more straightforward integration options, which
might worry smaller businesses or those with tighter budgets.

3. Learning Curve — Because of the advanced features and the

requirement for a thorough understanding of the principles of event-
driven architecture, users may face a steep learning curve that
requires additional training and resources.

4. Resource-Intensive — Implementation and maintenance might

require qualified staff and a sturdy infrastructure to exploit SAP
Event Mesh's potential fully.

5. Potential Overhead for Simple Use Cases - For companies with

simple integration requirements, SAP Event Mesh's sophisticated
features could add needless

7. Advanced Event Mesh and Event Mesh

Use Cases
Use Case for Advanced Event Mesh

1. Real-Time Integration Between SAP and Non-SAP Systems

Use Case: Companies frequently use both SAP and non-SAP

systems in tandem to run their businesses. Real-time integration
between these systems is made possible by SAP Advanced Event
Mesh. For instance, modifications in a non-SAP CRM system can
happen instantaneously in response to an event in a SAP ERP
system, such as creating a new order.

Benefit: Improving efficiency and making decisions more quickly by

automating seamless data synchronization across many platforms.

2. Event-Driven Microservices Communication

Use Case: SAP Advanced Event Mesh can serve as the event broker
for enterprises switching to microservices architecture, allowing
microservices to communicate asynchronously. Multiple services can
publish and consume events, which allows for loose coupling and
scalable communication between them.

Benefits: Flexibility in scaling services independently and

resilience, as services can continue to function even if other services
are temporarily unavailable.
Use Case for Event Mesh

1. Business Process Automation

Use Case: SAP Event Mesh can trigger a workflow based on events
to automate business processes. For instance, an event can start
automatic activities like creating invoices, arranging shipments, and
notifying customers when a new sales order is made.

Benefit: Streamlines company operations through real-time events

and automates manual procedures, increasing productivity.

2. Omnichannel Customer Engagement

Use Case—SAP Event Mesh enables retailers and service providers

to offer a consistent and flawless customer experience across
various channels. For example, an event set off by an in-store
purchase can be sent to online systems to update inventory, loyalty
points, and customer profiles.

Benefits: Provides a consistent and tailored customer experience

by guaranteeing that all touchpoints display real-time information.

8. Pricing of SAP Advanced Event Mesh vs

Event Mesh
The pricing structure of SAP Advanced Event Mesh (AEM) is subscription-
based. It comprises multiple service tiers and SKUs (Stock Keeping Units)
that are customized to meet the requirements of distinct organizations.
The following are the main elements of the pricing model:

Metric Billing Block

Block Price per Description
Size Hour

GB (Storage, 500 EUR 1.26 Gigabyte is the amount of capacity in

in blocks of the Cloud Service.
500 GB)
Tenant (100) 1 EUR 3.09 Supports 100 client connections with
a default message spool size of
10GB.
Tenant (100k) 1 EUR 37.00 Supports 100,000 client connections
with a default message spool size of
500 GB.
 Tenant (10k) 1 EUR 20.00 Supports 10,000 client connections
with a default message spool size of
300 GB.
Tenant (1k) 1 EUR 12.00 Supports 1000 client connections
with a default message spool size of
50 GB.
Tenant (250) 1 EUR 6.22 Supports 250 client connections with
a default message spool size of 25
GB.
Tenant (50k) 1 EUR 30.00 Supports 50,000 client connections
with a default message spool size of
500 GB.
Tenant (5k) 1 EUR 17.00 Supports 5000 client connections
with a default message spool size of
200 GB.

SAP Event Mesh's usage-based pricing structure is intended to meet

various organizational requirements. The following are the main elements
of the pricing model:

Metric Ranges Unit Price

per Description
Month

GB Up to 500 EUR 9.00 Gigabyte is the amount of

(Bandwidth) capacity in the Cloud
Up to EUR 8.00 Service.
1,000
From EUR 7.00
1,000

9. What Is SAP Integration Suite, Advanced

Event Mesh?
The Advanced Event Mesh within SAP Integration Suite is a holistic
platform for event streaming, management, and monitoring. It combines
best practices, expertise, and cutting-edge technology for event-driven
architectures (EDA) into a unified solution. Delivered as a software-as-a-
service (SaaS), it:

 Accelerates EDA Adoption: Provides all the tools to fast-track

your organization's embrace of EDA, enabling you to meet
 contemporary requirements for real-time, intelligent event
streaming.
 Unified Interface: This offers an intuitive platform for designing,
deploying, managing, monitoring, and governing your event
streaming infrastructure—including the events flowing through it—in
the most secure manner possible.

Advanced Event Mesh encompasses services in the following categories:

1. Event Streaming - Mission Control is the hub for event streaming

services. It grants access to event broker services equipped with
advanced features like publish-subscribe messaging patterns,
queuing, streaming, replay capabilities, and request-reply
mechanisms. While you concentrate on developing applications and
enhancing your EDA, Mission Control manages your services'
dynamic deployment, upgrading, patching, and operation.
Engineered for security, resilience, and cost-efficiency, it allows you
to:

 Manage event broker services both in the cloud and on-premises.

 Visualize and design event meshes effortlessly.
 Centralize the management of your EDA securely.
 Scale your EDA initiatives seamlessly.

Despite being offered as a SaaS, Advanced Event Mesh extends its

support beyond the cloud, accommodating infrastructure and EDAs
across hybrid cloud solutions and on-premises deployments. This
provides a cloud-managed solution that can handle event broker
services not only in public and dedicated cloud environments but
also within your virtual private clouds and on-premises setups. Its
architecture parallels how platforms like VMware Tanzu and Google
Anthos provide control planes for Kubernetes.

2. Event Management - Event Portal delivers comprehensive event

management services through a subscription model. It offers robust
tools to create, design, share, and oversee various aspects of your
EDA, whether based on event brokers or other streaming
technologies like Kafka. Key features include:

 Runtime Discovery: Advanced technology for discovering and

cataloging events, schemas, and application interactions within
your EDA.
 AsyncAPI Support: Full compliance with the AsyncAPI 2.0.0
specification, facilitating easy code generation, documentation,
 event validation, and the application of API management policies
for your EDA applications.

3. Event Monitoring and Insights - With Insights, you gain access to

curated dashboards and user-friendly visualizations that present
both historical and real-time metrics. Key benefits include:

 Proactive Issue Identification: Advanced information helps you

spot potential problems before they escalate, ensuring smoother
management as your EDA scales.
 Custom Monitoring: Collaborate with SAP to tailor monitoring
configurations to your specific needs.
 Advanced Visualization: A singular entry point to develop custom
visualizations that align with your organization's requirements.
 Notification Framework: An integrated email notification system
alerts you when critical metrics deviate from your predefined
thresholds. This enables you to monitor ongoing activities and
address emerging issues promptly, preventing any negative
impact on your EDA.
 Integration Capabilities: Configure notifications to seamlessly
integrate with your existing notification and logging systems.

9.1. Subscription Services in SAP Integration Suite,

Advanced Event Mesh
Advanced event mesh for SAP Integration Suite offers various deployment
options and provides a REST API you can use to perform administrative
tasks. In addition, you can choose from a wide range of rich client APIs to
connect to and use event broker services.
Event streaming, event management, and event monitoring are
accessible through an intuitive, unified interface called the Cloud
Console that provides these subscription services :
 Mission Control - Mission Control makes it easy to deploy event
broker services, create event meshes, and optimize and monitor the
health and performance of an event-driven system.

 Event Portal - Event Portal is the single place to design, create,

discover, share, secure and manage all of the events within your
ecosystem.

 Insights—Insights is an advanced monitoring service that allows you

to detect potential issues before they negatively impact your event
 broker services. You can use dashboards to monitor your event broker
services and Insights to receive email notifications.

10. Accessing SAP Integration Suite,

Advanced Event Mesh
1. Login to your SAP BTP Cockpit.

2. Navigate to your Service Marketplace and search for “SAP

Integration Suite, advanced event mesh” Click on Create.

3. Your SAP AEM will be subscribed and will be added into your
Subscription model of SAP BTP.

10.1. Login to Cloud Console

Before you begin, you require a user account to log in to the Cloud
Console. Your advanced event mesh administrator must invite you to get a
user account. Contact your advanced event mesh administrator
or contact SAP.
To use advanced event mesh, you require a supported web browser. For
more information, see Supported Web Browsers.

To start using advanced event mesh, log in to the Cloud Console. From
there, you can take a look around to familiarize yourself with the interface:
 1. Log in to the Cloud Console if you have not yet. The Cloud Console
URL differs based on your SAP BTP region. For more information,
see Logging In to the Cloud Console.

2. If this is your first time logging in, take a tour of the Cloud Console ;
otherwise, jump in and start some other tutorials.

10.2. Create your First Event Broker Service

1. After you log into the Cloud Console, you'll see a welcome page with
a navigation bar on the left-hand side of the page:

On the welcome page, you’ll find Cluster Manager, the tool you'll use to
create and manage your event broker services. When you open Cluster
Manager, the Services page displays the available event broker services.
If you’re using a new account, no services won’t be listed initially. To
create a new event broker service, follow these steps:

1. If you’re not already logged into Advanced Event Mesh, open your
browser and navigate to the Advanced Event Mesh login page.

2. go to the Cloud Console and select Cluster Manager from the

navigation bar once logged in.
3. On the Services page, click Create Service at the top-right corner
or choose the Create Service card.

4. In the Service Name field, enter "MyFirstService."

5. choose a cloud provider, such as Google Cloud, from the Cloud

dropdown list.

6. In the Region list, select a region for the cloud provider you
selected. For your first event broker service, choose the area closest
to your geographical location. For example, choose GKE - US Central
(Iowa) if you live in the United States. The map updates to show the
geographic location of the region you select.

7. Leave the default versions selected in the Broker Release and Broker
Version lists.

8. In the Service Type dropdown list, select Developer. Service types

offer different levels of connectivity, message spooling capacity, and
messaging performance. Refer to the Service Class Options for
Event Broker Services for more detailed information.

9. Once you've made your selections, click Create Service to finalize

the creation of your first event broker service.

Congratulations! You’ve successfully created your first event broker

service. Next, let’s explore the service’s details to access important
information such as connection details and other key configurations for
your service.
10.3. Try Out Your Event Broker Service

1. First, log in to the Cloud Console. The URL for accessing the console
will vary depending on your SAP BTP region. For detailed steps, refer
to the guide on Logging In to the Cloud Console.

2. In the Cloud Console, navigate to the Cluster Manager from the

main menu.

3. On the Services page, locate and click the card for your event broker
service to view its details.

4. Go to the "Try-Me!" tab within the Service Details page.

5. Click on "Open SAP Broker Manager."

6. In the Publisher panel, under the "Establish Connection" section,

click to expand the panel.

7. To establish a connection to the event broker service, enter the

connection details from the Service Details page into the Broker
Manager:

- Copy and paste the "Client Username" into the corresponding

field.
- Similarly, copy and paste the "Client Password" into its
respective field.

8. In the Subscriber panel, click Connect.

9. Check that beside the Establish connection text, the previously red
link icon changes to a green, which indicates that
the Publisher and Subscriber applications are correctly connected.

9.3.1Subscribe to a Topic
In the Subscriber panel, under "Topic Subscriber," click the "Subscribe"
button to subscribe to the `flight/>` topic. Once subscribed, the topic will
appear in the list.

You can also explore the suggested topics under the "Suggestions" section
or enter your own topic in the text box. For more details on how topics
work, refer to the guide on Understanding Topics.
9.4. Create your First Queue
To create a queue, follow these steps:

1. Log in to the Cloud Console if you haven’t already. The URL for
accessing the Cloud Console may vary depending on your SAP BTP
region. For more details, refer to the guide on Logging In to the
Cloud Console.

2. From the navigation bar, click on “Cluster Manager”.

3. On the “Services” page, select the card for your event broker
service to view its details.

4. Go to the “Manage” tab on the service details page.

5. Click on the “Queues” tile.

6. Click the *+Queue* button to create a new queue.

 7. Enter a name for your queue and click “Create”. You can use most
characters in the name, including spaces. However, certain
punctuation marks (`<>*?&;`) are restricted, and a slash (/) cannot
be the first character.

8. On the “Edit Queue Settings” page, click “Apply” to accept the

default settings.

9. Your new queue will now appear on the summary page, initially
showing zeros (0) in both the "Messages Queued" columns, as the
queue is currently empty.

9.4.1. Map a Topic to a Queue

To subscribe a topic to a queue, follow these steps:
1. From the queue summary, click on the row of the queue you want to
configure to access its Queue Detail page.
2. In the Queue Detail page, go to the Subscriptions tab.
3. On the Subscriptions tab, click +Subscription to add a new
subscription.
4. Enter the topic name try-me (the default topic for the Try Me! tool)
in the subscription field, then click Create.
The topic try-me is now mapped to the queue. Any messages published to
that topic will be directed into the queue for processing. This provides
more flexibility than directly publishing to the queue by name.

9.4.2. Publish a message in a Queue

To publish a message to the queue using the Broker Manager Try Me! tool,
follow these steps:
1. Navigate to the Try Me! tab:
o In the Service Details page, select the Try Me! tab.
2. Connect to the Event Broker Service:
o Copy the Client Username and Client Password from the
Service Details page.
o Paste these credentials into the Broker Manager under the
Establish Connection section.
3. Connect:
o In the Publisher panel, click Connect.
o Confirm that the publisher is successfully connected by
checking the connection status.
4. Publish a Message:
o In the Publisher panel, click Publish to send a message, using
try-me as the topic name.
This will publish the message to the queue associated with the try-me
topic.

9.4.3. Confirm message is in the Queue

In Broker Manager, you can confirm that the message is in the queue.
1. In the Broker Manager, on the Queues page, your queue is listed on
the summary page.
2. Ensure that the “Messages Queued” column displays "1" (or a
higher number if you published more messages) and confirm that
the “Messages Queued Quota (MB)” column shows a non-zero value.
9.5. Consume Message from Queue
1. Log in to the Cloud Console (URL depends on your SAP BTP region).
Refer to Logging Into the Cloud Console for more information if
needed.

2. From the navigation bar, select Cluster Manager.

3. Choose the event broker service you want to configure.

4. On the Service Details page, select the Try Me! Tab.

5. Click Open Broker Manager.

6. In Broker Manager, on the left navigation bar, select Try Me!.

7. In the Publisher panel, under the Establish Connection section, click

the expand icon.

8. Enter the connection details from the Service Details page:

9. Copy and paste the Client Username into the corresponding field.

10. Copy and paste the Client Password into the corresponding
field.

11. In the Subscriber panel, click the expand icon under the
Establish Connection section and confirm that "Same as Publisher"
is selected for each field.

12. Under the Publisher panel, click Connect.

13. Once the connection is established, click Connect in the

Subscriber panel as well.

14. In the Subscriber panel, click Bind to an endpoint to receive

guaranteed messages to expand the section.

15. If you changed the Subscriber queue to a queue you created

on the event broker service, change the Publisher queue to match it.

16. Under the Publisher panel, click Publish. The messages will
appear at the bottom of the Subscriber panel.

17. To consume guaranteed messages from a queue:

 Type the queue name (e.g., use the default queue name or the
one you created earlier).
  Click Start to Consume to begin consuming messages from the
queue.

18. To stop consuming messages from the queue, click Stop

Consume.

9.6. Design your Event-Driven Architecture

Ensure you have a user role with sufficient permissions for the Event
Portal. At a minimum, you will need the “Event Portal Manager” role to
complete this tutorial. If you cannot access the Event Portal, contact your
Administrator to request an update to your permissions.

9.6.1. Create an Application Domain

To create an application domain in Designer, follow these steps:

1. In the Cloud Console, click the Designer card or the icon in the left
navigation bar.

2. Click Create Application Domain.

3. In the Name field, enter "Tutorial".

4. add a description such as "Application domain for my tutorial" in the

Description field.

5. Check the option "All topic addresses within this application domain
must be unique." This ensures that each event has a unique topic
address, which helps organize your topic hierarchy.

6. To specify a topic domain, follow these steps:

 From the Broker Type list, select Solace.

 In the Topic Domain field, enter "learn/designer".
 Check All topic addresses within this application domain must
use a topic domain to ensure that every event in the
application domain starts with a topic domain. This option
becomes available after you create a topic domain.

7. Click on Save.
9.6.2. Create an Event
To create an event in your newly created application domain, follow these
steps:
1. In the list of Application Domains, click the name of the application
domain you just created.
2. Since the new domain contains no objects, click Add Objects.
3. Under Solace Objects, drag a new Event to the middle of the graph.
4. Under the Name field, type "My First Event."
5. Select the event icon and click Edit in the panel that appears.
6. Check the option Allow event to be shared across application
domains to make it available to other application domains.
7. Leave the Version field set to 0.1.0, allowing for future versions
during development.
8. Leave the Version Name field blank.
9. In the Description field, type "The first event in my tutorial."
10. Click Save.
11. Click Open Event to open the event details.
12. Click Edit This Version.
13. In the Topic Address field, select the topic domain
learn/designer and add /event to complete the topic address.
14. Click Select Schema to define the event's schema.
15. Choose Primitive and from the list of primitive types, select
String.
16. Click Select Primitive.
17. Close the Select Schema panel.
18. Finally, click Save & Close to save your event configuration.
This will create your first event in the application domain and associate it
with the specified topic address and schema.

9.6.3. Create Applications

To create an application that publishes the event, follow these steps:
1. Right-click on the graph to the left of your event.
 2. Under New Solace Objects, select Application.
3. Under the Name field, type "My First Application."
4. Select the application icon and click Edit in the existing panel.
5. Leave the Version field set to 0.1.0 (this allows for multiple versions
during development).
6. Leave the Version Name field blank.
7. type "Application to publish my first event" in the Description field.
8. Click Save.
9. Hover over the application until an arrow appears, then drag the
arrow towards the event.
10. You will now see the application and the event connected by a
line. The arrow pointing to the event shows that the application
publishes the event. Other applications can subscribe to this event
to receive its data.
Instead of creating another application to subscribe to the event, you can
import a sample application domain to explore event flows more deeply in
Designer.

9.6.4. Import Objects

To import a sample application domain, follow these steps:
1. In a new browser tab, navigate to the Event Portal Samples page on
GitHub.
2. Go to the retail > solace > sample-domain folder and download the
file solace_ep_acmeretail_storeoperations.json.
3. Return to the Event Portal browser tab.
4. At the top of the page, click Designer in the breadcrumb to return to
the application domain list.
5. On the Application Domains page, click More Actions and select
Import Application Domains.
6. Select the JSON file you downloaded
(solace_ep_acmeretail_storeoperations.json).
7. Click Open.
8. After the import completes, you’ll see four new application domains
in Designer.
Now, you can explore one of the imported application domains to learn
more about designing an event flow.
9.7. Create a Model of Your Event-Driven Architecture
This guides you through using objects in the Event Portal to create and
visualize a model of your event-driven architecture (EDA). A modeled
event mesh represents the event flows operating in a specific runtime
environment. These meshes help you define and visualize how events are
exchanged between publishing and subscribing applications within your
EDA.

You can build modeled event meshes using the objects you create in
Designer and those imported into the Event Portal. These event meshes
are created within environments, representing different runtime settings
in your organization. For instance, you may have separate development
environments for various business lines and testing, staging, and
production environments.

9.7.1. Create Modelled Event-Mesh

To create your first Modelled event mesh in Runtime Event Manager,
follow these steps:
1. In the Cloud Console, click the Runtime Event Manager card or the
icon in the left navigation bar.
2. Click Create Modelled Event Mesh.
3. In the Modelled Event Mesh Name field, type "Tutorial."
4. Select Solace as the Modelled event mesh Type.
5. In the Description field, add details about the Modelled event mesh,
such as "Model of my Tutorial event flows".
6. In the Environment list, select Default. (All new advanced event
mesh accounts come with a Default environment, but you can
create additional environments later if needed.)
 7. Click on Create.
You can start modeling your event flows or connecting the Event Portal
with your runtime environment.

9.7.2. Add Event Brokers to Your Modeled Event Mesh

To add event brokers to your modeled event mesh, follow these steps:
1. In the Modeled Event Meshes list, click Tutorial to open the modeled
event mesh you just created.
2. Select the Event Broker Connections tab.
3. In the top-right corner, click Connect Event Broker.
4. Click New Event Broker.
5. We're going to create a placeholder event broker:
 In the Name field, type "Placeholder".
6. Click Connect Event Broker. The Placeholder event broker will be
added to the modeled event mesh. Its details are on the Event
Broker Connections tab.
7. To add an event broker for an existing event broker service:
 In the top-right corner, click Connect Event Broker again.
 Select the checkbox next to My-First-Service. If multiple event
brokers are listed, use the Search field to find the desired
event broker service.
 Note: If My-First-Service doesn't appear, it might be because the
tutorial for creating the first event broker service hasn't been
completed or it has already been added to another modeled event
mesh. You can continue the tutorial without adding it.
8. Click Add or Cancel to close the dialog box without adding an event
broker service.
9. The Event Broker Connections tab shows the details of the event
brokers that have been added to the modeled event mesh.
10. Now, click the Architecture tab. Add objects (application and
event versions) to your modeled event mesh.

9.7.3. Add Applications to a Modeled Event Mesh

To add application versions to your modeled event mesh from Designer,

follow these steps:
1. click the Designer icon on the left navigation bar in the Cloud
Console.
2. In the Application Domains list, click Fulfillment, which you imported
into Designer in the previous tutorial.
3. right-click the Fraud Service application in the graph view and select
View Details.
4. Click Open Application.
5. Select the Runtime tab.
6. The Runtime tab will display the event brokers available to add the
application to in each environment.
7. Under the Default environment, click Add Application for the
Placeholder event broker.
8. In the Application version, to add a list, keep the latest version
selected and click Add.
9. You'll see the version you added for the Placeholder event broker in
the Application Version column. Note: Only one version of an
 application can be associated with an event broker in a modeled
event mesh. Adding a different version will replace the previous one.
10. Now, to add more applications, click the Details tab.
11. click More Actions for the Order Created event in the Event
Flows section and select Open Event.
12. In the Referenced By section of the event details, you’ll see all
applications that publish and subscribe to the Order Created event
version.
13. Notice that five applications subscribe to the event, and one
publishes it. We've already added the Fraud Service application to
the modeled event mesh. Next, we'll add the remaining subscribing
applications.
14. Click More Actions for the Email Service application and select
Open Application.
15. Select the Runtime tab.
16. Under the Default environment, click Add Application for the
Placeholder event broker.
17. In the Application version, to add a list, keep the latest version
selected and click Add.
18. Repeat steps 8-12 to add the Order Details Service application
to the modeled event mesh.
19. Repeat steps 8-12 for each remaining subscribing application
in the list. Select More Actions for each application you want to add
and follow the steps to include it in the modeled event mesh.
Following these steps, you’ll successfully add all relevant applications that
subscribe to and publish the Order Created event, building out your
modeled event mesh.
10.Features of SAP Advance Event Mesh
Here’s a detailed explanation of each key feature of SAP Advanced
Event Mesh (AEM):
1. Dynamic Message Routing: AEM automatically routes messages
between interconnected event brokers, ensuring seamless event
flow across regions. This allows enterprises to efficiently manage
complex, distributed, event-driven architectures without manual
routing.
2. High Availability (HA) and Disaster Recovery (DR): By
leveraging broker failover groups and replication across locations,
AEM provides continuous service uptime and ensures minimal data
loss in case of failures or disasters.
3. Distributed Tracing Tracks visualize event flow across brokers and
applications, helping developers monitor message lifecycles and
troubleshoot potential real-time issues.
4. Event Replay: This feature allows past events to be replayed on
demand, enabling users to reprocess specific messages for auditing,
debugging, or retraining systems. It ensures better fault tolerance
and data recovery.
5. Kafka and MQTT Bridges: AEM provides integration bridges for
Apache Kafka and MQTT-based systems. These bridges enable the
seamless exchange of messages between different messaging
protocols, thus extending AEM's functionality for hybrid
environments.
These features ensure that SAP AEM supports resilient, scalable, and
flexible event-driven architectures suited to modern enterprise needs.
11.Security in SAP Integration Suite,
Advanced Event Mesh
Security in SAP Integration Suite, Advanced Event Mesh is designed to be
robust and secure at all levels, protecting your event-driven architecture
(EDA) and data. Here’s a summary of the security features:
1. Secure Cloud Architecture
 Deployment Options: You can deploy services in:
o Public Regions: Applications connect over the public
Internet.
o Dedicated Regions: Private regions dedicated to a customer,
with applications connecting from a private network.
o Customer-Controlled Regions: Complete control over
infrastructure using a Kubernetes cluster.
 Security responsibilities vary based on the deployment option, with
more control given to the customer as you move from Public to
Customer-Controlled Regions.
2. VPC/VNet Isolation
 Event broker services can be deployed in an isolated Virtual
Private Cloud (VPC) or Virtual Network (VNet), ensuring
additional security for environments where:
o Access from the public Internet is not desired.
o Data sovereignty and isolated infrastructure are required.
3. Authentication and Authorization of Client Applications
 Messaging applications connect to event brokers for data
exchange (e.g., publish/subscribe).
 Management applications: Used for monitoring and managing
event broker services.
 Granular control allows for tight control over how these applications
authenticate and are authorized to access broker services.
4. Authentication and Authorization of Users in the Cloud Console
 Users are authenticated and authorized to create, monitor, and
design event broker services through a management system that
assigns specific permissions.
5. Customer Data Protection
 Data is separated into two planes:
o Control Plane: For management and monitoring data.
o Messaging Plane: For messaging data between event broker
services and customer applications.
 Data is encrypted both in transit and at rest using AES-256 and
TLS 1.2, ensuring maximum security for both control and
messaging planes.
6. Audit Logs and System Logs
 Full logs and system notifications, including:
o Audit logs for security-related access.
o System logs of event broker services accessible via SysLog
Forwarding.
 Logs contain no personally identifiable information and are used to
monitor system health.
7. Compliance with Industry Standards
 SAP Integration Suite, Advanced Event Mesh complies with several
industry standards:
o ISO/IEC 27001:2013 certification.
o Cloud Security Alliance (CAIQ v3.1).
o SOC 2 Type 2 audit.
o HIPAA compliance with the Business Associate Agreement
(BAA).
o GDPR compliance for data protection and privacy.
8. Considerations for Additional Security
 Advanced Event Mesh is secure by default, but additional security
configurations and updates can be applied based on your
infrastructure requirements. For those needing enhanced security,
recommendations for hardening deployments are available.
These features ensure your data and event architecture remain secure,
compliant, and resilient within the SAP Integration Suite Advanced Event
Mesh environment.
 12. Sample AEM sender and receiver

Sample AEM Sender

Sample AEM Receiver

 13. Steps to Configure SAP Event Mesh
SAP Event Mesh enables asynchronous communication by allowing
decoupled systems to exchange event messages. This guide outlines the
steps to configure SAP Event Mesh for use within your SAP Business
Technology Platform (BTP).
Step 1: Provision the Event Mesh Service in SAP BTP
1. Navigate to the BTP Cockpit: Access your SAP BTP global account
and go to the subaccount where you want to configure the Event
Mesh.

2. Enable the Event Mesh Service: In the subaccount, under the

'Service Marketplace', search for 'Event Mesh'. Create and configure
a service instance based on your requirements (plan selection,
name, etc.).
 3. Generate Service Keys: Generate service keys after the instance is
created. These will be needed for authentication when connecting to
the Event Mesh service.

Step 2: Create Event Queues and Topics

1. Access the Event Mesh Dashboard: Once the service is up, go to the
Event Mesh Management UI via the SAP BTP Cockpit.

2. Create a Queue: Define a queue for processing messages. You can

set properties such as retention time and maximum number of
messages.
Step 3: Configure SAP CPI for Integration with Event Mesh
1. Open SAP Integration Suite (CPI): In your SAP Integration Suite
tenant, create a new iFlow (integration flow) to send or receive
messages to/from Event Mesh. We will create an iflow to post the
data into the datastore using POSTMAN.

2. Create a new iflow to send the data from Data Store to SAP EM using
AMQP adapter.
3. Add AMQP Adapter: In the iFlow, select the AMQP (Advanced
Message Queuing Protocol) adapter for connecting to Event Mesh.
This adapter allows your iFlow to communicate asynchronously with
Event Mesh using standard messaging protocols.
4. Configure the AMQP Adapter:
o Set the Connection Details using the service keys generated
earlier.
o Provide the Queue Name where messages will be consumed
from or produced to.
o Set any additional parameters such as maximum retries,
acknowledgments, and delivery settings.
Step 4: Set Up OAuth2 for Authentication
1. Create an OAuth2 Client in CPI: Go to the Security Materials section
and create an OAuth2 credential in SAP CPI. Use the client ID, client
secret, and other details from the service keys of your Event Mesh
instance.
2. Apply OAuth2 Credentials: Link this OAuth2 credential to the AMQP
adapter in the iFlow to ensure secure communication between your
SAP CPI instance and Event Mesh.
3. Create the new iflow, in which we will take the message from the
SAP Event Mesh and bring back to SAP CPI. Configure the AMQP
sender adapter here.
Step 5: Deploy and Test the Integration Flow
 Deploy the iFlow: After configuring the AMQP adapter and setting up
the message queue, deploy the iFlow in CPI.
 Monitor Messages: In SAP CPI and the Event Mesh dashboard,
monitor the flow of messages and events. CPI provides message
processing logs, and Event Mesh shows message statistics and any
errors in the queue.
Step 6: Monitor and Manage Event Mesh
 Monitor Event Mesh Queues: Regularly check the Event Mesh
Management UI for queue and topic health. You can view statistics
such as the number of messages processed, retention, and failure.
 Retry Mechanisms: Configure retry settings within the AMQP adapter
or in Event Mesh to ensure failed messages are reprocessed as
necessary.
This configuration enables event-driven communication between
applications, ensuring asynchronous, decoupled integration.