Какие задачи решает агент системы на шине данных

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

(Возможно, удачнее было бы назвать агента системы адаптером.)

Вот некоторые типичные кейсы, с которыми работает агент системы.

• Бизнес-термины и соглашения. Новая система С приносит с собой свою терминологию, отлитую в граните названиях сообщений и полей. Например, исторически бизнес работает с заказами на приемку и заказами на отгрузку, а новая система управления складом ожидает на входе планы приемки и планы отгрузки. Агент системы берет на себя "перевод" и трансформацию сообщений, благодаря чему организация в целом продолжает оперировать заказами на приемку и заказами на отгрузку.
• Формат и соглашения. Новая система С работает с входными и выходными сообщениями определенного формата (скажем, csv), отличного от стандартного формата сообщений на шине данных организации (скажем, Avro). Причем даты в сообщениях системы представлены не в стандартном формате гггг-мм-дд, а в формате дд-мм-ггг. Агент системы С берет на себя преобразование форматов сообщений и представлений дат для системы, тем самым изолируя специфику системы от других клиентов шины данных.
• Идентификаторы сущностей. Система Х использует внутренние ключи для идентификации бизнес-сущностей даже в интеграционных сообщениях. Например, вместо бизнес-ключа товара, с помощью которого давно коммуницируют между собой и люди и системы в организации, интеграционный API системы X использует GUID в качестве идентификатора товара. Тогда агент Х берет на себя перекодировку бизнес-ключей в GUID и обратно, благодаря чему организация в целом продолжает оперировать бизнес-ключами.
• Сборка/разборка составной сущности. Новая система С приносит с собой специфичное представление составной бизнес-сущности во входящих и/или исходящих сообщениях, отличное от принятой на шине данных. Например, существующие клиенты шины данных работают с заказами, представленными одним сообщением, в котором есть заголовок и массив позиций. А система С принимает заказ как множество сообщений, каждое из которых описывает одну позицию (а последнее содержит контрольную сумму). Тогда агент С преобразует сообщения с шапкой и массивом позиций во множество сообщений для системы С, и изолирует специфику системы от остальных клиентов.
• Комплексная сущность. Система В требует на входе комплексную сущность, собирающую вместе данные нескольких сущностей, представленных на шине данных в отдельных топиках. Например, основные данные о товаре и данные о транспортной упаковке товара публикуются в разных топиках, так как в этих данных заинтересованы разные клиенты. А система В ожидает на входе сообщения, содержащие как некоторые из основных данных товара, так и данные о транспортной упаковке товара. Агент системы В будет формировать для нее такие сообщения при получении сообщений об изменении основных данных товара или об изменении транспортной упаковки.
• Интегрированная сущность (частный случай комплексной сущности). Система К требует на входе сущность, которая интегрирует данные из разных систем-источников. Например, основные данные о товаре публикуются на шине данных системой Т, а данные об изменении розничной цены товара системой Р, при этом система К принимает входящие сообщения, содержащие как данные о товаре, так и розничные цены. Агент системы К будет формировать для нее такие сообщения при получении сообщений об изменении основных данных товара или об изменении розничных цен.
• Обогащенная/обедненная сущность. Система С требует от входящих сообщений наличия текстового описания некоторого атрибута, тогда как в организации существует справочник со значениями этого атрибута и во всех топиках его значения кодируются числовым кодом из справочника. Например, система С требует на входе название валюты, а во всех топиках — трехзначный числовой код из Справочника валют. Агент сформирует специально для системы С сообщения, заменив в оригинальных сообщениях поле с кодом валюты на поле с названием. (А в исходящих сообщениях системы С заменит названия валюты на ее код.)
• Агрегирование данных. Система А требует на входе агрегированные данные, тогда как существующие клиенты шины данных работают с детальными данными. Например, ежедневно на шине данных публикуются сотни заказов от разных заказчиков, а системе А требуются суммарные количества товаров, заказанных за сутки (или с начала месяца) всеми заказчиками. Агент А выполняет необходимое агрегирование данных и ежесуточно формирует сообщения для системы А, тогда как остальные клиенты шины данных продолжают пользоваться детальными данными.
• Иерархические и "плоские" данные. Каждый узел некоторой иерархической структуры представлен на шине данных отдельным сообщением в топике. Например, в топике Организационная структура публикуются изменения узлов 5-тиуровневой организационной структуры. А новая система Н требует на входе только данные о линейных подразделениях (узлах нижнего уровня) с перечнем вышестоящих узлов структуры в отдельных полях. Агент системы Н формирует для нее такие сообщения при получении сообщений об изменении того или иного узла иерархической структуры.
• Начало (и окончание) действия сущности. Система К ожидает, что поступающие на вход данные немедленно становятся активны (вводятся в действие), тогда как исторически на шине данных публикуются данные с датой начала (и окончания) действия. Например, на шине опубликована (повышенная) розничная цена товара на период с 2026-03-01 по 2026-03-08, а сегодня только 2026-02-15 и система управления кассами К немедленно передает на кассы полученную на вход цену. Агент системы К передаст повышенную цену на вход системы только в ночь на 2026-03-01 (а в ночь на 2026-03-09 передаст прежнюю цену).
• Удовлетворение зависимостей и обратная связь. Система С ожидает, что на вход поступают данные, для которых в системе уже удовлетворены необходимые зависимости. Например, система успешно обрабатывает только входящие заказы с товарами, уже известными системе, а иначе заказ на входе просто помечается как ошибочный. Тогда, как вариант, агент системы С проверяет статус обработки заказа на входе в систему, и, в случае ошибки, передает в систему данные о товарах в заказе, прежде чем повторно передать заказ.
• Контроль качества данных и обратная связь. Все клиенты на шине данных ожидают, что входящие данные корректны, в частности, все обязательные поля присутствуют в сообщении и заполнены допустимыми значениями, а при наличии зависимостей между полями эти зависимости удовлетворяются. К сожалению, даже использование Avro-схем не предотвращает всех подобных проблем, а если система-источник передает данные в других форматах, то проблемы, скорее всего, будут возникать. В этом случае агент системы-источника берет на себя (дополнительный) контроль корректности данных в сообщениях от системы.

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

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