Advanced breakpoints, enhancement points and scripts — Guided debugger and evidence walkthrough

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 — Guided debugger and evidence walkthrough

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

Before you begin: SAP GUI New ABAP Debugger and authorized DEV; user/session, RFC and HTTP breakpoint constraints are release-dependent. Use only fictional test keys and an authorized development/test tenant.

Reproduce with the sample 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 

Six-stage diagnosis

1. Identify entry channel: SAP GUI dialog, RFC, HTTP request, asynchronous update or background job.
2. Confirm real execution user in DEV system logs; note client, session, process and any principal propagation.
3. Choose a breakpoint type supported for that channel; set it in an activated executable method or enhancement implementation.
4. Run a single test request and inspect the call stack; if not reached, confirm destination, client, implementation filters and selected service alias.
5. For a changing value, set a conditional watchpoint and capture exact before/after data without modifying production records.
6. If a script is used, restrict it to synthetic data and convert observations into a reproducible ABAP Unit fixture, then deactivate breakpoints.

What should be observed

1. Wrong breakpoint user: request completes without stopping; the service is not necessarily broken.
2. Correct user but wrong application server may still need environment-specific external-debug configuration.
3. An active BAdI filter explains why one business document enters an implementation while another bypasses it.

Alternative hypotheses to rule out

• HTTP request executes as a different ABAP identity than the breakpoint owner.
• Execution occurs in a different system/client or different active enhancement implementation.
• The supposed implementation is never reached because standard validation rejects the request earlier.

Verify, not just fix

• 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.

Test your diagnosis

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.

Production-safe approach: 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.