ABAP Developmentintermediate

Debugging Part 4: Watchpoints, Layers and Static Checks (ATC)

Key takeaway

Find where a value changes with watchpoints (variable change, conditions, objects), combine them with breakpoints and the call stack, use layer-aware debugging for standard + custom code, and prevent bugs earlier with the extended program check (SLIN), Code Inspector (SCI) and ATC.

Explanation

📌 KEY POINTS
✅ A watchpoint stops the debugger when a variable changes (optionally only when a condition is true) — ideal for "who overwrites this field?".
✅ Combine watchpoints with the call stack to find the program and routine responsible for the change.
✅ Layer-aware debugging (debugger profile / "System debugging" off, software layers) keeps you in custom code or includes selected packages.
⚠️ Static checks (SLIN, SCI, ATC) find many bugs before runtime — dumps from uninitialized FOR ALL ENTRIES tables, missing sy-subrc checks, performance issues.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 stepped through code. Some bugs are value changes somewhere in thousands of lines — watchpoints find them.

━━━━━━━━━━━━━━━━━━━━
▶ 1. WATCHPOINTS

Create: Breakpoints tab → Watchpoint (or right-click variable → Create watchpoint).
Variable: e.g. XVBAP-ROUTE, LS_ITEM-NETWR, an object attribute.
Condition: e.g. LS_ITEM-NETWR < 0 or VBAK-AUART = 'ZOR'.
Scope: local vs global variable; for globals of another program use (PROGRAM)VARIABLE syntax.
Continue with F8 — the debugger stops after the statement that changed the value.

━━━━━━━━━━━━━━━━━━━━
▶ 2. CALL STACK
Double-click entries to see the caller context and its variables — shows which user exit, BAdI or form changed the value.

━━━━━━━━━━━━━━━━━━━━
▶ 3. LAYER-AWARE DEBUGGING

Configure object sets (packages, programs) so the debugger stops only in your layer (e.g. Z packages or specific component).
System programs are skipped unless "System debugging" (/hs) is on.

━━━━━━━━━━━━━━━━━━━━
▶ 4. STATIC CHECKS

SLIN (extended program check): syntax-level warnings (unused variables, missing sy-subrc checks, wrong message usage).
SCI / Code Inspector: configurable checks (performance, security, robustness).
ATC: central check tool with check variants, exemptions, CI integration; often mandatory before transport.

━━━━━━━━━━━━━━━━━━━━
▶ 5. WHEN TO USE WHAT

"Where is the value changed?" → watchpoint.
"Where is this message raised?" → breakpoint at message.
"Why does it dump?" → ST22 (Part 6).
"Is this code risky?" → ATC before transport.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Set a watchpoint on a variable in the practice report with a condition.
Use the call stack at the stop to identify the changing routine.
Run ATC on your package and fix the top 3 findings.

✅ CHECKPOINT: you can locate value changes quickly and use static checks to prevent bugs.

Code example

ABAP Code

* ===== Practice: who changes the route? =====REPORT zdebug_watchpoint. DATA: gv_route TYPE route VALUE 'R00001'. START-OF-SELECTION.  PERFORM step_a.  PERFORM step_b.                     " the culprit  PERFORM step_c.  WRITE: / 'Final route:', gv_route. FORM step_a.  DATA lv_dummy TYPE i.  lv_dummy = 1.ENDFORM. FORM step_b.  gv_route = space.                   " watchpoint on GV_ROUTE stops right after thisENDFORM. FORM step_c.  IF gv_route IS INITIAL.    WRITE: / 'Route missing'.  ENDIF.ENDFORM. * ===== Watchpoint settings =====* Variable : GV_ROUTE           (global of this program)* Other program's global: (SAPMV45A)XVBAP-ROUTE   (syntax in the watchpoint dialog)* Condition: GV_ROUTE = SPACE    -> stops only when cleared * ===== Static checks before transport =====* SLIN  : extended program check (Program -> Check -> Extended Program Check)* SCI   : Code Inspector with a check variant* ATC   : ATC check on package/transport; fix or request exemption

Real project scenario

Delivery routes were randomly cleared in sales orders. Stepping through the save took hours with no result. A watchpoint on XVBAP-ROUTE with condition "initial" stopped after a line in a 10-year-old user exit that cleared the route for a special order type — the condition had been extended by mistake.
Fixing the condition took five minutes. ATC later flagged similar suspicious code in the same exit.

Common mistakes

Stepping manually instead of using watchpoints.
Watchpoints without condition on frequently changed variables.
Ignoring the call stack at the stop.
Skipping ATC before transport.
Debugging system code unnecessarily.

Best practices

Watchpoint + condition for "who changes X".
Call stack to identify the culprit.
Layer-aware debugging for custom code.
ATC mandatory before transport.
Fix findings, not only exempt them.

Interview angle

Questions: "What is a watchpoint?", "How do you find where a field value gets overwritten?", "What is ATC?"
Strong answer: watchpoint stops when a variable changes (optionally with condition), use (PROGRAM)VAR for other programs, then call stack to find the routine; layer-aware debugging; static checks SLIN, SCI and ATC with check variants before transport.

Practice this lesson

Quick check

1. Which tool finds the statement that clears a field somewhere in a long save process?

2. You need to analyze why a screen field is not being populated correctly during the PBO/PAI processing of a dynpro. Which debugger view should you use to inspect the screen flow logic directly?

3. By default, in what scope does a watchpoint monitor the field or variable you specified?

Interview questions

1. What is a watchpoint in the ABAP debugger and how is it different from a normal breakpoint?

Answer it in your own words first, then compare.

2. A newly onboarded developer keeps introducing production defects that could have been caught through better debugging discipline before transport. As an architect or technical lead, how would you mentor the team and design a review process to reduce this without slowing down delivery significantly?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.