Система гарантированной доставки сообщений во внешние системы

Задачи и цели

При интеграции Directum RX недостаточно выполнять однократную отправку данных во внешнюю систему, например, в SAP или 1С. Возникает необходимость контроля доставки сообщения.

Сложности при контроле доставки:

• Если при отправке сообщения возникла исключительная ситуация, сообщение должно быть отправлено повторно через некоторое время.
• При отправке больших объемов данных по различным объектам сложно контролировать результаты отправки сообщений.
• Анализ или поиск ошибки при помощи логов требует больших трудозатрат.
• Если контроль отправки осуществляется внутри автоматизированного процесса, то ошибка при отправке может привести к его остановке до выяснения причин.
• Нет возможности точечно выполнить повторную отправку объектов, которые не были отправлены из-за ошибки.

Для решения данных задач было разработано решение по централизованной отправке сообщений во внешние системы и контролю отправки.

Возможности решения

Система гарантированной доставки сообщений во внешние системы решает следующие задачи:

• Унификация процесса отправки данных во внешние системы, что позволяет включать в обмен любые данные в кратчайшие сроки;
• Наличие журнал сообщений для отслеживания любого объекта, который был отправлен во внешнюю систему, его статус и ответ от внешней системы;
• Построение механизма мониторинга и периодической отправки новых сообщений и повторной отправки сообщений, которые не были доставлены;
• Разделение бизнес-процессов и отправки данных во внешние системы для обеспечения их независимой работы друг от друга.

Описание решения

Решение состоит из нескольких объектов:

1. Справочник Журнал запросов – его задача хранить в себе всю информацию о сообщениях, требующих отправки, и о результатах его доставки.
2. Фоновый процесс – осуществляет периодическую отправку новых и повторную отправку недоставленных сообщений
3. Асинхронный обработчик – это непосредственная отправка сообщения в целевую систему.

Порядок работы на примере справочника контрагентов

Рассмотрим порядок работы на примере справочника компаний-контрагентов.

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

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

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

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

Пример вставки кода в регламент

Проверки и уведомления

Если сотрудник (случайно, или специально) нажмет на кнопку несколько раз – будет создано несколько записей, но каждая предыдущая запись, которая не была отправлена - изменит свой статус на «Отменённая».

Фоновый процесс с определенной периодичностью собирает Активные записи журнала интеграции в 2 списка:

1. неотправленные записи (логическое значение), и отправляет их в целевую систему.
2. недоставленные записи (логическое значение).

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

Для безопасности адреса внешних сервисов и учетные данные хранятся в отдельном справочнике «Настройки». Учетные данные хранятся в зашифрованном виде.

При использовании промежуточных сервисов для передачи ответов из сторонних систем разработан POST-метод, позволяющий наполнить данными конкретную запись справочника Журнал запросов.

Результаты

Решение в текущей реализации уже находится в промышленном использовании. одном из фармацевтических холдингов и доказало свою эффективность. В нем задействована интеграция между Directum RX и рядом сервисов заказчика, таких как, С: ЗУП, 1С: УПП, 1С: ДО, SAP.

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

При необходимости можно разработать функционал уведомления администратора о различных событиях отправки с определенными результатами. Например, оповещать о записях, которые внешняя система не приняла.

Перспективы развития решения

Решение является готовым для тиражирования в других проектах. Тем не менее, ест варианты его развития, а именно: возможность ручной настройки решения (шаблоны запросов, выбор сущностей и свойств сущностей для тела запроса и т.п.). Команда планирует в дальнейшем развивать данное решение.

Состав команды проекта

• Архитектор – Евлентьев Леонид
• Ведущий разработчик – Романов Иван
• Разработчик – Шарифуллин Ильназ