---
# === IDENTITY ===
id: business/erp-integration/sap-event-mesh-capabilities/2026
canonical_question: "What are SAP Event Mesh and Advanced Event Mesh capabilities - message size, protocols, queue limits?"
aliases:
  - "SAP Event Mesh vs Advanced Event Mesh comparison"
  - "SAP BTP event broker message size limits and protocols"
  - "SAP Event Mesh AMQP MQTT REST protocol support"
  - "SAP Advanced Event Mesh Solace service class limits"
entity_type: erp_integration
domain: business > erp-integration > SAP Event Mesh Capabilities
region: global
jurisdiction: global
temporal_scope: 2024-2026

# === SYSTEM PROFILE ===
systems:
  - name: "SAP Event Mesh"
    vendor: "SAP"
    version: "Default Plan (BTP)"
    edition: "Default / Premium"
    deployment: cloud
    api_surface: "AMQP 1.0, MQTT 3.1.1, HTTP REST, Webhook"
  - name: "SAP Integration Suite, Advanced Event Mesh"
    vendor: "SAP / Solace"
    version: "Solace PubSub+ Cloud"
    edition: "Broker 100 to Broker 100K"
    deployment: hybrid
    api_surface: "AMQP 1.0, MQTT 3.1.1, JMS, REST, SMF, WebSocket"

# === VERIFICATION ===
last_verified: 2026-03-01
confidence: 0.85
version: 1.0
first_published: 2026-03-01

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: volatile
  last_breaking_change: "2024 — SAP Event Broker for SAP cloud applications introduced as third option"
  next_review: 2026-08-28
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "Event Mesh Default Plan: max 1 MB message size for all protocols"
  - "Event Mesh Default Plan: max 10 GB total storage capacity"
  - "Event Mesh Default Plan: max 3 consumers per queue connection"
  - "Event Mesh Default Plan: guaranteed throughput minimum 250 KB/s"
  - "Advanced Event Mesh: max 30 MB message size (10 MB on Broker 100/250)"
  - "Advanced Event Mesh: max 1 TB spool on Broker 100K tier"
  - "Event Mesh is BTP-only; AEM supports on-premise and multi-cloud deployment"
  - "Event Mesh available under CPEA licensing only; not available as standalone under BTPEA"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "Need traditional file-based integration (IDoc, FBDI)"
    use_instead: "business/erp-integration/sap-s4hana-integration-patterns/2026"
  - condition: "Need S/4HANA OData or BAPI API capabilities"
    use_instead: "business/erp-integration/sap-s4hana-api-capabilities/2026"
  - condition: "Need SAP Integration Suite iPaaS capabilities (CPI)"
    use_instead: "business/erp-integration/sap-integration-suite-overview/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: integration_pattern
    question: "What integration pattern do you need?"
    type: choice
    options:
      - "event-driven (pub/sub, business events)"
      - "real-time notifications (webhook)"
      - "IoT event streaming (high-volume sensor data)"
      - "cross-system event mesh (multi-cloud, hybrid)"
  - key: data_volume
    question: "What's your expected event throughput?"
    type: choice
    options:
      - "< 1,000 events/day (standard business events)"
      - "1,000-100,000 events/day (moderate volume)"
      - "> 100,000 events/day (high-volume IoT/streaming)"
  - key: direction
    question: "What's the event flow pattern?"
    type: choice
    options:
      - "SAP-to-external (outbound business events)"
      - "external-to-SAP (inbound event triggers)"
      - "SAP-to-SAP (cross-module eventing)"
      - "multi-directional mesh (hybrid landscape)"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/erp-integration/sap-event-mesh-capabilities/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-01)"

# === RELATED UNITS ===
related_kos:
  depends_on: []
  related_to:
    - id: "business/erp-integration/sap-s4hana-api-capabilities/2026"
      label: "SAP S/4HANA API Capabilities"
    - id: "business/erp-integration/sap-integration-suite-overview/2026"
      label: "SAP Integration Suite Overview"
  solves: []
  alternative_to:
    - id: "business/erp-integration/salesforce-platform-events/2026"
      label: "Salesforce Platform Events"
  often_confused_with:
    - id: "business/erp-integration/sap-integration-suite-overview/2026"
      label: "SAP Integration Suite (iPaaS) vs Event Mesh (broker)"

