Перекодер — НСИ нового поколения

в 11:07, , рубрики: Без рубрики

С годами компания обычно доходит до того, что много справочников на одну тему (например, «Хобби» или «Пол») хранятся в совершенно невообразимых форматах в различных системах, препятствуя эффективной интеграции и обмену данными.

Традиционный подход в таких случаях рекомендует создавать единую версию справочника «Хобби» и настраивать потоки обмена в него (и из него) для всех информационных систем. Мы же решили пойти другим путем и разработали для этого новый опенсорсный продукт — Перекодер.

Хотите знать, что мы сделали, и какую роль в нашем продукте играют Lucene и Apache CXF? Читайте дальше!

Как обычно решается задача хранения справочников?

IT-директор решает прекратить видовое разнообразие справочников, и компания начинает заниматься построением единого справочника. Он будет призван объединить в себе все возможные виды корпоративных данных и наконец-то положить конец «лоскутной автоматизации» и «историческому наследию».
Если уж решать проблему, то сразу для всего, правда?

А вот и нет.

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

Не верите — посмотрите сами на таблицу с типами данным, которые обычно встречаются в компании:

Что описывают Стол, станок и т.д. Физические, юридические лица, ЧП/ИП. Атрибуты сущностей: образование, профессия и т.д.
Критерий истины атрибутов Объективный (есть реальный станок, на который можно посмотреть) Объективный (есть реальный человек или компания, у которого можно все спросить) Субъективный (мнение эксперта, который может быть кагбе не совсем прав, или системы)
Размер Средний (десятки тысяч единиц) Средний или большой (сотни тысяч и миллионы записей) Малый (тысячи единиц)
Количество атрибутов Среднее (атрибуты ТМЦ) Среднее (атрибуты клиента) Малое (в большинстве случаев структура типа id — название)
Как существующие объекты меняются во времени? Редко Постоянно изменяются (смена адреса, семейного положения, пола...) Непредсказуемо меняются в зависимости от потребностей информационной системы или бизнес-процесса

На практике самые быстрые и успешные внедрения происходят в тех компаниях, которые отдельно решают задачу ТМЦ, отдельно — задачу построения справочника контрагентов, и как-то по ходу разбираются с классификаторами.

Для ТМЦ обычно внедряется Product Information Management (PIM), для контрагентов — Customer Data Integration (CDI), а вот с классификаторами происходит интересное: для них часто отдельно внедряется НСИ (MDM) и формируется единая версия правды.

Правильно ли внедрять НСИ и создавать единую версию классификаторов? Или можно решить эту задачу по-другому?

Хорошо ли иметь единую версию правды для классификаторов?

При приведении классификаторов к единому виду обычно происходит один из сценариев:

  1. Создается монстро-справочник, который учитывает все комбинации в исходных системах. Этот сложный справочник с трудом поддается модификации, требует длительных согласований, и со временем на него потихоньку все забивают
  2. Создается единый справочник, который содержит в себе урезанную версию правды, устраивающую всех. Кто работал в большой компании, тот знает, что поиск «правды, устраивающей лебедя, рака и щуку» редко заканчивается успешно, а если заканчивается, то требует много-много часов ожесточенных совещаний.

В общем, единая версия правды обычно обходится дорого.

Кроме того, с единым стандартом всегда появляется проблема «серой зоны». Это разница между значениями в исходных системах и значениями вожделенной единой версии правды, которые собственноручно подтвердил специально назначенный эксперт. Наличие «серой зоны» и необходимости работы с ней приводит к появлению многочисленных воркфлоу и альтернативных потоков, что составляет значительную часть функционала (читай стоимости) НСИ.

А еще и бизнес не всегда готов ждать многочисленных согласований годами. Поэтому в итоге данные начинаются пробрасываться «под столом», с использованием «временных» перекодировок (что это такое, мы расскажем ниже).

Можно ли не создавать единую версию правды?

Возникает закономерный вопрос: если единая версия правды так дорого обходится, можно ли обойтись без нее?

Можно — есть организации, в которых не внедрены НСИ. Внимательно посмотрев, вы обнаружите в этих организациях много маленьких таблиц соответствия между справочниками «Пол», «Образование» и пр. в разных системах. Храниться они будут то в Oracle, то на шине, а то и прямо в коде для загрузок-выгрузок и экспортов-импортов. Потому что таблицы соответствия — это самый естественный способ решения проблемы, когда одинаковый домен для разных людей или систем обозначается по-разному.

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

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

