Setting breakpoints and using different debug step functions like F5, F6, F7 and F8 are described for debugging ABAP programs. The different types of breakpoints - debugger breakpoints, session breakpoints and user breakpoints are explained. Methods for debugging remote function modules using transaction SRDEBUG, debugging background jobs using transactions SM37 and SM50, and setting watchpoints to monitor variable changes are provided. Debugging techniques for smart forms using program lines and transaction SFTRACE are also summarized.

1. Starting abap debugging
1. Putting /H in command box and hitting execute button
2. Setting breakpoint in program.
Difference among F5 , F6 ,F7 and F8
F5: debug in single step (line by line)
F6: Skips Subroutines/FM
Whenever a control encounters a subroutine or FM debug them unlike F5
F7: controls return to main program from Subroutines & FM
F8: executes program until next break point.
Breakpoint Types
1. Debugger breakpoint:
When you set a breakpoint in the Debugger, it is created as a debugger breakpoint by default. A
debugger breakpoint is only valid while the Debugger instance, in which it was set, is active. When the
Debugger is closed, all debugger breakpoints set in it are deleted.
2. Session breakpoint:
If you set a breakpoint in the ABAP Editor, for example, this breakpoint is a session breakpoint. Session
breakpoints remain active independently of the existence of a Debugger and are valid for all external
sessions of a logon. Within the Debugger, you can convert a debugger breakpoint into a session
breakpoint and vice versa.
If the setting Session Breakpoints Active Immediately is checked
(via Utilities → Settings → ABAP Editor → Debugging in the ABAP Editor or Object Navigator), you can
set a session breakpoint in an external session of a logon to force a running program into the Debugger
that runs in the same logon (for example, in an external session) and will process the point at which the
session breakpoint was set.
3. User breakpoints:
User breakpoints (previously known as external breakpoints) are valid for all user logons on the current
server of the current system. User 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, for example.
Therefore, any breakpoints must be set before logging on.
User breakpoints are only valid for a period of 2 hours.
As of Release 7.00, user breakpoints set for BSP or Web Dynpro applications are also valid for SAP GUI
logons.

2. Within the Debugger, you can convert debugger or session breakpoints into user breakpoints and vice
versa.
We can create maximum 30 breakpoints only.
System Debugging
If you set this option, the Debugger is also activated for system programs (programs with status S in their
program attributes). When you save breakpoints, the System Debugging setting is also saved.
Update Debugging
Update function modules do not run in the same user session as the program that is currently running in
the ABAP Debugger. These function modules are therefore not included in debugging. Only if you select
the Update Debugging option you can display and debug them after the COMMIT WORK.

3. Remote abap debugging
1.
Open the Function module/ Proxy class and set an external break-point. Execute the transaction code
“SRDEBUG” (Note: this tcode is available only in ECC 6.0 system onwards)
Click on the button Activate Debugging. A pop-up screen will be opened. Fill the User-ID with which
break-point has been set. (The same user-id should be used as authentication data in the XI while
creating RFC communication channel). Select the radio buttons “all Appl. Servers” and “External
breakpoints already set”. Click on OK.

4. Another pop-up will be opened with a message “End debugging?” Leave the pop-up as it is. (Don’t close
the transaction).
When you run transaction in source system debugger will start in target system where SRDEBUG
transaction is set

5. 2.
For example we are calling an RFC enabled FM in ECC system from CRM system.
Scenario 1: Calling a custom RFC FM
1: Add an infinite loop in the remote custom Function Module (adding a “DO. ENDDO.” statement at
the start of the FM would be enough).
2: Execute your program in the CRM system. The execution stops at the RFC call, because of the
infinite loop.
3: login to the ECC system and go to transaction SM50. Select the process which is executing
the RFC and navigate to the menu: “Program/Session->Program->Debugging” this triggers the debugger
Session in a separate window.
Scenario 2: Calling a Standard RFC FM
When we are debugging a standard program we cannot add the infinite loop, hence we cannot go to
SM50 and debug the work process. The RFC destination for the ECC system has a User specified, the
RFC function module gets executed using this users credentials. Usually the basis team set up the RFC
user as non Dialog user, this does not allow debugging. Contact your Basis team and get this changed to
a dialog user enabling you to debug RFC function calls via the normal debugger.
Debugging a Popup Window
Sometimes we might want to start debugging from a popup window / information message, in this case
we cannot type "/h" as the “OK Code” box is not available.
Method 1: From any SAP windows press the “Customize Local Layout” button (Alt + F12) and select
“Create Shortcut…” Select system command in Type and and put /h in Command Provide desktop in
location and click on finish. A file is generated on your desktop. Now drag the file onto the popup
window / information message or click on file and debugging is enabled!

6. Method 2: For this create a text file with .SAP extension on your desktop, and type the below lines into
the file:

7. [System]
Name= ECD
Description= ECD [host.com]
Client=100
[User]
Name= Username
Language=EN
[Function]
Title=
Command=/H
Type=SystemCommand
[Configuration]
WorkDir=C:Documents and SettingsJohnSapWorkDir
[Options]
Reuse=1
Debugging background job
1. To debug active background process Go to the transaction SM37 and select the background job (with
job status ‘Active’) that you want to debug. Now select ‘Capture: active job’ from menu ‘Job’,
2. Also you can do the same from transaction SM50. Select the work process where this job is running
and then choose the menu path Program/ModeProgramDebugging.
3. To debug completed background process select job in SM37 and write 'JDBG' in command prompt and
press enter. You will be in debug mode. Press F7 couple of time until you get into the code.

8. Watchpoints
Watchpoints allow you the option of monitoring the content of individual variables. The Debugger stops as
soon as the value of the monitored variable changes. In addition, conditions can be specified. The
Debugger also checks whether such a condition is fulfilled.
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.
Use
You set watchpoints in the Debugger to monitor the contents of specific fields. They inform you when the value of a
field changes. When the value changes, the Debugger interrupts the program.
We can create maximum 24 watchpoints in a session
Creating a Watchpoint
In the toolbar of the New Debugger, you will find the pushbutton Create Watchpoint . It brings
you to the dialog box Create Watchpoint.
Using this function, you can enter the variable to be monitored.
All possible ABAP data structures are allowed here.

9. Watchpoint is reached
After you have created the watchpoint, the value of the variable will be monitored.
As soon as a change is found in the content of the variable after a Debug step and any conditions set
have been met, the Debugger will stop and you see the message "Watchpoint is reached
(<Watchpointvariable>)“.
In the Breakpoints tool (desktop Breakpoints/Watchpoints / Tab Watchpoints), you can view this reached
watchpoint in detail.
The reached watchpoint is marked with a yellow arrow. The old and the new values of the watchpoint
variable are at your disposal.
In addition, you can use the pushbutton Compare Variables ( ) to determine the differences between
the old and the new variable.
In addition, you can maintain the watchpoint in this view – that is change, activate, deactivate, or delete it.
Validity Area for Watchpoints
In contrast to breakpoints, watchpoints are only valid locally in the roll area. If a roll area changes, none of
the watchpoints defined in the underlying roll area are visible. Also, watchpoints that were created in the
New ABAP Debugger cannot be used further in the Classic Debugger (for example, after changing the
Debugger) and vice versa.

10. To debug script:
Execute the report RSTXDBUG to activate the script debugger.
OR 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 that 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.
3. SFTRACE can be used for debugging SMARTFORMS.
Go to tcode SFTRACE / SMARTFORM_TRACE --> click "trace on" and click checkboxes Warning/Error
under abap breakpoints tab.
So whenever you call the smart forms, it will stop at this breakpoint and you can debug onwards