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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Моделирование данных (о терминах и смыслах)

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

Борхес, "Аналитический язык Джона Уилкинса"

Модели данных делятся на

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

Ну, вы поняли?

Виды данных в информационных системах

Неоднократно встречал деление данных в информационных системах (далее ИС) на

1. справочники,
2. мастер-данные,
3. документы,
4. метаданные.

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

1. справочники,
2. ресурсы,
3. конфигурации,
4. операции,
5. транзакции,
6. деривативы,
7. метаданные.

Опишу эти виды данных неформально, но доходчиво.

dbang! Утилиты для работы с БД

Написанные на Python, утилиты dbang позволяют существенно сэкономить усилия при решении типичных задач, связанных с БД:

• ddiff.py - выполняет запросы к двум БД и формирует отчет о расхождениях;
• dtest.py - выполняет запросы к БД и формирует отчет о найденных проблемах;
• dget.py - выгружает данные из БД в файлы csv, xlsx или html;
• dput.py - загружает данные из файлов csv или xlsx в таблицы БД;
• hedwig.py - на основе файлов создает и отправляет е-мейл.

Утилиты могут работать с СУБД Oracle, PostgreSQL, SQLite и MySQL.

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

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

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

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

ddiff. Эффективное сравнение данных в разных БД

Как вы поступаете, когда нужно сравнить два больших набора данных? Скорее всего, первое, что вы делаете, – проверяете, одинаковое ли количество строк в каждом наборе и одинаковые ли суммы по некоторым столбцам. Можно еще сравнить количество уникальных значений в одних и тех же столбцах в двух наборах, минимальные и максимальные значения столбцов, сумму длин строк в строковых столбцах.

К сожалению, СУБД не предоставляют агрегатных функций для расчета хэша для набора строк. Поэтому для быстрого и грубого сравнения двух наборов данных приходится использовать возможности имеющихся агрегатных функций. Например:

Активирование и деактивирование логических сущностей в оперативной БД

Каждая логическая сущность предметной области

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

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

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

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

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

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

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