# === SOURCES ===
sources:
  - id: src1
    title: "SAP Event Mesh Default Plan Technical Constraints"
    author: SAP
    url: https://help.sap.com/docs/event-mesh/event-mesh/sap-event-mesh-default-plan-technical-constraints
    type: official_docs
    published: 2025-06-01
    reliability: authoritative
  - id: src2
    title: "Service Class Options for Event Broker Services (Advanced Event Mesh)"
    author: SAP / Solace
    url: https://help.pubsub.em.services.cloud.sap/Cloud/service-class-limits.htm
    type: official_docs
    published: 2025-09-01
    reliability: authoritative
  - id: src3
    title: "Event-Driven Architecture: A Deeper Look at SAP Solutions"
    author: RB Omnishore
    url: https://rb-omnishore.de/en/2025/08/15/event-driven-architecture-3-a-deeper-look-at-sap-solutions/
    type: technical_blog
    published: 2025-08-15
    reliability: moderate_high
  - id: src4
    title: "Messaging Protocols and Libraries — SAP Event Mesh"
    author: SAP
    url: https://help.sap.com/docs/event-mesh/event-mesh/messaging-protocols-and-libraries
    type: official_docs
    published: 2025-06-01
    reliability: authoritative
  - id: src5
    title: "Event Mesh Default Plan Concepts"
    author: SAP
    url: https://help.sap.com/docs/event-mesh/event-mesh/event-mesh-default-plan-concepts
    type: official_docs
    published: 2025-06-01
    reliability: authoritative
  - id: src6
    title: "SAP Event Mesh Resource Units"
    author: SAP
    url: https://community.sap.com/t5/technology-blog-posts-by-sap/sap-event-mesh-resource-units/ba-p/13492215
    type: community_resource
    published: 2021-02-22
    reliability: moderate_high
  - id: src7
    title: "BTP Event Mesh Advanced Concepts"
    author: SAP
    url: https://community.sap.com/t5/technology-blog-posts-by-sap/btp-event-mesh-advance-concepts/ba-p/13528142
    type: community_resource
    published: 2022-08-01
    reliability: moderate_high
  - id: src8
    title: "Advanced Event Mesh: Queue"
    author: SAP
    url: https://community.sap.com/t5/technology-blogs-by-sap/advanced-event-mesh-queue/ba-p/13574698
    type: community_resource
    published: 2023-11-06
    reliability: moderate_high
---

# 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 the Business Technology Platform (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 with minimal setup. **SAP Event Mesh** (formerly Enterprise Messaging) is the mid-tier offering for hybrid landscapes, supporting open protocols (AMQP 1.0, MQTT 3.1.1, HTTP REST) with a 1 MB message size cap. **SAP Integration Suite, Advanced Event Mesh** (AEM) is the enterprise-grade solution powered by Solace PubSub+ technology, supporting message sizes up to 30 MB, on-premise deployment, and sophisticated event mesh networking across clouds. [src3]

This card covers both Event Mesh (Default Plan) and Advanced Event Mesh (all 7 service classes). It does NOT cover SAP Cloud Application Event Hub (the basic tier) or SAP Integration Suite's Cloud Integration (CPI) iPaaS capabilities.

| Property | SAP Event Mesh | SAP Advanced Event Mesh |
|---|---|---|
| **Vendor** | SAP | SAP / Solace |
| **Platform** | SAP BTP | SAP BTP + On-Premise + Multi-Cloud |
| **Max Message Size** | 1 MB | 10-30 MB (tier-dependent) |
| **Max Storage** | 10 GB | 25 GB - 1 TB (tier-dependent) |
| **Protocols** | AMQP 1.0, MQTT 3.1.1, HTTP REST, Webhook | AMQP 1.0, MQTT 3.1.1, JMS, REST, SMF, WebSocket |
| **Deployment** | Cloud (BTP-only) | Cloud, On-Premise, Hybrid |
| **Monitoring** | Limited | Advanced (event replay, tracing) |
| **API Docs** | [SAP Help Portal](https://help.sap.com/docs/event-mesh) | [Solace Cloud Docs](https://help.pubsub.em.services.cloud.sap/) |
| **Status** | GA | GA |

## API Surfaces & Capabilities

SAP Event Mesh and Advanced Event Mesh support different sets of messaging protocols. 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]

