SAP Event Mesh — Part 1: Event-Driven Architecture & Setup
*A 3-part hands-on series on SAP Event Mesh: Event-Driven Architecture, Pub-Sub, and CPI integration.*
> **Series at a glance**
> – **Part 1 (this post):** EDA concepts + provisioning the Event Mesh instance, queues, subscriptions, and service key
> – **Part 2:** Testing with Postman + CPI iFlow configuration (publish & consume)
> – **Part 3:** Common errors, fixes, and a quick-reference cheat sheet
>
> **Environment used in this series:** SAP BTP — AP11 (Asia Pacific) · Namespace `S4HC/Testing/Masterdata` · March 2026
—
## Why this series
Most SAP integration developers learn point-to-point patterns first — RFC, SOAP, OData. They work, but they tightly couple systems together. The moment you need a *second* system to react to the same business event, you end up duplicating calls and adding brittle dependencies.
SAP Event Mesh flips that model. In this first post we’ll cover the architectural concepts you need, then walk through provisioning Event Mesh end to end so it’s ready for the integration work in Part 2.
—
## 1. Event-Driven Architecture (EDA) — Core Concepts
### 1.1 What is Event-Driven Architecture?
Event-Driven Architecture (EDA) is a software design pattern in which systems communicate by **producing and consuming events**. Instead of calling each other directly (RFC, SOAP, OData), systems publish events to a central hub, and any interested system subscribes to those events.
Why EDA over traditional integration:
– **Loose coupling** — systems don’t need to know about each other
– **Scalability** — multiple subscribers can consume the same event
– **Resilience** — if a subscriber is down, events wait safely in the queue
– **Real-time processing** — events are handled as they happen
### 1.2 How Event Mesh works — the Pub-Sub flow
“`
PUBLISHER SAP EVENT MESH SUBSCRIBERS
───────────── ──────────────────── ────────────────
TOPICS
S/4HANA Cloud ── publish ──► CustomerMaster
(Event Source) SupplierMaster
│
routed to
▼
QUEUES
Q: shopify ── subscribe ──► Shopify
Q: c4c ── subscribe ──► C4C / SAP Sales
Q: 3pl ── subscribe ──► 3PL System
DMS / Archive
“`
**Flow explained:**
1. S/4HANA Cloud (the **publisher**) sends an event to a **topic** (e.g. `CustomerMaster`).
2. Event Mesh receives the event and routes it to every **queue** subscribed to that topic.
3. Each subscriber system (Shopify, C4C, 3PL) has its own queue.
4. Consumer systems pull messages from their own queue, independently of each other.
The key insight: one publish can fan out to many consumers, and each consumer reads at its own pace.
### 1.3 The three types of events
| Event Type | Description | Example |
|—|—|—|
| **Notification Event** | A lightweight signal that something happened. No payload data. | Business Partner created in S/4HANA |
| **Data Event** | Carries the actual changed data payload. | Customer Master record with all fields |
| **Transaction Event** | Represents a complete business transaction. | Sales Order confirmed with all line items |
### 1.4 Key terminology
| Term | Meaning |
|—|—|
| **Topic** | A named channel where publishers send events. All queues subscribed to a topic receive the event. Topics follow the namespace pattern. |
| **Queue** | A message store for a specific subscriber. Each consumer system (Shopify, C4C…) gets its own queue. |
| **Namespace** | A prefix that groups topics and queues. Example: `S4HC/Testing/Masterdata`. All topics must follow the namespace rules. |
| **Publisher** | The system that sends events (e.g. S/4HANA Cloud, a CPI iFlow). |
| **Subscriber / Consumer** | The system that receives events by listening to a queue. |
| **Pub-Hub Model** | SAP’s term for the central Event Mesh hub through which all messages pass. |
| **EMIS** | Event Mesh Integration Suite — the embedded Event Mesh inside SAP Integration Suite. Same concept, different access path. |
—
## 2. SAP Event Mesh — Setup Steps
> ℹ️ **EMIS vs. standalone:** EMIS (Event Mesh Integration Suite) is the embedded version inside SAP Integration Suite. It behaves the same as standalone Event Mesh — you just access it through the Integration Suite client.
### Step 1 — Create the Event Mesh instance in your sub-account
1. In **SAP BTP Cockpit**, navigate to your sub-account.
2. Go to **Services → Service Marketplace** and search for **Event Mesh**.
3. Create a new instance with a service descriptor like this:
“`json
{
“resources”: { “units”: “10” },
“options”: { “management”: true, “messagingrest”: true, “messaging”: true },
“rules”: {
“topicRules”: {
“publishFilter”: [“${namespace}/*”],
“subscribeFilter”: [“${namespace}/*”]
},
“queueRules”: {
“publishFilter”: [“${namespace}/*”],
“subscribeFilter”: [“${namespace}/*”]
}
},
“version”: “1.1.0”,
“emname”: “S4_RudhTesting”,
“namespace”: “S4HC/Testing/Masterdata”
}
“`
> ✅ **Tip:** The namespace `S4HC/Testing/Masterdata` means **all** topics and queues must start with this prefix. The `${namespace}/*` filters allow any topic or queue under that namespace.
### Step 2 — Create queues
Each consuming system needs its own queue. In the Event Mesh dashboard:
1. Open the Event Mesh dashboard (`S4_RudhTesting`).
2. Go to the **Queues** tab.
3. Click **Create Queue** for each consumer:
– `S4HC/Testing/Masterdata/Shopify` — for Shopify integration
– `S4HC/Testing/Masterdata/C4C` — for C4C / SAP Sales Cloud
– `S4HC/Testing/Masterdata/3pl` — for the 3PL / logistics system
> 📝 **Note:** Queue names must start with your namespace prefix. Each queue is independent — one message published to a topic lands in **all** subscribed queues.
### Step 3 — Subscribe queues to topics
Once the queues exist, subscribe each one to the relevant topic(s):
1. Click a queue → click the subscription icon → **Queue Subscriptions**.
2. Enter the topic name to subscribe to. For example:
– Queue `…/Shopify` → Topic `S4HC/Testing/Masterdata/Shopify/CustomerMaster`
– Queue `…/C4C` → Topic `S4HC/Testing/Masterdata/C4C/CustomerMaster`
> ⚠️ **Topic names are CASE-SENSITIVE.** `CustomerMaster` and `customermaster` are different topics. Always match the exact case you configured. (This bites people later in CPI — more on that in Part 3.)
### Step 4 — Create a service key
The service key holds the credentials (OAuth2 client ID, secret, token endpoint, and API URIs) external apps use to connect to Event Mesh.
1. In BTP Cockpit, open your Event Mesh service instance.
2. Click **Create Service Key** and give it a name.
3. Copy / download the JSON — this is your connection credential.
**Service key — the fields that matter:**
| Field | What it’s for |
|—|—|
| `namespace` | Your event namespace prefix: `S4HC/Testing/Masterdata` |
| `management.uri` | Hub backend URL for managing queues via REST API |
| `management.oa2.tokenendpoint` | OAuth2 token URL for management-API authentication |
| `messaging[httprest].uri` | REST endpoint for publishing messages via HTTP POST |
| `messaging[amqp10ws].uri` | WebSocket endpoint for AMQP connections (used in CPI) |
| `uaa.clientid` | OAuth2 Client ID — used in all authentication calls |
| `uaa.clientsecret` | OAuth2 Client Secret — **keep this secret; rotate immediately if exposed** |
> 🔒 **Security note for anyone publishing this:** Never paste a real `clientsecret`, `clientid`, or your tenant-specific token-endpoint subdomain into a public post. Treat the service key like a password. In all examples in this series, those values are placeholders.
—
## What’s next
You now have a provisioned Event Mesh instance, queues bound to topics, and a service key with the credentials you’ll need. In **Part 2**, we’ll prove the setup works with Postman, then wire up the real integration in CPI — an HTTP iFlow to publish and an AMQP iFlow to consume.
*Found this useful? Part 2 covers the hands-on CPI integration, and Part 3 is a troubleshooting cheat sheet built from real errors.*
—
*Tags: SAP Event Mesh, Event-Driven Architecture, SAP BTP, Integration Suite, Pub-Sub, S/4HANA Cloud*
Read More Technology Blog Posts by Members articles
#abap