Advanced breakpoints, enhancement points and scripts — Concepts and mental models

Training simulation: All sample identifiers, logs, requests, transactions, values and cases are fictional. Tools and permissions vary by SAP release; perform any changes only in approved DEV/QA environments.

Advanced breakpoints, enhancement points and scripts — Concepts and mental models

Outcome: Choose session/external breakpoints and watchpoints; locate enhancement calls without unsafe production edits.

SAP environment: SAP GUI New ABAP Debugger and authorized DEV; user/session, RFC and HTTP breakpoint constraints are release-dependent.

Mental models

1. Understand the boundary

A session breakpoint belongs to a specific dialog debugging context; an external breakpoint is designed for eligible requests such as HTTP/RFC reaching an ABAP backend. The user who executes the request may be a technical identity or a principal-propagated end user, so the breakpoint owner matters.

2. How this investigation works

Watchpoints stop when the watched value or condition changes. They are valuable when many routines can change a field, but can add overhead; use a narrow scope and inspect stack and field-symbol bindings when the debugger stops. Layer-aware debugging can help filter framework noise where SLAD is supported.

3. Evidence-based decision making

Enhancement framework, BAdIs and exits are not interchangeable. Find the actual active implementation and filter conditions rather than placing a breakpoint in the interface definition alone. Debugger scripts can collect bounded test evidence in DEV but are not a reason to export productive personal data.

Three common false diagnoses

• An external breakpoint in one user is not guaranteed to intercept a background technical user.
• An active enhancement implementation may be filtered out by business context.
• A watchpoint that fires after a write shows where to investigate; it does not prove that value was invalid for the business rule.

Worked synthetic evidence

Request: POST /sap/opu/odata/sap/Z_DEMO_SRV/OrderSetHTTP user: TEST_HTTP_USERBreakpoint owner: TEST_DIALOG_USERResult: request succeeds, breakpoint never stopsSecond attempt: breakpoint scoped to executing identity in DEV → debugger stops 

Diagnostic sequence

1. Identify user, work process and entry point
2. Choose correct breakpoint scope and watchpoint
3. Inspect enhancement and writer, then verify

What to inspect

External breakpoint · Watchpoint · BAdI · Enhancement framework · Debugger scripting (sandbox only)

Your understanding check

Question: An HTTP test returns business data but your ABAP breakpoint is never hit. Which check comes first?

A. Confirm the executing backend user, target system/client and breakpoint scope.
B. Add an infinite loop to production code.
C. Turn off authorization checks.

Correct: A. Correct execution context and breakpoint scope usually precede code changes.

Safety boundary: Only enable debugging for an authorized identity and client. Avoid global breakpoints, uncontrolled debugger scripting, production data export and security bypasses.

Synthetic support case: A breakpoint is skipped or a variable is overwritten in another program.

In the exercise, the developer set an external breakpoint for TEST_DIALOG_USER while the service was executed as TEST_HTTP_USER. The request path was correct; only the debugger attachment context was wrong.

• An external breakpoint in one user is not guaranteed to intercept a background technical user.
• An active enhancement implementation may be filtered out by business context.
• A watchpoint that fires after a write shows where to investigate; it does not prove that value was invalid for the business rule.

Use approved user-scoped external debugging in DEV, confirm actual target backend and execution identity, then remove test breakpoints and record the call path.

• Positive test: Eligible test request reaches the intended implementation and stops exactly where expected.
• Negative test: An invalid business request is rejected by its normal validation and does not access unauthorized code.
• Cross-process regression: The service behaves identically after debugging and no live data was changed through variable editing.

Only enable debugging for an authorized identity and client. Avoid global breakpoints, uncontrolled debugger scripting, production data export and security bypasses.

Expect questions on breakpoint types: session vs external (user) breakpoints for RFC, HTTP or background processing, breakpoints at statements, methods, messages and exceptions, and how to debug background jobs and update tasks.