ЛК 5 Вичугова Анна Александровна Инструментальные средства информационных систем Методы и средства интеграции информационных систем

Зачем нужна интеграция ИС 2 Формирование единых стандартов и подходов при автоматизации бизнес - процессов на уровне функциональных подразделений компаний Учет и анализ характеристик используемых ИС в целях формирования программы развития информационно - технологической инфраструктуры Повышение прозрачности и управляемости бизнес - процессов, поддерживаемых информационными системами компаний Снижение вероятности появления операционных и прочих ошибок, связанных с вводом и передачей деловой информации в ручном режиме Сокращение длительности выполнения " сквозных " бизнес - процессов Сокращение трудозатрат за счет реализации однократного ввода информации и интегрированного документооборота Обеспечение сохранения инвестиций в информационные технологии Уменьшение числа ошибок во взаимодействии прикладных систем Снижение времени и стоимости внедрения новых систем

Уровни интеграции данных 3 Физический - наиболее простая задача - конверсия данных из различных источников в требуемый единый формат их физического представления. Логический - предусматривает возможность доступа к данным, содержащимся в различных источниках, в терминах единой глобальной схемы, которая описывает их совместное представление с учетом структурных и, возможно, поведенческих ( при использовании объектных моделей ) свойств данных. Семантические свойства данных при этом не учитываются. Семантический - поддержка единого представления данных с учетом их семантических свойств в контексте единой онтологии предметной области.

Ключевые различия ИС 4 определяются следующими их архитектурными компонентами : схема или модель данных интегрируемых ИС технологический стек, на котором реализовано приложение ( базовое ПО, СУБД, сервер приложений и т. д.) различие в моделях бизнес - процессов и в механизмах их реализации

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

Структурные и семантические конфликты 6 Различие в типах данных. Некоторый домен в одном источнике может представляться числом, в другом строкой фиксированной длины, в третьем строкой переменной длины. Различие в единицах измерения. В одной БД указана величина в сантиметрах, в другой в дюймах. В этом случае существует отображение 1:1. Различие в множестве допустимых значений. Один и тот же признак может определяться разными наборами констант. Например, выполнение задания одним источником может оцениваться по четырех бальной шкале, другим по трехбалльной, третьим по стобальной. Отображение не является 1:1, оно может быть многозначным, может не иметь обратного, может зависеть от сторонних данных ( например, 30 по математике - « удовлет.», а по русскому языку « неуд.»). Различие « домен - отношение ». Домен в одной БД ( строковое значение ) соответствует таблице в другой БД ( записи из таблицы - справочника ). Различие « домен группа доменов ». В одном источнике адрес записывается одной строкой, в другом отдельные поля для улицы, дома, строения, квартиры. Различие « данные - схема ». Данные одной БД соответствуют схеме ( метаданным ) другой. В одной БД « инженер » значение атрибута « должность » отношения « работник », в другой « инженеры » отношение, содержащее некоторых работников, в то время как « бухгалтеры » содержит других. Отсутствующие значения. В каком - то из источников может отсутствовать информация, имеющаяся в большинстве других.

Типы несоответствия собственно данных 7 Различие формата данных. « ул. Бахрушина, 18-1» или « Бахрушина, д.18, стр.1»; «8(910) » или « » Различие в представлении значений. Например, « Новолипецкий металлургический комбинат », « НЛМК », « ОАО НЛМК » Потеря актуальности данных одним из источников. Например, смена фамилии : в одной БД записана новая фамилия, в другой старая, и они не совпадают Наличие ошибок операторского ввода ( или ошибок распознавания бланков ) в отдельных источниках данных. Сюда относятся механические опечатки, ошибки восприятия на слух сложно произносимых имен / названий, отсутствие единых стандартов транскрипции с иностранных языков Намеренное внесение искажений с целью затруднить идентификацию сущностей Перечисленные различия приводят к дублированию записей при интеграции данных в одну БД. Разрешение перечисленных проблем и устранение дублирования записей вручную практически невозможно. Имеется множество методов для ее автоматического и полуавтоматического решения.

