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

Модель интеграции

DataHUB — корпоративная интеграционная шина (ESB, Enterprise Service Bus). Её задача — связать несколько информационных систем в единый контур обмена данными так, чтобы каждая система разговаривала только с шиной, а не напрямую с другими системами.

Без шины и с шиной

В простом сценарии «две системы обмениваются документами» можно обойтись прямой интеграцией: одна система знает, как достучаться до другой, и связывается с ней напрямую. Технически это может быть что угодно — вызов REST или SOAP API, COM-соединение между базами 1С, регулярная выгрузка/загрузка файлов XML или JSON через общий каталог, обмен через FTP, прямой SQL-доступ к чужой БД. Пока систем две — какой бы способ ни был выбран, всё в целом обозримо.

Как только в обмене появляется третья, четвёртая, пятая система, прямая интеграция превращается в «сетку»: каждая пара систем поддерживает свой канал и свой формат, каждая система должна знать про каждую соседнюю, отслеживать изменения у всех остальных. Сложность растёт по квадратичной зависимости от количества систем; добавление новой системы требует доработок во всех существующих, а способы передачи между разными парами часто оказываются разнородными (где-то API, где-то файлы, где-то прямое подключение) — что ещё больше усложняет сопровождение.

Шина переворачивает эту топологию: вместо «каждый с каждым» — «каждый с центром». Все системы подключаются к одному узлу (DataHUB), и все коммуникации идут через него. Системы перестают знать друг о друге; добавление новой системы — это её подключение к шине плюс описание её участия в обмене на стороне шины.

без шины (mesh):                с шиной (hub-and-spoke):

    A ─── B                          A
   ╱│╲   ╱│╲                          ╲
  C │ D ╳ │ E                      C ─ DataHUB ─ B
   ╲│╱   ╲│╱                          ╱
    F ─── G                          D

Что DataHUB делает

Принимает сообщения от систем-отправителей через единый REST API. Отправитель формирует сообщение в согласованном формате и отправляет его в шину — куда дальше пойдёт сообщение, решает шина, не отправитель.

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

Гарантирует надёжную доставку в режиме «хотя бы один раз»: если получатель временно недоступен, сообщение хранится в очереди и доставится при восстановлении связи. Если связь прервалась в момент передачи — сообщение будет доставлено повторно. Подробнее — в Гарантиях доставки.

Изолирует системы друг от друга — ни одна из подключённых систем не знает напрямую о существовании других. Это касается технических деталей (адреса, порты, учётные данные) и контракта обмена (формат данных, версии).

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

Делает обмен видимым на стороне участников. Каждое отправленное и принятое сообщение получает статус в клиентском модуле интеграции — пользователь видит, что отправлено, что доставлено, что зависло. Централизованный трекинг доставки на стороне самой шины запланирован, но пока в разработке — до его выпуска статус доставки конкретного сообщения определяется по состоянию очередей в RabbitMQ Management и по статусам в модулях-участниках.

Чего DataHUB не делает

Не выполняет бизнес-логику. Шина — это транспорт, а не приложение. Она не решает, нужно ли создать документ, как пересчитать остаток, какой бухгалтерский счёт затронуть. Все бизнес-решения принимает та система, которая получила сообщение и обрабатывает его.

Не трансформирует данные. В классических ESB-продуктах есть слой «mapper» — преобразование одного формата в другой, обогащение, валидация. DataHUB сознательно этот слой не вводит: контракт обмена един для всех участников и описывается в пакете обмена. Если двум системам нужно «разговаривать на разных языках» — приведение к общему формату делается на стороне самих систем, не на шине.

Не хранит сообщения после доставки. Сообщение существует в шине только пока оно ждёт обработки в очереди получателя. Как только получатель подтвердил обработку — RabbitMQ удаляет сообщение из очереди, и в шине от него не остаётся ничего. Дальнейшая жизнь содержимого — в системе-получателе, где оно превратилось в документ или запись справочника и хранится по её регламенту. В базе самой шины живут только метаданные обмена (системы, пакеты, маршруты, права), но не сами сообщения.

Не подменяет API учётных систем. Шина — это посредник между системами, а не общий API над их данными. Если внешнему клиенту нужны данные из учётной системы — он работает с её собственным API, а не с шиной.

Сценарий обмена «глазами систем»

С точки зрения системы-отправителя:

  1. Сформировать сообщение в формате, описанном в пакете обмена.
  2. Отправить его через REST API шины.
  3. Получить подтверждение, что сообщение принято в очередь.
  4. На этом ответственность отправителя заканчивается.

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

Процесс приёма — короткий, его задача быстро принять сообщение из шины:

  1. Получить сообщение из своей очереди в шине (опросом или подпиской).
  2. Сохранить его в локальный пул входящих в собственной БД получателя — payload + метаданные + статус «получено, ждёт обработки».
  3. Зафиксировать транзакцию.
  4. Подтвердить получение шине (ACK).
  5. Перейти к следующему сообщению.

Процесс обработки — отложенный, он применяет накопленные сообщения к бизнес-данным учётной системы:

  1. Взять необработанное сообщение из локального пула.
  2. Преобразовать значения payload в типовые (строки в числа, даты, ссылки в идентификаторы).
  3. Разрешить ссылки на другие сущности (контрагенты, товары, склады, документы).
  4. Создать или обновить бизнес-объект, проверить его валидность.
  5. Записать изменения в БД учётной системы.
  6. Пометить сообщение как обработанное и перейти к следующему.

Эти два процесса разделены сознательно. Если бы обработка шла сразу при приёме, любое сообщение, ссылающееся на ещё не пришедшую справочную запись, валилось бы и должно было ретраиться через очередь шины — это раздувало бы очередь и не давало гарантии, что нужное справочное сообщение успеет прийти между ретраями. Отложенная обработка из локального пула снимает эту проблему: при ошибке разрешения ссылки сообщение откладывается на повторную обработку внутри получателя (интервал и количество попыток — настройка администратора модуля), а критическая ошибка переводит сообщение в статус «ошибка обработки» для разбора. ACK шине при этом отдаётся быстро — на шаге приёма, не на шаге применения.

Отложенная обработка решает и задачу приоритезации. Когда в локальном пуле скопилось разнородное — оперативные документы (заказы, накладные, оплаты, для которых задержка критична) и справочники с прочими статичными или редко изменяемыми сущностями — модуль может разбирать пул не подряд, а с приоритетом: сначала оперативное, потом всё остальное. Через шину такую приоритезацию реализовать было бы сложно (очереди в RabbitMQ внутри одного получателя не упорядочиваются по бизнес-приоритету), а внутри пула — это простая выборка по полю «тип сообщения».

Такое разделение даёт получателю гарантию ссылочной целостности и не блокирует шину на время прикладной обработки. Подробнее модель раскрыта в Асинхронной обработке, а её типовая реализация для 1С — в Модуле 1С / Алгоритмы обмена.

С точки зрения системы-отправителя ничего не меняется в зависимости от того, сколько у сообщения получателей: один, пять или ноль (если временно нет подписчиков). Это полностью внутреннее дело шины и решается конфигурацией маршрутов.

Шина как «единая точка отказа»

Очевидный вопрос при переходе на шину: «если шина упадёт — встанет весь обмен?». Технически да, но это компенсируется тремя вещами:

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

Что дальше