SAP ABAP Debugging

Overview

The debugger is a programming tool that you can use to execute ABAP programs, by line or by section. With
this tool, you can display data objects and check the flow logic of programs.

Note: Take care in Production environments because:

- Work process are locked up
- Data changes may occur
- Program termination can lead to corrupted data

Debugging Types
Two types of debugging are currently possible:
- debugging with CLASIC debugger for release levels up to and including 6.40
- debugging with NEW debugger which is available for all release after 6.40.

The main differences between the classic and the new ABAP debuggers are described below:

The CLASSIC Debugger

- It’s a “one process” debugger. It’s displayed in the same window (internal session) as the
application. This technology has also some restrictions. For example, some abap programs cannot
be analyzed in debug mode for technical reasons.
- Obs. The most significant restriction is that no ABAP technology can be used for designing the
Debugger interface

The NEW Debugger

- is executed in a separate external session (debugger), while the application to be analyzed uses a
second external session. The user interface can be designed freely by abap means.
- provides the user with a flexible interface that can be configured and has more than 8 desktops.
IT’s possible to place and arrange up to 4 tools- depending on the user’s selection. The user can
design the Debugger interface.

Main components of the New ABAP Debugger user interface

  Process information area
Provides information about the status of the debugger or debugger. The information are:
o Session number: because you can debug several applications in parallel
o Debug settings/session type:
(/hs) indicates that system debugging is active
HTTP- indicates HTTP debugging
RFC->destination indicates debugging of an RFC module at the specified destination
UPDATE – indicates debugging of the asynchronous update functionality of a transaction
ATTACHED – indicates that the debugger is attached to a process (you can attach the
debugger to a running process via transaction SM50 by following the menu path Process
-> Debugging )
Exclusive/Non-Exclusive – in an exclusive debugging session, the work process is
exclusively locked for your currently running debugging session; in a non-exclusive
debugging session, the work process is non locked, and any debugger action may involve
an implicit database commit durring roll-in/roll-out of the debuggee context.
 Control area

 Source code information area

Displays the full information about the current source position. The displayed information depends
on the current code type:
o in ABAP code, you see “main program”, “include” and “source line” information
o in screen flow code, you see “main program”, “screen number” and “source line”
information
 Desktops and tools
Are your work areas and all available tools (source code, variable fast display) can be arranged on
the desktops.
There are 3 user-specific desktops and 7 standard desktops: Standard, Structures, Tables, Objects,
etc. )

OBS: You can save the current debugger settings and breakpoints in a debugger variant. And after that you
can load the saved variant after starting a debugging session and all settings and breakpoints will be active
at once.
You can specify which parts (layout, breakpoint, settings and options) to store in variant.
You can save the variant as a local file, which you can then email to a colleague, or in a location on the
database, in which case your collegue simply uses the Load debugger variant dialog to load your variant
from the database.
Start New Debugger - >menu path Debugger-> Debugger Session -> Load
Note: in the Classic ABAP Debugger, starting with SAP Web Application Server 6.20, this functionality is
available using menu path Debugging->Sessions

OBS.
1. Not all ABAP code can be debugged:
For example it’s not possible to debug conversion exits and field exits with the Classic Abap Debugger.
During conversion exits, all dialog operations are forbidden (call dialog and call screen); therefore
making it also impossible to send a debugger screen. And another thing: every functionally that is
running for the debugger can potentially affect the debugger’s context. To avoid this risk, the Classic
Debugger does not use Abap for own functionally.
So/..you can use the New Debugger.

2. As a release 6.40, you can select the debugging type as you wish by choosing the classic or the
new debugger in the ABAP Editor : Utilities->Settings.(in user-specific settings)
 3. or You can switch the type of debugger at any time during a session (under the menu option
Debugging)
4. As of Release 7.00, the New Debugger is the default.

Ways of starting the debugger

Setting breakpoints

There are 2 ways:

 By setting breakpoints then running the program
 Hard coded: if the program is editable, you can hard code the breakpoint into your ABAP
code using the BREAK-POINT statement. You can also use BREAK followed by a valid
SAP user name i.e. BREAK TESTUSER.


 Dynamic: If the program that you want to debug is not editable / can only be presented in
display mode / has a blue back-ground, one may use this “STOP” / break-point button.
For example: We are going to set up break-points upon execution of a selection, and on the turn of calling a
SAP standard function module.

Note: One can set more than one break-points in a program.

Position your cursor on the line where you’d like to set a break-point at and click the break-point button
(shown above). For this example, the cursor was positioned at the line “START-OF-SELECTION” and the
break-point button was pressed. The same was done for the line containing the words “CALL FUNCTION
‘TRCA_COMPANYCODE_GETDETAIL’ “. Break-points are now represented as highlighted points in the
program as shown in this picture.

 By running the program in debugging mode:

