Dealing with IDOCs

Jimbo's picture
Submitted by Jimbo on Thu, 08/27/2020 - 06:41

Dealing with IDOCsIn a long enough career implementing SAP, despite one's best efforts, an encounter with IDOCs is inevitable. Knowing how to handle IDOCs--especially in any implementation that uses MDG--will make short work of any problems one encounters as the result of using IDOCs.

In this example, a handful of Material Masters are MASS updated in an MDG system. The MM17 transaction successfully updates each of the Material Masters and the Material Masters are all already assigned to the Classification that triggers the ALE connector to update the Material Masters in the downstream system.

After some time, the Material Masters aren't updated in the downstream system. The first step is to check the MDG system to ensure that the IDOCs were created and to find out what, if anything, is happening with them.

The system creates a series of IDOCs to pass across the ALE (Application Link Enabling) connector automatically. For whatever reason, the IDOCs rest peacefully in the outbound queue instead of being processed and passed to the downstream SAP system, so the obvious next step is to process them.


In the target SAP system (likely the production server), the inbound IDOCs can be found by simply searching for them. Filtering by the time and date makes the work much easier.

These IDOCs might sit idle in the inbound processing queue, but the steps to get these processed are the same as they were for the outbound queue. Just select them and click on the Process button.

Using IDOCs to move Master Data between systems

Sending Material Masters from one system to the next is easy enough using the BD10 transaction. BD12 and BD14 can be used for Customer Masters and Vendor Masters respectively. Naturally, the ALE connections will need to be set up in advance, but that's not in the scope of this article is covered elsewhere on this site.

Dealing with failed IDOCs

Modifying IDOCs that fail is an easy enough task. In BD87, just drill down to the individual IDOC to see what error has caused the IDOC to fail.

Next, launch WE19 to edit the inbound IDOC. This doesn't actually edit the IDOC, but instead creates a new one with the corrected data.

Here the WE19 tool can be used to correct the fields that are causing the IDOC to fail. Save the IDOC and send it into the inbound queue by clicking on the "Standard Inbound" button.

This will create a new inbound IDOC that can be processed like any other IDOC. Just click on the green message at the bottom and copy-paste the new IDOC number into BD87 to process it manually.