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

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

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

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

Интеграция систем посредством шины данных

Ранее я писал о том, как мы интегрировали системы через шину данных. Этот пост продолжает тему интеграции систем через шину данных.

Дано: несколько систем и шина данных, реализующая обмен сообщениями через отдельные каналы (топики) по принципу publish - subscribe.

Цель: интегрировать системы посредством сообщений об изменениях, передаваемых и получаемых в/из шины данных.

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

В торговой сети "Бубль-Гум" десяток взаимодействующих информационных систем, а в качестве шины данных у нас Apache Kafka.

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

Еще раз о ловле и обработке изменений в реляционной БД

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

1. маркирование каждой измененной записи тем или иным образом,
2. регистрация каждого изменения в отдельной таблице с помощью триггера (см. подробнее Захват и обработка изменений в БД...),
3. получение изменений за период с помощью разности с более ранним снэпшотом (см. подробнее Передача изменений между БД: подход в духе KISS).

Если у вас есть выбор, какой из вариантов реализовать, то сделать этот выбор правильно помогут ответы на следующие вопросы:

JSON или CSV для обмена данными между БД?

Заметил, что зачастую для интеграции реляционных баз данных используются объектно-ориентированные сообщения. В сущности, это означает лишние расходы на преобразования между реляционным и объектным представлениями данных.

Например, в системе управления заказами клиентов есть логическая сущность заказ, состоящая из "шапки" и строк заказа. В реляционной БД она представляется двумя таблицами.

delta revisited. Работа с изменениями первичного ключа

Ранее я описал механизм delta для регистрации изменений в таблицах БД Oracle, позволяющий обрабатывать изменения независимо нескольким клиентам.

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

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

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

Кейс: изменение значения первичного ключа

Если значение первичного ключа изменяется не при выполнении специальных административных процедур, а в ходе обычной эксплуатации системы, то это выглядит как ошибка проектирования системы. Однако, иногда приходится иметь дело с такими системами.

Вопрос об изменении значения первичного ключа может также возникнуть в контексте интеграции систем.

Например, система А посылает в шину данных сообщения об изменениях бизнес-сущности Товар. И в этих сообщениях каждый отдельный экземпляр сущности – индивидуальный товар – идентифицируется бизнес-ключом, значение которого может быть изменено пользователем системы А (см. мой пост Кейс: изменение значения бизнес-ключа). А в системе Б, которая получает сообщения из шины данных и на их основании актуализирует собственную копию бизнес-сущности Товар, бизнес-ключ является первичным ключом таблицы в БД. И на него ссылаются внешние ключи из других таблиц.

Сможет ли система Б обновить первичный ключ, если она получит сообщение об изменении бизнес-ключа?

Кейс: изменение значения бизнес-ключа

Возьмем некоторую сущность модели данных, экземпляры которой идентифицируются бизнес-ключом. Бизнес-ключ - это код или номер, который известен конечным пользоватлям системы (представлен в пользовательском интерфейсе) и используется в коммуникациях. Например, артикул товара, код подразделения компании, табельный номер сотрудника. Когда один сотрудник передает другому список товаров, он передает список артикулов. Когда подразделение компании заводит заявку на обслуживание, оно указывает код подразделения; этот же код подразделения фигурирует в копроративных отчетах.

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

Бывает, что бизнес-ключ изменяется пользователем.

Логическая целостность данных, выгружаемых из БД

Задача: передавать данные из одной БД в другую, отсекая ненужные для интеграции данные – слишком старые или логически нерелевантные. При этом вся совокупность данных, выгруженных из БД-источника, должна оставаться логически целостной. Это значит,

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

Очевидно, что если выгружать все строки из выбранного набора таблиц БД, в котором обеспечена ссылочная целостность, то критерий выгрузки (все строки) не требует специальных анализа и реализации, а выгружаемые данные также будут ссылочно целостны.

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

Захват и обработка изменений в БД Oracle (at_delta)

Ранее я рассказывал о том, как получить изменения данных в исходных таблицах за период с помощью операции MINUS.

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

Передача изменений между БД: подход в духе KISS

В БД SOURCE в таблице itemz ведется некий справочник. Время от времени в справочник добавляются новые строки и изменяются существующие. Возможно, строки даже иногда удаляются. В данных этого справочника нуждается БД DEST, причем контракт состоит в передаче из БД SOURCE всех изменений справочника. И как же организована передача изменений БД SOURCE в БД DEST? А вот так.