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

Original author: Richa Tripathi
  • Transfer
  • Tutorial
Disclaimer
I continue to publish articles / translations related to the uncommon and rarely used techniques of SAP ABAP development. Key concepts are hard enough to translate into Russian, various interpretations create confusion, so I quote them in English. This post partially overlaps with the past , but carries a more detailed description of the concept of Checkpoint Group


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.

image

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

image

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:
image

Example of server definition:
image

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

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


image

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:
image

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


image

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.

image

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:
image

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

image

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.

image

From the author of the translation:
The first post on this topic can be read at the link .

Also popular now: