Создание сайтов: лендинг, визитка, интернет магазин. Продвижение, поддержка, реклама.

Всем привет! На связи Александр Киваев, руководитель направления департамента управления справочной информацией в команде управления данными «Ростелекома». Если у вас в компании внедрена и эффективно работает MDM система, то считайте, что вы сорвали джэк-пот, потому что это значительно облегчит вам процесс внедрения новых информационных систем в IT инфраструктуру компании, упростит и удешевит интеграцию имеющихся систем, и позволит вам создавать качественную аналитическую и управленческую отчетность, сократив при этом время на обработку, актуализацию и верификацию данных.

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

MDM из коробки

В качестве основного решения для построения системы управления мастер данными мы выбрали Microsoft Master Data Services (MDS). MDS доступна для предприятий, использующих Microsoft SQL Server Enterprise Edition, начиная с версии 2014 года. MDS входит в комплект поставки и не требует дополнительных затрат на лицензирование, что стало одним из определяющих факторов выбора в пользу данного продукта.

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

Проблемы… Системы…

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

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

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

Требования к системе Master Data Management

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

Мы видели для себя следующий сценарий использования MDM системы:

1.   Подготовить эталонные корпоративные справочники.

2.   Получить данные справочников из информационных систем предприятия, которые в этом случае называются системами-источниками. Для этого можно использовать какое-либо средство из Extract Transfom Load (ETL). Помещаем полученные данные в слой, который назовём Landing.

3.   Трансформировать данные в общий формат. Для этого выполняем приведение типов к типам данных принятым в системе MDM. Полученный результат помещаем в слой, который назовем Staging.

4.   Перевести данные из слоя Staging в слой готовых справочников.

5.   Установить соответствие записей, полученных от систем-источников на записи эталонных справочников. Такое действие называется мэппингом.

6.   Предоставить системам-потребителям средства для получения данных из эталонных справочников и мэппингов.

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

Ограничения Microsoft MDS

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

Исходя из вышесказанного, получается, что система Master Data Services решает только два пункта из приведенного выше сценария:

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

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

Мы в своей работе решили использовать систему MDS, так как она была доступна без дополнительных вложений. Вместе с тем, мы дополнили её недостающими функциями, чтобы получить решение, полностью соответствующее типичному сценарию MDM.

Доработка MDS до полноценной MDM

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

1.   Была создана отдельная база данных, которая выполняла функцию слоя Landing. В таблицы этой базы средствами стандартного ETL мы поместили данные справочников, полученные из систем-источников. Для каждого справочника каждого источника была подготовлена своя таблица.

2.   В этой базе данных мы создали хранимые процедуры, которые запускаются после получения справочников из систем-источников. Хранимые процедуры выполняют выделение инкремента и помещение его из слоя Landing в стандартный слой Staging MDS (в базе данных MDS, это схема данных stg). Кроме того, хранимая процедура может выполнять автоматический мэппинг новых или измененных записей системы-источника на эталонный справочник.

3.   Далее в хранимой процедуре мы реализовали вызов оригинальной хранимой процедуры MDS, которая переносит все данные из слоя Staging в справочник MDS.

Схема передачи данных между слоями:

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

Как мы это сделали

Схема взаимодействия MDS с информационными системами компании

Для наглядности предлагаем общую картину информационных потоков между системами-источниками и MDS, между MDS и системами-потребителями:

В приведенной схеме:

• Системы-источники – это все информационные системы, из которых выполняется передача данных в MDS;

• Нормативно справочная информация – это система MDS;

• Системы-потребители – это все информационные системы, которые получают данные от MDS.

Справочники MDS

Справочник, который мы считаем эталонным, это обычный справочник MDS, с которым работают пользователи, добавляя или изменяя записи.

Справочник, полученный от системы-источника, мы тоже считаем обычным, но с одним отличием – он имеет так называемый мэппинг на эталонный справочник, то есть ссылку на запись другого справочника. В MDS ссылка указывается в свойствах атрибута справочника – следует указать справочник, который мы считаем эталонным. Для этого атрибут должен иметь тип «На основе домена».

Следует отметить, что мы разрешили пользователям изменять только один атрибут в справочнике источника – это атрибут ссылки на эталон. Этому ограничению есть важная причина: мы должны быть уверены, что записи справочника в источнике и его копии в MDS идентичны.

Экран MDS, где устанавливается ссылка атрибута на эталонных справочник:

Таблицы базы данных слоя Landing

Слой Landing не предназначен для хранения, его функция промежуточная – получить данные от системы-источника и затем выделить инкремент относительно того, что уже находится в справочнике.

Предположим, что мы имеем эталонный справочник «Услуги», сущность называется Service. И имеем справочник услуг, полученный от системы-источника, пусть эта сущность называется SERVICE_000085.

Тогда в слое Landing мы создаем два объекта баз данных:

• Таблицу lnd.SERVICE_000085;

• Хранимую процедуру lnd.Load_SERVICE_000085.

В таблице создаем поля, соответствующие полям справочника в источнике и нашему эталонному справочнику:

