В данной статье посмотрим некоторые часто встречающиеся приёмы, а также посмотрим наличие к ним стандартной документации (справка тут Auding and Logging). В данной статье будут рассмотрены прежде всего стандартные инструменты. Все код-листинги доступны на github в ZABAPFILEOS_07.
Типы логирований в 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-примере эта галочка стоит на каждом элементе данных.
|
Заголовок прототипа продукта (Prototype Header ) ZTAF07_PROTO_H |
||
|
Поле |
Комментарий |
Техн.тип |
|
PROTO_PRODUCT_ID |
Id-прототипа |
CHAR(10) |
|
PROTO_PRODUCT_TXT |
Краткое текстовое описание прототипа |
CHAR(80) |
|
BEGIN_WORK_DATE |
Дата начала работ на прототипом (самая ранняя) |
DATS(8) |
|
ANALYSIS_DATE |
Дата представления |
DATS(8) |
|
ESTIMATE_DATE |
Дата оценки Ближайшая дата, когда оценивается затраты на прототип (цена-затраты-качество) |
DATS(8) |
|
MARKET_DATE |
Дата выхода на рынок Возможная ближайшая дата вывода прототипа на рынок (хотя на фокус-группу); показ с целью продажи внешним потребителям |
DATS(8) |
|
RESPONSIBLE_TEAM |
Ответственная команда |
CHAR(20) |
|
PRODUCT_OWNER |
Ответственный руководитель |
CHAR(20) |
|
QA_TEAM |
Команда Контроля качества |
CHAR(20) |
|
TARGET_CONSUMER_GRP |
Целевая группа пользователей/потребителей |
CHAR(25) |
|
Характеристики продукта (Prototype Features (Plan/Actual)): ZTAF07_FEATURES |
||
|
Поле |
Комментарий |
Техн.тип |
|
PROTO_PRODUCT_ID |
Id-прототипа, ключевое поле |
CHAR(10) |
|
PROTO_FEATURE |
Характеристика/свойство прототипа, ключевое поле |
CHAR(30) |
|
PLAN_FEATURE_VAL |
Плановое значение характеристики |
CHAR(10) |
|
ACT_FEATURE_VAL |
Фактическое значение характеристики (на дату анализа) |
CHAR(10) |
|
COMPLEXITY_LVL |
Сложность достижения целевого значения характеристики (от 1 до 100) |
INT1(3) |
|
CONSUMER_YES_LVL |
Вероятность покупки потребителем, когда это свойство с целевым значением есть (от 1 до 100) |
INT1(3) |
|
CONSUMER_NO_LVL |
Вероятность отказа от покупки, если этого свойства с этим значением нет (от 1 до 100) |
INT1(3) |
|
Компоненты, необходимые для продукта (Prototype Material Components): ZTAF07_COMPNENTS |
||
|
Поле |
Комментарий |
Техн.тип |
|
PROTO_PRODUCT_ID |
Id-прототипа, ключевое поле |
CHAR(10) |
|
COMP_POSNR |
Номер позиции, ключевое поле |
NUMC(6) |
|
PROTO_QUAN |
Результирующее количество прототипируемого продукта |
QUAN(15.3) |
|
PROTO_UOM |
Единица измерения продукта-прототипа |
UNIT(3) |
|
COMPONENT |
Обозначение компонента (~matnr + free text) |
CHAR(20) |
|
COMPONENT_QUAN_UOM |
Единица измерения компонента |
UNIT(3) |
|
COMPONENT_QUAN_PLAN |
Плановая потребность в компоненте для результирующего количества |
QUAN(15.3) |
|
COMPONENT_QUAN_ACT |
Фактическая потребность в компоненте для результирующего количества |
QUAN(15.3) |
|
COMP_UNIT_PRICE_MIN |
Минимальная рыночная цена на компонент |
CURR(15.2) |
|
COMP_UNIT_PRICE_MAX |
Максимальная рыночная цена на компонент |
CURR(15.2) |
|
COMP_UNIT_PRICE_AVG |
Средняя рыночная цена на компонент |
CURR(15.2) |
|
COMP_WAERS |
Валюта цены компонента |
CUKY(5) |
|
Услуги, необходимые для прототипа продукта (Prototype Services): ZTAF07_SERVICES |
||
|
Поле |
Комментарий |
Техн.тип |
|
PROTO_PRODUCT_ID |
Id-прототипа, ключевое поле |
CHAR(10) |
|
SERV_POSNR |
Номер позиции, ключевое поле |
NUMC(6) |
|
PROTO_QUAN |
Результирующее количество прототипируемого продукта |
QUAN(15.3) |
|
PROTO_UOM |
Единица измерения продукта-прототипа |
UNIT(3) |
|
SERVICE |
Обозначение услуги |
INT4(10) |
|
SERVICE_HOURS_PLAN |
Плановая продолжительность услуги в часах |
INT4(10) |
|
SERVICE_HOURS_ACT |
Фактическая продолжительность услуги в часах |
INT4(10) |
|
SERVICE_AMOUNT_PLAN |
Плановая стоимость за услугу |
CURR(15.2) |
|
SERVICE_AMOUNT_ACT |
Фактическая стоимость за услугу |
CURR(15.2) |
|
SERVICE_WAERS |
Валюта стоимости услуги |
CUKY(5) |
Для наглядности на каждую таблицу сделаем свой тип таблицы; а если не хотите создавать на каждую таблицу отдельный тип, то 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) и нажимаем «Создать».
Вводим название объекта и отмечаем нужные галочки (пояснения даны в таблице).
|
Int.Table |
Возможность передавать множественные значения (то есть во внутренней таблице). |
|
Delete Documentation |
Логирование удаления записей. Система будет анализировать и удаление в том числе.
Если отмечена эта галочка Single Field, то значит удаление будет отображено по каждому полю. Если галочки не будет, то система в логах отобразит факт удаления записи по ключу, а значения полей отображать не будет. Чем детальнее записывается, тем быстрее растет база. |
|
Insert / Single Field |
Логирование вставки записи: либо по каждому полю (если галка отмечена), либо указание факта вставки с указанием только ключа. |
Затем нажимаем Generate. Цель этого действия сгенерировать (или обновить) функциональный модуль, который будет обновлять CDHDR и CDPOS (лучше для этого действия выделять отдельную группу функцию; генерация отдельной группы функций – будет предложена дальше).
Затем подтверждаем ввод
Указываем нужные параметры или подтверждаем предлагаемые по умолчанию. Жмем Generate.
Система предварительно покажет, что будет сгенерировано; если всё ок – нажимаем Активировать.
После нажатия на активировать система начнет генерировать нужные объекты: группу функций, функциональные модули и типы данных для них. Чем больше таблиц – тем дольше генерация 😊 По завершению (если всё успешно завершено), то будет примерно подобное сообщение.
Выходим по зеленой галочке в начальное меню; теперь мы можем использовать ФМ ZPROTOTYPE_WRITE_DOCUMENT, но в режиме update task (так как мы это указали на этапе генерации; очередь будет V2 – то есть после обновления таблиц бизнес-сущности).
Посмотрим на его параметры и прокомментируем.
|
Import OBJECTID |
Id-объекта, которые мы сохраняем. В нашем случае = ZPROTOTYPE |
|
TCODE |
Код транзакции: мы можем указать любой код. И этот код будет записан в CDHDR и CDPOS |
|
UTIME |
Время записи. Как правило, до процедуры сохранения можно вызвать оператор GET TIME. |
|
UDATE |
Дата записи. |
|
USERNAME |
Имя пользователя, от которого будут записаны данные. Не обязательно должен совпадать с тем пользователем, под кем выполняется программа. |
|
… |
|
|
UPD_ZTAF07_COMPNENTS |
Признак, что та или иная таблица объекта будет обновляться. Если данные в таблице как-то изменены, то нужно поставить букву ‘U’; а если нет – оставить поле пустым (SPACE). |
|
UPD_ZTAF07_FEATURES |
|
|
UPD_ZTAF07_PROTO_H |
|
|
UPD_ZTAF07_SERVICES |
|
|
UPD_* |
|
|
Tables |
|
|
XZTAF07_COMPNENTS |
X-данные (новые данные, иногда N_*): внутренняя таблица или структура с новыми данными (для обновления или вставки). В этой структуре должно быть поле KZ, в котором проставлен индикатор обновления. |
|
YZTAF07_COMPNENTS |
Y-данные (старые данные, иногда O_*): внутренняя таблица или структура с данными, которые были ДО запуска программы. Предполагается, что перед началом работы программы мы либо прочитали данные из таблицы, либо перед сохранением в БД прочитали, что было сохранено в БД до наших изменений. Y-данные также должны содержать KZ-поле, в котором стоит индикатор обновления: I-insert, D-delete, U-update. |
|
XZTAF07_FEATURES |
X-данные для целевой таблицы базы данных ZTAF07_FEATURES |
|
YZTAF07_FEATURES |
Y-данные для целевой таблицы базы данных ZTAF07_FEATURES |
|
XZTAF07_PROTO_H |
X-данные для целевой таблицы базы данных ZTAF07_PROTO_H |
|
YZTAF07_PROTO_H |
Y-данные для целевой таблицы базы данных ZTAF07_PROTO_H |
|
XZTAF07_SERVICES |
X-данные для целевой таблицы базы данных ZTAF07_SERVICES |
|
YZTAF07_SERVICES |
Y-данные для целевой таблицы базы данных ZTAF07_SERVICES |
Глядя на эти параметры, можно подумать, что все индикаторы нужно подготавливать полностью вручную, но это не так. Есть функциональный модуль 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»
Возникновение дампа в системе, может быть, по разным причинам и исправление дампа тоже может быть различное. При двойном щелчке на дампе – мы можем увидеть подробную информацию о нем. Мы можем увидеть краткое описание, а также перейти к место кода, где случилась проблема.
И мы можем посмотреть значения переменных, в момент дампа, а также стэк вызовов.
Популярные дампы и пояснения к ним в таблице
|
SYSTEM_NO_ROLL TSV_TNEW_PAGE_ALLOC_FAILED SQL_CAUGHT_RABAX |
Нехватка внутренней памяти: либо нет проверка на for all entries в выборках на больших таблицах (Типа VBRK/VBRP, LIKP, LIPS и т.д.), либо программа просто неоптимально выбирает (либо вообще без ограничений).
Если в описании дампа идет описание о программе ??????? (символы вопросики) – это может быть SUBMIT на пустой программе. |
|
SYNTAX_ERROR |
Синтаксическая ошибка в коде. Классический случай 😊 , когда что-то забыли перенести; перенесли частично; или перенесли то, что не стоит переносить. Например, в программе идет обращение к элементу структуры, которого не существует. |
|
CONVERT_NO_NUMBER |
В программе идет попытка преобразовать нечисло к числовому типу данных |
|
DYNPRO_MSG_IN_HELP |
Программа выдает сообщение такого типа, что не соответствует месту в программе. Например, Warning в модулях обновления. Исправляется через корректировку кода (либо силами внутренней поддержки, либо SAP-поддержки). |
|
GETWA_NOT_ASSIGNED |
Обращение к неприсвоенной переменной (field symbol). Если это код клиента, то нужно исправлять код и/или не использовать программу с таким набором данных, что он приводит к такой ситуации. Если это стандартная программа, то нужно проанализировать данные – все ли правильно и корректно? «Нет ли попытки продать несуществующий материал?» «Или провести документ в неизвестной валюте?». Таким образом, дамп может быть связан либо с ошибочными данными, либо с кодом, который явно в дампе не фигурирует, но влияет на данные. Для стандартных программ нужно посмотреть ноты и/или выставить сообщение в SAP SUPPORT. |
|
CALL_FUNCTION_CONFLICT_LENG |
Вызов ФМ с неправильными параметрами (либо с отсутствующими, либо несоответствующими по типу). |
|
MESSAGE_TYPE_X / RAISE_EXCEPTION |
Возникла исключительная необрабатываемая ситуация. Если программа стандартная – то нужно искать ноту или выставлять сообщение в SAP. При этом нужно иметь ввиду, что возникшая ситуация не обрабатывается стандартом и значит, возможно, дело в том, что бизнес данные так сложились, что для SAP ERP это неприемлемо. Например, в таблице вариантов для конфигурации (транзакция CU60 неприемлемо ведение дублированных значений) (это логично, так как в случае дублирования вариант не может быть однозначно определен), однако в самой транзакции проверки на это нет; а вот при конфигурации сбытового заказа может возникнуть дамп. Для стандартных программе нужно посмотреть ноты и/или выставить сообщение в SAP SUPPORT. |
|
CALL_FUNCTION_NOT_REMOTE |
Вызов ФМ для RFC-обновления (BACKGROUND task), который не предназначен для таких операций. |
|
DYNPRO_FIELD_CONVERSION |
Попытка показать отрицательные значения в полях экрана без знака. |
|
LOAD_PROGRAM_NOT_FOUND |
Попытка вызвать несуществующую программу. Возможно, через SUBMIT. |
|
LOAD_PROGRAM_MISMATCH |
Идет перенос программы (или связанных технических объектов с программой). При этом в процессе переноса (генерации) кто-то работал в этой программе. По этой причине запрещено переносить юзер-экзиты и другие расширения в течение рабочего дня. (только в исключительных ситуациях). |
Как было сказано при анализе дампов обращать внимание на тип 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-документа.
Выводы
Мы видим, что имеются различные типы логов и подходы к логам. При создании/корректировке приложений наличие удобочитаемых логов, которые не загружают систему, даст Вам «почёт и уважение, а также сэкономит время 😊». Вот для этого мы и рассмотрели стандартные подходы к логированию. Если какой-то журнал остался вне рамок статьи, то прошу прокомментировать/дополнить.
ссылка на оригинал статьи https://habr.com/ru/articles/825214/
Добавить комментарий