Основное назначение Перекодера — хранить в себе копии справочников исходных систем и перекодировки между ними.

Как это все работает

  • В начале работы Перекодер считывает справочники из баз данных исходных систем и сохраняет их копии к себе в базу для последующей автоматической синхронизации. Мы работаем с Sybase, MariaDB, Vertica, MS SQL Server, MySQL, Oracle, PostgreSQL.

    Перекодер — НСИ нового поколения
    Пруфпик

  • В интерфейсе Перекодера оператор настраивает таблицы соответствия записей справочников. Например, если мужской пол в одной системе заведён как «М», а в другой как «1», то оператор ставит в соответствие эти два значения, создавая перекодировку.
  • Теперь любая система в процессе обмена информацией с другой системой может запросить у Перекодера через SOAP или REST интерфейс перевод значения из своего классификатора на язык целевой системы или перевести полученный данные на свой диалект.

    Перекодер — НСИ нового поколения
    Перекодировка из справочника «Тип документа» некой банковской системы (АБС) в справочник «Тип ДУЛ» для CRM. Загранпаспорт соответствует общегражданскому заграничному паспорту, водительское удостоверение соответствует иным документам. АБС и CRM не нужно интегрировать с мастер-справочником, все довольны.

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

Что можно делать с помощью Перекодера

Можно и нужно:

  • Управлять справочниками, группами справочников и перекодировками (создавать, редактировать и удалять).
  • Настраивать периодические синхронизации справочников Перекодера с исходными системами.
  • Выполнять онлайн-перекодировки и получать значения исходных справочников через SOAP и REST интерфейсы.
  • Получать автоматические оповещения об изменениях в исходных справочниках. Если вдруг появилось значение, для которого нет перекодировки, SOAP/REST вернут ошибку и оповестят всех заинтересованных лиц.

Перекодер — НСИ нового поколения
Классификатор «Программа обслуживания клиента», в котором атрибуты почему-то названы нерусскими словами Description и Full Description

Что под капотом?

Система разбита на модули, чтобы изолировать API, бизнес-логику и хранилище друг от друга. Связующим IoC контейнером между компонентами выступает Spring Framework.

Технологическую схему потоков данных можно представить так:
Перекодер — НСИ нового поколения

Как можно видеть, сервисы вообще не взаимодействуют напрямую с БД. Вместо этого вся работа (read / write) идет с индексом Lucene, а результаты write-операций дополнительно записываются в базу. Для чего так сделано? Все просто: основная задача системы — максимально быстро найти перекодировку (соответствие между записями в паре справочников), а такая архитектура наиболее эффективно справляется с этим на больших объемах данных. Плюс ко всему, получаем полнотекстовый поиск по всем данным «из коробки». Конечно, можно было бы использовать более высокоуровневые решения, например Elasticsearch или Solr, но у них есть свои недостатки, борьба с которыми выходит дороже, чем написать свой код.

Для того чтобы обеспечить целостность информации, модификация данных производится в одной транзакции в поисковом индексе и в базе. Причем интерфейсы спроектированы так, что бизнес-логика приложения знает только об индексе, а СУБД можно заменить на другое решение с минимальными модификациями. Фактически нужно реализовать пару классов и добавить их в classpath — все остальное сделает Spring и фабрики компиляции классов на лету (runtime code compiling).

Каркасом для SOAP и RESTfull интерфейсов выступает Apache CXF, который позволяет легко настроить версионность API (если вдруг понадобится изменить его) и вклиниться в любую фазу обработки входящего/исходящего сообщения.

Исходный код

github.com/hflabs/perecoder

Тестовый стенд

rcd.hflabs.ru/rcd/admin/login/
Логин: admin
Пароль: demo

Документация

confluence.hflabs.ru/x/RICSCg

Что дальше

Мы начали внедрение Перекодера у нескольких заказчиков.
Будем рады вашим комментариям по функциональности: что нравится, что нет, что непонятно.
Ну и если этот продукт будет вам полезен, значит, мы не зря потратили время на написание этой статьи ;)

Автор: lyalius

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js