Lesson 4 of 5
Monitoring and reprocessing
10 min
Listen to this lesson
IDoc interfaces are asynchronous, so failures are silent. Nobody's screen turns red when a supplier's order confirmation fails at 3 a.m. Monitoring is therefore a daily job with a named owner, and reprocessing is a controlled procedure, not a button anyone presses. This lesson covers the tools in an SAP S/4HANA system and the discipline around them.
Finding IDocs
| Tool | Use it to |
|---|---|
WE02 / WE05 IDoc display | List IDocs by date, direction, status, message type and partner; open one to see its records |
WE09 search by content | Find IDocs that contain a value in a segment field, such as Great Lakes' purchase order number |
BD87 status monitor | See IDocs grouped by status and message type, and process selected ones again |
SM58 transactional RFC | Find outbound IDocs stuck in the tRFC layer because the receiver was unreachable |
WLF_IDOC IDoc monitor | A combined list, display and processing tool, originally the IDoc monitor for agency business. It shows all segments of one name at once, compares two IDocs and starts reprocessing; field editing works only after Customizing says which fields may be changed |
| SAP Cloud ALM integration monitoring | Central monitoring and alerting for IDocs and other messages across systems, after setup |
| SAP Application Interface Framework (AIF) | For IDoc interfaces enabled for AIF monitoring: business users see and fix their own errors in the Message Dashboard (a Web Dynpro app on the launchpad) or /AIF/ERR; integration experts use Message Monitoring for Integration Experts (SAP S/4HANA 2021 and later) |
Tools for finding and monitoring IDocs. WLF_IDOC, AIF and Cloud ALM monitoring depend on your system, setup and license; check yours.
SAP Cloud ALM's Integration and Exception Monitoring can collect IDoc messages from SAP S/4HANA on-premise and Private Edition systems and raise events for failed messages, unusual volumes or long processing times. For a program like Contoso's, where the S/4HANA project already runs in SAP Cloud ALM, that gives operations one place for alerts instead of a person checking BD87 every morning. It needs setup and SAP notes in the managed system; plan it as a deliverable, not an afterthought.
- Alert or daily checkMonitoring flags failed IDocs or a person reviews BD87 by status
- Read the errorOpen the status record and application log
- ClassifyMaster data, configuration, mapping or partner data
- Fix the causeOwner corrects data or configuration; mapping fixes go through change control
- ReprocessProcess the original IDoc again with BD87 or the scheduled job
- VerifyStatus 53 and the posted document; record the incident
Reprocessing options
Once the cause is fixed, the original IDoc can be processed again. In BD87 you select IDocs by status and choose to process them; the system runs the same inbound function as before. For large numbers of failures, background programs process IDocs by status: RBDAPP01 for IDocs waiting in 64, RBDMANI2 for IDocs in 51, and RSEOUT00 for outbound IDocs waiting in 30. RBDAGAIN retries outbound IDocs in error statuses such as 02 and 29, and RBDAGAIE processes edited IDocs (32 and 69). Each run of a failing IDoc adds another status record, so do not schedule reprocessing of 51s every few minutes without fixing causes first.
Sometimes the data in the IDoc itself is wrong and the partner cannot resend. SAP allows authorized users to edit an IDoc. When an edited IDoc is saved, it gets status 69 (IDoc was edited), and the system keeps a copy of the original with status 70. That trail matters for audit: it shows exactly what was changed. Editing should be rare, authorized by role and recorded with a reason, especially for financial messages such as invoices.
| Situation | Right action | Wrong action |
|---|---|---|
| 51: material missing in sales area | Extend the material, then reprocess the original IDoc | Edit the IDoc to use a different material |
| 51: partner sent a wrong quantity | Partner corrects and resends; close original with 68 and a reason | Edit the quantity without the partner's written confirmation |
| 64 for hours | Check processing mode and job schedule; run the job | Set the status to 53 |
| 03 but partner never received it | Check middleware monitor and SM58, then the partner | Create a new IDoc with WE19 in production |
| Duplicate inbound order | Confirm, then close the duplicate with 68 and a reason | Post both and cancel one later |
What would you do?
On the Monday after go-live, 140 inbound order IDocs from Great Lakes are in status 51 with "Pricing error: mandatory condition PPR0 is missing". Sam, the Basis lead, offers to schedule RBDMANI2 every 10 minutes. What should Theo do?
- Find IDocs with WE02/WE05, WE09 and BD87; check SM58 for outbound tRFC problems.
- SAP Cloud ALM integration monitoring can alert on failed IDocs after setup.
- Fix the cause first, then reprocess the original IDoc, then verify the business document.
- Editing an IDoc creates statuses 69 and 70; keep it rare, authorized and documented.
Check your understanding · not graded
Lesson check
1. Which transaction lets you find an IDoc by a value inside its segments, such as the customer's PO number?
2. What status does an IDoc get when an authorized user edits and saves it?
3. Why should you not schedule reprocessing of 51s every few minutes before fixing the cause?