Индивидуальный логгер

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

Модель данных логгера

Для этого начнем с создания модели в базе данных. Нам потребуется весьма простая модель с тремя необходимыми полями:

• info (text) - общая информация о событии
• user (integer) - ID пользователя
• access (array string) - группы пользователя (их может быть несколько)

Бизнес процесс логгера

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

Для получения информации о пользователе используется блок Auth: Get current user. Обратите внимание на то, что он сможет представить результат в виде модели пользователя только в том случае, если в эндпойнте, который инициировал его выполнение, был включен Middleware Token Auth.

Используем Expand User, чтобы развернуть полученный результат и достать необходимые поля. В нашем случае это ID, Login, Groups. Использование первых двух весьма банально, нужно лишь выполнить преобразование Login из формата почты в стандартный String (блок To String).

В случае с группами пользователя ситуация несколько сложнее. Они хранятся в формате Enum. Это перечисляемый тип, который сохраняет в базе лишь список идентификаторов, а не их текстовое значение. В нашем случае значение 1 соответствует группе администраторов (Admins), а значение 2 группе пользователей (Users).

Наша задача заключается в том, чтобы расшифровать данный идентификатор и записать результат в виде удобных текстовых данных. Для этого необходимо:

• Объявить переменную, в которую будет будет записываться текстовая информация о группах пользователя. Воспользуемся блоками String Array и Set Variable
• Запустить цикл с помощью блока For each loop. Он будет получать массив групп пользователя, а затем в каждой итерации преобразовывать очередную группу в ее текстовое значение и добавлять в массив.
• С помощью блока Switch проверить группу пользователя и, в зависимости от результата, направить процесс дальше.
• С помощью блоков String и Set Variable, сохранить необходимое значение группы пользователя в переменной.
• Воспользоваться блоками Append Array и Set Variable для добавления полученного результата в массив и сохранения его в переменной, объявленной перед началом цикла.

По завершению цикла необходимо воспользоваться блоком Concat Strings (Multiple), чтобы из разрозненных данных сформировать итоговую строку, которая будет преобразована в Text и записана в лог.

Последнее, что необходимо сделать - сформировать модель log и записать ее в базу данных.

Итоговый БП должен выглядеть подобным образом:

Эндпойнт логгера

Бизнес-процесс готов. Теперь необходимо создать эндпойнт для него. Для этого заменим системный бизнес-процесс эндпойнта POST /log/ на БП, который был только что создан.

Теперь наш собственный логгер полностью готов к работе. Можно вернуться к самому началу модуля, в бизнес-процесс Basic functions, и заменить стандартный лог на тот, который сделали сами.

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

Отлично, наш лог действительно работает. Теперь в нем содержится информация о событии, логин пользователя и его права доступа.

Возможные ошибки и рекомендуемые действия

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

• Ошибки в самом бизнес-процессе. Рекомендуется использовать логи для пошаговой проверки. Таким образом можно проверить сам факт запуска определенного блока БП, а также все параметры, которые блок использует, как на входе, так и на выходе.
• Ошибки в передаче запроса на сервер. Для этого используются Инструменты Разработчика в браузере. Можно проверить факт отправки запроса, разобрать его структуру, увидеть полученный ответ.
• Запросы неправильно сформированы. Рекомендуется использовать Swagger для тщательного тестирования, проверки различных вариантов запросов, комбинаций параметров.
• Результат запроса неправильно обрабатывается. Бывает так, что мы ждем результат там, где его не должно быть. Например, добавляем данные в базу, но не обновляем их в таблице, которая эти данные отображает. Необходимо помнить, что для работы каждого компонента необходим соответствующий бизнес-процесс, и убедиться в том, что данный БП настроен корректно.