В данной статье посмотрим некоторые часто встречающиеся приёмы, а также посмотрим наличие к ним стандартной документации (справка тут Auding and Logging). В данной статье будут рассмотрены прежде всего стандартные инструменты. Все код-листинги доступны на github в ZABAPFILEOS_07; видео к SLG1.

Типы логирований в SAP NetWeaver

Можно выделить 3 типа логирования (журналирования):

1) Системное: сбор информации о событиях в системе: правка под отладкой, изменение настроек, вызов HTTP и т. д.

2) Журнал приложения (application): это журнал, встроенный в приложение, куда информация пишется и читается по некоторому id‑бизнес сущности (заказ, поставка, FI‑документ и т. д.)

3) Трассировка приложений (подробный системный лог по требованию): подробный лог, который может активироваться и деактивироваться на пользователя, процесс, задание. Используется в инструментах трассировки ABAP‑кода, SQL‑запросов, RFC/HTTP‑соединений, проверок полномочий.

В первой части статьи мы рассмотрим журналы приложений, а во второй – системные логи.

Часть1. Использование журналов приложений

Рассмотрим следующие логи, используемые в бизнес-приложениях

1.       Business Application Log (транзакция SLG1 / SLG0 /  SLG2)

2.       Change documents (транзакция SCDO)

3.       SCU3 Table History Log

4.       Отображение изменений при правке таблиц через SE16N

Немного затронем такие логи

1.       IDOC-logs

2.       Output в SD/MM (NAST-based)

3.       ODATA-segw logs

4.       SXI_MONITOR XI: Message Monitoring

5.       Workflow Execution (транзакция SWI5)

Логи приложений ориентированы на сбор информации о действиях конкретного бизнес-объекта (заказа на закупку, финансового документа, или других действий пользователя, связанных с обработкой именно бизнес-данных).

Business Application Log (BAL) – SLG1 / SLG0 / SLG2

Лог приложений (Business Application Log) является наиболее универсальным и часто используемым в приложениях, однако не единственным. Имеет множество API и встроенные интерактивные функции. Документация к этому функционалу доступна по ссылке. Также этому функционалу посвящено множество статей и выделен отдельный пакет (SZAL) с демо-программами внутри SAP-системы (их маска SBAL_DEMO_*). Как видно, это хорошо задокументированный функционал, что повышает его привлекательность.

В системе и среди разработок энтузиастов существует множество обёрток (wrappers) над этим логом. Моя рекомендация: не делайте еще одну обёртку сверху (это трата времени) – лучше используйте существующие обёртки (их вполне достаточно и весьма достойные). Один из примеров IF_RECA_MESSAGE_LIST (на основе класса CF_RECA_MESSAGE_LIST); пример описан по ссылке, а также множество примеров в системе. Давайте рассмотрим несколько важных достоинств BAL-функционала. В примерах я буду ссылаться на стандартные DEMO-программы, поэтому Вы всегда можете посмотреть реализацию той или иной опции и реализовать её в своем решении.

Возможность иерархичного накапливания и представления сообщений. Лог дает возможность накапливать и отображать данные не в одной куче, а к какому-либо признаку (сущности), в которой в свою очередь могут быть под-сущности, у которой тоже под-сущности. Это позволяет не запутаться в сообщениях; кроме того, мы можем фильтровать сообщения по степени критичности, что тоже улучшает понимание логов. Для показа этой возможности запустим программу SBAL_DEMO_04_DETLEVEL в режиме ALV.

Мы можем отображать логи в виде дерева и отображать (фильтровать) сообщения только те, которые относятся к нужной «ветке-сущности». Также можем отображать лог по степени критичности сообщений.

Отображение в различных форматах.

ApplicationLog можно отобразить отдельным окном, встроенное окном, в качестве POPUP, а также custom-окно (как модальное, которое блокирует родительские окно), так и немодальное (которое не блокирует). Для просмотра этих возможностей запустим программу SBAL_DEMO_04.

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

В демо-программе SBAL_DEMO_05 и SBAL_DEMO_06 показано, как можно сохранять лог в базу данных с последующим отображением в SLG1. В программе SBAL_DEMO_06 показано, как можно сохранять доп.данные к логу.

Когда у нас сохранены к определенному сообщению данные, то появляется спец.пиктограмма, по нажатию на оной появляется доп.экран. Доп.данные сохраняются через INDX-like таблицу BAL_INDX, где ключом является номер журнала и номер сообщения внутри журнала.

Возможность расширять экран кнопками и доп.переходами с помощью callback.

В журнал встроена возможность добавить свои callback и тем, самым мы можем: добавить custom-кнопки для отображения лога, добавить свой обработчик на функцию открытия сообщения и другие callback. Возможные callback приведены в программе SBAL_CALLBACK (там же можете найти программную реализацию).

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

 В статье обозначил те, возможности, которые показались мне наиболее часто применимыми. Если хотите посмотреть и другие возможности, то откройте пакет SZAL (не SBAL, а именно SZAL) через транзакцию SE80 и посмотрите программы SBAL_DEMO*.

Удаление логов

При работе с журналом SBAL нужно иметь ввиду, что они периодически должны очищаться. Очистку также можно настроить по разным параметрам. Делается это через транзакцию SLG2. При использовании лога в приложениях у нас есть возможность указания expired time (время актуальности) той или иной записи. Задание может работать в фоновом режиме.

Пример сustom-объекта в BAL.

