Перейти к содержанию

Обработчики интеграции

Обработчик интеграции — код в клиентском модуле информационной системы, который умеет формировать (для исходящих) или применять (для входящих) сообщения одного конкретного класса. Шина обработчики не выполняет и не хранит — это всегда часть клиентской ИС, не часть платформы. Но без обработчиков обмен работать не будет, поэтому концептуально они — равноценная часть модели интеграции, наряду с маршрутами.

Привязка к классу и направлению

У обработчика два жёстких признака:

  • Направление — исходящий (формирует сообщение из объекта учётной системы) или входящий (применяет принятое сообщение к учётной системе). Один и тот же обработчик не может быть и тем и тем одновременно.
  • Класс сообщения — к какому классу обработчик привязан. Сообщение принадлежит ровно одному классу, значит, к нему применяется ровно один обработчик соответствующего направления.

Получается: на каждый класс в каждой ИС, в каждом направлении — ровно один обработчик (если этот класс для этой ИС вообще обрабатывается).

Что делает исходящий обработчик

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

  • Взять объект учётной системы.
  • Извлечь данные, нужные для сообщения.
  • Сформировать структуру сообщения по контракту, согласованному для этого класса.
  • Передать сформированное сообщение в очередь отправки модуля.

После этого обработчик завершает работу; дальнейшая судьба сообщения (отправка в шину, ACK, ретраи отправки) — забота транспортного слоя модуля.

Что делает входящий обработчик

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

  • Прочитать payload сообщения.
  • Преобразовать значения к типам учётной системы.
  • Разрешить ссылки на другие сущности.
  • Создать или обновить бизнес-объект; провести валидацию.
  • Зафиксировать изменения в БД учётной системы.

При успехе — сообщение помечается обработанным. При нештатной ситуации — сообщение переводится в один из ошибочных статусов (см. Жизненный цикл сообщения).

Состояние

Каждый обработчик в любой момент времени включён или отключён. Срабатывают только включённые. Отключение — штатный инструмент, не аномалия:

  • На время настройки или тестирования нового класса.
  • На время поиска и устранения ошибки в обработчике.
  • При временной несовместимости — например, если контракт класса изменился, а обработчик ещё не обновлён.

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

Чего нет в обработчиках

  • Бизнес-логики «снаружи» от объекта. Обработчик создаёт или изменяет одну бизнес-сущность; всё, что должно произойти дальше (пересчёт остатков, движения регистров, расчёт цен), — это логика учётной системы, которая срабатывает по созданию/изменению этого объекта, а не код обработчика.
  • Маршрутизации. Обработчик не выбирает, кому отправлять сформированное сообщение и от кого получать. Это решают маршруты на стороне шины.
  • Решений о повторе. Политика отложенной обработки при ошибках ссылок — параметр модуля, не отдельного обработчика. Сам обработчик просто возвращает «не смог» при ошибке; что с этим делать дальше — решает фреймворк модуля.

Концептуальная универсальность

Концепция обработчика — общая для любого клиентского модуля DataHUB, независимо от платформы (1С, Java, .NET, Python, Mobile). Конкретное представление различается:

  • В 1С это записи в отдельной подсистеме модуля с привязкой к коду на встроенном языке.
  • В Java/.NET/Python это, как правило, классы или функции, регистрируемые в реестре обработчиков фреймворка.
  • В мобильных приложениях — обычно функции-обработчики, привязанные к классам сообщений.

Деталь реализации меняется; суть — «один класс → один обработчик в каждом направлении» — остаётся.

Что дальше