CREATE TABLE lnd.SERVICE_000085(
	code nvarchar(250) NOT NULL,
       Name nvarchar(250) NOT NULL,
       business_service_key nvarchar(250) NULL,
       technology_type_key nvarchar(250) NULL,
       access_service_type_key nvarchar(250) NULL,
      [service_type_key nvarchar(250) NULL
)

В хранимой процедуре пишем программный код:

CREATE PROCEDURE lnd.Load_SERVICE_000085
AS
BEGIN
       --Подготовка уникального имени пакета BatchTag
       declare @SourceSystem varchar(50) = 'SERVICE_000085' + '_' + getdate()
 
       --Выполнение сравнения со справочником для выборки новых записей, полученных от системы-источника. Для сравнения используем представление справочника mdm.SERVICE_000085_V предварительно подготовленное в разделе MDS «Управление интеграцией».
       --Помещение выбранного в таблицу слоя Staging.
       insert into stg.SERVICE_M_000085_Leaf
             (
             ImportType
             , ImportStatus_ID
             , BatchTag
             , Code
             , Name
             , business_service_key
             , technology_type_key
             , service_type_key
      
             )
             select
                    '0'
                    , '0'
                    , @BatchTag
                    , l.code
                    , l.Name
                    , l.business_service_key
                    , l.technology_type_key
                    , l.service_type_key
      
             from lnd.SERVICE_000085 as l
             left join mdm.SERVICE_000085_V as ve on l.code = ve.code
                    where
                           ve.code is null
      
 
       declare @count int = @@ROWCOUNT
 
       if (@count > 0)
       begin
             --Запуск стандартной хранимой процедуры MDS для помещения записей из слоя Staging в справочник
             EXEC stg.udp_SERVICE_000085_Leaf
                    @VersionName = 'VERSION_1', 
                    @LogFlag = 1, 
                    @BatchTag = @BatchTag, 
                    @UserName = 'SIUSER'
 
       end
END

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

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

Web Services и запросы REST

MDS предлагает только один способ получения данных справочников системами-потребителями – это подключение по dblink к базе данных и выполнение запросов к представлениям (view). Однако, на сегодняшний день этот способ считается уже морально устаревшим и небезопасным. Сегодня для обмена данными компании предпочитают использовать Web Services с запросами REST, которые и удобнее и предпочтительны с точки зрения информационной безопасности.

Мы решили разработать Web Services, которые, обращаясь к базе данных MDS, выполняют запросы к представлениям справочников и полученные данные передают системе-потребителю в виде структур JSON или XML.

В рамки этой статьи не входит описания создания Web Services, но мы поделимся своим подходом, как всё организовали.

Метаданные MDS

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

Например, формат тела запроса REST можно сделать таким:

{"format": "формат ответа",
   "name": "имя_сущности",
    "where": [
        {
            "name": "имя_поля1",
            "operator": "=",
            "value": "значение для сравнения"
        },
        {
            "name": "имя_поля2",
            "operator": ">=",
            "value": "значение для сравнения"
        }
    ]
}

Где:

• format – параметр, задающий формат возвращаемых данных. Возможны два значения: json или xml;

• “name”: “имя_сущности” – наименование сущности, из которой выбираются данные;

• Необязательный блок “where” содержит параметры для фильтрации данных, где: “name”: “имя_поляN” – имя поля, по которому фильтруются данные справочника, “operator”: “=” – оператор сравнения для фильтрации данных. Допустимые операторы:

Необязательный блок “where” содержит параметры для фильтрации данных, где:

• “name”: “имя_поляN” – имя поля, по которому фильтруются данные справочника;

• “operator”: “=” – оператор сравнения для фильтрации данных. Допустимые операторы: = равно, <> не равно, > больше, < меньше, >= больше либо равно, <= меньше либо равно;

• “value”:  “значение для сравнения” – значение, с которым сравниваются значение поля.

Тело запроса может выглядеть так:

{"format": "json",
  "name": "service_000085",
    "where": [
	 {
            "name": "technology_type_key",
            "operator": "=",
            "value": "PSTN/Телефония"
        },
        {
            "name": "lastchgdatetime",
            "operator": ">",
            "value": "2018.12.31 10:30"
        }
    ]
}

Далее мы опираемся на метаданные MDS. В таблице mdm.tblEntity находится перечень всех сущностей и их свойства. В таблице mdm.tblAttribute содержатся атрибуты сущностей и их свойства.

Приложение сервиса выполняет sql-запрос к метаданным MDS, чтобы получить перечень пользовательских атрибутов и их типы данных.

SQL-запрос к метаданным MDS:

select a.Name, a.AttributeType_ID, a.DataType_ID from  mdm.tblAttribute as a
	inner join  mdm.tblEntity as e on a.Entity_ID = e.id
						and e.name = 'SERVICE_000085'

После чего приложение генерирует sql-запрос, где указывает имя представления справочника, заранее подготовленного в разделе MDS «Управление интеграцией», все пользовательские атрибуты и условия отбора записей.

Sql-запрос к представлению справочника может выглядеть так:

select Code, Name, ImportType, ImportStatus_ID, business_service_key, technology_type_key, technology_type_key 
	from mdm.SERVICE_000085_V
		where technology_type_key = 'PSTN/Телефония'
		and lastchgdatetime > '2018.12.31 10:30'

В итоге, мы получили полноценный web-сервис, который может возвращать данные любого указанного справочника в независимости от того, когда он был добавлен в MDS и был ли изменен состав его атрибутов.

Общий итог

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

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

В ближайшем будущем у нас запланировано замещение проприетарных компонент разработанного решения на отечественные и open-source аналоги с максимальным переиспользованием имеющихся наработок. Для нас это новая планка и естественное продолжение развития MDM-решений в компании. Но об этом мы напишем в нашей следующей статье.

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