OData Debugging: External Breakpoints, Error Logs and Payload

Explanation

OData debugging requires knowing the runtime user and request context. Session breakpoints often do not stop because the service is called from Fiori, browser, middleware or a technical user. Set an external breakpoint for the actual runtime user. Use /IWFND/ERROR_LOG for frontend Gateway errors and /IWBEP/ERROR_LOG for backend errors. Use /IWFND/GW_CLIENT to replay requests. Inspect filters, key values, payload, headers, top/skip and entity set name in DPC_EXT. A strong debugger compares the Fiori request with Gateway Client request because frontend may send different filters or payload.

Code example

* OData debugging checklist:* 1. Identify actual runtime user.* 2. Set external breakpoint for that user.* 3. Check /IWFND/ERROR_LOG and /IWBEP/ERROR_LOG.* 4. Replay request in /IWFND/GW_CLIENT.* 5. Inspect key values, filters, payload, top and skip. METHOD customerset_get_entityset.   * Set external breakpoint here for the runtime user.   DATA(lt_filters) = io_tech_request_context->get_filter( )->get_filter_select_options( ).  DATA(lv_top)     = io_tech_request_context->get_top( ).  DATA(lv_skip)    = io_tech_request_context->get_skip( ).   * Check whether frontend is sending expected filters and paging. ENDMETHOD.

Real project scenario

A Gateway Client test works, but Fiori fails. Debugging shows Fiori sends $skip and $top, but backend ignores paging and returns too much data.

Common mistakes

- Using session breakpoint for Fiori request. - Setting breakpoint for wrong user. - Ignoring Gateway error logs. - Testing different request in Gateway Client than frontend.

Best practices

- Use external breakpoint. - Check correct runtime user. - Use Gateway error logs. - Replay exact request. - Inspect request context.

Interview angle

A practical answer should include external breakpoint, runtime user, Gateway logs and payload/filter inspection.