Система интеграции приложений обеспечивает 8 Согласование данных, используемых различными приложениями Синхронизацию и маршрутизацию информационных потоков в соответствии с определенными бизнес - правилами Преобразование данных по заданным алгоритмам Поддержку интерфейсов к существующим промышленным системам, системам технологического уровня Поддержку удобного интерфейса пользователя для описания бизнес - правил и алгоритмов взаимодействия приложений Поддержку промышленных стандартов в области передачи и обработки данных Интеграцию промышленных приложений между собой, например, SAP/R3, Oracle EBS, People Soft, Hyperion, Siebel, 1C и др.

Задачи разработки систем интеграции 9 Разработка архитектуры системы интеграции данных Создание интегрирующей модели данных, являющейся основой единого пользовательского интерфейса в системе интеграции Разработка методов отображения моделей данных и построение отображений в интегрирующую модель для конкретных моделей, поддерживаемых отдельными источниками данных Интеграция метаданных, используемых в системе источников данных Преодоление неоднородности источников данных Разработка механизмов семантической интеграции источников данных

Основные подходы к интеграции ИС 10 построение единой корпоративной ИС установление прямой связи между интегрируемыми ИС ( интеграция отдельных приложений ) сервисно - ориентированное решение

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

Установление прямой связи между ИС 12 Подходит для объединения малого количества приложений, в этом случае стоимость подобного решения невысока, поддержка обходится относительно недорого. Но это до тех пор, пока не наступает момент обновления ИС, поскольку « наладочные работы » при замене приложения сравнимы по объему и затратам с первоначальным проектом по интеграции. Добавление каждого нового приложения ведет к увеличению затрат и существенному усложнению интеграционной модели. Таким образом, построение интерфейсов по принципу « точка - точка » наиболее удобно в тех случаях, когда необходимо связать небольшие количество ИС, а требования к интеграции ограничиваются синхронизацией данных между ними. Рост связей при таком подходе идет по формуле (N – 1) · N, где N – число интегрируемых ИС. Такой характер увеличения связей между ИС значительно усложняет архитектуру и делает ее трудно эксплуатируемой и развиваемой. При интеграции каждая ИС должна содержать адресную информацию о том, с кем она взаимодействует, а также выполнять преобразование форматов данных. Таким образом, вопросы согласования форматов данных, передачи данных, обеспечения надежности и безопасности должны решаться отдельно для каждой пары ИС. Это усложняет интеграционную логику при выполнении простых сценариев взаимодействия.

ESA (Enterprise Service Architecture) 13 Основная ценность архитектуры ESA ( или ESB – Enterprise Service Bus, сервисная шина предприятия ) состоит в том, что она предлагает принцип более свободного соединения ИС посредством сервисов. Благодаря таким открытым интерфейсам задача интеграции сводится к реализации единого интегрирующего компонента, который осуществляет связи ИС через их публичные сервисы. Такой подход обеспечивает слабую связанность участников обмена в рамках определенных регламентов, а, следовательно, гибкость и адаптивность всей структуры.

ESA/ESB 14 Компонент ESB является медиатором между сервисами и обладает достаточно четким набором функциональности. В первую очередь шина предоставляет транспорт для передачи данных от источника до получателя. Тут вместо топологии « каждый с каждым » получается топология «hub», где роль hub а выполняет ESB. Следующий блок функциональности интегрирующего компонента – это подключение к нему сервисов. Задача ESB – обеспечить подключение всех « заинтересованных » систем к центральной шине и обеспечить всех необходимым форматом данных. Внутри самой шины можно использовать промежуточный формат данных ( например, XML), который обеспечивает унифицированное представление данных и метаданных. Сервисы подключаются к шине через адаптеры, трансформирующие внутреннее представление данных шины в родной формат сервиса. Адаптера может и не быть, если формат сервиса принят как стандарт внутри шины. Таким образом, достигается прозрачное соединение всех ИС через центральный узел, шину данных. Кроме транспортной функции у шины появляется задача маршрутизации данных между источниками и приемниками. На этой стадии можно задействовать и Workflow- технологии.

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

Популярные методы интеграции ИС 16 обмен файлами, в которые помещаются общие данные общая база данных ( БД ), в которой сохраняется общая информация удаленный вызов процедур в рамках систем обмена сообщениями для выполнения действий или обмена данными