Рассмотрим простой пример настройки и использования лога по шагам. Пусть у нас есть некая программа, которая запрашивает данные в системе ABFOS по HTTP-протоколу (Advanced Business Flexible Operational Server – это учебный сервер на основе nginx, созданный специально для целей демонстрации, прототипирования и тестирования ERP-задач). Система SAP ERP отправляет запрос по HTTP-протоколу с параметром (для текущего примера: ОЗМ/продукт и дата) и получает прогноз продаж на этот материал. Наша задача с помощью Application Log сделать объект и залогировать request-response в понятном виде, а также отобразить это пользователю.

Создадим основной объект: пусть в нашем случае он будет называться ZABFOS– Advanced Business Flex Operational System, и подобъект: ZFORECAST (вычисления прогноза с помощью AI / ИИ). Для этого запустим транзакцию SLG0 и нажмем New Entry (Создать).

Затем, выделив строку с ZABFOS дважды, кликнем на под-папке Sub-Objects.

С помощью кнопки New Entry (Создать). В качестве подобъекта указываем ZFORECAST и текст: вычисления прогноза с помощью AI / ИИ, как на скриншоте ниже.

Для логирования будем использовать класс на базе интерфейса IF_RECA_MESSAGE_LIST (замечательная статья про это тут), а для сохранения составных данных (complex data) будем использовать таблицу BAL_INDX. Метод по сохранению complex data будет выглядеть как на код-листинге ниже, а полный код программы доступен здесь.

  METHOD save_complex.
    DATA lv_json_http_info TYPE string.
    DATA lv_lognumb_ext TYPE balognr.

    lv_lognumb_ext = mo_msg_list->md_extnumber && mv_complex_counter.
    mv_complex_counter = mv_complex_counter + 1.

    lv_json_http_info =
    /ui2/cl_json=>serialize(
      EXPORTING
        data             = iv
    ).

    EXPORT http_call_json = lv_json_http_info
       TO DATABASE bal_indx(al)
     "  ID g_lognumber. "
       ID lv_lognumb_ext.

    MESSAGE s004(zabfos_msg) WITH lv_lognumb_ext INTO sy-msgli.
    me->add_prev_msg( ).
  ENDMETHOD.

При http-вызове сохраняется запрос, код ответа, и полное сообщение ответа. Показано в код-листинге (инклюд, который содержит вызовы для ABFOS).

  METHOD _log_httpcall.

    MESSAGE s002(zabfos_msg) 
WITH ms_http_call-req_method ms_http_call-req_path
      INTO sy-msgli.
    mo_log->add_prev_msg( ).

    MESSAGE s003(zabfos_msg) WITH 
ms_http_call-resp_code ms_http_call-resp_reason
       INTO sy-msgli.
    mo_log->add_prev_msg( ).

    mo_log->save_complex( ms_http_call ).

  ENDMETHOD.

А для отображения составного типа данных мы «прикрутим» callback при просмотре сообщения. Для этого в профиле просмотра укажем функциональный модуль в качестве callback. Это нам даст возможность «перехватить» обработку при двойном клике по сообщению. Полный текст программы доступен здесь для log.

    ls_display_profile-clbk_ucbf-userexitp = ''.
    ls_display_profile-clbk_ucbf-userexitf = 'Z_AF07_SBAL_CALLBACK_BEFORE'.
    ls_display_profile-clbk_ucbf-userexitt = const_callback_function.

    ls_display_profile-clbk_ucaf-userexitp = ''.
    ls_display_profile-clbk_ucaf-userexitf = 'Z_AF07_SBAL_CALLBACK_AFTER'.
    ls_display_profile-clbk_ucaf-userexitt = const_callback_function.

В самом функциональном модуле может быть любая обработка (в зависимости от потребности и ситуации). В нашем случае мы просто читаем из INDX-таблицы http-запрос-ответ и отображаем в HTML-браузере.

FUNCTION z_af07_sbal_callback_before.
*"----------------------------------------------------------------------
*"*"Local Interface:
" CHANGING "
"     REFERENCE(C_S_USER_COMMAND_DATA) TYPE  BAL_S_CBUC"
*"----------------------------------------------------------------------
  DATA lc_complex_data_mark TYPE string VALUE 'Complex save id:'.
  DATA lv_trg_id TYPE string.
  DATA lv_log_id_indx TYPE balognr.
  DATA lv_http_info_json TYPE string.
  DATA html_xstring TYPE xstring.

  IF c_s_user_command_data-ucomm EQ '&IC1'.
    IF c_s_user_command_data-list_msgh-log_handle IS NOT INITIAL
        AND c_s_user_command_data-list_msgh-msgnumber IS NOT INITIAL.

      IF c_s_user_command_data-list_value CS lc_complex_data_mark.
        lv_trg_id = c_s_user_command_data-list_value.
        REPLACE ALL  OCCURRENCES OF lc_complex_data_mark IN lv_trg_id WITH ''.
        CONDENSE lv_trg_id NO-GAPS.
        lv_log_id_indx = lv_trg_id.

        IMPORT http_call_json = lv_http_info_json
          FROM DATABASE bal_indx(al)
            ID   lv_log_id_indx
            IGNORING STRUCTURE BOUNDARIES
            .

        TRY .
            CALL TRANSFORMATION sjson2html SOURCE XML lv_http_info_json
                                   RESULT XML html_xstring.

            cl_abap_browser=>show_html(
              html_string = cl_abap_codepage=>convert_from( html_xstring )
               ).

            c_s_user_command_data-ucomm_exec = abap_true.
          CATCH cx_root.

        ENDTRY.
      ENDIF.
    ENDIF.
  ENDIF.

