SAP Event Mesh Architecture Patterns

This blog post explores common architectural patterns using SAP Event Mesh in a cloud-native integration landscape.

Audience & Prerequisites

Audience: Integration architects and developers familiar with AMQP principles and SAP Cloud Integration. Prerequisites: Basic understanding of event-driven design.

Key Components

• Producer System: Source of events (e.g., e-commerce platform).
• SAP Cloud Integration Suite: Acts as an AMQP broker or event router.
• Consumer System(s): Subscribers processing events (e.g., warehouse, analytics).

1. Single Publisher → Single Event Type → Single Subscriber

Use Case A customer places an online order. The e-commerce app publishes an OrderCreated event, and a warehouse service processes it to trigger shipping.

Motivation Simplest guaranteed-delivery scenario for point-to-point integration.

Description

• Producer sends events to a dedicated queue.
• Consumer subscribes to the queue for ordered processing.

Pros & Cons

• ✅ Pros: Guaranteed delivery, simple error handling.
• ❌ Cons: Tight coupling, no scalability.

When to Use Legacy system integrations or one-to-one workflows.

Configuration

• Queue: Queue_OrderCreated
• Protocol: AMQP (pull-based).

2. Single Publisher → Single Event Type → Multiple Subscribers (Fan-out)

Use Case A retail platform publishes OrderCreated events to notify analytics, billing, and notification services in parallel.

Motivation Broadcast events to multiple consumers for independent processing.

Description

• Producer publishes to a topic.
• Event Mesh replicates the event to subscriber queues.

Pros & Cons

• ✅ Pros: Decoupled subscribers, scalable.
• ❌ Cons: Resource overhead, management complexity.

When to Use Multiple downstream systems need the same event.

Configuration

• Topic: Topic_OrderCreated
• Subscriber Queues: Queue_Analytics, Queue_Billing, Queue_Notification.

3. Multiple Event Types → Single Subscriber

Use Case A fulfillment engine handles OrderCreated and OrderUpdated events from a single subscription.

Motivation Centralize logic for related event types.

Description

• Producers emit events to a shared topic.
• Subscriber filters events by headers (e.g., type=Created).

Pros & Cons

• ✅ Pros: Fewer endpoints, unified logic.
• ❌ Cons: Filtering overhead, load concentration.

When to Use A service needs multiple event types.

Configuration

• Topic: Topic_OrderEvents
• Queue: Queue_OrderProcessor with header-based bindings.

4. Multi-Topic Selective Subscription

Use Case A procurement system subscribes to material/vendor events, while analytics uses product events.

Motivation Domain-driven subscriptions for segregated data.

Description

• Producers publish to domain-specific topics.
• Consumers bind to relevant topics.

Pros & Cons

• ✅ Pros: Fine-grained control, domain isolation.
• ❌ Cons: Binding management.

When to Use Segregated event types per domain.

Configuration

• Topics: Topic_MaterialEvents, Topic_ProductEvents, Topic_VendorEvents.
• Queues: Queue_Procurement (material/vendor), Queue_Analytics (product).

5. Aggregator Pattern

Use Case An integration flow aggregates daily material/product updates into a MasterDataBundle for reporting.

Motivation Batch processing of related events.

Description

• SAP Cloud Integration (CI) consumes source queues, aggregates data, and publishes a bundled event.

Pros & Cons

• ✅ Pros: Simplified downstream consumption.
• ❌ Cons: Latency, complex logic.

When to Use Batch reporting or composite events.

Configuration

• Source Queues: Queue_MaterialEvents, Queue_ProductEvents.
• Output Topic: Topic_MasterDataBundle.

6. Event Enrichment Pipeline

Use Case Enrich raw order events with customer credit scores and product availability.

Motivation Decouple enrichment steps from producers/consumers.

Description

• CI flows progressively enrich events across stages.

Pros & Cons

• ✅ Pros: Modular design, separation of concerns.
• ❌ Cons: Increased latency.

When to Use Progressive event enhancement.

Configuration

• Topics: Topic_RawOrderEvents → Topic_EnrichedEvents.
• Queues: Queue_Enrich1, Queue_Billing, Queue_Shipping.

7. Scatter–Gather Pattern

Use Case A credit-check flow queries two agencies in parallel and aggregates responses.

Motivation Parallel execution and result collation.

Description

• CI publishes requests to a topic.
• Subscribers process requests and publish responses.
• Aggregator CI flow correlates responses.

Pros & Cons

• ✅ Pros: Parallelism, resilience.
• ❌ Cons: Correlation complexity.

When to Use Multi-service orchestration.

Configuration

• Topics: Topic_Requests, Topic_Responses.
• Queues: Queue_ServiceA, Queue_ServiceB, Queue_Aggregator.

8. Error Handling & Dead-Letter Queue

Use Case Malformed events are moved to DLQ_OrderProcessor after retries.

Motivation Isolate poison messages for analysis.

Description

• Configure queues to route failed messages to a DLQ.

Pros & Cons

• ✅ Pros: Prevents message loss.
• ❌ Cons: Requires monitoring.

When to Use Critical pipelines needing reliability.

Configuration

• Primary Queue: Queue_OrderProcessor.
• DLQ: DLQ_OrderProcessor (bound via dead-letter exchange).

9. Webhook Integration Pattern

Use Case Event Mesh invokes a third-party SMS gateway’s webhook on OrderShipped events.

Motivation Real-time integration with HTTP endpoints.

Description

• Event Mesh pushes events to HTTP endpoints via POST.

Pros & Cons

• ✅ Pros: No persistent consumer needed.
• ❌ Cons: HTTP reliability challenges.

When to Use Lightweight integrations with REST APIs.

Configuration

• Topic: Topic_OrderNotifications.
• Webhook: https://api.sms-gateway.com/notify (TLS + OAuth).

Conclusion

Choose patterns based on coupling, scalability, and latency needs. SAP Event Mesh’s flexibility with queues, topics, and webhooks supports diverse integration scenarios.