Способ интеграции информационных систем

Обзор методов интеграции информационных систем, их преимуществ и недостатков

Рубрика: Информационные технологии

Дата публикации: 11.06.2018 2018-06-11

Статья просмотрена: 12057 раз

Библиографическое описание:

Думченков, И. А. Обзор методов интеграции информационных систем, их преимуществ и недостатков / И. А. Думченков. — Текст : непосредственный // Молодой ученый. — 2018. — № 23 (209). — С. 176-177. — URL: https://moluch.ru/archive/209/51296/ (дата обращения: 18.11.2021).

Развитие информационной сферы повлекло за собой информатизацию общества. В настоящее время активно происходит автоматизация процессов в различных видах деятельности. Яркими примерами являются такие проекты, как «Портал ГосУслуг», «ЕМИАС», «Электронный дневник», которые позволяют выполнять различные действия, такие как оплата коммунальных услуг, запись к врачу, отслеживание успеваемости школьника, не выходя из дома. В связи с этим необходимо понимать, какие из методов интеграции информационных систем являются оптимальными для каждого конкретного случая.

В данной статье будут рассмотрены наиболее популярные и используемые методы интеграции.

‒ Интеграция на уровне брокеров. Преимуществом данного метода является универсальность: как правило, в любой ситуации можно реализовать дополнительный программный модуль, который может обращаться в другие системы различными способами. Например, такой модуль может обращаться к одной системе через базу данных (БД), а к другой с помощью RPC (англ. Remote Procedure Call — Удалённый вызов процедур). Недостатками такого подхода интеграции является трудоёмкость и сложность реализации, и, как следствие, высокая стоимость разработки, внедрения и поддержки.

‒ Интеграция на уровне интерфейсов (физических, программных и пользовательских). Данный вид интеграции разрабатывался как один из видов «лоскутной интеграции», целью которой являлось объединение распределённых программных приложений, реализованных разными разработчиками в разное время, в подобие единой системы. Приложения связывались по принципу «каждый с каждым», что, в конечном итоге, затрудняло их взаимодействие и создавало ряд проблем и ошибок. Также осложнялось использование унаследованных (Legacy Software) и встроенных (Embedded System) систем. Описанный подход интеграции удобен для небольшого количества программных приложений. Для большого числа приложений он является малоэффективным и не обеспечивает построение качественно новых запросов к объединяемым данным. Таким образом, агрегирование данных не принесёт выигрыш. На настоящий момент, проблема интеграции на уровне интерфейсов решается на базе внедрения информационных подсистем, которые реализуются стандартными приложениями с открытыми программными интерфейсами (англ. Open Application Programming Interface, OAPI — Открытый программный интерфейс приложения, Открытый интерфейс прикладного программирования).

‒ Интеграция на функционально-прикладном и организационном уровнях. Данный вид интеграции построен на объединении нескольких однотипных или похожих функций в макрофункции, в которых перераспределяются ресурсы, потоки данных, управление и механизмы исполнения. Как следствие, это влечёт за собой реорганизацию информационных структур, бизнес-процессов и, соответственно, перестройку схем их информационного и документационного обеспечения. Преимущества данного вида интеграции:

• прозрачность и управляемость процессов;
• процессы становятся менее затратными;
• сокращается количество обслуживающего персонала;
• сокращается число ошибок.

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

‒ Интеграция на уровне корпоративных программных приложений. Данный вид интеграции предполагает совместное использование исполняемого кода, а не только внутренних данных интегрируемых приложений. Программы делятся на компоненты, которые затем интегрируются при помощи стандартизованных программных интерфейсов (API) и специализированного связующего программного обеспечения (ПО). Такой подход позволяет создать из этих компонентов универсальную программную платформу (ядро), которая может быть использовано всеми приложениями. Каждое приложение будет иметь только один интерфейс для взаимодействия с этим ядром, что значительно облегчает задачу интеграции. Систему, построенную на таком интеграционном подходе, легче администрировать, поддерживать и масштабировать. Возможность повторного использования функций в рамках имеющейся среды позволяет существенно сократить сроки и стоимость разработки приложений. Обязательным этапом оценки возможности интеграции приложений, которые предполагается связывать в рамках определённого проекта, является анализ внутренней архитектуры приложений. Этот анализ может быть осложнён тем, что, как правило, разработчик приложений, являющихся готовыми программными продуктами, не раскрывает всех деталей внутренней структуры приложений.

‒ Интеграция при помощи Web-сервисов. Данный вид интеграции является передовым и стремительно развивающимся подходом к интеграции приложений. Он базируется на предоставлении стандартного для Web-служб интерфейса доступа к приложениям и их данным. Примером может являться стандартный протокол доступа к объектам — SOAP (англ. Simple Object Access Protocol — простой протокол доступа к объектам). Так, при помощи SOAP, браузер пользователя может одновременно сравнить данные на нескольких выбранных веб-сайтах и представить клиенту сравнительный отчет. Другой пример: сотрудники одного географически распределенного предприятия могут единовременно использовать корпоративные приложения, доступ к которым осуществляется через соответствующие Web-сервисы (портальное решение). Web-сервисы похожи на подход EAI, но с одним главным отличием — EAI-решения, в своём множестве, выпускаются как частные случаи для связи определённых продуктов. Соответственно, подключить к уже используемому EAI-решению еще одну стороннюю систему будет довольно трудной и длительной задачей. По своей природе Web-сервисы существенно более унифицированы и стандартизованы. Поскольку Web-сервисы базируются на общих и единых для Консорциума Всемирной паутины (англ. World Wide Web Consortium, W3C-консорциум) стандартах, они могут работать везде, где используется сеть Интернет.

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

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

‒ Интеграция на уровне пользователя. Данный вид относится к неавтоматизированной интеграции, и основан на взаимодействии пользователей друг с другом: обмен данными и файлами между системами через ручное копирование, оправку почты и т. д. Является наиболее простыми видом\подходом, и часто применяются в тот момент, когда происходит подготовка внедрения программных систем, а деятельность компании не может прерываться.

Источник

Способ интеграции информационных систем

Аннотация: статья содержит краткий обзор популярных способов интеграции данных между корпоративными информационными системами. Рассмотрены механизмы 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. Результаты работы успешно апробированы в одном из структурных подразделений крупной российской нефтяной компании.

Источник