SAP ABAP: Understanding “Checkpoint Group” (translated from saptechnical.com)

Introduction to Checkpoint Group

The concept and implementation of the Checkpoint Group originally appeared in the SAP Web Application Server (SAP WebAS) 6.20 and is entirely related to the field of accuracy control and the ability to track variables. When used correctly, the technology facilitates debugging work and improves the quality of the ABAP code. These checks are portable between systems using transports. Managed using transaction SAAB.

Checkpoints can be defined for both the BREAK-POINTS statement and the ASSERT statement.

It is also possible to use the LOG-POINT operator to display data in the group log.

Consider an ASSERT statement.
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 supplied to the productive system, without any influence on the code. Called only if the Checkpoint group is activated. An extended list of actions is provided for the operator.

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

The transaction shown below is SAAB during the group ID creation phase.



After clicking the create button, we 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 of 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. If BREAK-POINT is activated, then upon reaching this statement the debugger will be called.

The syntax for the BREAK-POINT statement is:

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

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

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

Next, consider the ASSERT statement.

There are three main uses for the operator:

• Inactive: the statement does not work
• Log: logging when using
• Abort: program interrupt 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 entered in the log

Principles of using ASSERT:

1. Do not use ASSERT instead of exceptions.
2. Use ASSERT only in custom code.
3. When ASSERT is called, log entries are generated before runtime error.

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 control Checkgroup, you can create options. Variants are created both locally and for a specific user.

The following is an example of a custom variant:


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 previously for the create screen.

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



As you can see 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 transaction SAAB for a specific Check Group.

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

Log viewing 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 on this topic can be read at the link .