ENDFUNCTION.

Обращаю внимание, что для логирования и отображения мы используем полностью концепцию и хранилище SLG1.

Теперь, когда мы щелкнем дважды по сообщению, то у нас будет открываться HTML-браузер c подробным логом (столько данных, сколько мы хотели). Пакет с демонстрационными данными (включая конфигурацию nginx, rust-реализацию ABFOS) опубликован в репозитарии на github.

При работе с логами (тем более с подробными) нужно помнить про их чистку и длительность хранения. Это делается через транзакцию SLG2. HTTP-вызовы можно также смотреть через трассировку SMICM, но об этом в части системных логов.

Change documents (транзакция SCDO)

В системе есть мощный функционал Change Document Objects (транзакция SCDO {последний символ - буква, а не цифра; от слова Objects}), который использует таблицы CDHDR и CDPOS. Этот функционал записывает изменения к полям транзакционных таблиц и зачастую привязан к стандартным транзакциям. Его удобство заключается в структурированности и чёткой технической привязкой к конкретным полям бизнес-сущностей. Для просмотра журнала изменений можно использовать программу RSSCD200 (для стандартных объектов, как правило, выведено в пункт меню).

Пример из FB02/FB03.

Мы можем посмотреть в разрезе технических данных какие поля и как изменились.

Чтобы узнать идентификатор стандартного объекта – нужно поставить точку останова в ФМ CHANGEDOCUMENT_READ_HEADERS и посмотреть переменную OBJECTCLASS. Видим, что для FI-документа объект для change documents = BELEG.

А теперь через программу RSSCD200.

Давайте посмотрим, как использовать этот способ логирования, пошагово создав свой бизнес-объект.

Создадим объект «прототип продукта», который состоит из 4х таблиц (для целей демонстрации). Одна таблица заголовочная, 3 таблицы раскрывают аспект прототипа: какие характеристики у прототипа могут быть, какие материалы нужны и какие услуги нужны для создания определенного количества прототипа. Поля описаны в таблицах ниже. Для целей демонстрации важно, что таблиц несколько и есть различные поля, которые могут обновляться в разное время. Но всё это составляет единый бизнес-объект, который мы и используем для change documents. Демо-программа для обновления составлена так, что часть данных будет меняться, часть добавляться, а часть удаляться, и какая-то часть не будет меняться. Её можно использовать как опору для своих ТЗ или разработок (если есть замечание – прошу дать знать через комментарий или issue).

Чтобы поле отражалось в change documents – на элементе данных должно быть установлено значение Change Documents. В моем custom-примере эта галочка стоит на каждом элементе данных.

Для наглядности на каждую таблицу сделаем свой тип таблицы; а если не хотите создавать на каждую таблицу отдельный тип, то AnyTabpUpdateTask поможет Вам ?. У нас будет такой набор объектов: таблица БД и на каждую БД свой тип таблицы.

Также создадим простой функциональный модуль обновления для этих таблиц баз данных.

FUNCTION z_af07_proto_upd_bustabs.
*"----------------------------------------------------------------------
*"*"Update Function Module:
*"
" Local Interface:  "
"  IMPORTING  "
"     VALUE(IT_PROTO_H) TYPE  ZTTAF07_PROTO_H OPTIONAL "
"     VALUE(IT_FEATURES) TYPE  ZTTAF07_FEATURES OPTIONAL "
"     VALUE(IT_COMPONENTS) TYPE  ZTTAF07_COMPNENTS OPTIONAL "
"     VALUE(IT_SERVICES) TYPE  ZTTAF07_SERVICES OPTIONAL "
"     VALUE(IV_MODE) TYPE  UPDKZ_D DEFAULT 'A' "
"----------------------------------------------------------------------  "
  CONSTANTS lc_all_reload TYPE updkz_d VALUE 'A'.
  CONSTANTS lc_modify TYPE updkz_d VALUE 'M'.
  CONSTANTS lc_delete TYPE updkz_d VALUE 'D'.

  FIELD-SYMBOLS <fs_prot_h> TYPE ztaf07_proto_h.

  CASE iv_mode.
    WHEN lc_all_reload.
      LOOP AT it_proto_h ASSIGNING <fs_prot_h>.
        DELETE FROM ztaf07_proto_h   WHERE proto_product_id  = <fs_prot_h>.
        DELETE FROM ztaf07_features  WHERE proto_product_id  = <fs_prot_h>.
        DELETE FROM ztaf07_compnents WHERE proto_product_id  = <fs_prot_h>.
        DELETE FROM ztaf07_services  WHERE proto_product_id  = <fs_prot_h>.
      ENDLOOP.
      MODIFY ztaf07_proto_h   FROM TABLE it_proto_h.
      MODIFY ztaf07_features  FROM TABLE it_features.
      MODIFY ztaf07_compnents FROM TABLE it_components.
      MODIFY ztaf07_services  FROM TABLE it_services.

    WHEN lc_modify.
      MODIFY ztaf07_proto_h   FROM TABLE it_proto_h.
      MODIFY ztaf07_features  FROM TABLE it_features.
      MODIFY ztaf07_compnents FROM TABLE it_components.
      MODIFY ztaf07_services  FROM TABLE it_services.
    WHEN lc_delete.
      DELETE ztaf07_proto_h   FROM TABLE it_proto_h.
      DELETE ztaf07_features  FROM TABLE it_features.
      DELETE ztaf07_compnents FROM TABLE it_components.
      DELETE ztaf07_services  FROM TABLE it_services.

    WHEN OTHERS.
  ENDCASE.

