ABAP Keyword Documentation → ABAP - Reference → program editing → Testing and Checking Programs → Checkpoints
BREAK-POINT
Other versions: 7.31 | 7.40 | 7.54
Syntax
BREAK-POINT { [ID group]
| [log_text] }.
Extras
1. ... ID group
2. ... log_text
Effect
This statement defines a breakpoint.
The addition ID
controls the activation. Without the addition ID
, the breakpoint is always active.
Breakpoints in dialog processing
If the program reaches an active breakpoint during
dialog processing,
the execution of the program is interrupted and the ABAP Debugger is opened. An inactive breakpoint is ignored and the program execution continues with the statement after BREAK-POINT
.
Breakpoints in background processing
During background
processing, program execution is not interrupted. When the program reaches a (permanently) active
breakpoint (the addition ID
is not used), the entry "Breakpoint reached"
is written to the system log along with the program name and the location of the breakpoint in the program.
Activatable breakpoints (where the addition ID
is used) are ignored. The program execution continues in both cases with the statement after BREAK-POINT
.
Breakpoints in updates
During synchronous and asynchronous updates, the behavior depends on the setting of the ABAP Debugger:
- If the ABAP Debugger is not set to update debugging, a breakpoint behaves as in background processing.
-
If the ABAP Debugger is set to update debugging, a breakpoint behaves as in dialog processing. The update is executed in a dialog work process on the current application server.
During local updates, a breakpoint behaves as in dialog processing.
Breakpoints on HTTP servers
If an ABAP program is executed as an Internet Communication Framework (ICF) HTTP server, the system only stops at an active breakpoint and branches to the ABAP Debugger if external debugging is switched on. External debugging can be switched on for a limited time period (by default two hours) using transaction SICF or by setting an external breakpoint in the ABAP Editor. If external debugging is not switched on, the breakpoints behave as in background processing.
Breakpoints in system programs
In system programs, system modules, system subroutines, and system function modules whose name begins
with %_ , the BREAK-POINT
statement is only respected if system
debugging is switched on in the ABAP Debugger (you do this in the Settings menu or by entering "/hs" in the command field of the
system toolbar). Otherwise, breakpoints are ignored.
Addition 1
... ID group
Effect
The following applies when using the addition ID
:
-
In dialog processing, activation from outside the program is controlled by a
checkpoint group
group
or an activation variant. The rules that apply to theASSERT
statement also apply when you specify the checkpoint group. However, you can only choose between inactive and break as operation mode. -
If the breakpoint with the addition
ID
is used in background processing, during updates in the update work process, and when executing programs as HTTP servers without external debugging, the breakpoint is always inactive.
Example
Addition 2
... log_text
Effect
You can enter a supplementary text for the system log in log_text
. In dialog processing, log_text
has no effect. In background processing and during the
update task, the contents of
log_text
in the system log are inserted between the words "Breakpoint" and "reached". For log_text
, a
flat, character-like data object
with a length of 40 characters is expected. If a data object of type string
is specified, it is ignored.
Notes
-
A breakpoint in
SELECT
loops can raise an exception due to the loss of the database cursor. This is because a database commit may be triggered during debugging. -
Breakpoints that are always active are used solely for test purposes and are not permitted in production
programs. The
BREAK-POINT
statement without theID
addition therefore causes an error in the enhanced program check. -
BREAK
followed by a user name is not a statement, but a predefined macro. -
The
BREAK-POINT
statement defines a checkpoint that is part of an ABAP program. In the ABAP Editor and ABAP Debugger, you can set and manage the following breakpoints without changing the source code:
- Session breakpoints
are set in the ABAP Editor. Session breakpoints are valid in all main sessions of the current user session.
- External breakpoints
are set in the ABAP Editor or in transaction SICF. External breakpoints have the same validity as session breakpoints, but remain valid for other user sessions when the current session is ended. They are therefore particularly suitable for external HTTP debugging and RFC debugging.
- Debugger breakpoints
are set in the ABAP Debugger window. They are valid for the current debugging session and for all internal sessions and main sessions of the debuggee. Debugger breakpoints can be saved as external breakpoints.