Основы интеграции способы интеграции

Интеграция информационных систем

Ни для кого не секрет, что «уже все сделано до нас». Осталась всего-то малость «собрать фрагменты» для решения поставленной задачи. И тут оказывается, что интегрировать разобщенные части не редко сложнее, чем их написать. Почему же так происходит? Что можно с этим сделать?

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

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

Давайте перечислим и проанализируем факторы, влияющие на интеграцию:

• Ускорение процессов. Развитие организации требует все чаще и чаще менять структуры данных, бизнес-процессы, не говоря уже о дизайне и пользовательском интерфейсе, который просто постоянно находится в изменении. Вот, как раз в таких динамичных областях, где “изменчивость” является самой сутью и природой системы, задача интеграции усугубляется и превращается в серьезную проблему.
• Распределенность. Организации становятся все более крупными, а решаемые задачи все более комплексными, появляется логическая, организационная и географическая рассредоточенность.
• Гетерогенность. В крупном проекте, почти никогда нет возможности придерживаться платформ и инструментов от одного производителя, поэтому приходится учитывать и поддерживать особенности нескольких платформ.
• Наследственность. Невозможность полностью отказаться от легаси систем, морально устаревших технологий, старого аппаратного обеспечения, корторые, кстати, иногда дают вполне хорошие показатели по надежности и производительности но уж ни как не способствуют интеграции.
• Хаотичность. Не всегда есть возможность полностью формализовать, специфицировать и структурировать данные, и часть модели остается “слабо-связанной”, не поддающейся или слабо поддающейся машинной обработке, анализу, индексации, обсчету.
• Обусловленность. К сожалению, информационные системы ограничены не только техническими рамками, но и привычками людей (которых сложно переучивать), особенностями законодательства (которое просто не готово к появлению таких систем), множеством других факторов, не зависящих от разработчиков.
• Интерактивность. Потребитель информации постоянно повышает свои ожидания о скорости реакции системы, быстродействии и оперативности доставки информации. Большинство процессов стремятся к выполнению в реальном времени.
• Мобильность. Пользователь систем стал передвигаться быстрее, а взаимодействие с ним ведется через каналы связи общего пользования в транспорте, дома и на улице, в общественных местах и повсеместно.
• Безопасность. Пока данные хранились на носителе внутри охраняемого помещения, то особо ни кто не беспокоился о шифровании, но теперь сетевые пакеты летают в воздухе и это нельзя оставлять без внимания.
• Высоконагруженность. На сложность интеграции влияют: количество пользователей в системе, интенсивность потока обработки данных, объемы данных и ресурсоемкость вычислений.
• Непрерывность цикла работы. Интеграция и апгрейд систем почти всегда должны проводиться без остановки их функционирования, плавно, постепенно и незаметно для организации и ее клиентов.
• Межсистемная интеграция. Задачи стыковки не ограничены рамками организации, все чаще нужно интегрироваться с партнерами, клиентами, поставщиками, подрядчиками и даже государственными структурами.

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

• Концептуальная разница — основывается та том, что разработчики разных систем изначально приняли разные решения, предположения и допущения, которые концептуально не стыкуются между собой. Решается введением еще одного слоя абстракции, который концептуально не противоречит обоим подходам. При этом, есть два варианта реализации: (а) когда получившаяся система становится централизованной, а две и более интегрируемых системы превращаются в подсистемы и (б) когда мы используем архитектуру брокера (посредника, не являющегося центром), при этом системы остаются независимыми, а брокер обеспечивает прослойку между ними.
• Технологическая разница — когда мы имеем несовместимые форматы обмена данными, протоколы взаимодействия и интерфейсы. Решается написанием конвертов, прослоек, брокеров и других примочек, не вполне красивых, но достаточно надежных.
• Несовместимость лицензий. Подробнее останавливаться на этом не буду, так как не специалист я в этом вопросе, а решение может быть в каждом случае индивидуальное, на организационном уровне.

Общая задача у нас теперь выглядит так: необходимо интегрировать N информационных систем, характеризуемых описанными выше факторами, с минимизацией количества прослоек, конвертеров, брокеров и интерфейсов между ними. Если решать задачу в лоб, то между N системами будет N(N-1)/2 связей, то есть, при двухстороннем взаимодействии N(N-1) интерфейсов. Если учесть, что под интерфейсом мы тут можем понимать все что угодно, от веб-сервиса до оффлайнового процесса, запускаемого, например раз в сутки и делающего целый ряд сложных операций по синхронизации баз (запросы, обработку, экспорт, закачку по FTP, передачу сигнала другой части системы, чтобы та приняла переданные данные и выполнила свою часть работы, а потом уведомила о результатах и передала необходимые данных обратно). В общем от таких вариантов никогда не удастся избавиться полностью, вопрос только в грамотной их реализации.

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

• Стандартизация — нужно и важно использовать как можно больше международных, государственных и отраслевых стандартов, а если каких-то не хватает, а они явно просятся, то нужно вводить корпоративные стандарты, а часто имеет смысл и продвигать их в соответствующих организациях для скорейшего распространения и популяризации.
• Интеграция на уровне брокеров. Преимущества: универсальность — практически всегда можно создать дополнительный программный модуль, который будут обращаться в обе системы, еще и разными способами (например, в одну через базу данных, а в другую через RPC). Недостатки: сложность, трудоемкость, а следовательно высокая стоимость разработки, внедрения и владения.
• Интеграция на уровне данных — то есть несколько приложений могут обращаться в одну базу данных или в несколько баз данных, связанных репликациями. Преимущества: низкая стоимость интеграции, а при использовании одной СУБД это становится очень заманчивым решением. Недостатки: если база данных не экранирована хранимыми процедурами и не имеет необходимых ограничений целостности (в виде указания каскадных операций и триггеров), то разные приложения могут приводить данные в противоречивые состояния. Если же база экранирована и целостность обеспечивается, то и в этом случае, в параллельно работающих с одной БД приложениях, будут дублирующиеся части кода, выполняющие одинаковые или похожие операции. Кроме того, при изменениях структуры базы мы будем отдельно переписывать код всех приложений, с ней работающих.
• Интеграция на уровне сервисов — это красивая интеграция, основанная на фиксации интерфейсов и форматов данных с двух сторон и позволяющая наладить быструю отработку межкорпоративной бизнес-логики. Есть и недостатки: все же, присутствует фиксация, а если структуры или процессы изменяются, то образуются проблемы и узко специализированные, частные решения.
• Интеграция на уровне пользователя — это крайний случай, не автоматизированная интеграция, когда пользователи перемещают данные между системами через копипаст, файлы, почту и другие безобразия. Мы такие методы не рассматриваем, но они, к сожалению, часто применяются в тот период, пока программные системы не готовы, а развитие компании не позволяет ждать.
• Динамическая интерпретация метаинформации — об этом мы поговорим в отдельной статье.

Это почти исчерпывающий обзор классических методов, прошу дополнять, если я что-то упустил. А вот по не классическим методам интеграции я готовлю еще одну публикацию. Спасибо за внимание.

Источник

Основы интеграции способы интеграции

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

Источник