ENDFUNCTION.

Сделаем программу, которая будет заполнять таблицы начальными сгенерированными данными (доступна по ссылке). А теперь создадим CHANGE DOCUMENT для фиксации изменений в данных бизнес-сущности Прототип. Запускаем транзакцию SCDO; указываем имя объекта (в нашем случае ZPROTOTYPE) и нажимаем «Создать».

Вводим название объекта и отмечаем нужные галочки (пояснения даны в таблице).

Затем нажимаем Generate. Цель этого действия сгенерировать (или обновить) функциональный модуль, который будет обновлять CDHDR и CDPOS (лучше для этого действия выделять отдельную группу функцию; генерация отдельной группы функций – будет предложена дальше).

Затем подтверждаем ввод

Указываем нужные параметры или подтверждаем предлагаемые по умолчанию. Жмем Generate.

Система предварительно покажет, что будет сгенерировано; если всё ок – нажимаем Активировать.

После нажатия на активировать система начнет генерировать нужные объекты: группу функций, функциональные модули и типы данных для них. Чем больше таблиц – тем дольше генерация ? По завершению (если всё успешно завершено), то будет примерно подобное сообщение.

Выходим по зеленой галочке в начальное меню; теперь мы можем использовать ФМ ZPROTOTYPE_WRITE_DOCUMENT, но в режиме update task (так как мы это указали на этапе генерации; очередь будет V2 – то есть после обновления таблиц бизнес-сущности).

Посмотрим на его параметры и прокомментируем.

Глядя на эти параметры, можно подумать, что все индикаторы нужно подготавливать полностью вручную, но это не так. Есть функциональный модуль CHANGEDOCUMENT_PREPARE_TABLES, который позволяет подготовить данные для WRITE_CHANGEDOCUMENTS. Посмотрим, как можно использовать этот ФМ и что в итоге будет. Вот пример для подготовки одной таблицы.

   DATA lv_tabname_proto_h    TYPE tabname VALUE 'ZTAF07_PROTO_H'.
    DATA lv_if_equal TYPE char1.

    ms_chngdocs_tabs-s_proto-ch_ind = 'U'.
    MOVE-CORRESPONDING mt_proto_h_old TO ms_chngdocs_tabs-s_proto-old_y.
    MOVE-CORRESPONDING mt_proto_h_new TO ms_chngdocs_tabs-s_proto-new_x.

    SORT ms_chngdocs_tabs-s_proto-old_y.
    SORT ms_chngdocs_tabs-s_proto-new_x.

    " cf_reca_storable=>get_change_indicator <- можно и этот способ использовать "
    " , но prepare - уже классика и лежит в пакете SCDO "
    CALL FUNCTION 'CHANGEDOCUMENT_PREPARE_TABLES'
      EXPORTING
        tablename              = lv_tabname_proto_h
      IMPORTING
        result                 = lv_if_equal
      TABLES
        table_new              = ms_chngdocs_tabs-s_proto-new_x
        table_old              = ms_chngdocs_tabs-s_proto-old_y
      EXCEPTIONS
        nametab_error          = 1
        wrong_structure_length = 2
        OTHERS                 = 3.
    IF sy-subrc <> 0.
      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
                 WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 INTO sy-msgli.
      EXIT.
    ENDIF.

    IF lv_if_equal NE mc_tables_not_equal.
      MESSAGE s000(cl) WITH 'no changes was done'.
      CLEAR ms_chngdocs_tabs-s_proto-ch_ind.
    ENDIF.

    IF 1 = 2.
      " если ФМ вызвать нескольо раз, то будет разный номер документа изменения "
      CALL FUNCTION 'ZPROTOTYPE_WRITE_DOCUMENT'
        IN UPDATE TASK
        EXPORTING
          objectid           = ms_write_doc_hdr-v_objectid
          tcode              = ms_write_doc_hdr-v_tcode
          utime              = ms_write_doc_hdr-v_hdr_utime
          udate              = ms_write_doc_hdr-v_hdr_udate
          username           = ms_write_doc_hdr-v_hdr_username
          upd_ztaf07_proto_h = ms_chngdocs_tabs-s_proto-ch_ind
        TABLES
          icdtxt_zprototype  = ms_write_doc_hdr-t_cdtxt_tab
          xztaf07_proto_h    = ms_chngdocs_tabs-s_proto-new_x
          yztaf07_proto_h    = ms_chngdocs_tabs-s_proto-old_y.
    ENDIF.

Полный пример программы доступен по ссылке. Что же мы получаем? В таблицах CDHDR / CDPOS фиксируются данные, которые были изменены.

Мы видим, какие значения полей были изменение, добавлены, удалены; когда и кем это было сделано. Более того, у нас есть возможность табличного (SQL-совместимого) поиска по этим данным. И стоит добавить, что в нашем случае (так как мы указали отложенное обновление) – это не нагружает сам бизнес-объект. Те же самые данные мы можем посмотреть и через программу RSSCD200.

А это значит, что мы можем подключить change documents к любой custom-транзакции.

Транзакция SCU3 – Table History

Этот лог также требует доп.активации (выполняется базисом и, как правило, включена). В профиле сервера в параметре rec/client нужно установить мандант для логирования (можно перечислить все).  Справка по этому типу лога в Logging Changes to Table Data.

