ABAP Debugger: Session vs External Breakpoints and Watchpoints

The New ABAP Debugger can stop at static BREAK-POINT statements, dynamic session breakpoints, external breakpoints, exception breakpoints, message breakpoints and watchpoints. A session breakpoint is tied to the current internal/external session context and is ideal for SAP GUI dialog execution. External breakpoints are stored so requests entering through ICF/RFC under the same user can trigger debugging even though they run in another session. Debugger settings, system/client/user and request user identity all matter. Update, background and system-user processing require additional techniques beyond simply placing a session breakpoint.

Use session breakpoints when you start the transaction/report yourself in the same GUI user session. Use external breakpoints for OData/Fiori/RFC/HTTP requests executed under your user or a user whose debugging authorization/context is intentionally configured. Use watchpoints when the key question is where a variable becomes wrong rather than which code path runs. Prefer conditional breakpoints to stopping thousands of loop iterations. On production, use traces/logs first and attach debugging only under controlled support procedures.

Debugger work sits alongside ST22, Gateway error logs, SAT/ST05, application logs and authorization traces. A dump may reveal the failing statement without a debugger; a performance issue may need SAT instead of step-through; an OData 500 often needs /IWFND/ERROR_LOG to identify the backend exception before setting a targeted breakpoint. Remote calls can execute under technical users, which explains why an external breakpoint for the developer's user is ignored.

A Fiori save request reaches a RAP behavior implementation but a breakpoint set in ADT never triggers. The browser request is actually executed under a propagated business user different from the developer account. The team identifies the backend user from Gateway/request context, sets the permitted external breakpoint for that user in the correct system/client and repeats the request. The debugger stops immediately. The same logic called from a local test class would have worked with a session breakpoint.

The debugger remains fundamental in S/4HANA, RAP and classic code. ADT integrates breakpoints for modern ABAP development; OData/RAP requests still require the correct external-user context. ABAP Cloud allows debugging of permitted custom code but not arbitrary modification/access to restricted standard internals. Observability should increasingly complement, not replace, targeted debugging.

ABAP developers own breakpoint strategy and must respect debugging authorizations. Basis/security control production debugging access. Integration/Fiori teams supply request correlation and actual execution user/system so development can attach to the right context.

ST22, /IWFND/ERROR_LOG and SLG1 often identify the location before debugging. The background/RFC/update debugging topic covers contexts where normal external breakpoints are insufficient.

Production verification: Capture system and client, actual execution user, timestamp, request, job or RFC context, program, class or method, and the log or correlation identifier that proves the failing path. This prevents debugging the wrong system, user, work process or frontend layer and gives support a reproducible starting point.

Operational readiness: For production readiness of ABAP Debugger: Session vs External Breakpoints and Watchpoints, add one reproducible test case with realistic data volume and boundary values, one negative test that proves the failure contract, and one operational check that a support developer can run without changing productive data. Record the exact program, class or function and any release-dependent API assumptions. Where the topic affects performance or transaction consistency, compare evidence before and after the change instead of relying on coding folklore or one sandbox execution.