DEBUGGING

TECHNIQUES
The ABAP Debugger is a tool used to execute and analyze programs line by line. Using it we can check the flow logic of a program and display runtime values of the variables. Currently, SAP offers two types of Debuggers:

• The Classic ABAP Debugger

• The New ABAP Debugger
How to debug?
There are two possible strategies for starting the
Debugger in the ABAP Workbench:
• By setting breakpoints then running the program
• By running the program in debugging mode
Setting Breakpoints
A breakpoint is a signal in a line of code that tells the ABAP
runtime processor to interrupt the program at that line and start
the ABAP Debugger.

Running a Program in Debugging Mode

You can start the Debugger without previously having set
breakpoints. This is the best procedure to use when you want to
test a program right from the beginning. It is also useful if you
do not know the program very well and therefore are not sure
where to set breakpoints
BREAK-POINTS
Static Breakpoints
Static breakpoints are not normally user-specific. Once a user
has inserted a BREAK-POINT statement in an ABAP program,
the system always interrupts the program at that point. You
should only use static breakpoints during the development phase
of an application. You should set static breakpoints whenever
more than one programmer is working on the same program and
you always want to stop the program in the same place.

program RSDEBUG_01.
....
if SY-SUBRC <> 0.
break-point.
endif.
....
Dynamic Breakpoints
Dynamic breakpoints are user-specific. You
should, therefore, use them when you only
want the program to be interrupted when you
run it yourself. All dynamic breakpoints are
deleted when you log off from the
R/3 System.
Dynamic breakpoints are more flexible than
static breakpoints, because you can deactivate
or delete them at runtime.
You do not have to change the program code
You can set them even when the program is locked by another programmer
You can define a counter (for example, only activate the breakpoint after it has been reached five times).
30 dynamic break points can be set.
EXTERNAL BREAK-POINT
External breakpoints are valid for all user logons on the current server of the current
system. External breakpoints are specifically required when debugging BSP or Web
Dynpro applications. In these cases, you do not log on using the SAP GUI but via a
browser. User breakpoints are only valid for a period of 2 hours
Breakpoint Variants
DEBUGGING KEYS

F5: debug in single step (line by line)

F6: Skips Subroutines/FM whenever a control encounters a
subroutine or FM .
F7: controls return to main program from Subroutines & FM
F8: executes program until next break point, if no breakpoint
completes execution.
WATCHPOINTS
Like a breakpoint, a watchpoint is an indicator in a program that tells the ABAP
runtime processor to interrupt the program at a particular point. Unlike
breakpoints, however, watchpoints are not activated until the contents of a
specified field change. Watchpoints, like dynamic breakpoints, are user-specific,
and so do not affect other users running the same program. You can only define
watchpoints in the Debugger.
• You can set up to five watchpoints in a program.
• You can also specify the conditions on which a watchpoint is to become active.
Display Modes in the Debugger
PROCESSING FIELDS
You can change the values of fields at runtime to see how the change would
affect the program flow. Suppose you have found out that a field contains
an incorrect value. You would be able to replace it with another value in the
Debugger to test whether the program would run properly in that case.
Constants declared cannot be changed.
PROCESSING INTERNAL TABLE
The internal tables can be modified through debugging, similar to field processing.
POP UP DEBUGGER
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.

DEBUG.BAT
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.
MODIFICATION TO DATABASE
RECORD
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.

Edit the values through SE16.

Attached document file below has detailed steps on how to modify database record.

Microsoft Word
Document
GO TO STATEMENT
You can use go to statement 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 do is just put your cursor on the desired line and then press the SHIFT +
F12 key(both preceding and following lines).
Continue to Cursor option executes the program to the line where you have placed the
cursor. The function does not work if the cursor is placed on a line preceding the
currently executed statement.
Navigation Functions
• We can navigate to the source code from the debugger.

• Displays program name/Include/ Line which is to be processed

• Displays the program event.

DEBUG BACKGROUND JOB
Debug background job with scheduled/released/completed/cancelled status:
Select the job in SM37 and enter JDBG in the command line and press enter, it’ll take you to
debugging mode for the corresponding job.

Background jobs with active status:

Goto SM50 to get the list of processes.Identify the work process related to the job(program).Go to
menu option Program/Mode -> program -> debugging
or Job -> Capture active job in SM37.
DEBUG SCRIPTS & SMARTFORMS
To debug script:
1.Execute the report RSTXDBUG to activate the script debugger.
2.Goto SE71 and give your form name and go to Utilities-->Active De-bugger.
To debug Smart form:
1. One way to debug smart form is to debug the Function Module of that smart
form. Within PERFORM %GLOBAL_INIT node level coding can be found.
2. If you want to debug particular smart form node then the solution would be,
insert a "Program Line" just above the node you want to debug and this program
line write a normal ABAP breakpoint (static breakpoint). (BREAK ID )
DEBUGGER SETTINGS
The System Debugging function enables the user to analyze system programs, in
addition to application programs, using the Debugger. This function is called or
terminated through the menu Settings ® System Debugging On /Off. By selecting
the menu Settings ® Save, this predefined setting is stored to the database and thus
activated again each time the new Debugger is activated.
Update Debugging and TRFC

Update Debugging can be used to debug function modules that were called
using the option IN UPDATE TASK. Without update debugging activated,
you will not go into these functions that are processed in another task.
Example attached below

Update
Debugging example

TRFC

Transactional RFCs use the suffix IN BACKGROUND TASK.

We need to activate TRFC in debugger settings when we want to debug in
background task.Example attached below

TRFC debugging
exmaple
Limitations of new Debugger
Debug screen programs:
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
ST22 ANALYSIS
Whenever a program generates runtime errors, this error information can be accessed
in future only thru Tcode ST22. You can use the tools of the ABAP dump analysis
(ST22) to list the ABAP runtime errors that have occurred in an ABAP system as
well as the relevant short dumps.
• Save in a local file
• Store for a longer period of time

Go to st22 source code extract and locate for symbol “>>>>”. We ll get the line
where the error is triggered.

Also ST22 provides inputs on ‘possible reason for dump’ and ‘possible solution’.
COMMON RUNTIME ERRORS

• COMPUTE_BCD_OVERFLOW
• CX_SY_ZERODIVIDE
• TABLE_ILLEGAL_STATEMENT
• LOAD_PROGRAM_LOST
• TSV_TNEW_PAGE_ALLOC_FAILED
• DBIF_RSQL_INVALID_RSQL
• DBIF_RSQL_TABLE_UNKNOWN
• CONVT_NO_NUMBER
• GETWA_NOT_ASSIGNED
• CALL_FUNCTION_PARM_MISSING
• CALL_FUNCTION_CONFLICT_TYPE
• STRING_OFFSET_TOO_LARGE
• DYNPRO_SYNTAX_ERROR
THANK YOU 