При создании таблицы (как правило, настроечной) можно указать отметку о необходимости логировать изменения. Проверить наличие этой функции для таблицы можно через транзакцию SE11 -> Технические параметры настройки (либо через транзакцию SE13).

Затем переходим в Технические параметры настройки

В блоке изменения данных должна стоить опция «Записать изменения данных в журнал», чтобы происходило логирование

Тогда мы сможем просмотреть изменения через транзакцию SCU3 следующим способом. Запускаем SCU3 и нажимаем Анализ журналов.

Затем указываем нужную таблицу (или несколько); отмечаем галочку просмотр ALV Grid для более удобного просмотра и запускаем.

В результате увидим информацию о пользователе, дате, времени, ключе таблицы и значения, привязанные к этому ключу. Это довольно информативно и наглядно.

Данные по логированию для этой транзакции уже хранятся в неструктурированном виде в таблице, а не в файлах, а именно в таблице DBTABLOG (пожалуй тот редкий случай, когда справка чуть ошибается ?, в справке указано DBTABPRT ).

 Вывод: эти подходы (application log (SLG1), change documents (SCDO) и table changes (SCU3)) к логированию позволяют получить информацию об изменениях в стандартных объектах, а также разрабатывать свои приложения, логируя нужную информацию и вовремя её архивируя. Использование этих инструментов сократит временные затраты на разработку, повысит понимание приложений и разбор на случай «что-то пошло не так».

Отображение изменений при правке данных через SE16N

Иногда данные в таблице могут быть исправлены через транзакцию SE16N. Подобные изменения также можно посмотреть через программу RKSE16N_CD_DISPLAY (она же встроена в SE16N, что неудивительно).

В транзакции SE16N переходим по пути Extras -> Display Change Documents (Дополнительная информация -> Просмотр документов изменений).

Указываем нужную таблицу(ы) и запускаем просмотр (если требуется – ограничиваем также по дате).

Сначала у нас будет срез в формате: таблица-пользователь. Сделав по нему double-click (двойной клик) – получим подробную информацию: что было вставлено/изменено/удалено и когда.

А теперь посмотрим подходы к логированию, которые специфичны для конкретного типа бизнес-приложения.

IDOC-list (WE02)

IDoc – это документ для обмена между системами. Его набор полей зависит от определенного типа сообщений. Здесь не будем расписывать детали про IDOC. А скажем, что сообщения, которые возникают в процессе обработки IDOC могут быть просмотрены в транзакции WE02.

Открыв конкретный idoc, мы можем видеть сообщения, связанные с обработкой idoc. Для IDOC важность имеет статус. На основе статуса можно принимать решения о повторной обработке, или корректировке данных со стороны внешней системы.

Каждый тип сообщения IDOC обрабатывается каким-то функциональным модулем, в параметрах у которого есть IDOC_STATUS. И именно в эту таблицу нужно добавлять то или иное сообщение, если мы хотим, чтобы оно отобразилось в журнале обработке IDOC.

Подробнее об администрировании и разработке IDOC (если нужно) – можно почитать по ссылке. Для себя же делаем вывод, что сам по себе журнал нужен не столько для детального понимания, как и что происходило, а скорее для фиксации ошибки (если она есть) и понимании «на чем споткнулась» обработка.

Output in Logistics (NAST-based protocol)

В логистике (SD/MM) с IDOC и пост-обработчиками связан функционал выходных документов. Обработка зачастую происходит в фоне или в отдельном процессе. И для целей логирования в стандарте предполагается своё отдельное логирования.

С точки зрения пользователя для его просмотра можно использовать интерфейс выходных документов. Выделяем нужный выходной документ и смотрим «Processing Log».

В сам интерфейс выходных документов можно попасть по-разному (зависит от исходного документа). Для сбытового заказа VA03->[указываем номер заказа]->Открываем заказ через ENTER и из обзорного экрана переходим по пути: Extras -> Output -> Header -> Output.

С точки зрения разработчика работа с логом ведётся при помощи функциональных модулей группы функции WMCP (для каждого ФМа в системе можно найти примеры с использованием).

Output (выходные документы) предназначены в том числе для печати, отправке по почте и в электронном виде документов, поэтому справка к этому функционалу находится в Printing Guide.

Работа с логами в OData-сервисах

OData-сервисы имеют разделение на два вида логов: логи бизнес-приложений и системные логи (анализ ошибок).

Для анализа ошибок: используют транзакции /IWFND/ERROR_LOG (SAP Gateway Error Log) и /IWBEP/ERROR_LOG (SAP GW Backend Error Log). Их принцип работы одинаков с точки зрения пользовательского интерфейса, но логируют они сообщения, которые возникают в разных местах (Gateway vs Backend), поэтому две транзакции и есть. А также есть транзакция для Application Log Viewer /IWFND/APPS_LOG (SAP Gateway Application Log Viewer).

В транзакции /IWFND/ERROR_LOG (SAP Gateway Error Log) имеются следующие полезные возможности:

1)      Выборка сообщений с учетом различных параметров (время, тип сообщения и т.д.)

2)      Возможность повтора сообщений на тех параметрах, которые пришли в сервис. Когда случается Exception в рамках работы сервиса, то параметры его сохраняются, что облегчает последующий разбор.

В тестовом окружении мы можем увидеть параметры и, если нужно, скорректировать их.

Далее мы можем тестировать сервис стандартными средствами OData (видео и прошедший вебинар на этот счет).