Архитектура систем интеграции 17 Консолидация - данные из нескольких источников сливаются в Хранилище, но не распространяются из него обратно в распределенную систему Федерализация – физического перемещения данных не происходит : данные остаются у владельцев, доступ к ним осуществляется при необходимости ( при выполнении запроса ) Распространение данных – двустороннее копирование данных из одного места в другое Сервисно - ориентированный подход – основан на использовании распределённых, слабо связанных заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам

Консолидация данных 18 данные извлекаются из источников, и помещаются в Хранилище данных. Процесс заполнения Хранилища состоит из трех фаз извлечение, преобразование, загрузка (Extract, Transformation, Loading ETL). Во многих случаях именно ETL понимают под термином « интеграция данных ». Распространенная технология консолидации данных управление содержанием корпорации (enterprise content management, ECM). Большинство решений ECM направлены на консолидацию и управление неструктурированными данными, документы, отчеты и web- страницы. Часто консолидированные данные служат основой для приложений бизнес - аналитики (Business Intelligence, BI), OLAP- приложений При использовании этого метода существует задержка между моментом обновления информации в первичных системах и временем, когда данные изменения появляются в конечном месте хранения.

Компоненты корпоративного хранилища данных 19 ETL - Extract, Transformation, Loading - извлечение, преобразование, загрузка

Федерализация 20 При использовании медиатора создается общее представление ( модель ) данных. Медиатор посредник, поддерживающий единый пользовательский интерфейса на основе глобального представления данных, содержащихся в источниках, а также поддержку отображения между глобальным и локальным представлениями данных. Пользовательский запрос, сформулированный в терминах единого интерфейса, декомпозируется на множество подзапросов, адресованных к нужным локальным источникам данных. На основе результатов их обработки синтезируется полный ответ на запрос. Две архитектуры с посредником Global as View и Local as View. Отображение данных из источника в общую модель выполняется при каждом запросе специальной оболочкой. Для этого необходима интерпретация запроса к отдельным источникам и последующее отображение полученных данных в единую модель. Технология интеграции корпоративной информации (Enterprise information integration, EII) поддерживает федеративный подход к интеграции данных.EII

Распространение данных 21 Перемещение данных к местам назначения зависят от определенных событий. Обновления в первичной системе могут передаваться в конечную систему синхронно или асинхронно. Синхронная передача требует, чтобы обновления в обеих системах происходили во время одной и той же физической транзакции. Независимо от используемого типа синхронизации, метод распространения гарантирует доставку данных в систему назначения. Такая гарантия это ключевой отличительный признак распространения данных. Большинство технологий синхронного распространения данных поддерживают двусторонний обмен данными между первичными и конечными системами. Например, технологии интеграции корпоративных приложений (Enterprise application integration, EAI) и тиражирование корпоративных данных ( Е nterprise data replication, EDR).EAI EDR

Сервис - ориентированная архитектура 22 SOA, service-oriented architecture модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам. Программные комплексы, разработанные в соответствии с сервис - ориентированной архитектурой, обычно реализуются как набор веб - служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации ( например, на базе jini, CORBA, на основе REST).

Отличия EAI и SOA 23 EAI, Enterprise Application Integration – Интеграция приложений предприятия это технологии и приложения, задача которых вовлечь несколько приложений, используемых в одной организации, в единый процесс и осуществлять преобразование форматов данных между ними. Под EAI понимается не архитектура, а средства интеграции, которые накладывают архитектурные ограничения. SOA предпочитает логику в сервисах логике в промежуточном слое, что прямо противоречит классическим подходам EAI. SOA является не технологическим, а архитектурным понятием. Но, как и любой архитектурный стиль ( среди прочего ), накладывает технологические ограничения. EAI рассматривает разные модели интеграции и чаще всего отделяет бизнес - логику от логики интеграции, то есть доступа к бизнес - сервису, предлагаемому тем или иным приложением, несущим бизнес - логику.

