Classic and new ABAP Debugger — 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.

Classic and new ABAP Debugger — Concepts and mental models

Outcome: Set the correct breakpoint, step across calls and inspect the actual changing variable.

SAP environment: Classic SAP GUI debugger and New ABAP Debugger; availability/options depend on installed SAP_BASIS release.

Mental models

1. Understand the boundary

The debugger executes the real application one statement at a time. Before opening it, find the transaction event, program, screen flow or enhancement that owns the value. The command /h activates debugging for a subsequent dialog action; it is not a universal way to debug a browser-triggered HTTP request.

2. How this investigation works

Use F5 Step Into for method bodies, F6 Step Over for executing a method as a unit, F7 Step Return to leave the current routine, and F8 Continue to the next breakpoint. Read the highlighted next statement carefully: it has usually not executed yet. Compare variable values before and after a step.

3. Evidence-based decision making

Variables, internal tables, reference variables and the call stack answer different questions. A table view explains contents; a call stack explains how this point was reached; watchpoints explain when a value changed. Editing a variable during debugging is a test technique, not a permanent fix.

Three common false diagnoses

• Debugger launch is not equivalent to proving the program is correct.
• Step Into may enter framework or generated code; Step Over is often more useful to keep context.
• Field-symbol assignment refers to underlying storage; changing a referenced row can change the original table.

Worked synthetic evidence

DATA(lv_amount) = CONV decfloat34( '1250.00' ).CALL METHOD zcl_discount_demo=>apply  CHANGING cv_amount = lv_amount." Observed after call: LV_AMOUNT = 0.00" Expected for customer group B: LV_AMOUNT = 1187.50 

Diagnostic sequence

1. Locate the executing program and dynpro/event
2. Step into/out/over; read variable and call stack
3. Compare before/after with a safe test case

What to inspect

/h · SE38 · SE80 · Debugger · Call stack

Your understanding check

Question: After F5 the highlighted statement is CLEAR lv_amount. What is the safest next step?

A. Change LV_AMOUNT in production to the expected price.
B. Inspect branch inputs, then execute one statement and compare the value.
C. Resume with F8 and claim that CLEAR caused the problem without checking.

Correct: B. Evidence must connect statement execution and branch inputs before a correction.

Safety boundary: Never skip authorization logic or alter productive financial amounts using debugger variable editing. Use synthetic inputs and approved DEV changes.

Synthetic support case: A calculation or field value changes unexpectedly in a SAP GUI transaction.

The fictional method's fallback branch clears the amount because the group lookup does not match the intended customer category. The watchpoint/call stack identifies the actual writer.

• Debugger launch is not equivalent to proving the program is correct.
• Step Into may enter framework or generated code; Step Over is often more useful to keep context.
• Field-symbol assignment refers to underlying storage; changing a referenced row can change the original table.

Correct the exact group predicate and add ABAP Unit tests for configured and missing customer groups; avoid overriding the debugger value to hide the branch.

• Positive test: Known group B applies the documented 5% discount and produces 1187.50 for test input 1250.00.
• Negative test: Unknown groups follow an explicit documented fallback without corrupting the original amount.
• Cross-process regression: Display currency formatting and the value read back from the saved document agree with the calculation.

Never skip authorization logic or alter productive financial amounts using debugger variable editing. Use synthetic inputs and approved DEV changes.

Show practical debugger fluency: starting with /h, stepping with F5/F6/F7/F8, using breakpoints and watchpoints, inspecting variables and internal tables, and — importantly — debugging safely without changing data in production.