История создания функционала
С 2022 года я работаю 1С-программистом в компании, занимающейся установкой и обслуживанием систем безопасности многоквартирных домов. В 2021 году в ней началась разработка собственной внутренней новой информационной корпоративной системы (НИКС), суть которой состояла в следующем.
В структуру компании входят следующие подразделения:
• Контакт-центр
• Служба сервиса
• Центр удаленного управления
• Центр управления биллингом
• Аналитический центр
• Бухгалтерия
• Отдел кадров
В каждом структурном подразделения необходимо было внедрить своё прикладное решение:
• В контакт-центр – прикладное решение для приёма обращений клиентов, сервис "Личный кабинет клиента", единый сервис аутентификации пользователей НИКС.
• В службе сервиса – прикладное решение для координации работы мастеров службы с мобильным приложением для них.
• В центре управления биллингом – прикладное решение для ведения учета взаиморасчетов с клиентами.
• В центре удаленного управления – прикладное решение для управления оборудованием, поддерживающим соответствующие функции.
• В аналитическом центре – прикладное решение для построения аналитики на сводных данных по активам компании.
• В бухгалтерии и отделе кадров – прикладное решения для ведения соответственно бухгалтерского и кадрового учета.
А обмен данными между базами должен был быть настроен так, чтобы он соответствовал процессам обмена информацией между структурными подразделениями.
Реализацию решили делать посредством API.
Примеры передачи данных
1. Контакт-центр принимает заявку клиента и передает её в службу сервиса.
Служба сервиса возвращает контакт-центру ФИО исполнителя заявки.
Для передачи заявки исполнителю часть данных запрашивается в основной информационной базе (ИБ) компании – материнской базе.
Итого – 3 последовательных вызова api-методов (3 http-запроса).
2. Исполнитель запрашивает назначенные ему заявки.
При первичном запросе, или в случае, если время жизни переданного токена авторизации истекло, он – токен – проверяется запросом в единый сервис аутентификации пользователей НИКС.
Итого – 2 последовательных вызова api-методов (2 http-запроса).
3. Исполнитель передает данные о выполнении заявки в службу сервиса.
При первичном запросе, или в случае, если время жизни переданного токена авторизации истекло, он – токен – проверяется запросом в единый сервис аутентификации пользователей НИКС.
Служба сервиса передает данные о выполнении заявки в контакт-центр
В случае, если заявка была платная и оплата была выполнена по безналу, контакт-центр запрашивает данные о поступлении оплаты в центре управления биллингом.
Итого – до 4-х последовательных вызовов api-методов (до 4 http-запроса).
Объем обрабатываемых данных
Компания работает в 21 регионе России.
Обслуживает ~ 3 млн. абонентов.
Служба сервиса ежедневно принимает ~ 2000-3000 клиентских заявок.
Плюс – до 5000-6000 тысяч служебных заявок (задач) ежедневно создаются в системе.
В результате – трафик данных, проходящих через информационную систему (ИС) службы сервиса составляет ~100-400 запросов в минуту.
Производительность
Среднее время обработки запросов из мобильного приложения ~ 1 секунда.
Трудности, которые возникали в процессе разработки и внедрения НИКС в целом можно разделить 2 категории:
1. Некорректная передача/прием данных
2. Ошибки, полностью останавливающие обмен
Первая была обусловлена тем, что разработка API всех информационных систем (модулей) НИКС велась одновременно, параллельно и в условиях дистанционного взаимодействия.
Пример.
Прикладное решение КЦ передает заявку в информационную базу службы сервиса вызовом соответствующего api-метода. В виде документа заявка не создается в ИБ службы сервиса. Для отлаживания api-метода необходимы данные http-запроса (заголовки, тело). Получить эти данные можно лишь обратившись к разработчику прикладного решения КЦ.
Основная же сложность исправления ошибок, полностью останавливавших обмен (ошибок, вызывавших аварии), состояла в поиске самой ошибки в цепочке вызовов api-методов.
Пример.
Мобильное приложение мастера передает данные о выполнении заявки в основную ИБ службы сервиса. Запрос на подтверждение валидности нового токена авторизации в сервис аутентификации не проходит. Мобильное приложение, не получив ответ об успешной обработке запроса, вновь его отправляет. В результате нарастания в прогрессии количества входящих запросов из мобильного приложения увеличивается количество сеансов ИБ службы сервиса – нагрузка увеличивается – скорость обработки запросов, параллельно поступающих из других модулей НИКС, снижается – система виснет.
Основная причина аварии – на стороне сервиса аутентификации (недоступность сервиса в целом, или ошибки в коде). Второстепенная причина – та, что аварию вызвала – на стороне мобильного приложения (отправка запросов в чрезмерно большом количестве). Второстепенную причину частично можно определить по консоли администрирования серверов 1С – частично! Определить же первопричину на стороне потерявшей работоспособность информационной системы службы сервиса невозможно вовсе. Платформа 1с не логирует результаты обмена данными по API.
Имея же логи API, появляется возможность:
- Проверять, какая информация была передана.
- Видеть ошибки: ошибки в конкретных запросах и сбои и цепочках запросов.
- Анализировать нагрузку на систему и её производительность.
- Проверяя по регламентному заданию имеющиеся логи, отслеживать возрастание нагрузки на систему и предотвращать аварии.
Столкнувшись с вышеперечисленными проблемами, и придя к сформулированным выводам, решил в качестве вспомогательного инструмента сделать функционал логирования API.
Расширение 1С:ЛогированиеAPI
Предусмотрена запись следующих данных:
• Направление запроса – «Входящий» или «Исходящий».
• Адрес – URL http-метода (без параметров URL).
• Параметры URL – если они есть.
• Процедура – обработчик запроса или процедура/функция, из которой исходящий запрос отправляется.
• Заголовки запроса.
• Тело запроса – если оно есть.
• Код ответа.
• Тело ответа.
• Время начала обработки входящего или время отправки исходящего запроса.
• Время окончания обработки входящего запроса или время получения ответа на исходящий.
• Время выполнения – разность времени начала и окончания.
• Номер сеанса, в котором запрос был принят или выполнен.
• Имя пользователя, под УЗ которого запрос был принят или выполнен.
• Ошибка не обработанного или не выполненного запроса.
• Комментарий – произвольный.
Данные можно записывать в регистр сведений и/или в журнал регистрации.
На основании данных, записанных в регистр сведений можно формировать отчеты в виде графиков о количестве запросов и о времени их выполнения.
Для выполнения исходящих http-запросов предусмотрена функция ОтправитьЗапрос, находящаяся в программном интерфейсе модуля ЛогAPI_ОбщегоНазначения. Запись лога запроса осуществляется внутри данной функции.
Логировать входящие http-запросов предполагается вызовом остальных функций программного интерфейса модуля ЛогAPI_ОбщегоНазначения.
В расширение добавлен http-сервис ЛогAPI_Logs, в обработчике единственного метода которого представлен пример последовательности вызовов этих функций.
Нежелательные последствия при записи логов API
1. Увеличение времени выполнения и обработки запросов. Сама запись лога тоже требует времени. Но в процессе эксплуатации данной системы логирования в рамках проекта разработки описанной выше корпоративной ИС критических значений данная издержка не достигала.
2. Если записывать логи в регистр сведений, размер базы данных будет ощутимо расти. Проблема решается в рамках плана обслуживания базы на SQL-сервере. Логи API достаточно быстро теряют свою актуальность. Соответственно, прямым SQL запросом можно удалять старые записи, оставляя таким образом регистр логов в приемлемом для системы размере.
Проверено на следующих конфигурациях и релизах:
- 1С:Библиотека стандартных подсистем, редакция 3.1, релизы 3.1.12.281
Вступайте в нашу телеграмм-группу Инфостарт