Integration Patterns in SAP
Forget marketing slides. Here are the real integration patterns you’ll deal with in SAP, how they map to technologies (IDoc, RFC, SOAP, OData, Events), and when to use what. Practical O2C examples included.
Patterns at a Glance
Use this page to quickly decide between API, IDoc, and Events, and whether you need sync (request/response) or async (message/event) flow.
1) Point-to-Point (Direct Invocation)
SAP Tech: RFC, SOAP services, direct OData/REST calls. When used: fast, cheap, 1:1 integration for a single consumer with tight coupling; good for simple or short‑lived scenarios.
O2C Example: Sales Order creation triggers an RFC call to an external credit check system. Works fine until you have 5 partners and each needs a slightly different API.
- Simple setup — no mediator.
- Lowest latency for request → reply.
- Good for one consumer or a spike/POC.
- N connections over time → spaghetti.
- Each new consumer = new interface variant.
- Tight coupling; difficult to govern and monitor.
2) Hub‑and‑Spoke (Mediated Integration)
SAP Tech: SAP PI/PO, SAP Cloud Integration (CPI), SAP Integration Suite. Pattern: systems publish/consume via a central mediator that handles mapping, routing, and errors.
O2C Example: Sales Order in S/4HANA generates an IDoc (ORDERS05); CPI transforms and routes it to CRM, 3PL, and Billing — one source → many consumers without spaghetti.
- Each system connects once (governed contracts).
- Central mapping, transformation, and error handling.
- End‑to‑end monitoring and retries in one place.
- Hub can become a bottleneck without sizing.
- Needs governance to avoid “everything through CPI” anti‑pattern.
3) Event‑Driven (Publish/Subscribe)
SAP Tech: SAP Event Mesh, SAP Integration Suite — Advanced Event Mesh. Pattern: producer emits an event; broker distributes to all subscribers (loose coupling; add consumers without upstream change).
O2C Example: SalesOrder.Created is published from S/4HANA; Logistics, CRM, and Finance subscribe in parallel. Tomorrow Data Lake subscribes too — with zero change to SD.
- Loose coupling — producers don’t know consumers.
- New consumers can subscribe with zero upstream change.
- Great for real‑time, scalable multi‑consumer flows.
- Lifecycle & versioning of event schemas.
- Topic design, governance, and consumer lag.
Learn More
Data Mesh
Key prep topic for interviews: understand domains, data ownership, contracts, and how SAP landscapes move toward event-driven Data Mesh.
API First & Basics
Understand API First mindset, REST basics, data contracts, and why APIs matter in modern SAP and non-SAP landscapes.
4) Synchronous vs Asynchronous
Two timing models: request/reply for immediate answers (pricing, ATP, credit) vs message/event for decoupled flows that can wait in a queue. If the target is down, async buffers; sync blocks.
| Aspect | Synchronous (Req/Reply) | Asynchronous (Message/Event)Best |
|---|---|---|
| Tech | RFC, SOAP, OData/REST | IDoc, Event Mesh/AEM |
| Use | Immediate validation (ATP, pricing, credit) | Loosely coupled distribution (SO, delivery, invoice) |
| Resilience | Caller blocks if callee is down | Queue/broker buffers; process continues |
| Latency | Lowest | Varies; consumer‑paced |
5) Pub/Sub vs Streaming
Pub/Sub pushes ephemeral events to subscribers for real‑time triggers. Streaming keeps an append‑only log for replay and backfills; consumers read at their own pace (Kafka/AEM streaming).
| Aspect | Pub/Sub | Streaming (Event Log)Best |
|---|---|---|
| Delivery | Push to subscribers; fire‑and‑forget | Append to log; consumers read at own pace |
| History | Typically ephemeral | Replayable history |
| Good for | Real‑time triggers (order notifications) | Analytics, recovery, ML |
| Tech | Event Mesh / AEM | Kafka / AEM streaming |
6) Choosing Between API, IDoc, and Event
Quick chooser for SAP interfaces. Match the job: APIs for validations, IDocs for bulk/legacy transfers, Events for real‑time fan‑out and scale.
| Pattern | SAP Tech | When to Use | O2C Example |
|---|---|---|---|
| API (REST/OData, SOAP, RFC) | RFC, OData, SOAP, BAPI | Request/response, synchronous validation | ATP check during Sales Order creation |
| IDoc (ALE, Middleware) | ORDERS, DELVRY, INVOIC | Bulk transfer, batch sync, legacy ECC ↔ EWM | Distribute Sales Orders to 3PL via IDoc |
| Events (Pub/Sub) | Event Mesh, AEM | Real‑time, multi‑consumer, scalable | SalesOrder.Created → CRM, Billing, Logistics in parallel |