New ABAP Debugger Tips and Tricks

149 Likes 110,412 Views 91 Comments

The New ABAP Debugger was first released by SAP with NetWeaver04. As of release
NetWeaver 7.0 it fully replaces in the scope of its functionality the “old-fashioned”
Classic ABAP Debugger. During the last SAP TechEds I learned that more and more
people use the New ABAP Debugger (that is a great news!) but still many are not aware
of some of its useful features. The purpose of this blog is to point you to these features so
that you can make the most of the New ABAP Debugger.

Some useful debugger settings

The New ABAP Debugger settings dialog lets you activate special debugging modes and
comfort options that can speed up your troubleshooting scenarios. Here you will find some
helpful debugger settings with instructions on when and how to use them. You can access
debugger settings in the debugger by using Settings->Display/Change Debugger Settings:

 System Debugging: if you have problems that involve system programs (such as a
function that can’t be accessed in the debugger), turn on this setting (or use menu
Settings->System debugging On/Off ” or the command /hs in the debugger command
field). You can declare a program as a system program by setting Status to “System
Program” in its attributes in the ABAP Editor (SE38) (check the radiobutton Attributes
and press Change button).

 Update Debugging: turn on this setting if you need to analyze asynchronous updates,
which are functions that are called as follows: CALL FUNCTION ‘…’ IN UPDATE
TASK. These functions are executed asynchronously in a special update work process
(after the next COMMIT WORK statement). The debugger can’t follow them since it
is attached to a single process. Set a breakpoint in the function that is called IN
UPDATE TASK, start debugging, turn on this setting, and the debugger will reach the
breakpoint in your update function.

 TRFC (In Background Task): Block Sending: turn on this setting if you need to
analyze transactional Remote Function Calls (TRFC), which are called as follows:
CALL FUNCTION ‘…’ IN BACKGROUND TASK. These functions are called
asynchronously, along with other TRFC functions of this logical unit of work (LUW),
after the next COMMIT WORK statement. The debugger can’t follow them since it is
attached to a single process. When you turn on this setting, these TRFC functions are
stored in the system for debugging instead of being sent. Use the TRFC Monitor
(transaction SM58) to analyze the unprocessed LUWs and select Edit->Debug LUW
to debug them.

 Close debugger After ‘Continue’ (F8) and Roll Area End: usually after you press
Continue (F8) in the debugger session, the debugger session remains available but
inactive when the program is finished. If you switch on this setting, then the debugger
will be closed automatically after pressing Continue (F8), when the roll area (internal
session) is ended.
  Always Create Exception Obj.: turn on this setting if you need to analyze exception
objects (if you catch ABAP exceptions in your program via the CATCH
CX_MY_EXCEPTION without specifying a reference variable to which the exception
object can be assigned). You can then examine the created exception objects in the
debugger via Display Exception Obj. magnifier button.

How to handover a debugger problem – Use

Debugger Variants
Imagine that you have had to reproduce and troubleshoot a problem in a rather complicated
environment. You have finally found the function module which doesn’t work properly under
certain conditions. You may need to hand over this debugging session for further analysis to
a colleague who has expert knowledge of this function module.

In order to ensure that your colleague can reproduce the problem, you must create a very
detailed description: the source lines at which to set breakpoints, the debugger settings that
must be active, and so on. This is time consuming and there is still a chance that you might
forget critical information. In such situations, use a debugger variant (menu Debugger-
>Debugger Session->Save) to store your debugger session. You can choose which parts to
store: current layout (customized desktops), debugger settings, options and breakpoints. Then
you can save the variant either in the database or in a local file and send it per email to your
colleague.

Afterwards your colleague can load the saved variant from a file or the database after starting
a debugging session (menu Debugger->Debugger Session->Load). All settings and
breakpoints will become active immediately. Of course he can choose which components of
the variant to load: layout, settings, options, breakpoints, or all of them.
How to display all loaded programs and
global variables – Use the Loaded Programs
Tool
A double-click on the variable name in the source code leads to the Variable Fast Display
Tool where you get information about variable: type, value, etc. On the Locals tab you get all
parameters (including parameter kind) and local variables of the current function module, on
the Globals tab, you can display all global variables of the current program. But sometimes
this local and global information is not enough; you maybe need to display all currently
loaded programs and their global variables as well. For this purpose, use the Loaded
Programs Tool (button New Tool, Special Tools->Loaded Programs).

