How to debug ABAP programs¶

Breakpoints, watchpoints, logpoints, and the ABAP Debugger — a practical guide.

Introduction¶

The ABAP Debugger lets you pause execution, inspect variables, step through logic line by line, and change values at runtime. Knowing how to use it efficiently is the single highest-leverage skill for any ABAP developer — it turns hours of guesswork into minutes of focused investigation.

This page covers everything from opening the debugger to advanced techniques like background job debugging and watchpoints.

Opening the debugger¶

There are three common ways to enter the debugger:

1. /h in the command field Type /h in the SAP GUI command field and press Enter before executing the transaction. The next program event (screen PAI, report START-OF-SELECTION, etc.) will open the debugger. This works for any transaction without modifying code.

2. BREAK-POINT statement in code Insert BREAK-POINT. anywhere in source code. Execution stops there when the statement is reached, regardless of who runs it. Remove before transporting to production.

BREAK-POINT.   " stops here for ALL users — remove before transport!

3. BREAK username — static user-specific breakpoint Like BREAK-POINT but only triggers for the named user. Safer for shared systems.

BREAK jsmith.  " stops only when user JSMITH runs the program

4. Click the breakpoint icon in SE38 / Eclipse ADT Open the program in SE38, click the grey bar to the left of a source line, and a red dot appears. This sets a session breakpoint (see below) without changing the code.

Use /h before a transaction entry point

Type /h then call the transaction (e.g. MM60). The debugger opens at the very first statement of the transaction, before any screen or initialization logic runs. Faster than adding a BREAK statement when you don't know where to look yet.

Breakpoint types¶

Understanding the difference between session and external breakpoints saves a lot of confusion on shared systems.

Type	Scope	Survives logout?	Where to set
Session breakpoint	Your user, your session only	No	SE38 breakpoint icon, `/h`, `BREAK-POINT`
External breakpoint	Your user, any session/mode	Yes (until deleted)	Transaction SAAB
Static breakpoint	Hardcoded in source (`BREAK user`)	Yes (until code changes)	Source editor

External breakpoints for background jobs

Session breakpoints are invisible to background work processes. Use SAAB to set an external breakpoint on the program name and your username — when the job runs and hits that line, the debugger opens in your SAP GUI session.

Debugger panels¶

The modern ABAP Debugger (opened via SAAB or in newer systems) has several dockable panels:

Source — shows the current program source with the execution pointer (yellow arrow). Double-click any variable to inspect it inline.

Variables (Desktop 1 / 2) — displays up to four variables or field symbols simultaneously with their current values. You can pin frequently-watched variables here.

Table — when an internal table is selected, shows it as an editable grid with all rows and columns. You can add/delete rows and change values.

Call Stack — lists all active programs and include names from the current stack frame down to the lowest subroutine. Click any frame to jump to it and inspect its local variables.

Watchpoints — lists active watchpoints and shows which one triggered the last stop (see below).

Breakpoints — list and manage all currently active session and external breakpoints.

Inspecting variables¶

Double-click any variable name in the source view to inspect it.
For structures, the inspector shows each component on its own row.
For internal tables, the grid view lets you scroll through all rows and sort by column.
Use the Call Stack panel to navigate up one frame and inspect the caller's local variables — essential when a wrong value arrives from a calling method.

Use the 'Display as' dropdown for hex and packed values

Right-click an inspected variable and choose Display as to see packed numbers, dates, or raw hex values rendered in different formats. Useful when a date field looks wrong — check whether the raw value is YYYYMMDD as expected.

Watchpoints¶

A watchpoint stops execution the moment a specific variable changes value. This is far more efficient than stepping through hundreds of loop iterations trying to find where an unexpected overwrite happens.

Creating a watchpoint:

Right-click the variable name in the source or variables panel.
Choose Create Watchpoint.
Optionally set a condition (e.g. stop only when the value becomes 'X').

The debugger will stop execution at the exact statement that modifies the variable — even inside called function modules or methods.

Watchpoints work across call stack frames

You can set a watchpoint on a global variable or a class attribute and it will fire no matter which method or function module changes it. This makes watchpoints ideal for hunting race conditions and unexpected field resets.

Logpoints¶

Logpoints are non-stopping breakpoints that write the current value of one or more variables to a log, without pausing execution. They are set in SAAB.

When to use them: - Near-production systems where stopping execution is disruptive. - Performance-sensitive code paths where stopping would mask timing issues. - Long-running loops where you want a history of value changes rather than stepping through each iteration.

How to use: 1. Open SAAB, create a new breakpoint of type Logpoint. 2. Specify the program, line, and the variable expressions to log. 3. Run the program normally — values are written to the logpoint log in SAAB.

Logpoints are visible to all your active sessions

Unlike session breakpoints, logpoint output accumulates in SAAB and persists across multiple program runs. Delete or deactivate them when done to avoid filling the log table.

Step controls¶

Key	Action
F5	Step Into — enter the called function module or method
F6	Step Over — execute the call without entering it
F7	Step Out — run to the end of the current subroutine and return to the caller
F8	Continue — run until the next breakpoint or watchpoint

F8 with a temporary breakpoint is faster than F6/F5 grinding

Click the grey bar next to a line further down in the source to set a temporary session breakpoint, then press F8. The debugger jumps straight there — no need to step line by line through code you don't care about.

Changing values at runtime¶

Right-click any variable in the variables panel or source view and choose Change Value. Type the new value and confirm. The change takes effect immediately for the current execution.

Changing values at runtime can corrupt program state

Changing a variable that is part of a SELECT or a BAPI call already in progress can lead to unpredictable results. Use this feature for testing only, and never on a production system. The change does not persist — it only lasts for the current program execution.

Background job debugging¶

Background jobs run in work processes that have no SAP GUI session attached, so session breakpoints have no effect.

Procedure:

Open SAAB and create an External Breakpoint for your program and your username.
Schedule or re-run the background job.
When the job hits the breakpoint line, SAP pauses the work process and opens the ABAP Debugger in your SAP GUI session.
Step through the code, inspect variables, then press F8 to let the job continue.

The background job is suspended while you debug

The work process is blocked — the job will not time out immediately, but holding it for too long may trigger a work process timeout in the system. Investigate quickly, then continue (F8) or terminate the job from SM37.

Tips and tricks¶

SAAB is more powerful than the classic debugger

The new ABAP Debugger (accessible via SAAB, or automatically in newer kernel versions) supports watchpoints, logpoints, multi-session debugging, and a much better table display. Always prefer it over the classic debugger invoked by /h on older systems.

Use the 'Go to statement' shortcut to skip lines

Right-click a line in the source view and choose Execute to Here (or the equivalent in your kernel version). This skips all lines in between without executing them — useful for bypassing large initialization blocks you already know work correctly.

Conditional breakpoints reduce noise in loops

When debugging inside a LOOP with thousands of iterations, set a condition on the breakpoint (e.g. ls_item-status = 'E'). The debugger only stops when the condition is true, saving you from pressing F8 thousands of times.