SAP Debugging

You start the debugger by setting a breakpoint (in the editor, or /h in the command field before running a transaction). It then lets you step through the code line by line, watch variables and internal tables, inspect the call stack, and even change values on the fly to test scenarios.

Where it lives, in the three ways people reach it. Typing /h in the command field arms the debugger so the next screen action stops in it, which is how you debug a transaction you did not write. Setting a breakpoint in the editor stops execution at that line. And a runtime error leads to the debugger from the dump, which lets you re-enter the failure rather than read about it.

The distinction that matters most is between a session breakpoint and an external breakpoint. A session breakpoint applies to your own dialog session. An external breakpoint is registered for a user and fires when work arrives from outside the dialog: a web request, an OData call, an RFC. Debugging a Fiori application with a session breakpoint and concluding the code is never reached is a rite of passage, and the fix is one setting.

• Breakpoints: line, and powerful conditional/statement/exception breakpoints (e.g. break when a specific message is issued or an exception is raised).
• Watchpoints: break when a variable’s value changes.
• Step / step over / return: control execution granularity.
• Layers: debug across RFC and background steps.

Four controls do almost everything, and knowing which to press is most of the skill.

Step into enters the subroutine on the current line. Useful when you suspect that subroutine. Step over executes it and stops after, which is what you want most of the time. Return finishes the current routine and stops in its caller, which is how you climb out of somewhere you did not mean to enter. And continue runs to the next breakpoint.

The habit that separates fast debugging from slow is stepping over by default and only stepping into something you have a reason to suspect. Stepping into everything means walking through framework code for twenty minutes to reach a line you could have breakpointed directly.

Beyond stepping, two facilities are worth learning early. Watchpoints stop execution when a variable changes, which answers the question of who set this field far faster than reading code can. And the call stack shows how you arrived, which is often more informative than where you are.

The single most useful debugging exercise, and it takes half an hour.

1. Pick any transaction where a field ends up with a value nobody expects. A default that keeps appearing will do.
2. Type /h and press enter on the screen before the value appears.
3. When the debugger opens, find the field's variable in the structure being processed.
4. Set a watchpoint on it rather than a breakpoint. Then continue.
5. Execution stops the moment something writes to it. Read the call stack: that is who did it, and the line above tells you why.
6. If it was a user exit or a BAdI, you have just found the customisation that nobody documented.

Step five is why watchpoints are worth learning before anything else. The alternative is reading the program looking for assignments, which in standard SAP means reading code that spans dozens of includes. See methods.

A key skill is knowing where to break. Techniques include setting a breakpoint on a message (to catch where an error is raised), on an exception class, or on a statement like a specific function call. This gets you to the problem without stepping through thousands of lines.

When you have no idea where to start, three techniques narrow it down quickly.

Break on the message. If the symptom is an error message, note its message class and number and set a breakpoint on the statement that issues messages. Execution stops where the message is raised, which is where the logic decided something was wrong.

Break on the database read. If the symptom is wrong data, breakpoint the SELECT on the table concerned. You land where the value was fetched.

Break on the change document or the update. If the symptom is something being saved that should not be, breakpoint the update rather than hunting through the input.

All three work because they start from the symptom rather than from the beginning of the program, which is the difference between half an hour and an afternoon. See loops and internal tables for what you will be looking at when you get there.

One more that saves an enormous amount of time in standard SAP: find the enhancement point rather than the logic. If the question is why does this system behave differently from the one next door, the answer is usually a customer exit, a BAdI implementation or a substitution, not a difference in standard code. Breakpointing the framework call that invokes enhancements lands you in whatever your predecessors added, which is where the difference lives.

The debugger can change data, so use it carefully, especially in production (where debug/change authorization is tightly controlled). Non-production is the place to experiment. Reading dumps (ST22) often complements debugging by showing exactly where and why code failed.

Being blunt about the risk: the debugger can change values and skip statements, and in a system with the relevant authorisation that includes production. Changing a field in the debugger to get past a check posts data the checks would have refused, and it leaves no trace that says so. There are legitimate uses, under supervision, in an emergency, with somebody watching. There is no legitimate casual use.

The authorisation to change values in the debugger should be separate from the authorisation to debug at all, and in a well run landscape it is not held in production by developers. If you find you have it, that is worth mentioning rather than using.

Two practical courtesies as well. A breakpoint left in a shared system stops other people's work. And debugging a background job holds a work process for as long as you sit there, so on a busy system, do it in the quiet hours or on a copy. See ABAP and OData for the case where the caller has a timeout and will give up while you are still reading.

• Stepping blindly instead of breaking on the message/exception.
• Changing values in production, tightly controlled for good reason.
• Ignoring ST22 dumps that pinpoint failures.

• Session breakpoints for external calls. The code runs and never stops.
• Stepping into everything. Step over by default.
• Reading code to find an assignment. Use a watchpoint.
• Changing values to get past a check. It works, and it posts data the system was protecting itself from.

Version note: newer releases run the redesigned debugger by default, which is a separate session with a configurable layout and better tools for internal tables and objects. The older screen still exists and is occasionally forced by circumstances. The techniques above apply to both; only the arrangement of the screen differs.

Stepping through code is an afternoon, and knowing where to break so you arrive in three minutes rather than three hours is the judgement the course builds.