| API Surface | Protocol | Available In | Best For | Real-time? | Notes |
|---|---|---|---|---|---|
| AMQP 1.0 | AMQP over WebSocket | Both EM + AEM | Enterprise app-to-app messaging, guaranteed delivery | Yes | Open standard; message orientation, queuing, routing [src4] |
| MQTT 3.1.1 | MQTT over WebSocket | Both EM + AEM | IoT, low-bandwidth devices, edge scenarios | Yes | Lightweight; recommended for non-cloud apps [src4] |
| HTTP REST | HTTPS/JSON | Both EM + AEM | Simple publish/consume, request-reply | Yes | Stateless; no persistent connection required [src4] |
| Webhook (HTTP POST) | HTTPS | Both EM + AEM | Push notifications to consumer REST endpoints | Yes | Use when consumer lacks AMQP/MQTT support [src7] |
| JMS | Java Message Service | AEM only | Java EE applications, legacy middleware | Yes | Full JMS 1.1 compliance via Solace [src2] |
| Solace SMF | SMF over WebSocket/TCP | AEM only | High-throughput, low-latency Solace-native apps | Yes | Proprietary; highest performance option [src2] |
| WebSocket | WS/WSS | AEM only | Browser-based and real-time web clients | Yes | Solace Web Messaging library [src2] |

## Rate Limits & Quotas

### SAP Event Mesh — Default Plan Limits

| Limit Type | Value | Notes |
|---|---|---|
| Max message size | 1 MB | Applies to all protocols; includes headers + payload [src1] |
| Max storage capacity | 10 GB | Total across all queues in the service instance [src3] |
| Guaranteed throughput | 250 KB/s (minimum) | Guaranteed minimum; actual may be higher [src1] |
| Max consumers per queue | 3 | Per connection to a specific queue [src1] |
| Max webhook unacknowledged messages | 9 | Webhook holds max 9 unacked messages before backpressure [src7] |
| Connections per service instance | 50 | Bound by resource units allocated [src6] |

### SAP Advanced Event Mesh — Service Class Limits

| Limit Type | Broker 100 | Broker 250 | Broker 1K | Broker 5K | Broker 10K | Broker 50K | Broker 100K |
|---|---|---|---|---|---|---|---|
| **Max message size** | 10 MB | 10 MB | 10-30 MB | 30 MB | 30 MB | 30 MB | 30 MB |
| **Message spool** | 25 GB | 50 GB | 200 GB | 400 GB | 600 GB | 800 GB | 1,000 GB |
| **Client connections** | 100 | 250 | 1,000 | 5,000 | 10,000 | 50,000 | 100,000 |
| **Enterprise connections** | 100 | 250 | 1,000 | 5,000 | 10,000 | 30,000 | 30,000 |
| **IoT connections** | 100 | 250 | 1,000 | 5,000 | 10,000 | 50,000 | 100,000 |
| **Max queued messages** | 240M | 240M | 240M | 3B | 3B | 3B | 3B |
| **Queues + topic endpoints** | 100 | 250 | 1,000 | 5,000 | 10,000 | 50,000 | 100,000 |
| **Transacted sessions** | 100 | 100 | 1,000 | 5,000 | 10,000 | 10,000 | 10,000 |
| **Topic subscriptions** | 500K | 500K | 500K | 5M | 5M | 5M | 5M |

[src2]

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

## Authentication

| Flow | Service | Use When | Token Lifetime | Notes |
|---|---|---|---|---|
| OAuth 2.0 Client Credentials | Event Mesh | BTP service binding, message client auth | Configurable (typically 12h) | Standard BTP service key / XSUAA binding [src5] |
| OAuth 2.0 Client Credentials | AEM | Programmatic broker management via REST API | Configurable | Solace Cloud API token [src2] |
| Client Username + Password | AEM | AMQP/MQTT/SMF client connections | Session-based | Configured per Message VPN in broker [src2] |
| Client Certificate (TLS) | AEM | Mutual TLS for high-security connections | Certificate validity | Supported on all protocols [src2] |

