I believe that most of you know how to debug the basic report or class methods etc.

But things can become complicated when debugging is needed for a backround job, RFC function module or even some user-exit which is being triggered in an update task. E.g. when you update material master in ECC using MM02, you can’t easily debug all user-exits because they’re triggered in separate process independent on session you are currently running.

In this article I’d like to present several useful debugging tricks you can use in your more complex scenarios.

Basic debugging

1. Put a break-point in your code and execute the program.
2. Once the line with break-point is reached, the ABAP Debugger is started automatically.

Basic debugging using ‘/h‘

When you are in a started transaction/program and you would like to begin debugging at the moment:

1. Type ‘/h‘ (without the quotes) in the command box and press enter
2. Do any action in your program (eg. Save, Display, press F4, …)
3. After you do any action which triggers PAI of the screen the ABAP Debugger is started

Debugging of “Update Task“

Debugging of an Update task is not possible with normal setup and without modification of user settings you are basically not able to debug a program which is started in an update task. To enable debugging of update task:

1. Start basic debugging using ‘/h‘
2. When ABAP Debugger is started, go to Top menu -> Settings -> Change Debugger Settings / profile (Shift+F1)
3. Select check box “Update debugging“
4. Press F8 to let current processing continue and wait until the update task is started in another window

Debugging “Queued RFCs“

Debugging Queued RFC might become useful e.g. for ECC <-> APO interface where a CIF is used and data are sent back and forth using named queue called ‘*CF’

The outbound debug is easy – this can either be achieved by the Basic debugging or by Debugging of an update task (outbound queues).

Inbound debugging is a bit harder because the queue is setup to process all incoming requests automatically at the moment of their arrival. To be able to debug inbound queue you have to STOP processing of arriving requests on a specific queue.

Debugging “Background tasks“

Debugging of a background task is not normally possible because the background task is started in another process (like the update task) so developer is not automatically navigated to the background code during debugging.

To enable background debugging:

1. Start basic debugging using ‘/h‘
2. When ABAP Debugger is started, go to Top menu -> Settings -> Change Debugger Settings / profile (Shift+F1)
3. Select check box “TRFC (In Background task): Block sending”
4. Press F8 to let current process to finish
5. Go to SM58 and find your un-processed background task
6. Start its debugging in Top-menu -> Edit -> Debug LUW

Debugging “Dialog windows“

When a dialog window is displayed in SAP you don’t have the command box available. So you are not able to start debugging using the ‘/h’ command as usually.

The trick is in creating a ‘shortcut’ as a flat file in your file system with the following contents:

[FUNCTION]
Command=/H 
Title=Debugger
Type=SystemCommand

To enable debugging of a dialog window just Drag&Drop your prepared flat file on that dialog window and you should notice the message saying that debugging has been switched on.

After you perform any action on such dialog window the ABAP Debugger is started and you can evaluate the user action results.

Debugging as different user

This might become useful when processing e.g. requests from webdynpro which is handled on SAP backend by some predefined system user.

To enable debugging for a different user, go to SE38 (or SE37, SE24 or anythnig else which uses ABAP Editor) in the Top-menu open Utilities -> Settings -> tab ABAP Editor -> sub-tab Debugging -> enter the name of user you would like to use for debugging.

Dynamic Breakpoints

Dynamic breakpoints are extremely useful especially in debugging of an update task because the update tasks are started in new sessions where your temporary breakpoints are not kept – so you have to set them again.

1. Once ABAP Debugger is started for the update task you can put breakpoints to your code using Top-menu -> Breakpoints -> Breakpoint at …
2. Just select the proper “Breakpoint at …”, eg. Function Module and enter the user-exit name you are going to debug
3. Press Enter and F8 to continue running the update task until your user-exit is reached and debugger is available again for you in the user-exit

I personally use it a lot when searching for the user-exits/BAdIs called during the program execution: just put new dynamic breakpoint as “Breakpoint at Statement” with the following ABAP command

CALL CUSTOMER-FUNCTION

Conditional breakpoints

This feature of debugger might become quite handy when you need to debug something in a loop and let’s say in its 500^th iteration.

Without the conditional breakpoint you’d have to do each iteration manually. Using this approach you just set the breakpoint condition (in this case sy-tabix = 500) and you are done:

When standard debugger is started press F9 (Create Breakpoint), select desired target (Method, Function module, Program-form) and type your “Free Condition Entry” (e.g. SY-TABIX = 500).

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

In typical scenario an active external debugging triggers ABAP debugging when interacting with web pages: When a web page requires a call back to ABAP backend and you’ve set an external breakpoint in that code, an ABAP debugger window pops up.