Lesson 4 of 5
Interface patterns
9 min
Listen to this lesson
Interfaces are where architectures succeed or fail in production. The choice of pattern decides latency, coupling, error handling and how hard the interface is to test. SAP's Integration Solution Advisory Methodology (ISA-M) gives a vendor-neutral vocabulary for these choices, and SAP Integration Suite provides the main SAP platform to implement them.
Start from integration styles
ISA-M describes integration styles as basic categories of integration, refined by use case patterns. SAP's documentation lists five styles: process integration (business processes spanning applications, with patterns such as A2A, B2B and master data integration), data integration (replication for ETL, virtualization, orchestration), analytics integration (embedded and cross-application analytics), user integration (UI, mobile and chatbot integration) and thing integration (devices to processes, analytics or a data lake). The methodology then maps these technology-agnostic requirements to suitable technologies.
- DomainWhere do the systems run? For example cloud to on-premise
- StyleProcess, data, analytics, user or thing integration
- Use case patternFor example A2A, B2B, master data integration, data replication
- Technology mappingChoose the technology that fits, such as Cloud Integration for A2A with adapters
- Interface requestEach new interface is classified and approved against these policies
Interaction patterns
| Pattern | How it works | Use when | Quality risk |
|---|---|---|---|
| Synchronous request/response | Caller waits for an answer (OData, REST, SOAP, RFC) | The caller needs the answer now: availability check, price inquiry | Coupling: if the provider is down, the caller fails |
| Asynchronous messaging | Sender hands a message to middleware or a queue; delivery is guaranteed later (IDoc, async SOAP) | Business documents: orders, deliveries, invoices | Messages stuck in error queues unnoticed |
| Events | Publisher announces "business partner changed"; subscribers react | Many consumers need to know about a change | Event ordering, duplicates, subscribers that fall behind |
| Batch / file | Scheduled bulk transfer | High volume, low urgency: bank statements, payroll results | Partial files, reruns that duplicate data |
| Data replication | Tables or views copied to another store | Analytics and data platforms | Silent lag or gaps in replicated data |
Interaction patterns and their typical quality risks.
- Does the caller need the result before it can continue?Yes → synchronous API; design timeouts and a fallback · No → next question
- Is it a business document that must arrive exactly once?Yes → asynchronous messaging with guaranteed delivery and monitoring · No → next question
- Do several consumers need to react to the same change?Yes → events; consumers fetch details if needed · No → next question
- Is it high volume with no urgency?Yes → batch or replication, with control totals
Point-to-point versus middleware
SAP's BTP solution architect material argues for a unified integration platform over ad hoc approaches, with predefined content from the SAP Business Accelerator Hub, open standards such as OData, REST and SOAP for third-party systems, and coverage of A2A, B2B, events and data integration. In practice, a middleware layer gives central monitoring, mapping, security and reuse. Direct point-to-point calls are acceptable for simple, owned, low-risk links, such as a Fiori app calling its own OData service, but every point-to-point interface is another place to monitor and test.
Design the unhappy path
Every interface specification should say what happens when things go wrong. Which errors are retried automatically, and how often? Is the receiver idempotent, so that a resent message does not create a second order? Where do messages that cannot be processed go, who owns that queue and how fast must they act? Which business key travels with the message so that support can find it? These answers decide whether an interface failure is a five-minute fix or a month-end surprise, and they are exactly what integration testing must prove.
What would you do?
The portal team wants to create sales orders in S/4HANA with a synchronous API call and show the customer an order number immediately. During peak hours S/4HANA maintenance windows and slow responses are expected. What should the architect recommend?
- ISA-M: classify by domain, integration style and use case pattern, then map to technology.
- Five styles: process, data, analytics, user and thing integration.
- Choose interaction patterns by need: sync API, async messaging, events, batch, replication.
- Prefer a governed integration platform; keep point-to-point links simple and few.
Check your understanding · not graded
Lesson check
1. Which is one of the ISA-M integration styles?
2. In ISA-M, which use case pattern belongs to the process integration style?
3. Which pattern fits a business document that must arrive exactly once?
4. What is the main quality risk of synchronous request/response?