Understanding "Checkpoint Group"

By Richa Tripathi, Yash Technologies

The checkpoints are the type of statements introduced in the SAP Web Application Server (SAP WebAS) 6.20 that is totally dedicated to ensuring program correctness and maintainability. This improves the quality of software written in ABAP. These checks are transportable and can be transported .The transaction that takes care of these checkpoints and the place where they are maintained is SAAB.  

The Checkpoints now can be created for break-points and checkpoints and the two statements for this are  

  1. Assertions
  2. Break-points  

The one which actually does not checks the errors but is used to log the data that u want is LOG-POINT.  

To start with step by step explanation of the checkpoints we start first with the Assertions.  

Assertions syntax as per the SAP Library that is to be used in the coding is as below:

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

Assertions are used as a high quality means of problem determination in the case of code failure.  Assertions are invoked at run time. They can be made active or inactive. Assertions can be left in code when promoted to production with no impact to the code. They are only invoked if the checkpoint group is activated.

The checkpoint groups can be activated through the transaction SAAB and that is referred by ID in the programs with assert statements.

This is the transaction below SAAB where in the checkpoint group we can create the group ID.


Clicking on the create button below the Name we get to the below screen.

Now the checkgroup activation can be done with three levels  

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

In the personal level activation that checkgroup will be active for the current user only and for the User the Checkgroup will be active for that user that has been defined and same is for the Server.  

The User when clicked there you can define the Specific users for it as this…  

And similarly it can be done for specific Servers on clicking on the add Sign as below:  

As for the screen below:-  

There are three things that can be controlled with the checkgroups.  

The breakpoints can be made active or inactive. Inactive then that particular statement will be ignored and if break then in the program wherever the statement occurs the program gets into debugging.  

The Statement as per the SAP Library that goes with this in the Program is as below…  

            | [log text] }.

Ex. BREAK-POINT ID YH_check.  

Without the addition ID, the breakpoint is always active. The log text is the text which you can specify for the system log which is seen in the logs getting created.

During background processing the program execution is not interrupted. If the program reaches a breakpoint, the entry "Breakpoint reached" is written to the system protocol under which the program name and the location of the breakpoint in the program are recorded. An inactive breakpoint is ignored.

Now taking for the assertions…

Following are the ways the assertion can be used:-

  • Inactive (default): statement is ignored
  • Log: occurrence is logged
  • Abort: program terminates with runtime error ASSERTION_FAILED  

The below two options come with a pop-up having options as:-

  • Break/Log: program is interrupted and starts the debugger / like LOG mode in background, batch etc.
  • Break/Abort: program is interrupted and starts the debugger / like ABORT mode in background, batch etc.

The below two options come as this...

Assertion RULES:

  1. Exception handling should always be used to trap and handle failures. DO NOT use an assertion in the place of exceptions.
  2. Assertions should only be used on custom code rather than on standard codes.
  3. When an assertion is invoked, it should create a log entry unless and until there is a compelling reason to terminate with a run time error.

Here is a sample program where the LOG-Points and ASSERTIONS are used.

REPORT yh1316_test_checkgrp..      
** Parameters Declarations
LIKE sflight-carrid.

*data : max type i.
*Types Declarations of sflight
TYPES : BEGIN OF type_s_sflight,
TYPE sflight-carrid,
TYPE sflight-connid,
TYPE sflight-fldate,
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
TABLE OF fs_sflight.
DATA  yh1316_subkey TYPE char200.

IF p_carrid IS INITIAL.
SELECT carrid
FROM sflight
INTO fs_sflight.
WRITE: / fs_sflight-carrid,
APPEND fs_sflight TO t_sflight.
ASSERT ID yh1316_check SUBKEY    'YH1316_parameter_if_initial'
FIELDS    p_carrid
                           condition p_carrid  
eq  'LH'  .


ASSERT ID yh1316_check SUBKEY    'YH1316_1'
FIELDS    p_carrid
         CONDITION p_carrid  
EQ  'LH'  .

ASSERT ID yh1316_check SUBKEY    'YH1316_2'
FIELDS    p_carrid
       CONDITION p_carrid EQ ’LH’.

  SELECT carrid connid fldate MAX( price ) AS max
FROM sflight
WHERE carrid EQ p_carrid
GROUP BY carrid connid fldate

 IF sy-dbcnt < 4.

APPEND fs_sflight TO t_sflight.
FIELDS    p_carrid
WRITE: / fs_sflight-carrid, fs_sflight-connid, fs_sflight-fldate,


A variant is created for the Particular Checkgroup created. Variant can be created as a Local as well as at a user level. Here it is created at the User Level.

Click here to continue...

Please send us your feedback/suggestions at webmaster@SAPTechnical.COM 

HomeContribute About Us Privacy Terms Of Use • Disclaimer • SafeCompanies: Advertise on SAPTechnical.COM | Post JobContact Us  

Graphic Design by Round the Bend Wizards

footer image footer image