Всем привет! В предыдущей статье мы рассказали об использовании коробочного продукта Master Data Management и обещали рассказать о дальнейшем развитии подходов управления справочниками в компании. Сегодня мы сдержим свое обещание.

Система MDM — специализированное программное решение, которое помогает унифицировать нормативно‑справочную информацию (НСИ) во всех информационных системах предприятия и организовать управление НСИ

Коробочный продукт мы использовали в течение пяти лет. И спустя эти пять лет наша история создания и развития MDM получила логическое продолжение — мы создали свой программный продукт Master Data Management, о котором сегодня и расскажем вам.

Наступило новое время импортозамещения, поменялись платформы в компании, мы активно включились в процесс и разработали концепцию импортозамещенного MDM.

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

С чего начинался продукт

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

Был выбран актуальный на сегодняшний день стек:

• Java‑платформа для разработки — Spring Boot.

• Фреймворк для фронтэнда MVM — Vue.JS.

• Для реализации базы данных PostgreSQL.

Почему именно он. Spring Boot предоставляет большую гибкость во внутренней архитектуре приложения и его настройке, базовый проект включает в себя «из коробки» многие вещи, такие как маршрутизацию, соединение с БД, профили, транзакции и многое другое. А почему Vue — из всех наших популярных SPA‑фреймворков (AngularJS, Vue.JS и ReactJS) Vue — один из самых простых с лаконичным синтаксисом кода.

Для себя мы определили назначение системы MDM:

• Ведение централизованных справочников.

• Ведение эталонных федеральных и отраслевых справочников.

• Получение и хранение данных полученных из справочников систем‑источников.

• Приведение через мэппинги в соответствие к эталонным справочникам систем‑источников.

Далее определили основные функциональные требования к системе MDM:

• Управление справочниками через систему метаданных. Дает возможность создавать новые справочники и изменять их свойства без перезапуска системы и без привлечения программистов.

• Создание и ведение эталонных справочников.

• Мэппинг справочников, получаемых от систем‑источников на эталонные справочники.

• Управление событиями записей базы данных.

• Ведение бизнес‑правил.

• Получение данных от систем‑источников.

• Передача справочников системам‑подписчикам.

• Ведение истории изменений записей справочников.

• Процессное управление согласованием и утверждением записей справочников.

• Разделения прав доступа пользователей к справочникам, выполнение аутентификации и авторизации пользователей. Управление правами пользователей через ролевую модель системы.

• Интеграция с Microsoft Excel, для пакетной обработки пользователем большого количества записей справочников.

• Предоставление функций REST API для получения системами‑подписчиками справочников.

Архитектура системы

Однозначно, сразу на этапе проектирования применен микросервисный подход, который мы уже применяли в других проектах, четко разделяя все треды для разработки основных ядровых методов. Аналогично, мы совершенно не постеснялись вынести часть бизнес‑логики с приложения на уровень хранимых процедур СУБД. В части обработки данных это оказалось весьма гибким подходом. Организация предобработки данных и бизнес‑правил на уровне слоев загрузки была основана исключительно на хранимых процедурах.

Ниже мы изобразили распределение микросервисов по уровням архитектуры.

Схема взаимодействия уровней:

Метаданные

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

Мы заложили в метаданные такие понятия как:

• Система‑источник.

• Модель данных.

• Справочник.

• Атрибут справочника.

• Правило связи источник‑справочник.

• Правило сравнения записей.

• Бизнес‑правило.

• Обработчик событий.

Система‑источник — описание источников данных, где указаны их названия, ip‑адреса, способы получения данных.

Модель‑данных — логический способ группировки справочников по их назначению, например, услуги абонентов, каналы IP‑телевидения и т. п.

Справочник — описание свойств справочника, его связей с другими справочниками.

Атрибут справочника — или другими словами — поле справочника, в котором и сохраняются данные.

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

Правило сравнения записей — описание на языке программирования какие записи одного справочника должны маппироваться на какие записи другого справочника.

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

Обработчик событий — описание на языке программирования действий, выполняемых системой во время событий, например, при добавлении записи, исправлении, удалении.

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

Получение данных от систем-источников

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

В основу обработки данных мы заложили идею слоев, в системе реализованы три слоя данных: Landing, Staging и Слой справочников.

Landing — это слой сырых данных, которые получены от источников. Данные помещаются в слой как есть, почти без предварительной обработки.