### Authentication Gotchas

- Event Mesh message clients are scoped to a namespace — a client in namespace `sap/btp/myapp` cannot consume from queues in namespace `sap/btp/otherapp` without explicit cross-namespace subscription configuration. [src5]
- AEM client usernames are per-Message VPN. The maximum simultaneous connections per client username is configurable but applies across ALL protocols (SMF, AMQP, MQTT, REST). [src2]
- BTP service keys for Event Mesh contain separate `httprest`, `amqp10ws`, and `mqtt311ws` protocol endpoints — use the correct one for your protocol. [src5]

## Constraints
<!-- Agents: read this section before recommending any integration approach from this unit.
     These are hard constraints that must not be violated. -->

- Event Mesh is BTP-cloud-only. If you need on-premise event brokers or multi-cloud mesh networking, you must use Advanced Event Mesh. [src3]
- Event Mesh max message size is 1 MB including headers. Messages larger than 1 MB will be rejected — you cannot split and reassemble at the broker level. [src1]
- Event Mesh storage is capped at 10 GB. For high-volume scenarios exceeding this, use AEM (up to 1 TB spool). [src3]
- AEM Broker 100 (Developer tier) has only 100 client connections — not suitable for production workloads with many consumers. [src2]
- Event Mesh is only available under CPEA licensing. BTPEA does not include a standalone Event Mesh entitlement. [src3]
- AEM enterprise connections cap at 30,000 even on the Broker 50K and 100K tiers — the higher connection numbers apply to IoT/client connections only. [src2]
- Webhook subscriptions in Event Mesh can hold a maximum of 9 unacknowledged messages before applying backpressure — not suitable for high-burst webhook consumers. [src7]
- S/4HANA business events are notification-only by default (no payload). For full-state events, you must configure the Event Add-On for ERP or build custom event payloads. [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 storage, <1 MB messages)
│   │   ├── Already have BTP license with CPEA?
│   │   │   ├── YES → SAP Event Mesh (Default Plan)
│   │   │   └── NO (BTPEA only) → SAP Cloud Application Event Hub (included)
│   │   └── Need webhook push to external?
│   │       ├── YES → Event Mesh with webhook subscription (max 9 unacked)
│   │       └── NO → Event Mesh with AMQP/MQTT consumer
│   ├── Enterprise-grade (>1 MB messages, >10 GB storage, or >50 connections)
│   │   ├── Messages > 1 MB?
│   │   │   ├── YES → Advanced Event Mesh (10-30 MB per message)
│   │   │   └── NO → Could use either EM or AEM
│   │   ├── Need on-premise broker?
│   │   │   ├── YES → Advanced Event Mesh (only option with on-prem)
│   │   │   └── NO → Depends on other requirements
│   │   └── Need event replay / message tracing?
│   │       ├── YES → Advanced Event Mesh (monitoring capabilities)
│   │       └── NO → Event Mesh may suffice
│   └── IoT / high-volume streaming (>10K connections)
│       └── Advanced Event Mesh — Broker 10K or higher
├── Which protocol?
│   ├── AMQP 1.0 → Both EM and AEM (guaranteed delivery, enterprise messaging)
│   ├── MQTT 3.1.1 → Both EM and AEM (IoT, low-bandwidth, edge)
│   ├── HTTP REST → Both EM and AEM (simple, stateless)
│   ├── JMS → AEM only (Java EE, legacy middleware)
│   └── SMF → AEM only (highest throughput, Solace-native)
└── S/4HANA business events?
    ├── Notification events (no payload) → Standard, works with EM or AEM
    ├── Full-state events (with payload) → Need Event Add-On for ERP
    └── Custom events → RAP business events or CAP-based
