Lesson 2 of 5
Synchronous versus asynchronous
9 min
Listen to this lesson
The most important design choice in any interface is whether the caller waits. In synchronous integration the sender makes a request and waits for the answer before it continues, like a phone call. In asynchronous integration the sender hands the message over and carries on; the answer, if any, comes later, like a letter. Neither is better. Each fits different business needs, and each fails in a different way.
| Question | Synchronous | Asynchronous |
|---|---|---|
| Does the caller wait? | Yes, until a response or a timeout | No; the message is stored and delivered later |
| Typical SAP technologies | OData, RFC/BAPI, synchronous SOAP | IDoc over tRFC, asynchronous SOAP, events, files |
| What happens if the receiver is down? | The call fails immediately; the caller must retry or show an error | Messages queue up and are delivered when the receiver returns |
| Delivery guarantee | The caller knows the result at once | Depends on the protocol; queues can guarantee once-only, in-order delivery |
| Good fit | Lookups, checks, user screens that need an answer now | Business documents, high volumes, partners that are not always online |
| Main risk | Slow or unavailable receiver blocks the user or process | Silent backlog: messages wait or fail without anyone noticing |
Synchronous: the answer now
Use synchronous calls when the sender cannot continue without the answer. A sales rep entering an order in the customer portal needs to know the available-to-promise date before telling the customer. The portal calls an OData service and waits. If SAP S/4HANA answers in half a second, the user is happy. If it takes 30 seconds, the user leaves. If the system is down, the portal must show a sensible message.
This makes synchronous integration sensitive to performance and availability. Tests must cover response times under realistic load, timeouts, and what the calling application does when it gets an error. A synchronous interface that works in a quiet quality system can still fail on the first Monday morning after go-live.
Asynchronous: the message gets through eventually
Use asynchronous messages when the business document matters more than the immediate answer. Lakeside Components does not need Contoso to wait while its system books a purchase order. Contoso sends an ORDERS IDoc and moves on. If Lakeside's connection is down for an hour, the message waits and is delivered later. Later still, Lakeside replies with its own asynchronous order confirmation.
The price is visibility. An asynchronous failure does not show up on anyone's screen. An IDoc can sit in an error status for days while the business assumes the order went out. That is why asynchronous interfaces need monitoring with alerts and an owner, and why testers must check the end of the chain, not just the start.
- Contoso creates POPurchase order 4500002210 for 500 rotors CMC-RTR-200 is saved in SAP S/4HANA
- Outbound IDocORDERS IDoc is created and passed to the port; the buyer continues working
- MiddlewareMessage is mapped and queued for Lakeside Components
- Partner receivesLakeside books the order in its own system, minutes or hours later
- Asynchronous replyAn order confirmation comes back and updates the PO confirmation tab
Quality of service
Asynchronous protocols differ in their guarantees. SAP describes these as quality of service. Best effort is how synchronous calls work: one attempt, and the caller sees the result. Exactly once means the message is delivered once and only once, which transactional RFC (tRFC) provides for IDocs. Exactly once in order adds sequencing through queues (qRFC), which matters when a change must not overtake the create it depends on. When you review an interface design, ask which guarantee it needs and whether the chosen technology gives it.
What would you do?
The customer portal team wants to check whether a fleet customer has exceeded its credit limit before accepting an order online. Theo proposes a nightly file of credit exposure. What is the best response?
- Synchronous: the caller waits; good for lookups and decisions a user needs now; sensitive to speed and availability.
- Asynchronous: the sender hands over the message and continues; good for business documents and volume; failures are silent.
- Know the quality of service: best effort, exactly once, or exactly once in order.
- Test duplicates, timeouts and backlogs, and collect evidence at the far end of the chain.
Check your understanding · not graded
Lesson check
1. What is the main operational risk of an asynchronous interface?
2. Which quality of service do you need when a change message must never overtake the create message it depends on?
3. A portal needs the available-to-promise date while the customer is on the phone. Which style fits?