SAP IDoc Integration

IDoc integration exchanges structured business documents (orders, invoices, master data) asynchronously, with full status tracking and reprocessing. It is robust and restartable, ideal for high volumes and where guaranteed, auditable document delivery matters (classic EDI).

• IDoc types/segments defining the document.
• ALE (SAP-SAP) and EDI subsystems (partners).
• Partner profiles & ports.
• Status monitoring (WE02/BD87).

An IDoc has three parts and knowing them makes the monitoring transactions readable.

The control record is the envelope: sender, receiver, message type, IDoc type and direction. It answers who sent what to whom. The data records are the segments, a hierarchy carrying the actual document, header segments with item segments below them. The status records are the history, one per state the IDoc has passed through, each with a message.

The message type says what the document means, such as ORDERS for a purchase order. The IDoc type says how it is structured, and one message type can have several as the structure is extended over releases. Custom fields are added by extending the IDoc type, not by editing the standard one.

The statuses are worth memorising because they route the investigation. Outbound: 03 dispatched, 02 error passing to the port. Inbound: 53 posted, 51 application error, 64 waiting to be processed. A 51 means the document arrived intact and the receiving application refused it, which is a data problem in the receiver rather than an interface fault.

WE02 and WE05 list and display IDocs, and WE19 is the test tool that lets you copy an existing IDoc, change a value and reprocess it, which is how most debugging is actually done.

WE20 holds partner profiles, defining which message types a partner may send and receive and with which process code. WE21 defines ports, the technical channel. WE31 and WE30 maintain segments and IDoc types when a custom extension is needed. BD87 reprocesses IDocs in bulk, and SM58 shows transactional RFC calls that never left.

Distribution model configuration for SAP to SAP scenarios is BD64. The tables are EDIDC for control records, EDID4 for data and EDIDS for status.

Half an hour, and it teaches the diagnostic order that makes IDoc work fast.

1. Find a successfully posted inbound IDoc in WE02, status 53.
2. Open WE19, use it as a template, and change a field to something invalid, such as a material number that does not exist.
3. Process it inbound. It fails with status 51 and a message naming the missing object.
4. Read the status record. The message is from the receiving application, not from the interface, which is the distinction that matters.
5. Create the missing master record, then reprocess the same IDoc with BD87. It posts. Nothing about the interface changed.

That sequence, and the confidence that a 51 is not a connectivity problem, is most of what an IDoc support role asks for. See SAP integration for where this sits among the other styles.

Use IDocs for asynchronous, high-volume, guaranteed document exchange, especially EDI and SAP-to-SAP distribution. Modern middleware (CPI/PI-PO) often orchestrates IDoc flows to/from partners.

And when not to. A caller that needs an answer before it can continue should not be waiting on an asynchronous document, so a credit check or an availability enquiry belongs on a synchronous API instead. See SAP REST integration and Integration Suite for those.

• Standard message type or extension. Extending is supported and every extension is something you own through upgrades. Exhaust the standard segments first.
• Immediate or collected processing. Immediate is responsive and creates load per document. Collected batches and is easier on a busy system.
• Who watches the errors. Failed IDocs accumulate silently, so somebody must own a daily check, or an alert must exist. This is the single most common operational gap.
• Reprocess or resend. Reprocessing uses the IDoc already received. Resending asks the sender again. Which is correct depends on whether the data was wrong or the receiver was.

IDoc is the document format. ALE is the framework that decides who gets which document, and the two are often spoken about as one thing.

The distribution model, maintained in BD64, is a list of statements of the form: this system sends this message type to that system, optionally filtered. It is maintained in one system and distributed to the others, so everyone agrees on the arrangement.

Filters are what make it useful. Sending every material master to every plant system is rarely wanted; sending only the materials for that plant is. The filter sits in the model rather than in code, so changing what a partner receives is configuration.

Change pointers are the mechanism for master data distribution. When a field marked as relevant changes, a pointer is written, and a periodic job turns accumulated pointers into IDocs. That is why a material change does not always leave immediately: it leaves when the job runs. When somebody reports that master data is not reaching a system, the order to check is change pointers written, job scheduled, IDoc created, IDoc sent, IDoc posted.

Serialisation matters for master data because the order of arrival can change the result. Sending a change before the create, or two changes out of sequence, produces a state nobody intended.

For SAP to SAP master data distribution this framework is still the standard answer, and it predates and outlives several generations of middleware around it. See SAP master data for what is being distributed.

IDoc handles high volume well and there are a few things that decide whether it does.

Packet size. Sending one IDoc per document is simple and produces a great many small units of work. Collecting them into packets is more efficient and means a single bad document can hold up its packet.

Immediate versus collected processing. Immediate is responsive and each document costs a dialogue process. Collected uses a background job and is far kinder to a busy system, at the cost of latency measured in minutes.

Parallel processing. Inbound processing can be spread across servers, and doing so is usually necessary once volumes are real.

Archiving. The IDoc tables grow forever, and on an established interface they are often among the largest in the system. An archiving strategy from the start avoids a painful retrofit.

The failure mode to plan for is a backlog: a receiving system down for an hour leaves thousands of documents queued, and how they drain when it returns is a design decision rather than something to discover.

• Wrong tool for the integration style.
• Ignoring monitoring/error handling.
• Point-to-point instead of governed integration.

• Treating status 51 as an interface failure. It is an application rejection, and the fix is usually master data in the receiver.
• Deleting failed IDocs to clear the monitor. The document is the evidence of what a partner sent.
• No archiving. IDoc tables grow forever, and on a busy interface they become one of the largest data sets in the system.

Reading and reprocessing an IDoc is the daily work, and configuring partner profiles, ports and the distribution model behind them is the part you do in the course.

And the diagnostic habit: read the status before anything else. It tells you whether the document left, arrived, or arrived and was refused, and those three states send you to three different systems.