 The Classic ABAP Debugger

 The New ABAP Debugger

The Classic ABAP Debugger, with its old user interface and its limitations to debug certain types of ABAP
program is now not in use by many new and old ABAP developers.

The New ABAP Debugger, with its state of the art and flexible user interface,
can be used to debug all types of ABAP programs. It provides many new
features which improve our efficiency of debugging, both in ABAP support and
development.

In this article, we will learn how to use these new features and discover some
tips and tricks to efficiently use ABAP debugger.

Switching between the ‘Classic Debugger’ and

‘New Debugger’
You can switch between both the debugger and make any one your default
debugger. To do this, go to ABAP Editor (SE38)→ Utilities → Settings.
Now in the user-specific settings pop up box click on ABAP Editor tab and
then click on Debugging.

Here you can select the New Debugger radio button to make it your default
debugger.

External (User) Debugging

External debugging is used when we want to analyze our program which is
called by an external user through HTTP such as Web Dynpro ABAP, Web
Dynpro JAVA, and BSP etc. To activate external debugging we have to
set external breakpoints, which can be set just like the session breakpoints by
keeping the cursor on the desired code line and clicking on the ‘External
Breakpoint’ icon.

We can also set the external user for whom the breakpoint is to be activated
by going to ABAP Editor (SE38)→ Utilities → Settings, and in the ‘user-
specific settings’ pop up box click on ABAP Editor Tab and then click on
Debugging.

Here you can specify the username.

Watchpoints

Watchpoints can be used to break the execution of a program when the

values in a variable changes.

This help us to go to the exact position where the variable changes. You can
also specify conditions in Watchpoint and the execution of the program will
break as soon as the condition is fulfilled.

To create a Watchpoint, click to the Watchpoint button in the New ABAP

Debugger.

Now, in the Create Watchpoint pop up enter the variable name for which you
want to create the Watchpoint.
Debugger Variants
With the help of Debugger Variant you can save the current debugger settings
into the database or to a local file. These settings include breakpoints, UI
customizations and other special options for debugging tools.

Next time, when you will be debugging the same application you will not have
to set breakpoints again or to do all the settings again. Also, when you are
working in a large team then you can also pass the debugging variants to
other users.

To save the ‘Debugging Variant’ go to Debugger→ Debugger Session→ Save

You can save the current debugger session either to a file or in the database.
In the Debugger Variant you can save the following components :

1. Layout
2. Breakpoints
3. Settings
4. Options

To load the saved Debugger variants go to Debugger → Debugger Session

→ Load
Debugging a modal window
Generally, we can activate debugging by typing /h in the command line, but
what if the command line is not there?

Often you will come across modal windows and other pop-up windows
command line is not present and we cannot activate debugging directly. In
such cases, you can either create a SAPGUI shortcut of type ‘System
Command’ and command ’/h’ or create a text file with below texts.

[FUNCTION]
Command=/H
Title=Debugger
Type=SystemCommand
To debug a modal window drag and drop the above created file over it.
Debugging Tricks
Many a times, due to an incorrect entry in a database table or a table without
maintenance view we are not able to create, edit or delete a database record.
In these cases we can use this debugging trick.

To do this, go to transaction code SE16.

Enter the name of your database table. Select the line which you want to
process, and press the display button. Enter /h in the command line and hit
enter button two times.
Now, the debugger window will open and you can see the source code. Click
on the variable CODE, it will have ‘SHOW’ as its value.

Here you can edit this variable and set the new value based on the operation
you want to perform.

By setting the variable ‘CODE’ with value as ‘EDIT’ you can edit records,
‘INSR’, Insert new records
‘DELE’, Delete records
And, ‘ANVO’ is for editing the record with primary keys.

After setting the variable with the required operation, hit F8. Now, you are in
EDIT mode. Press save button to save the record.
The Magic of SHIFT + F12
You can use this key combination to bypass a specific line of code such as a
normal sy-subrc check or an authorization check. To jump or bypass any
line/lines of code all you have to fo is just put your cursor on the desired line
and then press the SHIFT + F12 key.
Some limitations of New ABAP debugger Screen
Debugging
When you try to set breakpoints in screen/dialog programs, you get the
message stating that debugging is not yet supported.
To get by this and debug your screen/dialog programs just switch back to the
classical debugger.

ABAP Memory ID
In the new debugger it is not possible to view the used ABAP memory ID’s
and their content. But, in the classical debugger you can view the ABAP
memory IDs by going to Go to → System Areas → ABAP Memory