3)      Переход в Application Log. OData-сервисы по умолчанию используют SLG1, в качестве стандартного лога для сообщений. И тогда мы можем использовать функционал BAL для работы с сообщениями.

С точки зрения разработчика, чтобы сообщения добавлялись в этот журнал, нужно их отправлять через Exception через специальный объект.

  METHOD varheadset_update_entity.
" *TRY. "
"*CALL METHOD SUPER->VARHEADSET_UPDATE_ENTITY "
"*  EXPORTING "
"*    IV_ENTITY_NAME          = "
"*    IV_ENTITY_SET_NAME      = "
"*    IV_SOURCE_NAME          = "
"*    IT_KEY_TAB              = "
"**    io_tech_request_context = "
"*    IT_NAVIGATION_PATH      = "
"**    io_data_provider        = "
"**  IMPORTING "
"**    er_entity               = "
"*    . "
"** CATCH /iwbep/cx_mgw_busi_exception . "
"** CATCH /iwbep/cx_mgw_tech_exception . "
"**ENDTRY. "

    DATA lo_msg_cont TYPE REF TO /iwbep/if_message_container.

    DATA ls_srv_in TYPE zcl_zweb_abap_demo1_mpc=>ts_varhead.

    io_data_provider->read_entry_data( IMPORTING es_data = ls_srv_in ).
    lo_msg_cont = mo_context->get_message_container( ).

    """"""""""""""""""""""""""
    IF ls_srv_in-num_of_files IS INITIAL.

      MESSAGE s000(cl) WITH 'Поле NUM_OF_FILES является обязательным' INTO sy-msgli.

      lo_msg_cont->add_message(
        EXPORTING
          iv_msg_type               = sy-msgty
          iv_msg_id                 = sy-msgid
          iv_msg_number             = sy-msgno
          iv_msg_text               = CONV #( sy-msgli )
          iv_msg_v1                 = sy-msgv1
          iv_msg_v2                 = sy-msgv2
          iv_msg_v3                 = sy-msgv3
          iv_msg_v4                 = sy-msgv4
      ).

      MESSAGE s000(cl) WITH 'и еще одно сообещние в лог' INTO sy-msgli.

      lo_msg_cont->add_message(
        EXPORTING
          iv_msg_type               = sy-msgty
          iv_msg_id                 = sy-msgid
          iv_msg_number             = sy-msgno
          iv_msg_text               = CONV #( sy-msgli )
          iv_msg_v1                 = sy-msgv1
          iv_msg_v2                 = sy-msgv2
          iv_msg_v3                 = sy-msgv3
          iv_msg_v4                 = sy-msgv4
      ).

      RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
        EXPORTING
          message_container = lo_msg_cont
          http_status_code  = /iwbep/cx_mgw_busi_exception=>gcs_http_status_codes-not_acceptable.
    ENDIF.
    MOVE-CORRESPONDING ls_srv_in TO er_entity.
  ENDMETHOD.

В журнал приложений OData мы можем попасть и через транзакцию /IWFND/APPS_LOG (SAP Gateway Application Log Viewer). В справке также есть информация по трассировке и логам в SAP Gateway. Если обратим внимание, то функционал OData-логов содержит переходы и в другие инструменты по логированию, как бы намекая, что для эффективного анализа ситуации нужно использовать все виды логов (собственно, про это и текущая заметка ?).

SXI_MONITOR (интеграционное взаимодействие через PI/XI)

При интеграционном взаимодействии через шину XI/PI для логирования запросов и ответов (как синхронных, так и асинхронных) используется транзакцию SXI_MONITOR. Она позволяет показать тело сообщения (сами данные), а также доп.информацию о интеграционном взаимодействии (время, система получатель/отправитель).  Подробнее про эту транзакцию, а также требуемых полномочиях можно почитать в справке ( HelpPortal: SAP NetWeaver -> Integration Engine -> Monitor for Processed XML Messages ). Полезно иметь ввиду транзакцию-меню: SXMB_MONI.

Workflow Logs (транзакция SWI5)

Workflow – это еще один функционал, который использует свои внутренние логи (связано с историческими причинами). Доступны эти логи через транзакции SWI5. Подробнее об этом можно почитать в справке по ссылке. Можно посмотреть незавершённые WF-задачи или завершенные на конкретный день в разрезе агента (исполнителя задачи).

Мы рассмотрели основные логи приложений, но не все. Во многих бизнес-решениях и интеграциях могут использоваться свои подходы к логам, но полезно понимать, что могут уже стандартные логи, чтобы не тратить время на переизобретение в рамках одной системы. Кроме того, в системе APO, EWM, CRM, SRM есть свои специфичные инструменты для мониторинга и логирования.

Часть2. Использование системных логов

Рассмотрим следующие системные логи (это не полный список, но полезный):

1.       System Log (транзакция SM21)

2.       Audit Log (транзакция RSAU_READ_LOG)

3.       ST22 ABAP Runtime Error

4.       Лог при работе с транспортной системой

5.       Изменение основных данных и полномочий пользователя

 

В системные логи консультанту/разработчику по прикладному модулю полезно периодически поглядывать и анализировать их. Системные журналы конфигурируются, как правило, на этапе запуска системы и НЕ предполагают никакой бизнес-информации, а только системную. Однако системная информация, может помочь в анализе как улучшить бизнес-приложение.

Транзакция SM21 – System Log

