SAP BREAK-POINT ABAP Statements



Get Example source ABAP code based on a different SAP table
  


ID BREAK-POINT
• BREAK-POINT ABAP Statement

BREAK-POINT
Short Reference

ABAP_SYNTAX
BREAK-POINT ${ $[ID group$]
$| $[log_text$] $}.

ABAP Addition
1 ... ID group
2 ... log_text

What does it do?
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 in dialog processing, the program execution is interrupted and the system branches to the ABAP Debugger. 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 following BREAK-POINT.
Breakpoints in Updates
During synchronous and asynchronous updates in an update session, the behavior depends on the setting of the ABAP Debugger:
If ABAP Debugger is not set to update debugging, a breakpoint behaves as in background processing.
If ABAP Debugger is set to update debugging, a breakpoint behaves as in dialog processing. The update is executed in a dialog work process of the current ABAP_ASINSTANCE .
In local updates, a breakpoint behaves as in dialog processing.
Breakpoints in RFC Processing
In RFC processing, the system stops at an active breakpoint and branches to the ABAP Debugger of the SAP GUI whenever an RFC dialog interaction is possible. The ABAP Debugger in the ABAP Development Tools (ADT) can also be displayed if no dialog interaction is possible.
Breakpoints in ICF and APC Processing
In ICF processing and APC processing, the system stops at an active breakpoint and branches to the ABAP Debugger of the SAP GUI only when external debugging is enabled. When programs or procedures are called in ICF processing and APC processing, they are executed in the context of the service context and their breakpoints behave accordingly.
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. The ABAP Debugger in the ABAP Development Tools (ADT) can also be displayed if external debugging is not enabled.
Breakpoints in ABAP daemon Processing
In ABAP daemon processing, the system stops at an active breakpoint and branches to the ABAP Debugger of the SAP GUI only when external debugging is enabled. This also applies to non-dialog users and in callback routines.
Breakpoints in System Programs
In system programs, system modules, system subroutines, and system function modules whose name begins with %_, the statement BREAK-POINT is only respected if system debugging is switched on in the ABAP Debugger (using the Settings menu or by entering /hs in the command field of the system toolbar). Otherwise, breakpoints are ignored.



Latest 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 exclusively for test purposes and are not allowed in production programs. The statement BREAK-POINT without the addition ID therefore causes an error in the extended program check.
BREAK followed by a user name is not a statement, but a predefined macro.
The statement BREAK-POINT defines a checkpoint that is part of an ABAP program. In the ABAP Editor and the ABAP Debugger, the following breakpoints can be set and managed without changing the source code:
Session breakpoints
are set in the ABAP Editor. Session breakpoints are valid in all ABAP 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. This makes them particularly well suited for debugging RFC, ICF, and APC processing.
Debugger breakpoints
are set in the ABAP Debugger window. They are valid for the current debugging session and for all ABAP_ISESSNS and ABAP sessions of the debuggee. Debugger breakpoints can be saved as external breakpoints.
ABAP_HINT_END



Example ABAP Coding

Breakpoint between two program sections.
ABEXA 00051
ABAP_EXAMPLE_END
• ID BREAK-POINT

ABAP Addition

What does it do?
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 the statement ASSERT also apply when the checkpoint group is specified. However, only inactive or break can be chosen as operation mode.
In background, update, ICF, and APC sessions without external debugging, the breakpoint is always inactive if the addition ID is used.



Example ABAP Coding

Specification of a breakpoint whose behavior is specified by the checkpoint group DEMO_CHECKPOINT_GROUP.
ABEXA 00052
ABAP_EXAMPLE_END

ABAP Addition

What does it do?
A supplementary text can be entered for the system log in log_text . log_text is ignored in dialog processing. In background processing and during the update task, the content of log_text in the system log is inserted between the words Breakpoint and reached. log_text expects a flat character-like data object with a length of 40 characters. If a data object of type string is specified, it is ignored.



Example ABAP Coding

Breakpoint with a text specified for the system log.
ABEXA 00053
ABAP_EXAMPLE_END

Return to menu