Conditional Breakpoints
Assume you are debugging some code containing a loop whereas you are interested in
debugging a certain cycle (e.g. the fifth loop cycle). Making the debugger stop in this
exact cycle is easy using conditional breakpoints.

Consider the following sample program.

REPORT zmd_cond_brkpnt_01.

DATA lv_foo TYPE i VALUE 0.

*for demonstration purposes; do not use static breakpoints in production
BREAK-POINT.

DO 50 TIMES.
ADD 1 TO lv_foo.
ENDDO.

*for demonstration purposes; do not use static breakpoints in production

BREAK-POINT.

The do loop runs 50 times whereas each loop cycle updates the variable lv_bar with the
current value of lv_foo. When we set a breakpoint inside the loop, we stop there 50
times by pressing F8.

By introducing a conditional breakpoint we can define that the debugger shall only stop
at this breakpoint in case a given condition is met.

We can define the condition using tab strip Break./Watchpoints.

Let’s say we want to stop when lv_foo gets 42 assigned.

After pressing F8 the debugger stops exactly at the respective loop cycle.

This simple example visualizes how to use conditional breakpoints. I found this feature
to be quite useful a couple of times throughout my projects.
Classification of Breakpoints
In the official documentation we can find terms such as static breakpoints, special
dynamic breakpoints, external breakpoints, debugger breakpoints. While investigating
the meaning of these terms I found that they are addressing different properties of
breakpoints, such as their life time or the way you create them.

Therefore, I was curious and have created a classification of breakpoint times according
to the following categories:

 Life Time
 Way of Creation
 Can be User-Agnostic
 Processing Mode
 Conditionally Considered
 Activated
Life Time

Breakpoints exist for a certain time, that is once their life time has passed they are gone
and cannot be used anymore. The possible life times are:

 Lives during current debugging session: Debugger Breakpoint

 Lives during all sessions of current user session: Session Breakpoint
 Lives typically for two hours: External Breakpoint

Generally all breakpoints can be deleted manually, i.e. their life time can be shortened
on purpose.

Way of Creation

There is several ways how to create a breakpoint:

 Hard-wired statement in the code (such as BREAK-POINT): Static Breakpoint

 Single line selected by hand: Dynamic Breakpoint
 Lines selected by certain definition (such as at every instance of certain
statement): Special Dynamic Breakpoint
Can be User-Agnostic

A breakpoint can be valid for a certain user name or not.

If so, the breakpoint is considered once the respective user executes the code line. This
applies to all breakpoints unlike Static Breakpoints defined with BREAK-POINT.
If not, the debugger stops at every execution regardless of the current user. This
applies to Static Breakpoints defined with BREAK-POINT.
Processing Mode
There is breakpoints that stop at dialog processing only, such as Debugger
Breakpoints.
in contrast, e.g. External Breakpoints are used to debug processing of remote calls
such as RFC or ICF processing.
Conditionally Considered
The consideration of a breakpoint may depend of a given condition expressed as logical
condition. For instance, a variable has to have a defined value and, therefore, the
debugger only stops if the condition is fulfilled. Such breakpoints are referred to
as Conditional Breakpoints.
Activated

Apart from their existence breakpoints can be active or inactive.

In case you do not need a breakpoint being considered in your debugging session, you
can deactivate it. You can turn it on again once you want to use it.

Discover changing Variables using Watchpoints

Watchpoints are quite useful whenever you are interested in the time point and the
code at which a certain variable or an object attribute changes its value. Especially in
very complex program flows with a deep call stack it may be hard to figure out value
changes manually.

In order to create a watchpoint we navigate to the tab Break./Watchpoints, choose the

tab Watchpoints and click the Create icon.

Considering the sample program about conditional breakpoints from above, we’re
interested in spotting changes of the value of variable lv_foo.

In this dialog we can choose between inspecting variables of object attributes. We can
also specify the respective ABAP program.

After creating this watchpoint and pressing F8 in our sample program, we get notified
that the watchpoint has been reached.
Debugger Scripting
Debugger Scripting is a powerful mechanism to automate processes that occur often,
are time-consuming and are conducted by hand.

Assume that you want to skip authorization checks by manipulating the sy-subrc value.

Disclaimer: Only do so if it is harmless, that is you must not abuse this feature. Tell
you admin if you are authorized to use it and you are working in a field with sensitive
data or processes.

You can open the tab Script in the debugger and there you will find a local class
implementation. Besides the methods prologue, init and end you can add you own logic
in the method script. On the left-hand side you can decide when the script shall be
triggered. For instance, et every debug step or after once a watchpoint is reached.

