ABAP Developmentadvanced

Debugging Part 9: RFC, IDoc and OData Debugging

Key takeaway

Debug calls that arrive from outside: RFC function modules called by external systems, inbound IDocs (WE19), OData/Fiori requests (external breakpoints, /IWFND/ERROR LOG, /IWBEP/ERROR LOG, /IWFND/GW CLIENT), and asynchronous tRFC/qRFC calls in SM58/SMQ2.

Explanation

📌 KEY POINTS
✅ RFC calls from outside run under the RFC user of the caller's destination — set external breakpoints for that user (with permission and debug authorization).
✅ IDocs: copy with WE19 and run the inbound function module in foreground/debug mode (test systems) instead of waiting for the real partner.
✅ OData: /IWFND/ERROR_LOG (hub) and /IWBEP/ERROR_LOG (backend) show failed requests; /IWFND/GW_CLIENT replays requests as your user so session/external breakpoints work.
⚠️ Asynchronous calls (tRFC/qRFC/bgRFC) execute later in other processes — inspect SM58/SMQ2 and debug by replaying the call, not the original sender.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 3 introduced external breakpoints. This lesson applies them to the main integration channels.

━━━━━━━━━━━━━━━━━━━━
▶ 1. RFC FROM EXTERNAL SYSTEMS

Identify the RFC user (caller's SM59 destination or logs: STAD, SM04 during call).
External breakpoint for that user in the called FM; trigger the call from the partner system.
Alternative: test the FM in SE37 with the same input (capture input via logging).

━━━━━━━━━━━━━━━━━━━━
▶ 2. IDOCS

WE19: enter IDoc number → copy → "Inbound function module" → choose FM → foreground / debug.
Breakpoints in the FM or its exits beforehand.
For outbound: repeat output from the document in a test system with breakpoints in the output FM.

━━━━━━━━━━━━━━━━━━━━
▶ 3. ODATA / FIORI

/IWFND/ERROR_LOG: error text, request URI, user, payload; "Replay" option to /IWFND/GW_CLIENT.
/IWBEP/ERROR_LOG: backend-specific errors.
External breakpoint for the Fiori user or replay in GW client as yourself.
Browser developer tools: see the $batch requests and responses.

━━━━━━━━━━━━━━━━━━━━
▶ 4. ASYNCHRONOUS RFC

SM58: tRFC errors with text; "Execute LUW" reprocesses.
SMQ1/SMQ2: outbound/inbound queues; lock the queue, debug the first LUW (SMQ2 → debug LUW) in test systems.
bgRFC: SBGRFCMON.

━━━━━━━━━━━━━━━━━━━━
▶ 5. PAYLOAD CAPTURE
For hard-to-reproduce cases, log the incoming payload (SLG1 or Z table) temporarily, then replay locally.

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

Find a failed request in /IWFND/ERROR_LOG and replay it in the GW client with a breakpoint.
Debug an inbound IDoc with WE19.
Inspect SM58 for tRFC errors in a test system.

✅ CHECKPOINT: you can debug RFC, IDoc and OData calls without waiting for external partners.

Code example

ABAP Code

* ===== Temporary payload capture in an RFC-enabled FM (remove after analysis) =====FUNCTION z_rfc_create_order.*"  IMPORTING VALUE(IS_ORDER) TYPE ZS_RFC_ORDER*"  EXPORTING VALUE(EV_VBELN) TYPE VBELN_VA*"  TABLES    ET_RETURN STRUCTURE BAPIRET2  DATA: ls_log TYPE zrfc_payload_log,        lv_ts  TYPE timestampl.   GET TIME STAMP FIELD lv_ts.  ls_log-ts      = lv_ts.  ls_log-uname   = sy-uname.              " the RFC user actually executing  ls_log-payload = is_order.              " flat char field copy for replay (simplified)  INSERT zrfc_payload_log FROM ls_log.   " ... business logic (BAPI call etc.)ENDFUNCTION. * ===== Tools per channel =====* RFC      : external breakpoint for the RFC user; SE37 test with captured input* IDoc     : WE19 -> copy -> inbound function module -> foreground/debug* OData    : /IWFND/ERROR_LOG (replay), /IWBEP/ERROR_LOG, /IWFND/GW_CLIENT* tRFC     : SM58 (error text, execute LUW)* qRFC     : SMQ1 / SMQ2 (queue status, debug LUW in test)* bgRFC    : SBGRFCMON

Real project scenario

A warehouse system's RFC calls to create goods movements failed intermittently. Developers could not reproduce them from SE37. Temporary payload logging showed the failing calls had storage location in lowercase, which the partner sent only for one site.
With the captured payload replayed in SE37 and an external breakpoint for the RFC user, the team confirmed the cause and added input normalisation. The logging was removed after the fix.

Common mistakes

Breakpoint for own user instead of the RFC/Fiori user.
Waiting for partners instead of replaying (WE19, GW client).
Debugging asynchronous calls at the sender.
Leaving payload logging in production permanently.
Ignoring /IWBEP/ERROR_LOG for backend errors.

Best practices

Identify the executing user.
Replay locally: SE37, WE19, GW client.
Use error logs per channel.
Temporary, controlled payload capture.
Check SM58/SMQ2 for async calls.

Interview angle

Questions: "How do you debug an RFC called from an external system?", "How do you debug an inbound IDoc?", "How do you debug a Fiori/OData error?"
Strong answer: external breakpoint for the RFC user or replay in SE37 with captured input; WE19 inbound FM in foreground/debug; /IWFND/ERROR_LOG and /IWBEP/ERROR_LOG with replay in /IWFND/GW_CLIENT, external breakpoint for Fiori user; SM58/SMQ2/SBGRFCMON for async.

Practice this lesson

Quick check

1. Which transaction lets you debug an inbound IDoc function module with a copy of a real IDoc?

2. Which transaction shows failed OData requests with user, URI and a replay option?

3. Where do you analyse failed transactional RFC (tRFC) calls?

Interview questions

1. As an architect, how would you decide, for a new complex integration involving background jobs, RFC calls, and update tasks, what proactive debugging and monitoring hooks should be built into the design from the start, rather than added reactively after production issues appear?

Answer it in your own words first, then compare.

2. An RFC-enabled function module is called from a non-SAP middleware system, and the caller reports a timeout, but no dump appears in ST22 on the SAP side. How would you debug this issue?

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.