SAP Event Mesh & Advanced Event Mesh Capabilities

TL;DR

• Bottom line: SAP offers three event broker tiers on BTP — Event Broker (basic, included with BTP license), Event Mesh (mid-tier, 1 MB messages, AMQP/MQTT/REST), and Advanced Event Mesh (enterprise-grade Solace-powered, 30 MB messages, 7 service classes up to 100K connections). Choose based on message size, throughput, and deployment flexibility needs. [src1, src3]
• Key limit: Event Mesh caps messages at 1 MB and storage at 10 GB; Advanced Event Mesh allows up to 30 MB messages and 1 TB spool storage (Broker 100K tier). [src1, src2]
• Watch out for: Event Mesh is BTP-only with limited monitoring; if you need on-premise brokers, multi-cloud mesh, or message replay, you must use Advanced Event Mesh. [src3]
• Best for: Event-driven integrations between S/4HANA and BTP extensions, microservice decoupling, and real-time business event distribution across SAP and non-SAP systems. [src5]
• Authentication: OAuth 2.0 client credentials via SAP BTP Service Manager; message clients bound to service instances with namespace-scoped permissions. [src5]

System Profile

SAP provides three event-driven messaging services on BTP, each targeting different complexity and scale requirements. SAP Cloud Application Event Hub (Event Broker) is the entry-level option included with BTP licenses, handling up to 75 million transactions. SAP Event Mesh (formerly Enterprise Messaging) is the mid-tier offering supporting open protocols with a 1 MB message size cap. SAP Integration Suite, Advanced Event Mesh (AEM) is the enterprise-grade solution powered by Solace PubSub+ with up to 30 MB messages and on-premise support. [src3]

API Surfaces & Capabilities

Event Mesh focuses on open web protocols over WebSocket, while AEM adds enterprise protocols (JMS, SMF) and native WebSocket support via the Solace stack. [src4, src2]

Rate Limits & Quotas

SAP Event Mesh — Default Plan Limits

SAP Advanced Event Mesh — Service Class Limits

Note: Broker 1K supports 10 MB max message on firmware v10.25.8.3179-18 and earlier, 30 MB on v10.25.8.3179-20+. [src2]

Authentication

Authentication Gotchas

• Event Mesh message clients are scoped to a namespace — cross-namespace consumption requires explicit subscription configuration. [src5]
• AEM client usernames are per-Message VPN. Max simultaneous connections per username applies across ALL protocols (SMF, AMQP, MQTT, REST). [src2]
• BTP service keys contain separate httprest, amqp10ws, and mqtt311ws protocol endpoints — use the correct one. [src5]

Constraints

• Event Mesh is BTP-cloud-only. On-premise or multi-cloud mesh requires Advanced Event Mesh. [src3]
• Event Mesh max message size is 1 MB including headers. Messages exceeding 1 MB are rejected. [src1]
• Event Mesh storage capped at 10 GB. For high-volume scenarios, use AEM (up to 1 TB spool). [src3]
• AEM Broker 100 (Developer) has only 100 connections — not suitable for production. [src2]
• Event Mesh available under CPEA licensing only; not standalone under BTPEA. [src3]
• AEM enterprise connections cap at 30,000 even on Broker 50K/100K tiers. [src2]
• Webhook max 9 unacknowledged messages before backpressure. [src7]
• S/4HANA business events are notification-only by default. Full-state events require Event Add-On. [src3]

Integration Pattern Decision Tree

START — Need event-driven integration in SAP landscape
|-- What scale do you need?
|   |-- Simple SAP cloud-to-cloud eventing (<10 GB, <1 MB messages)
|   |   |-- CPEA license? YES -> Event Mesh | NO (BTPEA) -> Event Hub
|   |   |-- Need webhook push? YES -> EM + webhook (max 9 unacked)
|   |   '-- No webhook? -> EM with AMQP/MQTT consumer
|   |-- Enterprise-grade (>1 MB, >10 GB, or >50 connections)
|   |   |-- Messages > 1 MB? -> Advanced Event Mesh
|   |   |-- Need on-prem broker? -> Advanced Event Mesh (only option)
|   |   '-- Need event replay? -> Advanced Event Mesh
|   '-- IoT / high-volume (>10K connections)
|       '-- Advanced Event Mesh Broker 10K or higher
|-- Which protocol?
|   |-- AMQP 1.0 -> Both EM and AEM
|   |-- MQTT 3.1.1 -> Both EM and AEM
|   |-- HTTP REST -> Both EM and AEM
|   |-- JMS -> AEM only
|   '-- SMF -> AEM only (highest throughput)
'-- S/4HANA business events?
    |-- Notification (no payload) -> Standard, EM or AEM
    |-- Full-state (with payload) -> Need Event Add-On for ERP
    '-- Custom events -> RAP business events or CAP-based

Quick Reference

Step-by-Step Integration Guide

1. Create an Event Mesh Service Instance on BTP

Create a service instance in the BTP Cockpit or via the CF CLI. [src5]