Логирует: Системные ошибки, некорректные попытки подключения, изменения переменных под отладкой, завершение сессий через SM51, «красные» и «желтые» ответы от базы данных и некоторые другие события системы. Сам журнал предполагает определенную конфигурацию (подробнее об этом в справке ).

Журнал в основном служит для контроля системы со стороны базиса, однако бизнес-консультанту тоже периодически приходится поглядывать в этот журнал (как и во все системные). Если полномочий на этот сист.журнал нет, то стоит знать, что он существует (или даже запросить полномочия хотя бы на время – в зависимости от исполняемых обязанностей на проекте).

Отчет запускается через транзакцию SM21 (один из путей: SAP Menu -> Tools -> Administration -> Monitor -> System Log (SM21), в этой же папке и другие полезные системные логи-журналы).

Про принцип работы отчета, важно знать:

1)      на каждом application server есть свой файл логирования (то есть этот отчет собирает информацию именно в определенный файл). Целевой файл настраивает базис (подробнее в справке по Monitoring and Administration Tool, а также в Syslog Monitor).
Транзакция SM51 – это список имеющихся серверов приложений с возможностью переключаться между ними. Транзакция SM50 – список всех процессов на текущем сервере. SM66 – полный перечень процессов по всем application server.

2)      запись в этот файл делается по принципу ring buffer (распространённый перевод: кольцевой буфер) – достигнув конца файла, система начнет писать в файл сначала. Таким образом: размер файла такой, какой выделен изначально.

3)      каждую запись в файле сопровождает метка времени, поэтому на экране в SM21 данные отображаются в хронологическом порядке (хотя ALV позволяет задать любой фильтр и сортировку)

С учётом этих пунктов – заполняем селекционный экран: указываем период времени для анализа, сервер (или несколько), и другие параметры; затем запускаем по F8 / Выполнить.

Примеры отображений показы на скриншотах.

Частое появление красных сообщений в этом журнале – не очень хороший знак.

Подробнее о журнале (конфигурировании, администрировании) в справке The System Log, а также в статьях Вячеслава Шиболова, а также в других блогах.

Транзакция RSAU_READ_LOG – Security Audit Log

Журнал проверки безопасности собирает более детальные события о действиях системы с целью аудирования. Информация об аудите собирается в отдельные файлы (они не имеют отношения к SM21). В журнале могут отображаться: успешные/неуспешные подключения в диалоге, через RFC/HTTP, запуски транзакций (как успешные, так и неуспешные), изменения основных данных пользователя и другие события, обозначения в справке к Security Audit Log.

Журнал отображает множество информации в том числе имя ПК (или адрес), с которого было совершенно событие.

Этот журнал требует отдельной активации и выделения пространства для файлов логирования. Журнал можно активировать временно через транзакцию SM19, а также на постоянной основе (параметр rsau/enable=1). Удаление логов выполняется через транзакцию SM18.

Транзакция ST22 – ABAP Dump Analysis / Runtime Error Log

Транзакция ST22 представляет собой отчет по динамическим ошибкам, возникшим в системе. Количество динамических ошибок является одним из показателей (количество дампов), которые можно применять к оценке стабильности системы. Справка sap help ABAP Dump Analysis (ST22).

Перечень содержит информацию по всем пользователям системы. Таблица SNAP (а именно в ней хранятся данные по дампам) обычно очищается через каждый период времени (настраивается базисом); но если Вам нужно сохранить дамп, и чтобы он не исчез из системы, то нужно нажать кнопку «Keep/Release»

Возникновение дампа в системе, может быть, по разным причинам и исправление дампа тоже может быть различное. При двойном щелчке на дампе – мы можем увидеть подробную информацию о нем. Мы можем увидеть краткое описание, а также перейти к место кода, где случилась проблема.

И мы можем посмотреть значения переменных, в момент дампа, а также стэк вызовов.

Популярные дампы и пояснения к ним в таблице

Как было сказано при анализе дампов обращать внимание на тип runtime error, стэк, актуальность дампа, корректность подаваемых данных, а также использовать справку и SAP-ноты при анализе (например, 1699048 (Unexpected short dumps in ST22), 2200714 (Dumps in ST22 show ?????? in ALV list))

Журнал при работе с транспортной системой.

При работе с переносами изменений в продуктив с помощью транспортных запросов полезно иметь ввиду соответствующие логи. Они пишутся в файл и могут отображаться по-разному. Список объектов записывается в таблицы: E070, E071 и E071K. Один из способов – это через транзакцию SE09: поставить курсор на нужный транспортный запрос и нажать логи. Подробнее в справке Logging in Transport System.

Изменение полномочий пользователя (основных данных пользователя).

При анализе возможных проблем с полномочиями полезно иметь ввиду журнал изменения полномочий пользователя. Запускаем транзакцию SU01D или SU01. Переходим по пути: Information -> Change Documents for Users.

Указываем галочками те атрибуты, по которым нужно проконтролировать изменения: основные данные, роли и т.д. (можно отметить всё, но ждать долго).

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

Другие системные логи

Журналы выше – это неисчерпывающий список системных журналов. Существуют и другие системные логи, в том числе специально разработанные для какой-либо отрасли/компании. Поэтому периодически полезно проверять появление новых логов: в документации (а также в alerting), в нотах или другими способами. Кроме того, в статье мы не затронули тему alerting (оперативное оповещение при наступлении какого-либо события), так как это отдельная тема (одна из документаций).

Использование трассировок