Staging — этот слой по своей структуре идентичен структуре справочников. Данные в слой переносятся из Landing, но в процессе переноса выполняется трансформация данных: приведение типов, дедубликация, дополнение данных и т. п.

Слой справочников — это слой собственно справочников. Данные в слой переносятся из Staging штатной процедурой, которая гарантирует правильное добавление и исправление записей.

Работа пользователей

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

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

Главное окно по работе с данными справочников:

На скриншоте мы видим основные элементы работы со справочником:

• Строка интерактивного полнотекстового поиска, когда поиск записей выполняется одновременно с набором пользователем искомого текста.

• Кнопка добавления записи.

• Кнопка добавления записи копированием существующей.

• Кнопка выгрузки справочника в Excel для последующего редактирования с использованием возможностей электронной таблицы.

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

• Кнопка фильтрации справочника по любому набору его атрибутов.

• Кнопка перехода к справочникам, которые ссылаются на сейчас открытый у пользователя.

Для пользователей будет интересным получить возможность перехода между связанными справочниками. Примером связанных справочников могут служить справочники интерактивного телевидения. Например, есть справочник телевизионных каналов, который имеет связь со справочником пакетов каналов, который в свою очередь имеет связь со справочником населенных пунктов, а тот в свою очередь имеют связь со справочником субъектов РФ.

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

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

Получение справочников системами-подписчиками

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

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

Чем удобно использование метаданных. Одна и та же система, один раз разработав вызовы стандартного метода из комплекта REST API MDM в дальнейшем может подключать любое кол‑во справочников с данной платформы. Все уже написано, подставляй только имя нового справочника и получай его к себе в систему!

Не хочешь REST API? Давай интегрироваться через ETL! Можно сразу писать и читать Landing‑слои, где сразу после создания справочника
автоматически генерируются структуры для обмена данными.

А что кроме обычных справочников? Перейдем к целевым эталонным витринам?

Конечно, хочется применить сразу всю артиллерию из возможностей новой платформы, иначе зачем делать что‑то похожее. И в итоге, мы начинаем получать синергию, когда один справочник получает данные из 5–10 разных систем, составляя в итоге прообраз золотой записи. Асинхронные задания, сверяют данные прообразов с федеральными и отраслевыми классификаторами, исправляя необходимые атрибуты, бизнес‑правила проводят дедубликацию и вводят необходимую иерархию.

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

Так, к чему готовиться тем, кто собрался писать свою собственную MDM-платформу?

Самое главное — определить минимальное необходимый скоуп функционала для ядра и хранилища метаданных. Приведем простой пример. Одна из важнейших вещей в MDM это Data Quality, которая в виде отдельного или встроенного решения участвует во многих функциях — от первичной загрузки до контроля регламента ETL‑процессов и обратно. Но АРМ по ее настройке для пользователя очень ресурсоемок. И если такие процессы, как DQ и подобные мы можем реализовать для первой версии системы в виде набора сервисных компонент под капотом, то это тоже решение, которое устроит и бизнес и нас, как разработчиков. Мы экономим на части UI/UX интерфейсов, тратя все ресурсы на ядро.

Также, нельзя забывать о принципах поедания слона по частям. MDM в этой части характерен именно объемами данных, которые в совокупности со всеми инфосистемами, которые надо переводить может стать непосильной ношей для команды. Здесь не стесняемся, декомпозируем все по группам и поэтапно переводим. Даже, если кажется, что можно все перевести за один раз, на практике все старые legacy‑решения оставляют закопанные «мины» в виде кастомно‑костыльного ПО.

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

Ну и самое главное — ничего не бояться!

Сейчас стало хорошо. А что же дальше?

Конечно, самое интересное наступает, когда решены все текущие задачи и можно заниматься развитием платформы. Здесь наши фантазии ничем не ограничены.

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

Мы планируем сделать надежные мастера настроек, когда из кучи шаблонов можно выбрать свой вариант справочника. Сделать библиотеку бизнес‑правил, которые можно применять к любому объекту MDM, проверяя результаты. Хотим сделать графические библиотеки для удобства отображение, изменения и настроек связей, да и много чего в принципе полезного для пользователя и для администратора.

А вот как у нас получится — поговорим через год‑другой, когда мы снова захотим рассказать о своих успехах, или получим замечательные отзывы на Хабре.

Всем пока!

Статья подготовлена командой управления данными «Ростелеком»