[Перевод] SAP ABAP: Understanding «Checkpoint Group» (перевод статьи c saptechnical.com)
Дисклеймер Продолжаю публиковать статьи/переводы относящиеся к нераспространённым и редко используемым техникам SAP ABAP разработки. Ключевые понятия достаточно тяжело переводить на русский язык, различные интерпретации создают путаницу, поэтому привожу их на английском языке. Данный пост частично пересекается с прошлым, но несёт в себе более детальное описание понятия Checkpoint Group Введение в «Checkpoint Group» Понятие и реализация «Сheckpoint Group» изначально появились в SAP Web Application Server (SAP WebAS) 6.20 и целиком относятся к области контроля правильности и возможности отслеживания переменных. При грамотном применении, технология облегчает работу по отладке и повышает качество ABAP кода.Данные проверки являются переносимыми между системами, с помощью транспортов. Управляется с помощью транзакции SAAB.
Checkpoints можно определить как для оператора BREAK-POINTS так и с помощью оператора ASSERT.
Для отображения данных в журнале группы также возможно использовать оператор LOG-POINT.
Рассмотрим оператор ASSERTSAP описывает следующий синтаксис для данного оператора:
ASSERT [[ID group [SUBKEY subkey]] [FIELDS field1 field2 table1 table2…] CONDITION] log_exp. ASSERT является расширенной копией оператора BREAK-POINT. Оператор может использоваться в коде, поставляемым в продуктивную системы, без какого либо влияния на код. Вызывается только в случае активации Checkpoint group. Для оператора предоставляется расширенный список действий.
Checkpoint groups могут быть определены и активированы в транзакции SAAB. Созданный ID используется для определения операторов ASSERT и BREAK-POINT.
Ниже показана транзакция SAAB на этапе создания group ID.
После нажатия кнопки создать переходим на экран с основными параметрами Checkpoint Group.
Существует 3 варианта активации групп:
Personal Activation; User Level activation; Server Level Activation. В случае Personal Activation, группа активируется только для текущего пользователя. User Level — для указанных пользователей, Server Level — для указанных серверов
Пример определения пользователей: 
Пример определения серверов: 
Для управления checkgroups возможно определение для каждого из операторов: 
BREAK-POINT определяются как активные или неактивные. Неактивные будут игнорироваться. В случае если BREAK-POINT активированы, то при достижении данного оператора будет вызван отладчик.
Синтаксис оператора BREAK-POINT:
BREAK-POINT { [ID groupID] | [log text] }.
Ex. BREAK-POINT ID YH_check. В случае если опустить параметр ID, точка будет вызываться безусловно (постоянный статус активно). Текст 'log text' будет отображаться в log.
В случае работы фонового процесса, программа не прерывается на breakpoint. Если в программе будет вызван breakpoint, то в системный протокол (log) будет внесена запись «Breakpoint reached» с указанием имени программы и местоположением breakpoint. Если breakpoint не активен, то они игнорируются.
Далее рассмотрим оператор ASSERT
Существует три основных варианта использования оператора:
Inactive: оператор не отрабатывает Log: протоколирование при использовании Abort: возникает прерывание программы (runtime error ASSERTION_FAILED) В случае фонового процесса возможны два варианта исполнения:
Log: происходит протоколирование события
Abort: происходит прерывание программы и соответствующая запись вносится в log
Принципы использования ASSERT:
Не используйте ASSERT вместо exceptions. Используйте ASSERT только в пользовательском коде При вызове ASSERT создаются log записи до runtime error. Пример программы использующий LOG-POINT и 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. Для управления Checkgroup возможно создание вариантов. Варианты создаются как локально, так и под конкретного пользователя.
Ниже приведён пример пользовательского варианта: 
При создании варианта можно выбирать различные типы объектов для которых активируются checkpoints.
Checkpoint Group
Program
Class
Function Group
Для каждого Object type определяются индивидуальных параметров для Breakpoint, Logpoint и Assert. Опции соответствуют перечисленным ранее для экрана создания.
После создания варианта перейдём обратно в checkgroup. Убедитесь что вариант активирован.
Как видно выше, создаются как локальные, так и глобальные варианты.
Запустим программу код которой был предоставлен выше.
Если условие Assert не выполняется — создаётся запись в log. Данный log просматривается в транзакции SAAB для определённой Check Group.
Log также воздаётся для оператора LOG-POINT. Для этого оператора также можно определить параметр SUBKEY. Данный ключ служит для дополнительной сортировки по определённым флагам (SUBKEY).
Просмотр Log возможен в двух представлениях:
Group/Subkey/Program/Procedure
Group/Program/Procedure/Subkey
Ниже представлен один из вариантов отображения: 
В log возможно провалиться в конечные строки дерева, где будут отображены расширенные данные.
Если в параметрах Assert были указаны переменные/таблицы, то они могут быть выведены на просмотр. Например для таблиц можно просмотреть всех хранящиеся в ней записи.
В отладчике возможен просмотр текущей Checkgroup
От автора перевода: Первый пост посвященный данной теме можно прочитать по ссылке.