- Via /h
- Setting breakpoints at key statements
- Double-clicking to set breakpoints
Note: One further thing to consider is that there are 2 type of breakpoint 'Session' and 'External'. Session is
really for basic ABAP reports and programs and external is for web application developments such BSP's
and web dynpros.

Deleting breakpoints

For “typed” break-point commands, simply erase by backspace or delete the “break-point.” command. For
highlighted break-points, just position the cursor on that line and press the break-point button again from the
toolbar, or one may even go to the utilities part in the menu bar.

1. Using breakpoints
Commonly used keys in debugging mode:
F5 – single step; commonly used for watching values or thorough step by step process
F6 – almost the same with single step but skips sub-routines
F7 – for forwarding to the next break-point or finishing a loop
F8 – run execution

This is the example that we’re going to use:

Using my own example, these are the sample input parameters to be used for the rest of the lecture:
Now, upon execution of the selection screen, SAP will forward to the debugging screen
 Okay, at this point, s_bukrs-low s_rfha-low and the rest of the field names on the lefts side have no
value yet. Once the abap debugger arrow proceeds to the next line, s_bukrs-low will have the value
of p_bukrs ( in this example is Company Code 1058 ).

Observe. (processed by single step or F5)

After pressing F5, s_bukrs-low acquires the value of p_bukrs, and the debugger cursor moves to the next
line.
From this point, pressing F7 will forward you to the next break-point.
 Now, since we’re about to process a SAP standard function module, we have a choice to skip this
part and proceed to the rest of the program (by pressing F6), or continue viewing the process of
this function module (by pressing F5).

Note: if by anytime you want to skip the debugging mode, just press F8.

Pressing F5 you’ll have a view of a SAP standard function module processing, notice the main program and
source code.

From this point, if one wishes to proceed debugging the SAP standard function module, press F5; If one
wishes to pick-up from where we left debugging the main program, simply press F7 and you’ll go to the next
line of the program after the “Call Function ..” statement.
 Note: What can we see in Abap Debugger:
- Fields: display fields
- Table: display/edit entries of internal table
 Here are the contents of the internal table t_ftr. One may manipulate the current view of the data by
choosing the fields he/she wishes to see, but this doesn’t change the actual structure of the internal
table.

The encircled portion on the bottom right expands the table upwards (if one’s having difficulty
looking at an internal table with many line items).

If one wishes to see the other fields in the table, simply press Shift+F7 to scroll to the right or
Shift+F6 to scroll to the fields on the left. Press Shift+F5 to go back to the original view.

- Breakpoints (max 30)

If one wishes to skip the debugging mode, and continue processing the program, go to:

If one doesn’t want to continue processing the program, go to: Debugging>Exit (Shift+F3).
 - Watchpoints
- Call stack – display current sequence of events
- Overview – display the structure of the program
- Settings – display the current debug settings

2.

Examples

How to test a function module in the debugger and pass parameters

- Transaction SE37
- Save data record (data input
- Test data directory
- Debug
- How to set a breakpoint on a function module during run time.
-
- 1. Execute any tcode that will run any program, e.g. ZTEST
- 2. Now execute /h tcode, to switch debugger on.

-
- 3. Now after execute the program as usual (F8), you will be entering the debugging mode. Now
choose Breakpoints > Breakpoint at > Breakpoint at function module

-
-
-
 -

-
- 4. Enter the name of the function module you want to debug, click enter to set the breakpoints.

-
-
-

How to debug a background job which is running in an endless loop

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

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
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.

How to debug HTTP requests

Use transaction SICF to activate the debugger for a specific web service and a
specific user (menu Edit->Debugging->Acivate Debugging). Please keep in mind
that your web application must run on the server where you set user breakpoints
and/or where you activate HTTP debugging via SICF. Please refer to SAP note
668256 for the details on HTTP debugging.
After activating debugging, you will stop in the system code of the http requests
in the debugger.You can set new user breakpoints or watchpoints to reach the
point of interest. Don’t forget to save them before continuing.
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 radio button
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) turn on this setting if you need to
analyze transactional Remote Function
Calls (TRFC), which are called as

Close debugger After Continue (F8) and Roll Area
End
Always Create Exception Obj.
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.
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.

Debugger Variants

 Save debug session

o Used to store a debugger session (menu Debugger->Debugger
Session->Save). 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.

 Load debug session

o Used to 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. You can choose which components of the variant to
load: layout, settings, options, breakpoints, or all of them.

Use the Loaded Programs Tool

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.
Tips & Tricks
Helpful debugger ok-codes

/h activate debugging

/hs activate system debugging

/ha skip dynpro (PAI, PBO) and directly debug ABAP code

/hx detach debugger

/hmusa create memory snapshot (can be used in the transaction

S_MEMORY_INSPECTOR for memory consumption analysis)

jdbg in SM37 restart of a finished or crashed background job for debugging

/ron start ABAP Runtime Analysis measurement (transaction SE30)

/roff stop ABAP Runtime Analysis measurement (transaction SE30)