```

## Quick Reference

### SAP Event Mesh vs Advanced Event Mesh at a Glance

| Capability | Event Mesh (Default Plan) | Advanced Event Mesh (Broker 1K) | Advanced Event Mesh (Broker 100K) |
|---|---|---|---|
| **Max message size** | 1 MB | 10-30 MB | 30 MB |
| **Storage** | 10 GB | 200 GB | 1,000 GB |
| **Connections** | 50 per instance | 1,000 | 100,000 |
| **Protocols** | AMQP, MQTT, REST, Webhook | AMQP, MQTT, JMS, REST, SMF, WS | AMQP, MQTT, JMS, REST, SMF, WS |
| **Deployment** | BTP cloud only | Cloud + On-Premise + Hybrid | Cloud + On-Premise + Hybrid |
| **Event replay** | No | Yes | Yes |
| **Dynamic Message Routing** | No | Yes (mesh networking) | Yes (mesh networking) |
| **Queue depth** | Limited by 10 GB | 240M messages | 3B messages |
| **Topic subscriptions** | Limited by RU | 500K | 5M |
| **Monitoring** | Basic BTP cockpit | Solace Event Portal + analytics | Solace Event Portal + analytics |
| **Setup complexity** | Low | Medium | Medium-High |
| **Cost** | Low (CPEA credits) | Medium | High |

[src1, src2, src3]

## 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. Each instance gets a namespace that scopes its queues and topics. [src5]

```bash
# Input:  BTP subaccount with CPEA entitlement for Event Mesh
# Output: Service instance with namespace and service key

# 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 credentials from the service key to obtain an OAuth token, then publish a message to a topic. [src4, src5]

```bash
# Input:  Service key JSON with tokenendpoint, clientid, clientsecret
# Output: HTTP 204 on successful publish

# Extract credentials from service key
TOKEN_URL="<tokenendpoint from service key>"
CLIENT_ID="<clientid>"
CLIENT_SECRET="<clientsecret>"
REST_URL="<httprest.uri from service key>"

# 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","timestamp":"2026-03-01T10:00:00Z"}'
```

**Verify**: HTTP response `204 No Content` → message published successfully

### 3. Create a Queue and Subscribe to Topics

Create a queue that subscribes to one or more topic patterns. Messages published to matching topics are routed to the queue. [src5, src7]

```bash
# Input:  OAuth token, REST URL, namespace
# Output: Queue created with topic subscription

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

# Subscribe queue to a topic pattern (wildcard)
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" -H "Authorization: Bearer $TOKEN"` → queue details with subscription count

### 4. Consume Messages from Queue

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

```bash
# Input:  Queue with messages, OAuth token
# Output: Message payload with acknowledgment

# 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"

# Response includes message ID for acknowledgment
# 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

```python
# 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

# Step 1: Get OAuth token
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"]

# Step 2: Publish via AMQP
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","status":"created"}')
        msg.content_type = "application/json"
        event.sender.send(msg)
        event.sender.close()
        event.connection.close()

# Usage
token = get_token(TOKEN_URL, CLIENT_ID, CLIENT_SECRET)
Container(Publisher(AMQP_URL, "topic:sap/btp/myapp/orders/created", token)).run()
```

### JavaScript/Node.js: Consume via MQTT 3.1.1

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

const mqtt = require("mqtt"); // mqtt@5.x

const MQTT_URL = "<mqtt311ws.uri from service key>";
const TOKEN = "<oauth-token>";

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

client.on("connect", () => {
  console.log("Connected to SAP Event Mesh via MQTT");
  // Subscribe to topic pattern
  client.subscribe("sap/btp/myapp/orders/+", { qos: 1 });
});

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

client.on("error", (err) => {
  console.error("MQTT error:", err.message);
});
```

### cURL: Quick Test — Publish and Check Queue

```bash
# Input:  Service key credentials
# Output: Message published + queue depth verified

# 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,"ts":"2026-03-01T12:00:00Z"}'
# Expected: 204 No Content

# Check queue depth (if queue is subscribed to test topic)
curl -s "$REST_URL/messagingrest/v1/queues/my-queue" \
  -H "Authorization: Bearer $TOKEN" | jq '.queueDepth'
# Expected: integer > 0
```

## Data Mapping

### S/4HANA Business Events to Event Mesh