Debugger in SAP can be started by typing ‘/h’ in the command fields before executing
the program. Normally all the Report programs has selection screen. Most of the
program code gets executed after the selection screen is displayed, so the debugging
can safely be started after the selection screen is displayed. If it is required to debug
the portion of the code, which gets executed even before selection screen, then it is not
recommended to start the debugging by this method. This method is not suitable for
the Reports without selection screen. To debug SAP module pools also, this method
should be used, if it is required debugging the program after first screen is displayed.

After entering ‘/h’, press enter and below message will be displayed.
Execute and debugging will start. Once the debugging starts following window is
displayed.

Before going into details, it is necessary to discuss the term ‘BREAK-POINT’. Break point
is a technique to stop the execution at particular line in the code and starting the
debugging.

There are four different ways in which you can go through the source code of a program
you want to analyze:

Execution Types in Debugging Mode:

Single step (F5) Use this option to execute the program statement by
statement. This allows you to branch to other program units.
Execute (F6) Use this option to process a program line by line. All of the
statements on the current line are processed in a single step.
This allows you to process the whole program.
Return (F7) The Debugger returns to the point at which control is passed
back to the main program. Use this option to return from
other program units.
Continue (F8) Use this option to process the program up to the next
breakpoint. If there are no more breakpoints in the program,
the system exits debugging mode and executes the rest of
the program normally.
Watch-point Once can set Watch on a variable. Whenever the value of
that variable changes or reaches at pre-defined value, the
execution stops in debugging mode.

The only exception to all above 5 option is the hard or soft break point. If a hard or soft
break point is already set then program stop at that point, irrespective of the option
selected.

The current value of the variable can be retrieved by double clicking on the variable.
The value and the variable are displayed in the bottom portion of debugging window. It
is possible to change the value of variable to test a particular scenario. This is controlled
by the authorization. It is very dangerous to have this access in Production System. To
change the value of variable, type in the new value against the variable in the window
below and hit change icon displayed one per record. It is not possible to change the
value of some variables like import parameter of a function etc. To view the content of
internal table, go to tables tab on the Debug window and double click on the internal
table. It displays the content of Internal table. If one knows the name of internal
table/Variable, it can directly be written in bottom of window. On hitting enter the
values are displayed.
The structures or internal tables are displayed as strings as shown above GV_BILLING. If
one wants to see as fields, then double click on the structure name in the above window
then structure is displayed as fields as below:

The button ‘Breakpoints’ is used to see all the breakpoints (of any type) set currently.
This is useful when debugging within a loop or want to delete or deactivate a particular
break point.
Programmed Break-Points:

This technique can be used in custom developments only. No SAP standard software
can be debugged using this technique. In this method a command has to be embedded
in the program to make the execution stop at that point. These techniques should be
used if the Soft Break-Point Technique does not suffice the purpose.

There are two ways of writing the break point in the program.

1. BREAK-POINT: Use of this command will make the program execution to stop at
this point.

The above technique should not be used in Field-Exits, using this command in field exits
will

result in the short dump. This technique should be used if program is in development
stage and

no one is using.

2. BREAK <UNAME>: If the program in in testing mode and is in use also, then this
technique

can be used. In this technique the break point is effective for the user <UNAME> only.
All other users will continue to execute the program in normal fashion. It should be
noted that there are high chances that these break points are embedded in the program
even after the solution and program is transported to Production System with Break
Points. So special care should be taken to remove these break points.

Soft Break-Points:

The Soft Break Point is the best way of debugging, it should be preferred over all the
techniques. One way is to go to the portion of the code, where break points need to be
set and hit STOP Icon It sets a break point for the current User Login. The break-point
will be effective in all the sessions of that particular login. The break point will be
effective from the next execution of the program.
One can set soft break points in debugging window itself by double clicking command.
This technique is used to fasten the debugging process. If one knows particular places,
where debugger needs to stop, the break points should be set on all those places. Only
limitation of this method is that the break point can be set in the current program only.
If there are other include programs, then one has to wait until the control reaches to
that program. These break points are applicable for that execution of the program. In
next execution one has to set it again, if required to stop. It is possible to save the break
point set this way. Upon saving the break points are like method 1 of this section.

SAP debugger gives an option to set the soft break point in few more ways. You can set
the direct break point at:

1. ABAP/4 Statements
2. Subroutines
3. Function modules
4. System Exception
One can set break point using ABAP/4 statements like ‘SELECT’, ‘MESSAGE’, ‘CALL
FUNCTION’, ‘PERFORM’, Etc. As displayed in the figure below, a small window pops up,
when this option is selected. An ABAP key word has to be typed in this window. Once
the enter is pressed on this popup, the soft break points are set on all the lines of all the
programs, where this statement is used.