Трассировки от обычного логирования отличаются тем, что включаются на какой-то период времени и направлены на фиксирование каких-то конкретных действий. То есть они работают не принципу «включено всегда или включено по исполнению», а покрывают какой-то ограниченный период наблюдения и конкретный набор информации (метрик).  В этой части мы рассмотрим 2 транзакции, а некоторые другие просто обозначим с указанием лишь их возможностей. Цель и приёмы у каждого инструмента трассировки различные.

STAD – statistics display

С помощью транзакции STAD мы можем посмотреть статистику системы за последние несколько часов (по умолчанию 48). В SAP NetWeaver каждый час записывается файл статистики, а через каждый 48 часов он удаляется. Что представляет из себя файл статистики? Представляет из себя перечень программ, и пользователей, которые их запускали, с временем работы; таким образом, файл статистики показывает, кто что запускал и как это что-то отработало. Файл статистики не покажет точное место кода, а только представит общую картину. Этот инструмент – прежде всего для анализа загрузки системы; то есть мы можем заранее найти узкие места системы, не дожидаясь того, как возникнет ситуация. Кроме того, мы можем быстро посмотреть, что именно запускал пользователь и как долго «это что-то» выполнялось (потенциально, мы можем сделать вывод: что требует улучшения, чтобы конкретный пользователь получал более быстрый отклик системы).

В разделе Display Mode мы укажем опцию группировки (сделаем все записи, сортированные по времени). В статистике мы найдем информацию о запускаемых транзакциях, пользователе, времени отклика.

Двойным кликом на строчке – получаем более детальную информацию. Эта информацию разбита на 4 блока: Время выполнения рабочего процесса (Time), DB (время на работу с базой данных), Task/memory (затраченное время) и информация по клиенте. В случае, если были RFC вызовы – будет информация по ним. Для нас важно обратить внимание на Time – характеризует работу ABAP-кода, и DB – характеризует время по выборке из базы данных.

В Wait смотрим на показатель Processing time – это то, сколько времени программа обрабатывалась на Application Server.

В блоке DB – смотрим на все столбцы и в особенности на Avg.time / row (ms) – от каждой базы данных можно требовать своего результата. На современных Oracle и HANA – менее 1 ms – Это норма; если продолжительнее, то стоит задуматься. Для старых БД – менее 10 ms – это норма.

Данные по статистике хранятся в системе по умолчанию 48 часов; время хранения может изменить базис. Система каждый час накапливает данные в файл и сохраняет его; при достижении конечного значения, система не создает новый файл, а «перезатирает» имеющийся (ring buffer). Чтобы не плодить количество файлов, можно поставить программу RSSTAT26 в фоновое выполнение и анализировать результат по данным фонового задания. Полезные заметки на эту тему:  read_stad, inside_stad. Ноты: 579462 - Runtime parameter of the statistics collection,  552845 - FAQ: RFC Statistics in Transactions ST03/ST03N and STAD, 8963 - Definition of SAP response time/processing time/CPU time.

SMICM – Internet Communication Monitor (ICM)

Транзакция SMICM даёт множество возможностей и инструментов, но мы рассмотрим включение трассировки для логирования HTTP-запросов. Для включения трассировки запускаем транзакцию SMICM и идем по пути Goto -> Trace Level -> Set.

На время запуска можем указать самый подробный способ трассировки

Затем запускаем HTTP-вызов. В нашем случае это будет интеграция с сервером ABFOS по протоколу HTTP. После прогона HTTP-вызовов, нам нужно посмотреть файл трассировки (путь: Goto -> Trace File -> Display All ( или Display End, чтобы посмотреть окончание файла)).

Затем по поиску через Ctrl + F находим примерные строки и уже точно видим, что, как и куда отправлялось.

После завершения трассировки – не забываем устанавливать уровень трассировки в наименее подробный уровень.

Прочие инструменты трассировки

OData-трассировка инструмент используемый в SAP Gateway. Транзакция /IWFND/TRACES (SAP Gateway Traces). Позволяет фиксировать входящие запросы и ответы, делать трассировку производительности запросов, можно активировать трассировку для любого пользователя (при наличии полномочий), позволяет выполнять повтор запросов.

Транзакции ST12 и SAT – два мощнейших инструмента, позволяющие быстро искать узкие места в программе, контролировать стэк, размер данных, скорость доступа. Используются для анализа и оптимизации программ. Позволяют делать трассировку фоновых процессов, update-процессов, трассировку по событию, дают возможность проводить «top-down analysis». Могут запускаться как из специальных транзакций, так и из инструмента отладки.

Трассировка полномочий ST01 – используется, прежде всего, для анализа нехватки полномочий для какого-либо действия в течение исполнения процесса от любого пользователя. Материал1 и материал2.

ST03N – Workload Monitor – инструмент, предоставляющий информацию о загрузке системе: что, когда, кем, сколько раз запускалось/вызывалось и сколько вычислительных ресурсов было потрачено. Мощный статистический инструмент – справка доступна по ссылка.

SFP trace utility  - трассировка печатных форм Adobe Document Services. Позволяет получить составные части формируемого pdf-документа.

Выводы

Мы видим, что имеются различные типы логов и подходы к логам. При создании/корректировке приложений наличие удобочитаемых логов, которые не загружают систему, даст Вам «почёт и уважение, а также сэкономит время ?». Вот для этого мы и рассмотрели стандартные подходы к логированию. Если какой-то журнал остался вне рамок статьи, то прошу прокомментировать/дополнить.