Starting ABAP Debugger

Use

You start the ABAP Debugger by calling or stopping the ABAP program to be tested in a specific way. Follow the procedure below:

If you have not done so already, log on to the AS ABAP.
The user you used to log on to AS ABAP must have debugging rights.

Authorization object: S_DEVELOP

Object type: DEBUG

Activity

3: debug

2: change and jump-in code

1: Reserved for internal SAP use

See also SAP Note 65968.
The ABAP Debugger should be configured as the standard debugger for your user (this is the default setting). You can check it in the following way:
- Open the Object Navigator (SE80) or the ABAP Editor (SE38).
- Choose Utilities Settings ABAP Editor Debugging .
There are many ways to start the ABAP Debugger. The suitable procedure depends on the use case. You have the following options:

Procedure	Typical Use
Start an ABAP program and set it directly under the control of the ABAP Debugger. The ABAP Debugger controls the execution of the program from the first row onwards.	Starting and directly debugging function modules, methods, and executable programs (such as transactions and batch jobs) that can be started in the ABAP Workbench in the context of the current user session. You can: Debug a program from the first row onwards. Debug program sections where you don't know the source code very well and therefore don't know where it makes sense to set breakpoints. For more information, see Starting ABAP Debugger Directly.
Jump directly to the ABAP Debugger while executing an ABAP program. It is not necessary to set breakpoints. The ABAP Debugger controls further execution of the program.	Stopping and debugging: Dialog applications with Dynpro-based interfaces that run in the context of the current user session Running processes and background jobs Waiting, rolled-out main modes You can: Directly explore inconsistencies that occur when executing a program. Debug program sections where you don't know the source code very well and therefore don't know where it makes sense to set breakpoints. For more information, see Starting ABAP Debugger Directly.
Set breakpoints in an ABAP program and then execute the program. ABAP Debugger starts after the program execution has reached a breakpoint. The ABAP Debugger controls further execution of the program.	Stopping and debugging ABAP programs where you know the source code and which does not run in the context of background jobs or monitoring. Depending on which user the program is executed for, there are different types of breakpoints and procedures for stopping and debugging: ABAP programs that are started and executed in the context of the current user sessions (local debugging). ABAP programs that are called using HTTP or RFC (external debugging, external breakpoints). Note Processing an RFC or HTTP request always takes place in the context of a new user session. For more information about external debugging, see External Debugging (HTTP and RFC Requests).

Procedure

Typical Use

Start an ABAP program and set it directly under the control of the ABAP Debugger.

The ABAP Debugger controls the execution of the program from the first row onwards.

Starting and directly debugging function modules, methods, and executable programs (such as transactions and batch jobs) that can be started in the ABAP Workbench in the context of the current user session. You can:

Debug a program from the first row onwards.
Debug program sections where you don't know the source code very well and therefore don't know where it makes sense to set breakpoints.

For more information, see Starting ABAP Debugger Directly.

Jump directly to the ABAP Debugger while executing an ABAP program. It is not necessary to set breakpoints.

The ABAP Debugger controls further execution of the program.

Stopping and debugging:

Dialog applications with Dynpro-based interfaces that run in the context of the current user session
Running processes and background jobs
Waiting, rolled-out main modes

You can:

Directly explore inconsistencies that occur when executing a program.
Debug program sections where you don't know the source code very well and therefore don't know where it makes sense to set breakpoints.

For more information, see Starting ABAP Debugger Directly.

Set breakpoints in an ABAP program and then execute the program.

ABAP Debugger starts after the program execution has reached a breakpoint.

The ABAP Debugger controls further execution of the program.

Stopping and debugging ABAP programs where you know the source code and which does not run in the context of background jobs or monitoring.

Depending on which user the program is executed for, there are different types of breakpoints and procedures for stopping and debugging:

ABAP programs that are started and executed in the context of the current user sessions (local debugging).
ABAP programs that are called using HTTP or RFC (external debugging, external breakpoints).

Note
Processing an RFC or HTTP request always takes place in the context of a new user session.

For more information about external debugging, see External Debugging (HTTP and RFC Requests).

Starting the ABAP Debugger triggers the following actions:

Executing the program to be tested is canceled.
The ABAP Debugger starts in a main mode of the current user session (local debugging) or in the user session where the breakpoint was set (external debugging).
Control is passed to the ABAP Debugger. The input-ready window of the ABAP Debugger is displayed and focussed.
You can now control further execution of the program using the ABAP Debugger. Use the tools offered in the ABAP Debugger window for this.

Note

A maximum of six main modes are offered in each user session by default. If no other main mode is available when starting the new ABAP Debugger, a message appears and the classic ABAP Debugger starts. Close any main sessions you no longer require to be able to work with the new ABAP Debugger. The maximum number of main modes in a user session can be controlled by the adiminstrator using profile parameters of each application server.

Note

System programs are excluded from debugging by default and are executed without being stopped.