Similarly, if one wants to set a break point at particular point at particular

Perform/Function module, the relevant option should be selected. A popup is displayed
to enter the name of Perform/ Function module.

It should be noted that the break points set by this method are set in all the programs in
the Call Stack.

What is debugging?
Debugging is often referred to as the process of analyzing the flow of a program,
thereby detecting defects/bugs. In addition to detection, an ideal debugging process is
followed by the omission or reduction of program flaws.

What is SAP debugging?

Unlike other programming languages, debugging process in SAP witnesses a process

of analyzing different objects. A powerful tool, the ABAP debugger is utilized to achieve
so. Imbibed with capabilities of analyzing the program or object by line or section, it can
even go on to alter objects during runtime.

There are two types of SAP ABAP debuggers: classical debuggers and new ABAP
debuggers in SAP.

The whole process of debugging is hyper-critical for a smooth workflow of an ABAP

system. Thus, an ABAP consultant’s thorough knowledge and skill over it, undoubtedly
flexes business’s arms over controlling flaws in the system. To quote some of the ready
reference benefits caters to:
 Quick turnaround time for analysis and issue resolution
 Reduction of complete dependence on ABAP team
 Calculate effort estimation
Advanced debugging techniques in ABAP
The process of debugging in SAP involves a lot of faces to it. Let’s start with the
following:

Programs in SAP ABAP:

If you are an ABAP consultant, then dealing with transaction codes would not be a new
phenomenon for you. However, while executing the program, in case you are shot by
trouble, debugging process can help you fix the coding error with precision.

TROUBLESHOOT:
Every piece of transaction code is backed by an ABAP source code which is either
delivered by SAP or customized for achieving a specific goal. Debugging the program
enables you to preserve the control in your hands while checking the program line by
line. As a result, this process allows you to find out a specific bug or clear out a specific
logic.

Get step by step guide for SAP debugging

How to debug in SAP:
Debugging process can be inducted in two methods:

1. /h command method:
The usage of the /h command in the initial transaction screen is followed by executing
the transaction. However, if any breakpoints occurs in between the start and end points,
the control directly flows in that point. Else, the debugging process is ended by further
execution of the program. This is the process of line-by-line debugging.
A. After the successful creation of the program, place the cursor on the desired line and
set session breakpoints.
B. Following this execute the program twice.
C. Now, you take up a sample value and check it in the output table.
Note: there are 4 different options in the debugger tool to execute a particular program
in SAP.
F5, executes the program step-by-step.
F6, executes a subroutine module without entering into it.
F7, sniffs out a subroutine.
F8, executes the program if there is more than one breakpoint then it can move from
one breakpoint to another.

2. Break-point method:
This method can be executed by entering in the source code editor and adding the
break point at the desired line. Here, the cursor has to be put up on the particular line,
the one where the control needs to stop. Right after, clicking the break point button will
readily create the breakpoint in the program.

Now, let’s try to understand where and how the break-point method works most
efficiently.

Debugging SAP:
SAP delivers two kinds of debugging procedures for its users in the break point
methodology.
A. Static breakpoints: Here, statement break-point in ABAP code enables the whole
process. Unlike others, these are not user specific and can be inducted by any user. It
needs to be deleted manually.

B. Dynamic breakpoints: These are user-specific and can only be inducted by users.
Set-up in an ABAP editor, these can be deleted automatically after log-off. However,
what needs to be kept in mind is that dynamic breakpoint scan be set up only in active
source only.

They are of two types of dynamic breakpoints.

External breakpoints can be activated for both SAP and Non-SAP applications. On the
contrary, session breakpoints can be activated for call within SAP systems only.

Session debugging:
Watch point method

Debugging a particular row in a table skipping line-by-line method makes the whole
process faster.

A. Starting with selecting the desired row, place the cursor on the variable and click on
create watch point button.
B. Set condition to free condition entry.
C. Watch point would be created.
D. We would witness the value of the selected variable.

Debugging is the way to find the root cause of SAP

transaction behavior (e.g., finding a reason why a certain value in
a field was updated or determining why users receive an error,
warning, or abnormal termination message during the processing of
a transaction). Debugging is necessary if the root cause cannot be
determined from functional methods such as checking customizing
or master data.

Since ABAP is the backbone of SAP, at one point or another, every

member of a functional team must have had to deal with SAP
development technicalities behind the business functionality. This
need for technical details can occur during various phases, such as
writing functional specifications or analyzing a production
environment issues.
If you are not sure about which line of code you want to debug, enter transaction /h in the
command prompt, sometimes refereed to as the OK CODE, while executing any transaction.
Press Enter to activate the debugger. (see below)

