ABAP Developmentadvanced

IDoc Part 10: Debugging and Production Support

Key takeaway

Support IDoc interfaces in production: a triage sequence by status, debugging inbound FMs with WE19 and BD87, outbound debugging (output processing, RSNAST00, exits), tRFC problems in SM58, partner/customizing checks, monitoring and alerting, and safe correction procedures.

Explanation

📌 KEY POINTS
✅ Triage by status first: 51 business error, 56 partner profile, 64/30 waiting jobs, 02 port/RFC, 03 but not received → receiver side.
✅ Debug inbound with WE19 (copy IDoc, "inbound function module" with debugging, in foreground) — never debug in production by reprocessing real IDocs without need.
✅ Outbound problems: check the document's output log (NAST), process output with RSNAST00, debug the exit that fills segments, and SM58 for tRFC errors.
⚠️ Corrections in production (editing IDocs, reprocessing, setting 68) must be documented — they change business data flows.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–9 covered building and configuring IDocs. This lesson is the support playbook.

━━━━━━━━━━━━━━━━━━━━
▶ 1. TRIAGE

WE02/WE05/BD87: find the IDoc by partner, message type, date or content (WE09 searches segment content).
Read the status history and the last status message (with long text).
Classify: configuration (56, 29, 02), business (51), job/backlog (64, 30), receiver (03 but not processed there).

━━━━━━━━━━━━━━━━━━━━
▶ 2. INBOUND DEBUGGING

WE19: enter IDoc number → copy → "Inbound function module" → select FM → "In foreground / debugging".
Set breakpoints in the FM or exits (e.g. VEDA0001 includes) before executing.
For CALL TRANSACTION–based inbound (e.g. some FMs with input method), process in foreground ("A" mode) in a test system to see the screens.

━━━━━━━━━━━━━━━━━━━━
▶ 3. OUTBOUND DEBUGGING

Document output log: was the output found and processed? Error messages?
Repeat output (test system) and debug the process code FM (e.g. IDOC_OUTPUT_ORDRSP) and customer exits.
RSNAST00 for pending outputs; check dispatch time settings.

━━━━━━━━━━━━━━━━━━━━
▶ 4. TRANSFER PROBLEMS

SM58: tRFC calls in error (e.g. logon failure, receiver down); execute again after fixing.
SM59: test the destination; check communication user lock.
BD87 for status 02/30 after fixing.

━━━━━━━━━━━━━━━━━━━━
▶ 5. MONITORING

Daily status overview by message type (Part 8 report), alerts for 51/56/02 and old 64/30.
Error agents in partner profiles / workflow notifications.
Solution Manager / Cloud ALM interface monitoring where available.
Archiving (SARA, IDOC) and deletion of old IDocs to keep tables small.

━━━━━━━━━━━━━━━━━━━━
▶ 6. CORRECTION PROCEDURES

Fix root cause first; reprocess; verify the business document.
Editing IDocs only with business approval; set obsolete IDocs to 68 with reason.
Record incidents and patterns; automate recurring fixes.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Find an IDoc with status 51 in a test system and debug it with WE19 inbound FM.
Search IDocs by content with WE09 (e.g. a PO number).
Check SM58 and describe what you would do for a failed tRFC entry.

✅ CHECKPOINT: you can diagnose and resolve IDoc incidents systematically and safely.

Code example

ABAP Code

* ===== Support playbook (as code comments) =====* 1) Find      : WE02/WE05 (partner, message type, date), WE09 (search segment content)* 2) Status    : read status history + long text (EDIDS)* 3) Classify  :*      51       -> business error: master data, customizing, mapping*      56 / 29  -> configuration: WE20 partner profile, BD64 model*      64 / 30  -> backlog: RBDAPP01 / RSEOUT00 jobs*      02       -> transfer: SM58, SM59, receiver availability*      03 only  -> check receiver side / middleware* 4) Debug     : WE19 copy -> inbound FM -> foreground/debug (test system)*                outbound: document output log, RSNAST00, process code FM, exits* 5) Fix+verify: correct cause -> BD87 -> check document / status 53* 6) Document  : incident, approval for edits (69) or closure (68) * ===== Find IDocs by a value in segment data (last N days) =====REPORT zidoc_find_value. PARAMETERS: p_mestyp TYPE edi_mestyp DEFAULT 'ORDERS',            p_value  TYPE c LENGTH 35 OBLIGATORY,            p_days   TYPE i DEFAULT 3. DATA: lt_edidc TYPE STANDARD TABLE OF edidc,      ls_edidc TYPE edidc,      lt_data  TYPE STANDARD TABLE OF edid4,      ls_data  TYPE edid4,      lv_from  TYPE sy-datum. START-OF-SELECTION.  lv_from = sy-datum - p_days.  SELECT * FROM edidc INTO TABLE lt_edidc    WHERE mestyp = p_mestyp AND credat >= lv_from.   LOOP AT lt_edidc INTO ls_edidc.    REFRESH lt_data.    SELECT * FROM edid4 INTO TABLE lt_data WHERE docnum = ls_edidc-docnum.    LOOP AT lt_data INTO ls_data WHERE sdata CS p_value.      WRITE: / ls_edidc-docnum, ls_edidc-status, ls_data-segnam.      EXIT.    ENDLOOP.  ENDLOOP.* For large volumes prefer WE09 or restrict by partner/date further.

Real project scenario

On quarter-end, 1,500 INVOIC IDocs to a key customer showed status 03 but the customer said nothing arrived. SM58 was clean; the middleware log showed the messages rejected because a new mandatory field was missing in the mapping after the customer changed its EDI spec.
The team fixed the mapping in middleware, resent the IDocs after agreement with the customer, and added an acknowledgement (status 16) so that "sent but rejected" is visible in SAP next time.

Common mistakes

Debugging by reprocessing real production IDocs.
Assuming status 03 means received and processed.
Editing IDocs without approval.
Ignoring SM58 for outbound transfer issues.
No archiving; EDID4 grows without limit.

Best practices

Triage by status and message type.
Debug with WE19 copies in test systems.
Use acknowledgements for critical partners.
Monitor and alert 51/56/02 and backlogs.
Document corrections and automate recurring fixes.

Interview angle

Questions: "How do you debug an inbound IDoc?", "An IDoc is in status 03 but the partner didn't receive it — what do you do?", "How do you support IDoc interfaces?"
Strong answer: triage by status (51/56/64/30/02/03); WE19 copy with inbound FM in foreground/debugging and breakpoints in exits; outbound: output log, RSNAST00, process code FM; SM58/SM59 for tRFC; 03 means sent from SAP — check middleware/receiver, use acknowledgements; monitoring, archiving, documented corrections.

Practice this lesson

Quick check

1. Best way to debug an inbound IDoc function module?

2. Which transaction is primarily used as a test tool to manually create and dispatch an outbound or inbound IDoc without needing an actual application transaction to trigger it?

3. Outbound IDoc exists but failed due to tRFC communication issue. Which transaction is useful to check?

Interview questions

1. How do you troubleshoot a failed inbound IDoc?

Answer it in your own words first, then compare.

2. IDoc integration is replaced with OData/RAP. Migration plan?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.