| S/4HANA Object | Event Type | Topic Pattern | Payload | Notes |
|---|---|---|---|---|
| Business Partner | Created/Changed/Deleted | `sap/s4/beh/businesspartner/v1/BusinessPartner/Created/v1` | Notification (key only) | Full-state requires Event Add-On |
| Sales Order | Created | `sap/s4/beh/salesorder/v1/SalesOrder/Created/v1` | Notification | CloudEvents format |
| Purchase Order | Changed | `sap/s4/beh/purchaseorder/v1/PurchaseOrder/Changed/v1` | Notification | Key fields in `data` |
| Material Document | Posted | `sap/s4/beh/materialdocument/v1/MaterialDocument/Posted/v1` | Notification | Goods receipt/issue |

[src3, src5]

### Data Type Gotchas

- S/4HANA business events follow CloudEvents specification but use SAP-specific topic naming. The topic hierarchy is `sap/s4/beh/{object}/v1/{Object}/{Action}/v1` — note the different casing conventions (lowercase for path segment, PascalCase for object/action). [src5]
- Notification events contain only the key of the changed object (e.g., BusinessPartner ID), not the full payload. You must make a follow-up OData call to get the actual data — this is by design to keep events small, but it adds latency and API call overhead. [src3]
- Event Mesh topics use `/` as the level separator. URL-encode the topic when using the REST API (`%2F`), but use raw `/` when using AMQP or MQTT. [src4]

## Error Handling & Failure Points

### Common Error Codes

| Code | Meaning | Cause | Resolution |
|---|---|---|---|
| 401 Unauthorized | OAuth token expired or invalid | Token not refreshed, wrong credentials | Re-authenticate with client credentials flow; implement token refresh before expiry |
| 403 Forbidden | Namespace permission denied | Message client lacks permission for target namespace | Check service key namespace scope; ensure topic matches client namespace |
| 413 Payload Too Large | Message exceeds size limit | Message body + headers > 1 MB (EM) or tier limit (AEM) | Reduce payload size; send reference + ID instead of full object; use AEM for larger messages |
| 429 Too Many Requests | Rate limit / throughput exceeded | Exceeding guaranteed throughput or connection limits | Implement exponential backoff; upgrade to higher tier; distribute across multiple instances |
| 503 Service Unavailable | Broker temporarily unavailable | Maintenance window, capacity issue | Retry with backoff; implement circuit breaker pattern |

[src1, src4]

### Failure Points in Production

- **Queue overflow (storage full)**: When Event Mesh storage hits 10 GB, new messages are rejected. Fix: `Monitor queue depth via REST API; implement consumer auto-scaling; archive processed messages; consider AEM with up to 1 TB spool`. [src1, src3]
- **Webhook delivery failure**: Webhook endpoints that return non-2xx responses cause message retry. After max retries, messages go to a dead letter queue (if configured) or are discarded. Fix: `Ensure webhook endpoint returns 200 within timeout; implement idempotent processing; configure DLQ for undeliverable messages`. [src7]
- **Consumer lag on 3-consumer limit**: Event Mesh allows only 3 consumers per queue. Under high load, this creates a bottleneck. Fix: `Create multiple queues subscribed to the same topic for horizontal scaling; or migrate to AEM where consumer limits scale with tier`. [src1]
- **Namespace collision across teams**: Multiple development teams using the same namespace can publish to or consume from each other's topics/queues unintentionally. Fix: `Establish namespace governance — assign unique namespace per application or team; use BTP role collections to restrict service instance creation`. [src5]
- **OAuth token expiry during long-running AMQP sessions**: Persistent AMQP connections do not auto-refresh tokens. Fix: `Implement reconnect logic with fresh token; monitor connection state; set connection idle timeout shorter than token lifetime`. [src4]

## Anti-Patterns

### Wrong: Sending full business objects as event payloads

```python
# BAD — Sends entire 500 KB sales order object as event
# Hits Event Mesh 1 MB limit with large orders; wastes bandwidth
event = {
    "type": "SalesOrderCreated",
    "data": get_full_sales_order(order_id)  # 500 KB+ payload
}
publish_to_event_mesh(event)
```

### Correct: Send notification event with key, fetch on demand

