ABAP Debugging in SAP: Breakpoints, F5-F8 and Watchpoints

Ashwini Mali · 31 January 2025 · 3 min read

Start the ABAP debugger with /h, step with F5 to F8, read internal tables and stop exactly where an error message comes from, in SAP GUI and in ADT.

The ABAP debugger shows what a program really does: which lines run, what each variable holds and where an error starts. Whether you support a live system or build new RICEF objects, it is the first tool to open when a program behaves differently from its specification.

Start the debugger

• /h : type it in the command field and press Enter. The next action on the screen (Enter, Execute, Save) opens the debugger.

• Session breakpoint : in SE38 or SE80 , put the cursor on a line, click the breakpoint (stop sign) button and run the program.

• /hs : system debugging, for when you also need to step into SAP system programs.

• BREAK-POINT : a breakpoint written into the code. Never transport it; use a checkpoint group instead (see below).

Step with F5 to F8

• F5 Single Step: runs the next line and enters any subroutine, function module or method it calls.

• F6 Execute: runs a call as one step without entering it.

• F7 Return: finishes the current routine and stops in the caller.

• F8 Continue: runs to the next breakpoint, or to the end of the program, where the debugger closes and the output appears.

While debugging, double-click in the column to the left of a line to set a breakpoint there; double-click it again to remove it.

Read variables and internal tables

• Double-click a variable in the source to add it to the Variables list, or type its name into the list and press Enter.

• An internal table such as IT_EKPO shows only its type and size in that list. Double-click it to open the table view, with one column per field.

• To test another branch, change a value with the pencil icon. This needs debug-change authorization, which users normally do not have in production.

Stop exactly where it matters

• Breakpoint at statement : stop at every MESSAGE , SELECT or CALL FUNCTION . A breakpoint on MESSAGE is the quickest way to find the line that raises an error message.

• Watchpoint : stops when a variable changes; add a condition such as lv_menge = 0 to stop only at that value.

• Checkpoint group : write BREAK-POINT ID zsd_pricing. and switch the group on for your own user in SAAB . It stays inactive for everyone else, so the code can be transported safely.

For a slow program, stepping is the wrong tool. Measure it with SAT (ABAP runtime analysis) and ST05 (SQL trace) instead.

Debugging in ADT and from Fiori apps

In ABAP Development Tools for Eclipse, double-click the ruler beside a line, or press Ctrl+Shift+B , to set a breakpoint. The keys stay the same: F5 into, F6 over, F7 return, F8 resume. ADT breakpoints apply to your user, so they also stop requests that come from a Fiori app or an OData service, not only SAP GUI sessions. In SAP GUI, an external (user) breakpoint does the same job.

Key takeaways

• /h switches on debugging for the next action; F5, F6, F7 and F8 step into, over, out and on.

• Double-click an internal table to read it as rows and fields.

• A breakpoint at statement MESSAGE quickly finds the source of an error message.

• Use checkpoint groups ( SAAB ) instead of hard-coded BREAK-POINT in transported code.

• Debug Fiori and OData calls with ADT or external breakpoints; trace performance with SAT and ST05 .

Want to practise debugging on real RICEF objects with a trainer? See our SAP ABAP Development course .