SAP ABAP: Understanding "Checkpoint Group" (translation of the article from saptechnical.com)

Introduction to the Checkpoint Group

The concept and implementation of the "Checkpoint Group" originally appeared in the SAP Web Application Server (SAP WebAS) 6.20 and are entirely related to the field of correctness control and tracking of variables. With proper use, the technology facilitates debugging work and improves the quality of the ABAP code. These checks are portable between systems using transports. Managed by a SAAB transaction.

Checkpoints can be defined for the BREAK-POINTS operator as well as with the ASSERT operator.
')
It is also possible to use the LOG-POINT operator to display data in the group log.

Consider the ASSERT operator
SAP describes the following syntax for this statement:

ASSERT [[ID group [SUBKEY subkey]] [FIELDS field1 field2 table1 table2...] CONDITION] log_exp. 

ASSERT is an extended copy of the BREAK-POINT statement. The operator can be used in the code delivered to the production system without any influence on the code. It is called only when Checkpoint group is activated. An extended list of actions is provided for the operator.

Checkpoint groups can be defined and activated in a SAAB transaction. The generated ID is used to define the ASSERT and BREAK-POINT statements.

The following shows the SAAB transaction during the creation of a group ID.



After clicking the create button, go to the screen with the main parameters of the Checkpoint Group.



There are 3 options for activating groups:

1. Personal Activation;
2. User Level activation;
3. Server Level Activation.

In the case of Personal Activation, the group is activated only for the current user. User Level - for specified users, Server Level - for specified servers

Example user definition:


Example of server definition:


To control checkgroups, it is possible to define for each of the operators:


BREAK-POINT are defined as active or inactive. Inactive will be ignored. In case BREAK-POINT is activated, the debugger will be called upon reaching this operator.

BREAK-POINT statement syntax:

 BREAK-POINT { [ID groupID] | [log text] }. Ex. BREAK-POINT ID YH_check. 

If you omit the ID parameter, the point will be called unconditionally (the permanent status is active). The text 'log text' will be displayed in log.

In the case of a background process, the program is not interrupted at the breakpoint. If breakpoint is called in the program, the “Breakpoint reached” record will be entered in the system log (log) with the name of the program and the location of the breakpoint. If breakpoint is not active, they are ignored.

Next, consider the ASSERT operator.

There are three main options for using the operator:

• Inactive: the operator does not work
• Log: logging when using
• Abort: program interruption occurs (runtime error ASSERTION_FAILED)

In the case of a background process, two versions are possible:

• Log: event logging occurs
• Abort: the program is interrupted and the corresponding entry is made in the log

Principles of using ASSERT:

1. Do not use ASSERT instead of exceptions.
2. Use ASSERT in custom code only.
3. Calling ASSERT creates log entries for runtime error.

An example program using LOG-POINT and ASSERT:

 REPORT yh1316_test_checkgrp.. ** Parameters Declarations PARAMETERS: p_carrid LIKE sflight-carrid. *data : max type i. *Types Declarations of sflight TYPES : BEGIN OF type_s_sflight, carrid TYPE sflight-carrid, connid TYPE sflight-connid, fldate TYPE sflight-fldate, price TYPE sflight-price, max TYPE i, END OF type_s_sflight. *Field String Declarations for sflight DATA: fs_sflight TYPE type_s_sflight. *Internal table for Sflight Data DATA : t_sflight LIKE STANDARD TABLE OF fs_sflight. DATA yh1316_subkey TYPE char200. IF p_carrid IS INITIAL. SELECT carrid connid fldate price FROM sflight INTO fs_sflight. WRITE: / fs_sflight-carrid, fs_sflight-connid, fs_sflight-fldate, fs_sflight-price. APPEND fs_sflight TO t_sflight. ASSERT ID yh1316_check SUBKEY 'YH1316_parameter_if_initial' FIELDS p_carrid t_sflight fs_sflight-carrid fs_sflight-connid fs_sflight-fldate fs_sflight-price condition p_carrid eq 'LH' . ENDSELECT. ASSERT ID yh1316_check SUBKEY 'YH1316_1' FIELDS p_carrid t_sflight CONDITION p_carrid EQ 'LH' . EXIT. ELSE. ASSERT ID yh1316_check SUBKEY 'YH1316_2' FIELDS p_carrid t_sflight CONDITION p_carrid EQ 'LH'. SELECT carrid connid fldate MAX( price ) AS max INTO CORRESPONDING FIELDS OF fs_sflight FROM sflight WHERE carrid EQ p_carrid GROUP BY carrid connid fldate ORDER BY carrid max DESCENDING. IF sy-dbcnt < 4. APPEND fs_sflight TO t_sflight. LOG-POINT ID yh1316_check SUBKEY 'LOG_POINT' FIELDS p_carrid t_sflight fs_sflight-connid fs_sflight-fldate fs_sflight-max. WRITE: / fs_sflight-carrid, fs_sflight-connid, fs_sflight-fldate, fs_sflight-max. ENDIF. ENDSELECT. ENDIF. 

To manage Checkgroup you can create options. Variants are created both locally and for a specific user.

Below is an example of a custom option:


When creating a variant, you can select various types of objects for which checkpoints are activated.

1. Checkpoint Group
2. Program
3. Class
4. Function Group

For each Object type, individual parameters are defined for Breakpoint, Logpoint, and Assert. The options correspond to those listed earlier for the creation screen.

After creating the option, go back to checkgroup. Make sure the option is activated.



As seen above, both local and global variants are created.

Run the program whose code was provided above.

If the Assert condition is not met, a log entry is created. This log is viewed in the SAAB transaction for a specific Check Group.

Log is also returned for the LOG-POINT operator. You can also define the SUBKEY parameter for this operator. This key is used for additional sorting by certain flags (SUBKEY).

Log view is possible in two views:

1. Group / Subkey / Program / Procedure
2. Group / Program / Procedure / Subkey

Below is one of the display options:


In log it is possible to fall into the final lines of the tree, where extended data will be displayed.



If variables / tables were specified in the Assert parameters, they can be displayed. For example, for tables, you can view all the records stored in it.

In the debugger, you can view the current Checkgroup.



From the author of the translation:
The first post dedicated to this topic can be found at the link .