```python
# GOOD — Sends lightweight notification; consumer fetches full object if needed
# Follows SAP's recommended notification event pattern
event = {
    "type": "SalesOrderCreated",
    "data": {"SalesOrder": order_id},  # ~100 bytes
    "source": "/sap/s4/beh/salesorder"
}
publish_to_event_mesh(event)
# Consumer fetches full object via OData only when needed
```

### Wrong: Using REST polling for real-time consumption

```javascript
// BAD — Polling REST endpoint every 100ms
// Wastes throughput quota; high latency; 250 KB/s limit hit quickly
setInterval(async () => {
  const msg = await fetch(`${REST_URL}/queues/myqueue/messages/consumption`, {
    method: "POST", headers: { Authorization: `Bearer ${token}` }
  });
  if (msg.ok) processMessage(await msg.json());
}, 100);
```

### Correct: Use AMQP or MQTT for real-time push consumption

```javascript
// GOOD — Persistent AMQP/MQTT connection with push delivery
// Low latency, efficient connection usage, proper QoS
const client = mqtt.connect(MQTT_URL, { username: "$consumer", password: token });
client.subscribe("sap/btp/myapp/orders/+", { qos: 1 });
client.on("message", (topic, msg) => processMessage(JSON.parse(msg)));
```

### Wrong: Single queue for all event types

```bash
# BAD — One queue subscribed to all topics
# No filtering, no priority, slow consumers block fast events
queue: "catch-all-queue"
subscription: "sap/btp/myapp/#"  # wildcard catches everything
```

### Correct: Dedicated queues per consumer concern

```bash
# GOOD — Separate queues with specific topic subscriptions
# Independent scaling, failure isolation, priority-based processing
queue: "order-processor"     → subscription: "sap/btp/myapp/orders/*"
queue: "invoice-generator"   → subscription: "sap/btp/myapp/invoices/*"
queue: "audit-logger"        → subscription: "sap/btp/myapp/+/+/+"  # catch-all for audit
```

## Common Pitfalls

- **Confusing Event Mesh with Advanced Event Mesh**: They are separate services with different capabilities, pricing, and licensing. Event Mesh (Default Plan) is BTP-native with 1 MB limit; AEM is Solace-powered with up to 30 MB. Choosing the wrong one causes either over-spending or hitting unexpected limits. Fix: `Use the decision tree above; start with Event Mesh for simple scenarios; upgrade to AEM only when you need >1 MB messages, on-prem, or >50 connections`. [src3]
- **Not URL-encoding topics in REST calls**: Topic `sap/btp/myapp/orders/created` must be encoded as `sap%2Fbtp%2Fmyapp%2Forders%2Fcreated` in REST URLs. Forgetting this causes 404 errors. Fix: `Always encodeURIComponent() topic strings in REST API calls; AMQP and MQTT use raw topics`. [src4]
- **Assuming S/4HANA events include full payload**: Business events from S/4HANA are notification events by default — they contain only the object key, not the full object. Fix: `Design consumer to make a follow-up OData call to S/4HANA to retrieve the full object after receiving the event notification`. [src3]
- **Exceeding 3-consumer limit under load**: Event Mesh Default Plan allows only 3 consumers per queue connection. Under load, this creates a processing bottleneck. Fix: `Create multiple queues subscribed to the same topic; implement competing consumers pattern across queues; or migrate to AEM for higher concurrency`. [src1]
- **Ignoring namespace scoping in multi-team setups**: Event Mesh namespaces control topic/queue visibility. Without governance, teams can accidentally consume each other's events. Fix: `Assign one namespace per application; document namespace conventions; use BTP subaccounts for hard isolation`. [src5]
- **Not configuring dead letter queues**: Unprocessable messages that fail repeated delivery attempts are discarded if no DLQ is configured. Fix: `Always configure a dead letter queue for production queues; monitor DLQ depth; set up alerts for DLQ messages`. [src7]

## Diagnostic Commands

