All topics
49 / 65
Integrationintermediate

IDoc & ALE (Application Link Enabling)

SAP's classic asynchronous document exchange format and the distributed system linking framework built around it.

An IDoc is a business document in a fixed, segment-based format, sent asynchronously between systems. ALE is the framework that decides who sends what to whom.

An IDoc is like a shipping manifest with a strict, standardized form (segments) that two companies' warehouses (SAP systems) both understand, dropped into a delivery service (the port/transactional RFC) that guarantees eventual delivery even if the receiving warehouse is temporarily closed, unlike a phone call (synchronous RFC) that requires both parties on the line at the same instant.

Key Concepts

1
Enormous amounts of live SAP integration still run on this, which is why it is asked about.
2
What an IDoc contains.
    control record   sender, receiver, message type, IDoc type
    data segments    the business content, in a defined structure
    status records   what has happened to it so far
3
The structure is rigid by design. Both sides agree on the IDoc type in advance, so no negotiation or schema discovery happens at runtime.
4
The configuration, and what each piece does.
    BD64   distribution model -- which system sends which message
           type to which other system
    WE20   partner profiles -- per partner, how to process inbound and
           outbound messages
    WE21   ports -- the technical transport: tRFC, file, or middleware
5
A partner profile is where most incidents start. It names the function module that processes an inbound IDoc and whether processing happens immediately or in a background job.
6
How an outbound IDoc is triggered. Either the application creates it directly, or change pointers do: a mechanism that watches specific fields and queues an IDoc when they change (BD50, BD61, and a job running RBDMIDOC).
BD50BD61RBDMIDOC
7
Change pointers are the usual answer to "master data changed in one system, distribute it". They also explain a common puzzle — the change happened and no IDoc appeared — because the job that converts pointers into IDocs runs on a schedule and may not have run.
8
Status codes are the daily language.
    03  passed to port                 30  ready for dispatch
    51  application document not posted 53  posted successfully
    56  IDoc with errors added         64  ready to be transferred
9
51 is the one you spend time on: the IDoc arrived, was well-formed, and the posting failed on a business rule. Its status record carries the message, which is the actual error.
10
WE02 and WE05 list and display IDocs; BD87 monitors and reprocesses failed ones. Reprocessing after fixing the cause is routine, and it is why an IDoc that fails is recoverable rather than lost.
WE02WE05BD87
11
Why it is still the right tool sometimes. High volume, asynchronous, guaranteed delivery, between systems that both speak it. An IDoc is queued and retried; it does not require the receiver to be up.
12
A synchronous API call requires the far end to be available and the caller to wait. For a nightly flood of material master changes that is the wrong shape.
13
And where it is not. Anything needing a response, anything conversational, anything where the receiver is a modern service expecting JSON. New integration usually means OData or an event, orchestrated by CPI — but "IDoc is legacy" is the wrong summary, since it remains the standard for SAP-to-SAP asynchronous document exchange.
14
What the interviewer is probing.1. "Describe the IDoc structure." Probing: the fundamentals. Stalls: "It is a file." *Moves up:* a control record with sender and receiver, data records in segments, and status records tracking processing — status is where you troubleshoot.
15
2. "What do you check for a failed inbound IDoc?" Probing: the practical skill. Stalls: "Resend it." Moves up: the status in WE02 or WE05, the partner profile in WE20, and whether the process code and function module found the data it needed.
16
3. "What is the role of the distribution model?" Probing: the ALE part. Stalls: "Nothing." Moves up: BD64 declares which message types flow between logical systems, which generates partner profiles and filters data.
17
4. "How do you reprocess without duplicating?" Probing: the care. Stalls: "Just resend." Moves up: edit and reprocess the existing IDoc with BD87 rather than resending from the source, which would create a second document.
Use cases:idocaleintegrationasynchronous-messaging