Алгоритм отправки

Отправка сообщения в DataHUB состоит из двух независимых фаз: регистрации события и доставки в шину. Разделение фаз позволяет не терять изменения при временной недоступности сервера.

Фаза 1: регистрация события

Когда объект изменяется, адаптер фиксирует это событие в локальном хранилище:

Механизм обнаружения изменений (подписка на событие, хук, триггер) срабатывает при изменении объекта.
В локальную очередь регистрации записывается минимальный набор данных: ссылка на объект, тип события, время.
Это действие выполняется в той же транзакции, что и изменение объекта, — чтобы событие не потерялось при сбое.

Цель фазы 1 — зафиксировать факт изменения, не выполняя тяжёлую процедуру формирования сообщения прямо в транзакции.

Фаза 2: формирование и отправка

Фоновый процесс обрабатывает очередь регистрации:

Выбрать необработанную запись из очереди.
Прочитать актуальный объект по сохранённой ссылке.
Вызвать исходящий обработчик — он сериализует объект в структуру тела сообщения.
Упаковать тело в транспортный конверт: заполнить поля Id, Type, ClassId, Source, CreationTime, Body.
Отправить сообщение через Transport API.

Обработать ответ:

Код	Действие
`200 OK`	Сообщение принято. Пометить как отправленное. Завершить цикл.
`401 Unauthorized`	Access-токен истёк. Обновить через Refresh-токен и повторить с шага 5.
Иные ошибки	Зафиксировать в логе, прервать цикл. Транзакция откатывается — сообщение остаётся в очереди неотправленным.

Параллельная отправка

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

Повторная отправка при сбое

Если отправка не удалась (ошибка сети, недоступность сервера, ответ 5xx), транзакция откатывается, цикл прерывается. Сообщение остаётся в очереди неотправленным — без смены статуса. При следующем запуске фонового процесса оно снова будет выбрано для отправки.