Интеграция на уровне данных (Information-Oriented Integration) подразумевает наличие в системах баз данных, для работы с которыми необходимо разработать единый программный интерфейс.
К основным технологическим решениям данного подхода относятся:
- системы репликации данных;
- федеративные базы данных;
Основы проектирования информационных систем
• использование API для доступа к EPR-системам.
Репликация является процессов синхронизации данных между различными источниками. Необходимость в этом возникает в момент изменения блока информации в распределённых системах хранения, чтобы гарантировать корректность и непротиворечивость данных используемых во всех модулях или приложениях информационной системы. Обычно функции репликации возлагают на промежуточное программное обеспечение.
Федеративные базы данных (Federated Database Systems) предоставляют единый интерфейс к распределённым данным. Это обеспечивает интеграцию множества автономных данных, которые могут быть физически расположены на различных устройствах в сети. Такие базы данных принято называть виртуальными.
Как описывать требования к интеграции информационных систем? Ольга Пономарева
Использование API для доступа к ERP-систе-мам призвано упростить механизмы обмена инфор-мацией между пользовательскими приложениями и программным обеспечением, предназначенным для управления функционированием производственных информационных систем (ERP).
Интеграция на уровне бизнес-функций и бизнес объектов подразумевает реализацию совместно исполь-зуемых служб (сервисов). Служба может являться набо-ром функций, используемом в нескольких приложениях. Набор служб и будет являться бизнес-функциями.
При использовании сервисно-ориентированной архитектуры, бизнес-функции можно рассматривать
Архитектура информационных систем
как бизнес-сервисы, а при компонентном подходе – бизнес-объектами (бизнес-компонентами).
Интеграция на уровне бизнес-процессов раз-личается в зависимости от уровня интеграции. При внутренней интеграции взаимодействует большое ко-личество сервисов, а при внешней интеграции, в ос-новном, два. Сами бизнес-процессы функционируют над выделенными службами, для управления которы-ми существует специальный интерпретируемый язык.
Порталы можно считать графическими интерфейсами бизнес-процессов, поскольку они предназначены для персонализированного доступа к информации и консолидации данных из нескольких источников.
Главное назначение процесса интеграции – объединение функций приложений или модулей для предоставления новой функциональности.
При интеграции приложений можно выделить два основных типа задач:
- задачи интеграции корпоративных приложений;
- задачи интеграции приложений из различных информационных систем.
Для решения задач первого типа применяются системы EAI, которые иногда называются A2A (Application-to-Application Integration), а для решения задач второго типа применяются системы B2B (Business-to-Business Integration).
Наталья Косинова. Мастер-класс: Интеграция информационных систем
В некоторых ситуациях очень сложно определить разницу между интеграцией A2A и B2B, поскольку сложность некоторых решений внутри
Основы проектирования информационных систем
информационных систем может превышать сложность решений для их совместного функционирования.
Существуют три альтернативных топологии интеграции:
- Точка-точка (Point-to-Point);
- Шлюз (hub-and-spoke);
В топологии «точка-точка» все объекты имеют прямые связи друг с другом (рисунок 19, а). Следует отметить, что каждая связь может быть реализована каким угодно способом. Варианты реализации зависят от требований и характеристик взаимодействия между объектами. К недостаткам топологии можно отнести:
- недостаточная гибкость;
- сложность поддержки многочисленных соединений «точка-точка»;
- изменения одного объекта влияют на оставшиеся;
- логика маршрутизации часто программируется в коде объектов;
- отсутствие общей модели безопасности;
- использование различных API;
- низкая надёжность;
- сложность создания фреймворков;
- сложность поддержки асинхронного взаимодействия;
Для сокращения числа используемых интерфей-сов следует использовать топологию с общим шлюзом (рисунок 19, б) или топологию с общей шиной (рису-нок 19, в). Такие модели интеграции реализуются на уровне промежуточного программного обеспечения.
Архитектура информационных систем
Рисунок 19 — Топологии интеграции
Следующим шагом в разработке интеграционных архитектур можно считать появление корпоративной сервисной шины (Enterprise Service Bus — ESB). Ряд авторов рассматривают системы ESB, как следующую ступень развития EAI. Однако есть несколько различаев:
- EAI – централизованная архитектура, с об-меном информации через хаб (брокер), а ESB – шинная архитектура, которая может быть реализована в виде нескольких распределённых систем;
- В отличие от EAI, ESB ориентирована на использование открытых стандартов.
Эти два различия наглядно демонстрируют возможность использования ESB как интеграционной платформы позволяющей использовать различные механизмы интеграции. ESB позволяет проводить как внутреннюю, так и внешнюю интеграции, и представляет собой шину (backbone), работающую как слабосвязная система, управляемая событиями.
Концепции сервисно-ориентированных архи-тектур (СОА) и ESB очень сильно связаны. ESB подде-
Основы проектирования информационных систем
рживает принцип реализации СОА: разделение пред-ставления службы и её реализации.
- предоставление интерфейсов взаимодействия;
- отправка и маршрутизация сообщений;
- преобразование данных;
- реакция на события;
- управление политиками;
На основании функций ESB, можно сформировать типовой список требований, предъявляемых со стороны пользователей:
- большая пропускная способность;
- поддержка нескольких стилей интеграции;
- обеспечение возможности приложениям ра-ботать с сервисами как напрямую, так и через адаптеры.
ESB является, по сути, логическим компонен-том архитектуры, приводящим интеграционную ин-фраструктуру в соответствие принципа СОА. Архи-тектурами, построенными по принципу ESB, сложнее управлять, но они более гибкие и масштабируемые, более того, внедрение СОА не потребует изменений во всех элементах системы, в результате чего сможет происходить поэтапно.
Можно представить ESB в виде пятиуровневой структуры:
- уровень сопряжения (адаптеры и интерфейсы);
- транспортная подсистема;
- уровень реализации бизнес-логики;
Архитектура информационных систем
- уровень управления бизнес-процессами;
- уровень бизнес-управления.
Уровень сопряжения призван решать проблему использования различных интерфейсов. На этом уровне функционируют адаптеры, отслеживающие события в приложениях и в интеграционной подсистеме, и обеспечивают преобразование передаваемых объектов при взаимодействии с транспортной подсистемой. Существует возможность, помимо заранее созданных адаптеров интеграционной платформы, использовать созданные самостоятельно.
Адаптеры можно разделить на две категории: технологические (применяются для интеграции технологических компонент, при отсутствии у них API), адаптеры для приложений (применяются для интеграции с конкретным приложением).
Транспортная подсистема предоставляет воз-
можность асинхронного взаимодействия интегрируе-мым приложениям. Данный уровень также отвечает за управление и безопасность информации, может выпол-нять маршрутизацию сообщений и их обработку.
Уровень реализации бизнес-логики предоставляет функции для трансформации и маршрутизации сообщений. На этом уровне функционируют брокеры сообщений, обменивающиеся сообщениями через транспортную подсистему.
Брокер сообщений может выполнять следующие функции:
1. Принятие сообщений и их отправка по указанным адресам.
Основы проектирования информационных систем
- Преобразование форматов сообщений.
- Агрегирование и фрагментации сообщений.
- Взаимодействие с репозиториями.
- Выборка данных через вызовы Web-
- Обработка ошибок и событий.
- Маршрутизация сообщений по адресу, содержимому, теме.
Управления бизнес-процессами на одноимённом уровне осуществляется при помощи BPEL (Business Process Execution Language) посредством Web-
Уровень бизнес-управления представляет из себя надстройку на предыдущим уровнем и предназначен для управления бизнес-процессами в терминах соответствующей предметной области.
Подход ESB имеет множество преимуществ и позволяет строить интеграционные архитектуры практически любой сложности. Типовая структура интеграционной системы представлена на рис.20.
Источник: studfile.net
Концепция интеграции информационных бизнес-систем
Ниже представлен пример проектного документа «Концепция интеграции информационных систем» который включает в себя предварительное описание регламента информационного взаимодействия. Данный документ формируется IT-специалистом на этапе проектирования потоков данных интеграции и интерфейсов интеграции (обмена данными).
В качестве примера для заполнения данного шаблона взят проект внедрения системы ERP с заменой существующих учетных систем. Т.е. перед IT-специалистом стоит задача организовать обмен данными между новой, внедряемой информационной системой (в нашем примере это ERP) с существующими (остающимися в эксплуатации) информационными системами на уровне управляющей компании (УК) и филиала.
- Описание текущих интеграционных процессов объекта автоматизации
- Интегрируемые информационные системы
- Схема потоков данных
- Периодичность обмена данными
- Описание интерфейсов интеграции информационных систем
- Организационные мероприятия
Описание текущих интеграционных процессов объекта автоматизации
В данном разделе документа приводится описание существующих потоков данных (процессов обмена данными между существующими информационными системами) в виде схемы потоков данных.
Например, приводится следующий текст:
На рисунке ниже представлена общая схема потоков данных взаимодействия между системами бухгалтерского учета, системами кадрового учета и другими информационными системами.
И ниже приводится существующая схема потоков данных между информационными системами. Схема потоков данных может приводится как в свободной форме, при этом обязательно необходимо её описание, так и в виде, например, DFD-диаграмм.
Интегрируемые информационные системы
В данном разделе документа приводится перечень информационных систем между которыми планируется организовать периодический обмен данными.
В рамки проекта внедрения системы ERP предполагается организация взаимодействия со следующими существующими информационными системами:
— Система финансового планирования (Управляющая компания), верс. X.Y.
— Система финансового планирования (Филиал) OFA, верс. X.Y.
— Система ведения договоров (Управляющая компания)) , верс. X.Y.
— Файлы с данными по учету расчетов с акционерами, для филиала и управляющей компании.
Схема потоков данных
В данном разделе проектного документа приводится схема потоков данных, описывающая будущие потоки интеграции (обмена данными) между информационными системами. Схема потоков данных может приводится как в свободной форме, при этом обязательно необходимо её описание, так и в виде, например, DFD диаграмм.
На рисунке ниже представлена схема потоков данных при организации синхронизации в рамках внедрения проекта ERP.
Периодичность обмена данными
Приводится периодичность осуществления обмена данными между информационными системами.
Система источник Система приемник Группа данных Периодичность обмена ERP MS Axapta Данные по НСИ Ежедневно Данные для проводок 1 раз в месяц После выполнения расчетов по З/П, до 15 числа . и т.д.
Описание интерфейсов интеграции информационных систем
В данном разделе приводится описание интерфейсов интеграции информационных системам. При этом описываются интерфейсы каждого потока и типа данных в отдельности.
Поток данных: ERP -> MS Axapta. Тип данных: данные по НСИ
Данные по НСИ ведутся в исключительно в ERP и передаются в MS Axapta. В MS Axapta переданные данные не корректируются. Справочники передаются и загружаются каждый раз полностью, без захвата изменений. Удаленные записи имеют соответствующую отметку в специальном поле.
Ниже приведено описание интерфейсов передачи данных (Типы данных: D – Data; C – Char/Text; N — Number).
Организационно-штатная структура
№ Наименование Физ. наименование Тип данных 1 Код ID N 2 Наименование Descr C 3 Код родителя ParentID N 4 Дата начала действия DataNach D 5 Метка удаленной записи Del_Ind N Ниже по примеру «Организационно-штатной структуры» описываются остальные интерфейсы по каждому из потоков данных.
.
Организационные мероприятия
В данном разделе приводится перечень организационных мероприятий, которые необходимо выполнить до начала разработки процессов интеграции (обмена данными).
- Сформировать требования, проектные решения по структурам выгрузки данных из .
- Сформировать регламент заведения новых данных и сопровождения существующих по НСИ.
- Подготовить распорядительные документы для организации внесения изменений в механизм загрузки данных в .
- .
Источник: www.prj-exp.ru
Описание интеграции информационных бизнес система
Аннотация: статья содержит краткий обзор популярных способов интеграции данных между корпоративными информационными системами. Рассмотрены механизмы XI/PI, SOAP и обмена плоскими файлами. Сформулированы требования для разработки программы интеграции на основе обмена плоскими файлами. Согласно выдвинутым требованиям разработана программа в среде ABAP.
Скачать: PDF.
Ключевые слова: пример интеграции корпоративных информационных систем, архитектура корпоративных информационных систем, интеграция информационных систем предприятия, интеграция информационных систем, требования к интеграции информационных систем, методы интеграции приложений, цели интеграции информационных систем, подходы к интеграции информационных систем, интеграция на уровне сервисов, этапы интеграции информационных систем, методы интеграции информационных систем, методы интеграции данных, способы интеграции приложений.
Развитие современных информационных технологий (ИТ) позволяет осуществлять интеграцию данных, распределенных в различных информационных системах (ИС) предприятия. Последние позволяют автоматизировать бизнес-процессы компании и обеспечивают помощь в принятии управленческих решений [1]. Наличие нескольких ИС на предприятии является делом вполне обыденным (рис.1), что особенно актуально для холдинговых структур, причины чего заключаются в следующем:
- функциональность ИС;
- относительная дешевизна ИС;
- отсутствие карты решений ИС.
Функциональность отдельных ИС, определяющих заданную прикладную область (например, транспортировка, управление складами и планирование), относительно интегрированных решений корпоративных информационных систем (КИС), охватывающих все аспекты деятельности компании (логистика, финансы и человеческие ресурсы), зачастую является более выигрышной. Кроме того, стоимость внедрения подобных систем существенно ниже по сравнению с затратами на имплементацию КИС. Наличие нескольких ИС на предприятии может свидетельствовать об отсутствии целостной концепции развития ИС (карта решений) службы ИТ [2].
Рис. 1. Программное обеспечение предприятия на основе: а) различных ИС; б) КИС
Цель работы заключается в реализации механизма обмена основными данными между КИС на примере SAP-системы и прочими ИС. Достижение поставленной цели требует решения следующих задач: анализ возможных способов обмена данных, формулирование требований и выполнение соответствующих операций для реализации выбранного способа интеграции.
1. Способы передачи данных корпоративных информационных систем
Интеграция данных распределенных ИС обеспечивает работу всех бизнес-приложений компании с единым массивом информации и, тем самым, позволяет формировать сводную аналитическую отчетность в масштабах всего предприятия. Существуют различные способы интеграции данных ИС [3], выделим лишь некоторые их них:
- инфраструктура обмена данных XI/PI;
- простой протокол доступа к объектам SOAP;
- обмен плоскими файлами.
Инфраструктура обмена данных XI (Exchange Infrastructure) / PI (Process Integration), разработанная компанией SAP, используется для обеспечения совместной работы разнородных КИС. Бизнес-приложения могут быть реализованы как на SAP-решениях, так и на решениях прочих вендеров. Концептуальная модель интеграции КИС на основе решения SAP XI/PI дана на рис.2.
Рис. 2. Концептуальная модель интеграции КИС на базе SAP XI/PI
Согласно приведенному рисунку, центральным звеном процесса обмена данными является интеграционный сервер (Integration Server), обеспечивающий преобразование запросов отправителя в формат получателя. В качестве средств взаимодействия с внешними системами могут служить:
- адаптеры RFC, File, JDBC и др. для удаленного вызова процедур, обмена данными (iDOC, XML, Flat Files) и таблицами данных соответственно;
- веб-сервисы (Web Services), опубликованные отправителем на UDDI-источнике (Universal Description, Discovery and Integration) и вызываемые получателем по HTTP-протоколу.
SAP XI/PI обеспечивает интеграцию данных в режиме онлайн, а так же высокий уровень безопасности, поддержку открытых стандартов взаимодействия и механизмы централизованного мониторинга [4].
Простой протокол доступа к объектам (Simple Object Access Protocol) представляет собой стандарт удаленного вызова процедур RFC (Remote Function Call), который позднее был дополнен механизмами обмена произвольными сообщениями. Модель SOAP является «прородителем» инфраструктуры обмена данными XI/PI. В основе данной архитектуры лежит SOAP-сервер, включающий такие компоненты, как: обработчик SOAP-запросов (Envelop), синтаксический анализатор запросов (Parser) и программа формирования результатов (Response). Интеграция ИС может осуществляться, как и в случае XI/PI, на уровнях данных, приложений и Web-сервисов. В отличие от механизма XI/PI, ориентированного преимущественно на интеграцию SAP-систем, SOAP обеспечивает большую универсальность [5].
Рис. 3. Концептуальная модель интеграции КИС на основе плоских файлов
Применение механизмов экспорта/импорта плоских файлов (Flat Files) является одним из самых быстрых и дешевых, с точки зрения программной реализации и стоимости, способов интеграции данных ИС. Обмен информацией происходит следующим образом: на стороне ИС-отправителя осуществляется выгрузка файла в строго заданном формате представления данных, на стороне КИС-получателя — загрузка выгруженного файла (рис.3). Экспортируемый файл может храниться как на локальном компьютере, так и на сетевом ресурсе в зависимости от того, осуществлялась ли выгрузка и загрузка данных одним пользователем. Данный способ интеграции применим в случаях, когда обмен данных ИС носит разовый или достаточно редкий характер [6].
2. Требования к реализации программ передачи данных на основе обмена плоскими файлами
Специфика интеграции основных данных КИС заключается в том, что обмен информацией выполняется достаточно редко. Поэтому поставленные цели и сформулированные задачи работы позволяют выбрать обмен плоскими файлами в качестве требуемого способа интеграции. Разработка программ, с помощью которых осуществляется выгрузка и загрузка плоских файлов, может вестись согласно указанным в табл.1 требованиям.
Таблица 1. Основные требования, предъявляемые к программе
Основы теории управления диктуют требования наличия контура обратной связи, позволяющего пользователю реагировать на всевозможные отклонения и ошибки в работе программы [7]. Область надежности, эргономики и качества АСОИУ (автоматизированные системы обработки информации и управления, к которым можно отнести ИС и КИС), предъявляет требования надежности, эффективности и удобства использования программных разработок [8].
Большая часть требований теории информации, кодирования и передачи данных реализуется выбранным способом интеграции. В частности, показатели количества информации, скорости и частоты ее передачи для поставленной задачи имеют относительно небольшие значения. Безопасность же передачи данных обеспечивается базовыми механизмами сетевой инфраструктуры предприятия [9]. Обобщение пусть даже очень частного программного решения, как в прочем и проведение всеобъемлющего тестирования разработки, лежит в основе принципов реализации и тестирования программного обеспечения согласно [10]. Указанные требования использовались при реализации программы загрузки данных в среде ABAP (Advanced Business Application Programming) SAP-системы.
3. Реализация программы обмена файлами в среде ABAP
Реализация требований, предъявляемых к разрабатываемой в системе SAP программе по загрузке основных данных, приведена в табл.2. Техническое задание (спецификация на разработку), на основе которого выполнялась реализация программы, включало описание следующих механизмов:
- задание начальных параметров программы;
- обработка позиций данных, загруженных из файла;
- создание объектов основных данных для загруженных позиций.
Запуск программы в системе SAP выполняется по коду транзакции, наименование которой должно отражать конечные результаты работы приложения. В рамках поставленной задачи «Загрузка основных данных из ИС». Результатом запуска транзакции является отображение экрана ввода начальных данных (рис.4а), в котором пользователь может указать организационные данные, сведения о файле загрузки и служебную информацию. Параметры были выделены таким образом, чтобы обеспечить максимальную обобщающую способность программы (обобщение решения). Завершающим шагом являлась проверка полномочий пользователя на выполнение операций по загрузке и созданию основных данных системы.
Таблица 2. Реализация основных требований, предъявляемых к программе
Успешно введенные начальные данные программы и проверенные полномочия пользователя позволили выполнить загрузку данных из указанного файла и их отображение в экране программы (рис.4б). Необходимо было предусмотреть проверку повторной загрузки данных по одному файлу и блокировку обрабатываемых основных данных, в случае их изменения или расширения. Выполнив контроль загруженных позиций, запускался процесс создания основных данных. При возникновении ошибки обработки одной из позиций не только выдавалось соответствующее сообщение об ошибке, но и отменялись уже выполненные изменения предыдущих позиций (удаление созданных объектов системы SAP).
Результаты создания объектов основных данных отражались как в журнале сообщений, так и списке загруженных позиций (рис.4в). Кроме того, выполнялась проверка контрольных сумм (суммарное значение количества и стоимости) загруженных позиций и созданных основных данных. Тестирование разработанной программы проводилось на реальном объеме данных, как функционально (корректность создания объектов основных данных со всеми необходимыми атрибутами), так и интеграционно (возможность корректного использования созданных данных в различных модулях SAP-системы).
Рис. 4. Структура программы загрузки данных: а) экран выбора данных; б) загруженные позиции; в) обработанные позиции
Основные результаты и выводы
В работе выполнен обзор нескольких способов интеграции данных корпоративных информационных систем. Рассмотрены механизмы обмена данных на основе XI/PI, SOAP и Flat Files, кроме того выделены предпосылки их использования. Для реализации способа обмена данных, использующего импорт/экспорт плоских файлов (Flat Files) сформулированы требования к разрабатываемой программе.
Требования универсальны и применимы для реализации всевозможных программных разработок. Предложены механизмы реализации сформулированных требований, и разработана программа по загрузке основных данных в систему SAP ERP. Результаты работы успешно апробированы в одном из структурных подразделений крупной российской нефтяной компании.
Литература
- Степанов Д.Ю. Перспективные направления развития корпоративных информационных систем на примере программных решений компании SAP. // Аспирант и соискатель. — 2013. — т.66, №6. – c.168-172.
- Лодон Дж., Лодон К. Управление информационными системами. / Пер. с англ. под ред. Трутнева Д.Р. — СПб.: Питер. 2005.
- Кусов А.А. Проблемы интеграции корпоративных информационных систем. // Управление экономическими системами: электронный научный журнал. – 2011. — т. 28, №4.
- Официальный сайт поддержки SAP. http://help.sap.com/
- Официальный сайт SOAP. http://www.w3.org/TR/soap/
- О’Лири Д. ERP-системы. — М.: Вершина. 2004.
- Егоров А. Основы теории управления. — М.: Физматлит. 2007.
- Закорюкин В.Б. Надежность, эргономика и качество АСОИУ. — М.: МИРЭА. 2006.
- Шеннон К. Работы по теории информации и кибернетики. — М.: Информационная литература. 1963.
- Кнут Д. Искусство программирования, том 1. Основные алгоритмы. — М.: Вильямс, 2006.
Источник: stepanovd.com