```bash
# 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 (depth, subscriptions, consumers)
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 to verify connectivity (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

| Version / Milestone | Date | Status | Key Changes |
|---|---|---|---|
| Enterprise Messaging (original) | 2018 | Rebranded | Original name before SAP Event Mesh |
| SAP Event Mesh Default Plan | 2020 | GA | Standardized as "Event Mesh"; AMQP 1.0, MQTT 3.1.1, REST |
| SAP Integration Suite, Advanced Event Mesh | 2022 | GA | Solace PubSub+ integration; 7 service classes; JMS/SMF/WebSocket |
| SAP Cloud Application Event Hub | 2024 | GA | Third tier — basic, included with BTP license; up to 75M transactions |
| AEM Broker 1K firmware update | 2024 | Update | Max message size increased from 10 MB to 30 MB on newer firmware |
| Event Mesh CPEA-only restriction | 2024 | Current | Event Mesh not available as standalone under BTPEA |

[src2, src3]

### Deprecation Policy

SAP's BTP services follow a minimum 12-month deprecation notice. Enterprise Messaging was rebranded to Event Mesh but remained backward-compatible. SAP has stated Event Mesh will continue as a supported service alongside AEM, but new investment is focused on AEM and Event Broker. Always check the SAP BTP roadmap for current service lifecycle status. [src3, src5]

## When to Use / When Not to Use

| Use When | Don't Use When | Use Instead |
|---|---|---|
| Simple S/4HANA-to-BTP event routing, <1 MB messages, <50 connections | Messages > 1 MB or need on-premise broker | Advanced Event Mesh (Broker 1K+) |
| Lightweight pub/sub between BTP microservices | Need JMS protocol for Java EE middleware | Advanced Event Mesh (JMS support) |
| Small team, <10 queues, CPEA-licensed BTP | Need event replay, message tracing, or advanced monitoring | Advanced Event Mesh (Event Portal) |
| IoT edge-to-cloud with <250 devices via MQTT | >250 IoT connections or need SMF protocol | Advanced Event Mesh (Broker 250+) |
| Cross-cloud mesh networking, multi-region deployment | Only need basic cloud-to-cloud in single BTP region | Event Mesh (simpler, lower cost) |
| Enterprise with >1,000 concurrent connections | Budget-constrained pilot with <50 connections | Event Mesh Default Plan |

## Cross-System Comparison

| Capability | SAP Event Mesh | SAP Advanced Event Mesh | SAP Cloud Application Event Hub |
|---|---|---|---|
| **Max message size** | 1 MB | 10-30 MB | Not published |
| **Max storage** | 10 GB | 25 GB - 1 TB | N/A (transaction-based) |
| **Protocols** | AMQP, MQTT, REST, Webhook | AMQP, MQTT, JMS, REST, SMF, WS | HTTP (SAP-native) |
| **Max connections** | 50/instance | 100-100,000 | N/A |
| **On-premise support** | No | Yes | No |
| **Event replay** | No | Yes | No |
| **Multi-cloud mesh** | No | Yes (DMR) | No |
| **Monitoring** | Basic BTP cockpit | Solace Event Portal | Basic |
| **S/4HANA integration** | Native (business events) | Native + Event Add-On | Native (limited) |
| **Licensing** | CPEA | CPEA or subscription | Included with BTP |
| **Setup complexity** | Low | Medium-High | Minimal |
| **Max transactions** | Unlimited (usage-based) | Unlimited (tier-based) | 75M included |

[src1, src2, src3]

## Important Caveats

- SAP has three distinct event services (Event Broker, Event Mesh, Advanced Event Mesh) that are frequently confused. Documentation and community posts sometimes use these names interchangeably — always verify which service is being discussed. [src3]
- Event Mesh pricing is consumption-based under CPEA. Costs scale with resource units (RUs), which bundle connections, queues, and storage. Actual costs depend on your CPEA agreement and usage patterns. [src6]
- Advanced Event Mesh service class limits are enforced per event broker service instance. If you need higher limits, you must provision a higher-tier broker — limits cannot be increased on an existing tier. [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 specific S/4HANA version's event availability. [src3]
- All rate limits and quotas in this card are current as of March 2026. SAP may change service class limits, message size caps, or licensing models — always verify against the official SAP Help Portal documentation before architecture decisions.

## Related Units

- [SAP S/4HANA API Capabilities](/business/erp-integration/sap-s4hana-api-capabilities/2026)
- [SAP Integration Suite Overview](/business/erp-integration/sap-integration-suite-overview/2026)