Loaded Programs shows you two tabs. On the Loaded Programs tab you see the attributes of
all loaded programs and their program groups. On the Global Data tab you get global
variables of each global program just by double-clicking the program in the navigation tree.

How to test a function module in the

debugger and pass parameters
Imagine you want to test a function module in the test framework of the Function Builder
(transaction SE37) in the debugger, and you need to pass as a parameter a big internal table
with many entries. It would be very time consuming to enter the input data for such a table
manually in SE37. But you don’t have to do this. If you access the function module from the
debugger, then you can download its parameters to the SE37 test framework. Select the
parameter and use the right mouse button context menu Save Parameters as Test Data
(SE37). Please consider that this download is restricted to the data types which are allowed in
the SE37 test framework: you cannot download objects, nested internal tables or data
references. After that just open the function module in a separate SE37 window and run it in
the test framework. You can access your downloaded data in SE37 via Test Data Directory
button.

Helpful hints for analyzing variables

 Use the Data Explorer to view deep nested objects With the Objects Tool (Objects
desktop) you can examine object properties including visibility, inheritance, references
to the object (where-used list ). You can double-click on attributes in order to navigate
to the subcomponents of a class. But if you have to analyze deep nested objects, then
the Data Explorer Tool is the better choice. The Data Explorer lets you drill down
into nested objects, structures, and references without losing context of the upper
levels.
 Use Text Translation to display large hex strings and the XML Browser to display
XML data. It is very time consuming to analyze the content of a variable that contains
2000 bytes of hex code. Therefore, the detail view (Detail Display desktop) for simple
types and strings allows you to translate hex strings into readable text using the
appropriate code page (field View , choose Text Translation). For binary XML data,
there is the XML viewer (field View , choose XML Browser).
How to debug a program which is running
in an endless loop
Imagine your program is running in an endless loop and you need to analyze its behavior. In
such situations you can force the running program into the debugger simply by setting a
session breakpoint in a second ABAP Editor. In Utilities->Settings…->Debugging just
choose the Session breakpoint active immed. option. When you activate this option, all
(running and waiting) sessions of your logon session immediately inherit all session
breakpoints set in any of those sessions. It is recommended that you activate this option in
development environments.
How to debug a background job which is
running in an endless loop
Now imagine that you have a background job that is running and running, and you want to
analyze its behavior. Just use the Process Overview (transaction SM50), select the running
process, and choose from the transaction menu Program->Debugging.

How to debug a finished or crashed

background job
Now just imagine that your background job finishes its execution so quickly, that you don’t
have a chance to attach a debugger to it in the Process Overview (SM50), or even worse: it
crashed with a dump and you need to analyze what caused the dump. Just choose your job in
the Job Overview (transaction SM37) and type “jdbg” into the command field. The debugger
will start, and you just would need to press a couple of times Return (F7) to get out of the
spool functions checks and you can debug your finished or crashed background job online in
dialog.

How to compare ABAP variables – Use the

Diff Tool
Just imagine you are in the debugger and need to compare two strings which are 2000 bytes
long, or you need to compare two nested objects to look for differences in deeply nested
attributes. With the Diff Tool (Diff Desktop) you can compare two compatible ABAP
variables, e.g. two tables, objects, structures or strings. The Diff tool provides differences
concerning type and value. If you double click on a hit in the diff result list, the variables are
displayed in parallel, and the debugger navigates to the difference.

In order to assure good performance of the diff tool, even for deeply nested variables no “deep
diff” is executed.

This means that if you have for example an internal table as the attribute of an object, then
you can at first only check if the tables of both objects are equal. You will not get details
about where they differ. To get the details of differences, you can run a diff for the unequal
subcomponents (Diff button in the corresponding result line). You can use the History tab to
get back to the first result list.