ABAP Developmentbeginner

Debugging Part 2: ABAP Debugger Essentials

Key takeaway

Use the ABAP debugger efficiently: starting it (/h, breakpoints in SE38/SE80/ADT), session vs external breakpoints, stepping (F5, F6, F7, F8), breakpoints at statements/messages/exceptions, changing variables, jumping, call stack, and the desktops and tools of the new debugger.

Explanation

📌 KEY POINTS
✅ Start: /h in the command field, breakpoints set in the editor (SE38/SE80/ADT), or BREAK-POINT in code (test only).
✅ Stepping: F5 single step (into), F6 execute (over), F7 return (out), F8 continue to next breakpoint.
✅ Breakpoints at statement (e.g. MESSAGE, SELECT, CALL FUNCTION), at a message ID/number, or at an exception class find the right spot without stepping.
⚠️ Changing variable values in the debugger is fine in test systems but dangerous in production — it can create inconsistent data.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 defined the approach. Now the main tool.

━━━━━━━━━━━━━━━━━━━━
▶ 1. STARTING

/h then execute → debugger starts at the next dialog step.
Session breakpoint (editor, Ctrl+Shift+F12 / stop sign): valid for your current logon session.
External (user) breakpoint: valid for your user in all sessions, including RFC/HTTP calls (Part 3).
BREAK-POINT statement / BREAK <user>: only in test code; use checkpoint groups (BREAK-POINT ID) otherwise.

━━━━━━━━━━━━━━━━━━━━
▶ 2. STEPPING

F5 into routines, F6 over them, F7 back to caller, F8 to next breakpoint.
"Go to statement" (Shift+F12 on a line / "Goto statement") jumps without executing — use carefully.

━━━━━━━━━━━━━━━━━━━━
▶ 3. DYNAMIC BREAKPOINTS

Breakpoints → Breakpoint at → Statement: e.g. MESSAGE, COMMIT WORK, CALL FUNCTION, SELECT.
Breakpoint at message: stops when message ID/number is issued — very effective for "where does this error come from?".
Breakpoint at exception class: stops at RAISE or when a class-based exception is created.
Breakpoint at method/function module/form.

━━━━━━━━━━━━━━━━━━━━
▶ 4. INSPECTING DATA

Variables desktop: values, change (pencil icon), structures, tables (Part 5).
Call stack: which program/routine called the current one — navigate up by double-click.
Objects: attributes of class instances.

━━━━━━━━━━━━━━━━━━━━
▶ 5. DESKTOPS AND TOOLS
Standard, Structures, Tables, Objects, Break/Watchpoints, Diff tool (compare two variables/tables), Memory analysis, System areas (SY fields).

━━━━━━━━━━━━━━━━━━━━
▶ 6. SAVING
Save breakpoints/layout; Debugger → "Save Debugger Session" in newer releases.

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

Run any report with /h and step with F5/F6/F7/F8.
Set a breakpoint at statement MESSAGE and trigger an error message.
Use the call stack to find the routine that decided to raise it.

✅ CHECKPOINT: you can start the debugger, step efficiently and use dynamic breakpoints.

Code example

ABAP Code

* ===== Practice report for the debugger =====REPORT zdebug_practice. TYPES: BEGIN OF ty_order,         vbeln TYPE vbeln_va,         netwr TYPE netwr,       END OF ty_order. DATA: lt_orders TYPE STANDARD TABLE OF ty_order,      ls_order  TYPE ty_order,      lv_total  TYPE netwr. START-OF-SELECTION.  ls_order-vbeln = '0000000001'. ls_order-netwr = 100. APPEND ls_order TO lt_orders.  ls_order-vbeln = '0000000002'. ls_order-netwr = -50. APPEND ls_order TO lt_orders.  ls_order-vbeln = '0000000003'. ls_order-netwr = 300. APPEND ls_order TO lt_orders.   PERFORM calc_total USING lt_orders CHANGING lv_total.   " F5 steps into, F6 over  WRITE: / 'Total:', lv_total. FORM calc_total USING    it_orders TYPE STANDARD TABLE                CHANGING cv_total  TYPE netwr.  DATA ls_ord TYPE ty_order.  LOOP AT it_orders INTO ls_ord.    IF ls_ord-netwr < 0.      MESSAGE 'Negative value found' TYPE 'I'.   " try: breakpoint at statement MESSAGE    ENDIF.    cv_total = cv_total + ls_ord-netwr.  ENDLOOP.ENDFORM. * ===== Useful debugger actions =====* /h                    start debugging at the next dialog step* F5 / F6 / F7 / F8     into / over / return / continue* Breakpoints -> Breakpoint at -> Statement: MESSAGE | COMMIT WORK | SELECT* Breakpoints -> Breakpoint at -> Message: ID V1, number 382* Call stack            double-click an entry to see the caller* BREAK-POINT ID zdbg.  checkpoint group, activate in SAAB (never plain BREAK-POINT in production code)

Real project scenario

A new developer tried to find where "Material is blocked" came from in a delivery by stepping through thousands of lines with F5. After three hours, a senior developer set "Breakpoint at message" for the message ID/number and reached the check in seconds, with the call stack showing the calling user exit.
The team added dynamic breakpoints to their onboarding training.

Common mistakes

Stepping with F5 through everything.
Leaving BREAK-POINT statements in code.
Changing values in production debugging.
Ignoring the call stack.
Using session breakpoints for RFC/HTTP calls.

Best practices

Use statement/message/exception breakpoints.
F6/F7 to skip irrelevant code.
Checkpoint groups instead of BREAK-POINT.
Inspect the call stack.
Change values only in test systems.

Interview angle

Questions: "Explain F5/F6/F7/F8.", "How do you find where an error message is raised?", "Session vs external breakpoints?"
Strong answer: /h or editor breakpoints; F5 into, F6 over, F7 return, F8 continue; breakpoint at statement/message/exception/method; call stack; variable inspection/change (test only); session breakpoints for own session, external for RFC/HTTP; checkpoint groups instead of hard breakpoints.

Practice this lesson

Quick check

1. You stopped in a routine that isn't relevant. Which key leaves it and returns to the caller?

2. Transaction code to enter the ABAP debugger while a program runs is:

3. What is the primary purpose of an exception breakpoint in the ABAP Debugger?

Interview questions

1. A month-end report shows a wrong total, and you have a few minutes with the debugger. Which debugger features do you use to get to the cause fast?

Answer it in your own words first, then compare.

2. What is system debugging in SAP, and when would you need to use it instead of normal application debugging?

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.