CC BY
297
УДК 004.9
А.Г.Алаудинов
Построение единой системы интеграции данных в крупных корпорациях
Аннотация
В статье рассмотрены принципы построения единой системы интеграции данных в крупных корпорациях. Предлагаются состав и структура подобной системы. Проведен анализ проблем и предложено решение по интеграции родительских систем.
Ключевые слова: СЭД, интеграция, родительские системы, ECM, документ, ERP
Ayub Alaudinov
The article deals with the principles of constructing a unified data integration system in large corporations. Proposed composition and structure of such system.The analysis of problems and suggested solution for the integration of parental systems.
Keywords: Docflow, Integration, Parental Systems, ECM, Document, ERP
ВВЕДЕНИЕ
Информационные технологии (ИТ) широко используются в различных сферах деятельности крупных компаний.Они позволяют оптимизировать информационные процессы, роль и значение которых для развития крупных компаний является стратегической, при этом значение самих технологий быстро возрастает.
Информационные системы (ИС) крупных компаний сегодня используют и накапливают большой объем транзакционной и справочной информации, кроме того ИС тесно взаимосвязаны друг c другом через множество интеграционных сценариев необходимых для автоматизированного решения ряда бизнес-задач. Определение же самих бизнес-задач, а также сопровождение автоматизированных процессов осуществляется с помощью управленческой, производственной и проектной документации крупных компаний, которая одновременно является источником, результатом и инструментом процессов.
АКТУАЛЬНОСТЬ ТЕМЫ
Большинство крупных и средних российских предприятий к настоящему моменту прошли первичный этап автоматизации, в ходе которого была создана необходимая инфраструктура, внедрены промышленные ERP-системы. Сегодня, когда инвестиции в ИТ-проекты подвергаются значительным сокращениям, организации, в первую очередь, вкладывают средства в повышение эффективности использования уже установленных систем. Одна из актуальных задач повышения эффективности - задача связывания структурированных и неструктурированных данных, возникающих при работе с различными информационными системами обеспечения единого подхода к управлению жизненным циклом и хранением документов [1]. На сегодняшний день в крупных компаниях образовался и сохраняет тенденцию разрыва процесс участия документов в автоматизации бизнеспроцессов. Зачастую тот или иной бизнес-процесс, автоматизируется локально, без учёта потребности смежных процессов. Отсутствие эффективной технологии управления документами, в конечном счете, приводит к многократному тиражированию документов, различному способу их описания и учета, отсутствию полной информации о состоянии работ, и как следствие, к образованию большого объема неструктурированной корпоративной информации.
Совершенствование процессов управления документами и повышение эффективности коллективной работы должно стать частью общей стратегии развития информационной системы крупных компаний и предусматривать развитие технологии управления документационными потоками.
Единая система интеграции данных (ЕСИД) должна стать платформой, которая объединяет разрозненные системы управления документами в единую корпоративную информационную систему и позволит создавать распределённые процессы управления документами, затрагивающее все информационные системы предприятия: управление ресурсами предприятия (ERP), системы управления документами (ECM), мультимедиа архив, хранилища данных.
ЕСИД позволит без существенных изменений использовать существующие информационные системы и технологии в том объеме и виде, в котором они удовлетворяют потребности пользователей, в то же время позволит организовать эффективное взаимодействие между системами и организационными единицами
общества [2]. ЕСИД должна обеспечить организацию единого информационного пространства для доступа ко всем видам документов, образующимся в хозяйственной деятельности крупных компаний.
Такой подход позволяет достичь следующих целей:
• консолидирование информации по всем документам (в т.ч. архивным) в одном месте;
• обеспечение связи с другими существующими информационными системами, осуществляющими учет и хранение документов;
• исключение многократной регистрации одного и того же документа;
• контроль и управление документами;
• эффективный поиск документов;
• возможность организации доступа к документам с мобильных устройств;
• обеспечение доступа к документам непосредственно из приложений ERP и клиентских приложений;
• подготовки аналитических данных;
• автоматическое формирование электронного архива.
МОДЕЛИ ИНТЕГРАЦИОННЫХ РЕШЕНИИ
Топология интеграционного решения отражает различные способы взаимодействия приложений, среди которых можно выделить соединения точка-точка, шлюзы и шины [3].
Децентрализованное соединение точка-точка означает, что интегрируемые приложения устанавливают прямые связи друг с другом. Данная модель обычно используется на начальной стадии любого интеграционного проекта как наиболее простой подход. Отличительной особенностью рассматриваемой модели являются многочисленные связи (интерфейсы) между приложениями, которые повышают трудоемкость управления корпоративной информационной системой. Это связано с тем, что с вводом нового приложения количество новых интерфейсов растет по
формуле n (n-1), где n — число приложений. При модификации одного из приложений корпоративной информационной системы возможно усложнение поддержки всей системы, в результате может снизиться эффективность принятия решений и управления бизнес-процессами.
Переход от модели взаимодействия точка-точка к моделям взаимодействия на основе централизованного шлюза или на основе шины обусловлен существенным уменьшением количества интерфейсов до 2n. Модели интеграции на основе шлюза и шины относятся к классу программного обеспечения промежуточного уровня (middleware), обеспечивающего трансформацию, транспортировку, маршрутизацию данных. Дополнительными функциями шлюза и шины являются: асинхронный тип взаимодействия на основе обмена сообщениями в формате XML; вызов приложений в последовательности, определенной бизнес-процессом; обеспечение
гарантированной доставки данных, а также их защиты и безопасности; динамическая маршрутизация данных, анализ содержимого коммуникаций. Внедрение и адаптация шлюза на основе интеграционного сервера или шины корпоративных сервисов связаны с существенными капитальными вложениями. С другой стороны, необходимость использования интеграционного решения класса middleware продиктована не только трудоемкостью управления моделью точка-точка, но и ее недостаточной надежностью.
Одним из популярных подходов к построению интеграционной шины является ESB (Enterprise Service Bus - сервисная шина предприятия). ESB обеспечивает взаимосвязь между корпоративными приложениями по различным протоколам взаимодействия. Система ESB строится на основе сервис-ориентированной архитектуры с использованием веб-сервисов. Конкретные реализации ESB содержат в себе адаптеры для соединения различных приложений. В качестве примеров подобных систем можно назвать SAP NetWeaver XI/PI (Exchange Infrastructure/ProcessIntegration) от SAP AG, BizTalk от Microsoft, WebSphere от IBM, webMethods компании Software AG, SOA Suite от Oracle Corporation.
Общей чертой систем интеграции является необходимость структурировать все данные подлежащие обмену. Процесс структурирования контента является весьма сложной и трудоемкой задачей. Более того, в случае изменения структуры данных одной из систем возникает потребность в доработке коннекторов между системами
в случае соединения типа точка-точка или коннекторов между системой и шлюзом (шиной). Однако, для интеграции данных в качестве единого общекорпоративного контента достаточно построить открытую и расширяемую ЕСИД, которая будет обеспечивать доступ для пользователей к данным из всех корпоративных информационных систем. Рассмотрим пример структуры ЕСИД и алгоритм интеграции родительских систем.
ОПИСАНИЕ ЕСИД
ЕСИД состоит из трёх подсистем (Рис.1.): хранения,трансформации и
индексирования данных, пользовательских интерфейсов и сервисов.
1. Система хранения документов является совокупностью репозиториев (место, где хранятся, поддерживаются данные используемые в одной или нескольких информационных системах, описанные в качестве бизнес-сущностей).
2. Система трансформации, индексирования и классификации документов обеспечивает процессы преобразования, распознавания документов, индексирования и поиска в информационных системах и хранилищах, сбор и консолидацию данных для перемещения в специализированные хранилища, содержит в себе информацию обо всех документах доступных пользователям системы, а так же о связях между объектами и документами.
3. Пользовательский интерфейс для доступа к корпоративным документам представляет собой индивидуально настраиваемый ресурс на основе WEB технологий, который должен удовлетворять следующим требованиям:
- обеспечивать поиск документа, как по реквизитам, так и по содержимому;
- предоставлять возможность пользователю систематизировать доступные документы по собственным критериям, организовывать персональные структуры и иерархии;
- обеспечивать возможность создания как собственных, так и групповых классификаций;
- построение логических связей между документами и объектами;
- программные интерфейсы, реализующие доступ к данным в соответствии со спецификацией CMISvl.0.
ЕСИД должна индексировать и поддерживать в актуальном состоянииинформацию обо всех объектах в родительских системах (информационная система, реализующая бизнес- процессы организации и содержащая данные, необходимые в бизнес-процессах реализуемых за пределами этой информационной системы) обо всех реквизитах объекта, его содержании, ограничениях на его использование. Обеспечивать хранение и обработку пользовательских классификаций, связей объектов между собой и с внешними объектами.
Система ЕСИД реализует 2 основные функции:
- поиск объектов корпоративной информационной системы;
- консолидацию и помещение на хранение неизменных данных (записей).
Для реализации функции поиска (программно-аппаратный
комплекспредоставляющий возможность поиска необходимой информации в репозитории и родительских системах используя поисковый механизм и систему классификации) объектов ЕСИД имеет интеграционные сценарии для доступа к объектам всех информационных систем, предоставляющим свои объекты в качестве объектов поиска. Производит периодическую индексацию объектов, хранит индексную базу метаданных (данные, описывающие контекст, содержание, структуру официальных документов (записей) и процесс управления ими во времени), имеет средства для трансформации, подготовки,вывода данных и пополнения индексной базы.
Для реализации функции управления записямиЕСИД производит процессы сбора, подготовки, и помещение на хранение записей в единое хранилище. Хранилище записей так же является одной из информационных систем, предоставляющих объекты для поиска.
Рис. 1. Структура ЕСИД.
В общем случае, работая с интерфейсом ЕСИД, пользователь может не иметь доступа ни к одной из родительских систем, но в зависимости от настроек классификации ЕСИД, а так же от атрибутов родительских систем получать, хранить и обрабатывать необходимые объекты.
Интеграция родительских систем
Основной сложностью при построении системы интеграции данных является проблема классификациинеструктурированного контента. Любая попытка структурировать все многообразие информационных потоков крупных компаний становится камнем преткновения для создания интеграторов. Рассмотрим решение которое позволяет объединять информацию из родительских систем для трансформации, классификации, индексирования и поиска без предварительной классификации.
Алгоритм интеграцииродительских систем (Рис.2.):
1. Заполнение метаданных.
1.1. Все родительские системы определяют набор всевозможных реквизитов (расширяемый). Для этого заполняется таблица показателей поле name. Если разные системы имеют общий реквизит, то он заносится один раз. Сама родительская система - один из реквизитов.
1.2. Определяется селективность реквизитов (количество уникальных значений). Таблица показателей, поле weight. Учитывается значения из разных систем (для общих реквизитов). После чего, таблица показателей упорядочивается по возрастанию поля weight. Новые показатели добавляются в конец. Таблица показателей не может менять порядок строк.
1.3. Определяется, какие реквизиты общедоступные, а какие имеют
персонифицированный доступ. Таблица показателей, поле public.
Родительские системы, не поддерживающие авторизацию ActiveDirectory предоставляют только общедоступную информацию.
2. Заполнение данных.
2.1. Каждая запись (документ) содержит набор реквизитов, каждый из которых занесен в метаданные.
2.2. Реквизиты конкретной записи упорядочиваются по таблице показателей.
2.3. Внесение первой записи в таблицу данных. Все реквизиты
заносятся поочередно в таблицу данных: идентификатор реквизита заносится в поле ParametrId, значение в поле Value, в поле ParentId
заноситсяидентификатор (Id) строки в которую занесли предыдущий реквизит. Для первого реквизита поля Id и ParentId равны.
2.4. Последующее заполнение таблицы данных. Если первый реквизит
в таблицу данных уже занесен то производится переход к следующему, при условии что в качестве ParentId указан идентификатор записи в которой хранится предыдущий реквизит и т.д. пока не наступит реквизит новой записи которого еще нет в таблице данных. Далее заносятся реквизиты новой записи которых нет в таблице данных (по аналогии с п.2.3.). При этом в качестве ParentId для первого нового реквизита указывается^ последнего совпавшего.
3. Заполнение таблицы доступа.
3.1. Каждая запись сопровождается либо признаком общедоступности (public) либо списком доступа в виде списка логинов ActiveDirectory.
3.2. По каждому документу, в таблицу доступа заносится идентификатор документа (поле Id таблицы данных) и логин. Если по одному документу список доступа состоит из m логинов, то в таблицу доступа заносится m записей. Для общедоступных документов заносится одна запись с особым признаком (public).
4. Поиск информации в ЕСУД.
4.1. Не структурированный поиск: пользователь задает только ЧТО искать (не задает в каком реквизите, в какой системе). Поиск производится в поле Value, тех реквизитов которые имеют признак public.
4.2. Структурированный: пользователь знает ЧТО и ГДЕ искать. Задает набор реквизитов по которым планируется поиск, если среди них есть реквизит с персонифицированным доступом, то учитывается авторизация ActiveDirectory.
Опционально: Те реквизиты которые имеют общий уровень доступа и мало уникальных значений могут быть вынесены в отдельные таблицы, при поиске
они становятся выпадающими списками.
*
Active Directory
*
Родительская Родительская Родительская
система 1 система 2 система п
T
T
Access List
Docld Login
1 public
2 oao\ivanov ss
2 oaoVkulagin ap
data (данные) parametr (Показатели)
Id Parametrld Value Parentld id name weight public
1 1 LanDocs 1 1 Родительская система 10 1
2 3 Приказ 1 2 Год 40 1
3 7 О работе в выходные дн 2 3 Вид документа 200 1
4 2 2010 1 4
5 3 Письмо 4 5 Контрагент 500 0
6 5 Ксерокс 5 6
7 1 R3 7 7 Краткое содержание 1000 0
8 2 2009 7
9 3 Счет фактура 8
10 5 Ксерокс 9
11 Синий цвет данных ^ Красный цвет доступа
12
13 5 Майкрософт 9
Рис. 2. Схема интеграции родительских систем.
ЗАКЛЮЧЕНИЕ
Отличительной особенностью и преимуществом предложенного решения является отсутствие потребности в структурировании данных, что позволяет ускорить и упростить процесс интеграции. Описанное решение является аппаратно и программно независимым механизмом интеграции ИС предприятия. Объединение всех ИС в единую систему интеграции данных существенно эффективнее по сравнению с построением точечных коннекторов между ИС, существенное изменение или замена одной из ИС приводит соответственно к изменению или созданию одного коннектора - к ЕСИД, а не множества коннекторов к ряду ИС предприятия. Данный подход к объединению ИС позволяет ускорить поиск неструктурированных данных и может быть реализован на уже существующих в предприятиях открытых программно-аппаратных комплексах.
Список литературы
1. Самофалов М., Завгородний П. Решения Open Text в области управления данными для SAP- инсталляций. CNEWS. URL: http://www.cnews.ru/reviews/free/dms2008/case/terralink/.
2. Грегор Хоп, Бобби Вульф. Шаблоны интеграции корпоративных приложений. М., Вильямс, 2006.
3. В.В. Бахтизин, Ю.В. Бородаенко. Модели интеграционных решений на предприятии и их надежность. Минск, Доклады БГУИР №4 (20), 2007.
4. Дубина О. Паттерны интеграции корпоративных информационных систем. CITFORUM. URL: http://citfomm.ru/SE/project/pattem/p_4.shtml.
5. Колесов А. Новые веяния на мировом рынке ECM // Журнал PCWEEK. 2010. URL: http://www.pcweek.ru/ecm/article/detail.php?ID=127009
6. Глинских А. Мировой рынок систем электронного документооборота //
CITF ORUM.URL: http://citforum .ru/consulting/docflow/market/article 1.8.2002 .html#AE N10
7. Сокова А.Н., Рекомендации по использованию Национального стандарта ГОСТ Р ИСО 15489-1-2007 «Система стандартов по информации , библиотечному и издательскому делу. Управление документами. Общие требования» в российском делопроизводстве. // Делопроизводство. 2008.№ 2.
8. Ефремов В., CMIS: управление контентом как сервис. М., Открытые системы. 2002. № 9.
9. Храмовская Н.А., Концептуальная модель новой версии стандарта MoReq. Электронные офисные системы. М.,Феникс.
