SAP ABAP: Understanding «Checkpoint Group» (перевод статьи c saptechnical.com)

в 9:24, , рубрики: Без рубрики
Дисклеймер

Продолжаю публиковать статьи/переводы относящиеся к нераспространённым и редко используемым техникам SAP ABAP разработки. Ключевые понятия достаточно тяжело переводить на русский язык, различные интерпретации создают путаницу, поэтому привожу их на английском языке. Данный пост частично пересекается с прошлым, но несёт в себе более детальное описание понятия Checkpoint Group

Введение в «Checkpoint Group»

Понятие и реализация «Сheckpoint Group» изначально появились в SAP Web Application Server (SAP WebAS) 6.20 и целиком относятся к области контроля правильности и возможности отслеживания переменных. При грамотном применении, технология облегчает работу по отладке и повышает качество ABAP кода.Данные проверки являются переносимыми между системами, с помощью транспортов. Управляется с помощью транзакции SAAB.

Checkpoints можно определить как для оператора BREAK-POINTS так и с помощью оператора ASSERT.

Для отображения данных в журнале группы также возможно использовать оператор LOG-POINT.

Рассмотрим оператор ASSERT
SAP описывает следующий синтаксис для данного оператора:

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.

image

После нажатия кнопки создать переходим на экран с основными параметрами Checkpoint Group.

image

Существует 3 варианта активации групп:

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

В случае Personal Activation, группа активируется только для текущего пользователя. User Level — для указанных пользователей, Server Level — для указанных серверов

Пример определения пользователей:
image

Пример определения серверов:
image

Для управления checkgroups возможно определение для каждого из операторов:
image

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

image

Принципы использования ASSERT:

  1. Не используйте ASSERT вместо exceptions.
  2. Используйте ASSERT только в пользовательском коде
  3. При вызове 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 возможно создание вариантов. Варианты создаются как локально, так и под конкретного пользователя.

Ниже приведён пример пользовательского варианта:
image

При создании варианта можно выбирать различные типы объектов для которых активируются checkpoints.

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

image

Для каждого Object type определяются индивидуальных параметров для Breakpoint, Logpoint и Assert. Опции соответствуют перечисленным ранее для экрана создания.

После создания варианта перейдём обратно в checkgroup. Убедитесь что вариант активирован.

image

Как видно выше, создаются как локальные, так и глобальные варианты.

Запустим программу код которой был предоставлен выше.

Если условие Assert не выполняется — создаётся запись в log. Данный log просматривается в транзакции SAAB для определённой Check Group.

Log также воздаётся для оператора LOG-POINT. Для этого оператора также можно определить параметр SUBKEY. Данный ключ служит для дополнительной сортировки по определённым флагам (SUBKEY).

Просмотр Log возможен в двух представлениях:

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

Ниже представлен один из вариантов отображения:
image

В log возможно провалиться в конечные строки дерева, где будут отображены расширенные данные.

image

Если в параметрах Assert были указаны переменные/таблицы, то они могут быть выведены на просмотр. Например для таблиц можно просмотреть всех хранящиеся в ней записи.

В отладчике возможен просмотр текущей Checkgroup

image

От автора перевода:
Первый пост посвященный данной теме можно прочитать по ссылке.

Автор: blick

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js