# Create service instance via CF CLI
cf create-service enterprise-messaging default my-event-mesh \
  -c '{"emname":"my-event-mesh","namespace":"sap/btp/myapp","version":"1.1.0","options":{"management":true,"messagingrest":true,"messaging":true}}'

# Create a service key for credentials
cf create-service-key my-event-mesh my-key
cf service-key my-event-mesh my-key

Verify: cf service my-event-mesh -> expected: status: create succeeded

2. Obtain OAuth Token and Publish a Message (REST)

Use the service key credentials to obtain an OAuth token, then publish. [src4, src5]

# Get OAuth token
TOKEN=$(curl -s -X POST "$TOKEN_URL" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET" \
  | jq -r '.access_token')

# Publish a message to a topic
curl -X POST "$REST_URL/messagingrest/v1/topics/sap%2Fbtp%2Fmyapp%2Forders%2Fcreated" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "x-qos: 1" \
  -d '{"orderId":"ORD-001","status":"created"}'

Verify: HTTP response 204 No Content -> message published

3. Create a Queue and Subscribe to Topics

Create a queue that subscribes to topic patterns. [src5, src7]

# Create a queue
curl -X PUT "$REST_URL/messagingrest/v1/queues/order-processor" \
  -H "Authorization: Bearer $TOKEN"

# Subscribe queue to a topic pattern
curl -X PUT "$REST_URL/messagingrest/v1/queues/order-processor/subscriptions/sap%2Fbtp%2Fmyapp%2Forders%2F%2A" \
  -H "Authorization: Bearer $TOKEN"

Verify: curl "$REST_URL/messagingrest/v1/queues/order-processor" -> queue details with subscription count

4. Consume Messages from Queue

Pull messages from the queue using REST or connect with AMQP/MQTT for push-based consumption. [src4]

# Consume one message (REST pull)
curl -X POST "$REST_URL/messagingrest/v1/queues/order-processor/messages/consumption" \
  -H "Authorization: Bearer $TOKEN" \
  -H "x-qos: 1"

# Acknowledge the message
curl -X POST "$REST_URL/messagingrest/v1/queues/order-processor/messages/acknowledgement" \
  -H "Authorization: Bearer $TOKEN" \
  -H "x-qos: 1" \
  -H "x-message-id: <message-id-from-response>"

Verify: Queue depth decreases by 1 after acknowledgment

Code Examples

Python: Publish and Consume via AMQP 1.0

# Input:  Service key credentials (AMQP endpoint, OAuth token)
# Output: Published message + consumed message from queue

import requests
from proton import Message
from proton.handlers import MessagingHandler
from proton.reactor import Container

def get_token(token_url, client_id, client_secret):
    resp = requests.post(token_url, data={
        "grant_type": "client_credentials",
        "client_id": client_id,
        "client_secret": client_secret
    })
    resp.raise_for_status()
    return resp.json()["access_token"]

class Publisher(MessagingHandler):
    def __init__(self, url, address, token):
        super().__init__()
        self.url = url
        self.address = address
        self.token = token

    def on_start(self, event):
        conn = event.container.connect(
            self.url, user="$consumer",
            password=self.token, sasl_enabled=True)
        event.container.create_sender(conn, self.address)

    def on_sendable(self, event):
        msg = Message(body='{"orderId":"ORD-002"}')
        msg.content_type = "application/json"
        event.sender.send(msg)
        event.sender.close()
        event.connection.close()

JavaScript/Node.js: Consume via MQTT 3.1.1

// Input:  Service key with MQTT endpoint + OAuth token
// Output: Real-time event consumption via MQTT

const mqtt = require("mqtt"); // [email protected]
const client = mqtt.connect(MQTT_URL, {
  username: "$consumer",
  password: TOKEN,
  protocolVersion: 4, // MQTT 3.1.1
  clean: true,
});

client.on("connect", () => {
  client.subscribe("sap/btp/myapp/orders/+", { qos: 1 });
});

client.on("message", (topic, message) => {
  console.log(`Topic: ${topic}, Payload: ${message.toString()}`);
});

cURL: Quick Test — Publish and Check Queue

# Get token
TOKEN=$(curl -s -X POST "$TOKEN_URL" \
  -d "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET" \
  | jq -r '.access_token')

# Publish test message
curl -v -X POST "$REST_URL/messagingrest/v1/topics/sap%2Fbtp%2Fmyapp%2Ftest" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"test":true}'
# Expected: 204 No Content

# Check queue depth
curl -s "$REST_URL/messagingrest/v1/queues/my-queue" \
  -H "Authorization: Bearer $TOKEN" | jq '.queueDepth'

Data Mapping

S/4HANA Business Events to Event Mesh

Data Type Gotchas

• S/4HANA topic hierarchy uses mixed casing: lowercase for path segments, PascalCase for object/action. [src5]
• Notification events contain only the key — you must make a follow-up OData call for the full object. [src3]
• URL-encode topics (%2F) in REST API; use raw / for AMQP and MQTT. [src4]

Error Handling & Failure Points

Common Error Codes

Failure Points in Production

