RFC, IDoc and OData External Debugging

Explanation

External debugging is needed when ABAP code is triggered by a different user or external process, such as RFC calls, OData services, IDoc processing, web applications or middleware. Session breakpoints work only for your current GUI session. External breakpoints are user-specific and are used when another user or technical user executes the code. For OData, the execution user may be a frontend or service user. For RFC, it may be an RFC destination user. For IDocs, processing may happen in background. A senior debugger checks the actual execution user and sets external breakpoint accordingly.

Code example

* External debugging checklist:* 1. Identify the actual runtime user.*    - OData/Fiori user*    - RFC destination user*    - IDoc/background user* 2. Set external breakpoint for that user.* 3. Trigger the request from external system.* 4. Check input payload, filters and authorization. METHOD /iwbep/if_mgw_appl_srv_runtime~get_entityset.   * Set external breakpoint here for the correct runtime user.  * For OData, check filter/select/top/skip values here.   DATA(lt_filter) = io_tech_request_context->get_filter( )->get_filter_select_options( ). ENDMETHOD.

Real project scenario

An OData service works in SAP Gateway Client but fails from Fiori app. External breakpoint was set for the developer user, but runtime user was a different frontend user. Setting breakpoint for the correct user exposed a missing filter mapping.

Common mistakes

- Setting session breakpoint instead of external breakpoint. - Setting breakpoint for wrong user. - Testing in Gateway Client but issue happens only from app. - Ignoring authorization difference.

Best practices

- Find actual execution user. - Use external breakpoint. - Check request payload/filter data. - Compare manual test and external call. - Check authorization for runtime user.

Interview angle

A practical answer should mention external breakpoint, runtime user, RFC/OData/IDoc context and authorization.