Удаленный вызов процедур 24 Remote Procedure Call, RPC класс технологий, позволяющих программам вызывать функции или процедуры в другом адресном пространстве ( на удалённых компьютерах ). Реализация RPC технологии включает : сетевой протокол для обмена в режиме клиент - сервер язык сериализации объектов ( или структур, для необъектных RPC). Различные реализации RPC имеют очень отличающуюся друг от друга архитектуру и возможности : CORBA - Common Object Request Broker Architecture общая архитектура брокера объектных запросов DCOM - Distributed Component Object Model SOAP – Service-oriented Architecture На транспортном уровне RPC используют протоколы TCP и UDP, однако, некоторые построены на основе HTTP.TCPUDPHTTP

25 Схема информационного обмена xml- файлами

26

Дополнительно 27 Три подхода к интеграции информационных систем. Интеграция информационных систем. Интеграция корпоративных приложений. Выбор ESB- топологии, соответствующей вашей бизнес - модели. SOA and ESB. Удалённый вызов процедур. Удалённый _ вызов _ процедур Удалённый _ вызов _ процедур Интеграция DIRECTUM c системой Business Studio. aspx Описание языка XPDL.

28 Интеграция DIRECTUM c системой Business Studio

Интеграция СЭД «DIRECTUM» и Business Studio 29

Взаимодействие СЭД «DIRECTUM» и Business Studio 30

31 Интеграция DIRECTUM c системой Business Studio При экспорте организационной структуры в Business Studio передаются данные справочников « Подразделения », « Персоны » и « Работники ». При этом : данные справочника « Персоны » переносятся в Business Studio в справочник « Физические лица » данные справочника « Подразделения » переносятся в Business Studio в справочник « Субъекты », где создаются субъекты с типом « Подразделение »

Взаимодействие СЭД «DIRECTUM» и Business Studio 32

Алгоритм работы пользователя при выполнении интеграции 33

Экспорт оргструктуры 34

Настройка справочника « Пользователи » 35

Настройка справочника « Пользователи » 36

Настройка справочника « Пользователи » 37

Настройка справочника « Пользователи » 38

Формирование регламента и его экспорт 39

Задание параметров процесса 40

Старт процесса 41

Изменение статуса процесса 42

Экспорт диаграммы процесса 43

Языки разметки для интеграции ИС 44 BPEL (Business Process Execution Language) язык на основе XML для формального описания бизнес - процессов и протоколов их взаимодействия между собой ( веб - службы, транзакции ). XML (eXtensible Markup Language расширяемый язык разметки ; произносится [ экс - эм - эл ]) рекомендованный Консорциумом Всемирной паутины (W3C) язык разметки. Спецификация XML описывает XML- документы и частично описывает поведение XML- процессоров ( программ, читающих XML- документы и обеспечивающих доступ к их содержимому ). WSDL (Web Services Definition Language) язык описания веб - сервисов и доступа к ним, основанный на языке XML. UDDI (Universal Description Discovery & Integration) инструмент для расположения описаний веб - сервисов (WSDL) для последующего их поиска другими организациями и интеграции в свои системы YAWL (Yet Another Workflow Language) - язык описания потоков работ, основанных на шаблонах. Языка поддерживается программными системами, включающими соответствующий движок, графический редактор и указатель перечня работ. XPDL - XML Process Definition Language - специализированный язык представления информации о бизнес - процессах. На сегодня считается оптимальным способом обмена данными о диаграммах BPMN, так как, в отличие от конкурирующих языков BPEL и YAWL позволяет сохранять не только информацию о структуре BPMN- диаграммы и том, как должен выполняться бизнес - процесс, но и графическую информацию о размещении узлов диаграммы.

Экспорт диаграммы процесса 45

Экспорт диаграммы процесса 46

Задание на лабораторную работу Экспортировать в СЭД DIRECTUM оргструктуру предприятия из Business Studio 2. Настроить в СЭД DIRECTUM справочники « Подразделения », « Персоны » и « Работники » 3. Экспортировать в СЭД DIRECTUM из Business Studio бизнес - процесс по работе с документами и регламент, его описывающий 4. Запустить процесс на исполнение в СЭД DIRECTUM 5. Импортировать в Business Studio бизнес - процесс из DIRECTUM, проанализировать с помощью ФСА 6. Сделать отчет со скриншотами и описанием по выполненным действиям 7. В отчете описать технологию интеграции DIRECTUM и Business Studio, рассказать про используемый для этого язык разметки