• Queue overflow (storage full): 10 GB Event Mesh storage hit — new messages rejected. Fix: Monitor queue depth; implement consumer auto-scaling; archive processed messages; consider AEM for larger spool. [src1]
• Webhook delivery failure: Non-2xx responses cause retry; messages discarded without DLQ. Fix: Ensure endpoint returns 200 within timeout; configure DLQ for undeliverable messages. [src7]
• Consumer lag on 3-consumer limit: High load bottleneck. Fix: Create multiple queues subscribed to the same topic; or migrate to AEM. [src1]
• Namespace collision: Teams sharing namespace consume each other's events. Fix: Unique namespace per app/team; BTP subaccounts for isolation. [src5]
• OAuth token expiry in persistent AMQP: Long-running connections fail silently. Fix: Reconnect logic with fresh token; set idle timeout shorter than token lifetime. [src4]

Anti-Patterns

Wrong: Sending full business objects as event payloads

# BAD — Sends entire 500 KB sales order; hits 1 MB limit
event = {"type": "SalesOrderCreated", "data": get_full_sales_order(order_id)}

Correct: Send notification with key, fetch on demand

# GOOD — Lightweight notification; consumer fetches full object via OData
event = {"type": "SalesOrderCreated", "data": {"SalesOrder": order_id}}

Wrong: REST polling for real-time consumption

// BAD — Polling every 100ms wastes throughput quota
setInterval(async () => {
  const msg = await fetch(`${REST_URL}/queues/myqueue/messages/consumption`);
}, 100);

Correct: AMQP or MQTT push consumption

// GOOD — Persistent connection, push delivery, proper QoS
client.subscribe("sap/btp/myapp/orders/+", { qos: 1 });
client.on("message", (topic, msg) => processMessage(JSON.parse(msg)));

Wrong: Single catch-all queue for all events

# BAD — No filtering, slow consumers block everything
queue: "catch-all" -> subscription: "sap/btp/myapp/#"

Correct: Dedicated queues per concern

# GOOD — Independent scaling, failure isolation
queue: "order-processor"   -> subscription: "sap/btp/myapp/orders/*"
queue: "invoice-generator" -> subscription: "sap/btp/myapp/invoices/*"
queue: "audit-logger"      -> subscription: "sap/btp/myapp/+/+/+"

Common Pitfalls

• Confusing Event Mesh with Advanced Event Mesh: Separate services with different caps, pricing, and licensing. Fix: Use decision tree above; start with Event Mesh for simple scenarios. [src3]
• Not URL-encoding topics in REST: sap/btp/myapp/orders must be sap%2Fbtp%2Fmyapp%2Forders in REST URLs. Fix: Always encodeURIComponent(); AMQP/MQTT use raw topics. [src4]
• Assuming S/4HANA events include full payload: Business events are notification-only by default. Fix: Design consumer to fetch full object via OData after event. [src3]
• Hitting 3-consumer limit under load: Only 3 consumers per queue connection. Fix: Multiple queues on same topic; competing consumers pattern; or upgrade to AEM. [src1]
• Ignoring namespace scoping: Multi-team namespace collisions. Fix: Assign unique namespace per application; use BTP subaccounts for hard isolation. [src5]
• No dead letter queue configured: Failed messages discarded silently. Fix: Always configure DLQ for production queues; monitor DLQ depth. [src7]

Diagnostic Commands

# Check Event Mesh service instance status
cf service my-event-mesh

# List all queues and their depth
curl -s "$REST_URL/messagingrest/v1/queues" \
  -H "Authorization: Bearer $TOKEN" | jq '.[]|{name,queueDepth,consumers}'

# Check specific queue details
curl -s "$REST_URL/messagingrest/v1/queues/order-processor" \
  -H "Authorization: Bearer $TOKEN" | jq '.'

# List topic subscriptions for a queue
curl -s "$REST_URL/messagingrest/v1/queues/order-processor/subscriptions" \
  -H "Authorization: Bearer $TOKEN" | jq '.[]'

# Test publish (should return 204)
curl -v -X POST "$REST_URL/messagingrest/v1/topics/sap%2Fbtp%2Fmyapp%2Fhealth" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"ping":true}'

# Check OAuth token validity
curl -s "$TOKEN_URL/tokeninfo" \
  -H "Authorization: Bearer $TOKEN" | jq '.expires_in'

Version History & Compatibility

When to Use / When Not to Use

Cross-System Comparison

Important Caveats

• SAP has three distinct event services (Event Broker, Event Mesh, Advanced Event Mesh) that are frequently confused. Always verify which service is being discussed in documentation and community posts.
• Event Mesh pricing is consumption-based under CPEA. Costs scale with resource units (RUs), which bundle connections, queues, and storage. [src6]
• AEM service class limits are enforced per broker instance. Limits cannot be increased on an existing tier — you must provision a higher-tier broker. [src2]
• S/4HANA Cloud exposes 600+ business events, but S/4HANA On-Premise has a smaller event catalog. Check the SAP Business Accelerator Hub for your version.
• All limits in this card are current as of March 2026. SAP may change service class limits, message size caps, or licensing models — verify against official documentation before architecture decisions.