IDoc automation

IDocs are the workhorse of SAP integration: EDI orders and invoices, master data distribution, and many links between SAP systems. Every IDoc has a control record (who sent it, to whom, which message and IDoc type), data records (the segments with business data) and status records that log each processing step. An automated IDoc test creates or sends an IDoc, follows its status and checks the document it produced.

The status codes that matter

SAP's documentation for testing inbound processing is clear about the decisive statuses: when the application has accepted the IDoc, its status is 53 (application document posted); otherwise it is 51 (application document not posted), and the status records hold the application's error messages. Before that, status 64 means the IDoc is ready to be passed to the application. When the test tool writes an IDoc to an inbound file, it saves it with status 68 (error, no further processing).

Creating test IDocs: WE19

The IDoc test tool (transaction WE19) generates an IDoc manually and sends it for inbound or outbound processing. You can start from an IDoc type (an empty IDoc) or use an existing IDoc as a template and change segments and data. For inbound tests, SAP's documentation describes three options: standard inbound processing, where the IDoc is treated as if an external system sent it and the partner profiles are checked; calling the inbound function module directly, optionally in debugging mode; and writing an inbound file. Use standard inbound processing for regression tests, because it tests the partner profile and process code as production will use them.

For automated regression, WE19 is a design and debugging aid rather than the runner. A repeatable test sends the IDoc through the same channel production uses (a file port, an RFC from another system, or the middleware), with a template whose business values are parameters. Keep a library of anonymized template IDocs per message type and partner, and set unique references (such as the customer purchase order number) per run.

Monitoring and assertions

The status monitor (BD87) shows inbound and outbound IDocs grouped by status, message type or partner, lets you display individual IDocs with their control, data and status records, shows links to application objects, and lets you process IDocs manually. For automation you need the same information programmatically: find the IDoc by your reference or by message type and creation time, wait for a final status, read the status records, follow the link to the application document, and assert on that document.

Negative and edge cases

• Unknown material or customer: expect status 51 with the specific message, and no sales order.
• Missing partner profile: expect the IDoc to stop before the application; this proves configuration, not just code.
• Duplicate: send the same customer PO twice and check the expected duplicate handling (a warning, a block or a second order, per Contoso's design).
• Reprocessing: fix the master data and reprocess a 51 IDoc; it should then post. Remember that status 53 IDocs cannot be processed again.
• Volume: send a realistic batch and check that processing mode (immediate or collected) handles it without backlog.