You’ll see the message in the status line and now if you were
to press enter again, or hit save, or perform any function on this transaction, you will see the
DEBUGGER screen appear (see below). You will be positioned at the first executable
instruction based on the user interaction you performed. If you knew the exact line of code you
wanted to have the DEBUGGER screen appear at, then you could use a BREAKPOINT , but
we will cover that a little later
OK, lets take a look at the debugging screen itself…. let’s start with the control buttons.

CONTROL BUTTONS

If you look above, you can see four buttons I have highlighted and numbered 1 – 4. The buttons
control the flow of the debugging session and are described in detail below….

1. Single step (the F5 key). When you click this icon, the debugger control moves to the next
line of code in debugging. If the next line is a call to another program, (e.g., the function
module), then the control shifts to that program.
2. Execute (the F6 key). When you click this icon, the debugger control moves to the next line
of code in the same program only, without going inside the code of the function module or
program being called in the line of code in which you click this icon.
3. Return (the F7 key). When you click this icon, the debugger control returns to the calling
program. This icon is useful when you are in a loop or inside a function module or program
called from the main program and you want to return to the main program.
4. Run/Continue (the F8 key). When you click this icon, the debugger control moves to the
next breakpoint set, if any. Otherwise, the debugging is switched off, and the program is
executed completely.

FIELD DISPLAY
During debugging, the fields display shows the field list. If you click any field in the
program, the debugger shows the present value or contents of that field. If for some reason like
during testing, you want to use a different value for the field, you can change the field value
using the change icon , but this access in debug is generally given to developers only
and NEVER in a production system. (see below)

TABLE DISPLAY
Now we need to turn to how we could look into tables. Why? Lets say your looking at a sales
order, or purchase Req…etc Well the items are normally stored in whats called an INTERNAL
TABLE. This is not to be confused with a DATABASE TABLE like VBAK, or VBAP. The
DATABASE TABLES are stored on the Backend DBMS (Oracle, DB2, even HANA) and are
PERSISTENT. While the INTERNAL TABLES are NOT PERSISTENT and have a shelf life of
the current LUW in Memory.

First, like any field double-click on an internal table in the debugger. You will see the table
appear, like any field, on the right hand side. The way you will know this a table is by the
icon. (see below)

To see the current contents or rows of the internal table double-click the icon. I know you need
to know how to add, change or delete rows, so thats when you use the Object Services icon .
Depending on what you are looking at (Field, Database Table, Internal Table…etc), if you click
this icon then services relating to the type of object you are working with will be available for
your use. For instance you can add,change or delete a row. You can also export the internal table
to EXCEL by using the icon . (see below)
BREAK-POINTS
Now is a good time to discuss Break-Points. A break-point can be set for a line of code either
while in the debugger, or prior while in the EDITOR (SE80/SE38/SE37/SE24). The icon for a
breakpoint looks like this . In contrast, the icon shows you where your are in the execution
of an object. Say, you used /h to trigger the debugger and single-stepped one line at a time. Well
the icon would continue to move down with the execution.

When you double click on a line of code left of the line number, you will set a BREAK-Point.
Then when you run the transaction or program, the debugger will stop at that specific line of
code and pop up a debugger screen that by now you know well. (see below)
There is more than one way to set a break-point. One of my personal favorites that I have shown
above is to use the menu path BREAKPOINTS->BREAKPOINT AT. Here we have many options
to set dynamic break-points based on commands, functions, methods…etc. One way to use this
is to choose BREAKPOINT AT Statement, and enter the command AUTHORITY_CHECK.
This will cause the object to stop anytime this command is about to be executed. Then when you
stop, F6 to execute. Then use the field change capability to alter the contents of SY-SUBRC to
zero, if it is not zero already. This is a good way to bypass and use SAP transactions you may not
have authorization for. Please remember that you must use caution when doing this, and you will
NOT be able to do this in Production.

THE CALL STACK

Lets end this month’s Blog with a look at one more useful tool. The ABAP Stack.

The DESKTOP 2 Tab in the debugger UI displays the ABAP call stack. It allows you to switch
to the context of each stack level and navigate to the source code by opening the ABAP Editor,
in order to start a deeper analysis of the code in a separate window(just double click!). Also new
with SAP NetWeaver 2004s is the ability to display the screen (Dynpro) stack as well. Even
more important, you can display a combined ABAP and screen stack to find out on which ABAP
level which screen was called, and which screen invoked which ABAP module.

You can navigate from each stack line to the corresponding source line in the editor by double
clicking on the icon in the stack type column