Интеграция информационных систем на основе стандартов XML и WEB-сервисов в сфере закупок

            Введение

Развитие информационных технологий влечет за собой повышенные требования к информационным системам. С одной стороны, все больше учреждений и услуг государственного сектора переходят на работу с данными в электронном виде, создаются государственные информационные системы и веб-порталы. Государство на законодательном уровне стимулирует государственные и муниципальные учреждения к межсистемной интеграции. С другой стороны, коммерческие приложения (в частности веб-ориентированные) стремятся интегрироваться с различными информационными сервисами и транслировать полученную информацию своим пользователям. Возникает задача интеграции разнородных (выполненных на разных платформах) информационных систем между собой.

Повсеместная доступность сети Интернет и увеличение пропускной способности каналов создают условия, при которых становится выгодно решать задачи межсистемной интеграции при помощи Интернет технологий. Интернет предоставляет универсальный протокол связи HTTP(S) для любых информационных систем, но не решает проблему различных платформ реализации систем и несовместимых источников данных. Эти проблемы предлагается решить с помощью использования веб-сервисов в качестве шлюзов для программного взаимодействия. Веб-сервисы предоставляют универсальный интерфейс для взаимодействия с любыми информационными системами, тем самым освобождая разработчиков от необходимости реализовывать интеграцию на уровне «приложение-приложение» [3, 4]. Стандарт XML, принятый в качестве формата информационных сообщений веб-сервисов, позволяет обмениваться данными из разнородных источников в унифицированном виде.

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

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

Анализ проблемы организации взаимодействия в сфере закупок

В качестве предметной области рассмотрим сферу государственных и муниципальных закупок. В этой сфере на законодательном уровне введено требование к муниципальным информационным системам осуществить интеграцию с официальным общероссийским сайтом [12]. Помимо официального сайта муниципальным системам необходимо взаимодействовать с электронными торговыми площадками, расположенными в сети Интернет.

Анализ возможностей интеграции с электронными площадками и официальным сайтом [5, 9, 10] позволяет выделить два основных типа реализации веб-сервисов – REST и SOAP (XML-RPC).

REST был введен Роем Филдингом, который описал концепцию построения распределенного приложения, абстрагировав метод взаимодействия между клиентами и серверами в сети Интернет и назвав его передачей репрезентативного состояния (Representational State Transfer) [1]. Взаимодействие с веб-сервисом этого типа осуществляется путем вызова удаленных процедур с помощью HTTP-запроса. Необходимые для передачи данные указываются в качестве параметров запроса.

SOAP является следующей ступенью развития XML-RPC и является расширением протокола RPC. Отличие между ними в том, что RPC изначально предназначался только для вызова удаленных процедур, в то время как SOAP используется для обмена произвольными сообщениями в формате XML. Протокол SOAP разработан группой W3C и в настоящий момент рекомендуется использовать версию 1.2 [2].

Веб-сервис официального сайта работает по принципу REST и осуществляется по протоколу HTTPS с использованием криптографического протокола TLS (рис. 1). Данный веб-сервис позволяет загружать информацию по закупкам в автоматизированном режиме. Структура пакета и его тип (multipart/form-data) жестко регламентированы. Пакет должен состоять из следующих блоков: login, password, clientType, document, signature. Блоки login и password содержат соответственно имя и пароль пользователя, осуществляющего загрузку сведений (логин и пароль пользователя для входа в личный кабинет официального общероссийского сайта). В блоке clientType указывается тип клиента. Передаваемый XML-документ содержится в блоке document, а signature содержит электронную подпись XML-документа [5].

Рис. 1. Схема взаимодействия с веб-сервисом официального общероссийского сайта

Взаимодействие с электронными площадками рассмотрим на примере «РТС-тендер». Эта площадка предоставляет веб-сервис, работающий по принципу SOAP [9]. Взаимодействие с веб-сервисом осуществляется по протоколу HTTP путем вызова определенных функций с параметрами (рис. 2).

Рис. 2. Схема взаимодействия с SOAP-веб-сервисом «РТС-тендер»

XML-пакеты принимаются в виде строковых параметров. Набор функций и их сигнатура определяются с помощью WSDL-файла, доступного в сети Интернет по адресу веб-сервиса. На основе этого файла создается, или, как правило, генерируется специальными инструментами, клиент для работы с веб-сервисом. После этого все взаимодействие с площадкой осуществляется с помощью этого клиента – вызов функций и получение результатов их выполнения.

Анализ процедур и механизмов взаимодействия с веб-сервисами нескольких электронных торговых площадок и официального сайта позволил выявить общие задачи, решаемые в процессе интеграции с этими системами. Первым шагом является реализация транспортного протокола взаимодействия с внешней системой. Так как торговые площадки и официальный сайт предоставляют доступ к информации через веб-сервисы, весь транспортный уровень основан на протоколе HTTP(S). Затем следует реализация клиента для конкретной системы в соответствии с ее API (Application Programming Interface – интерфейс программирования приложений). В зависимости от типа веб-сервиса, реализованного на стороне информационной системы, API может быть описан с помощью спецификации вызова удаленных процедур (WSDL-файл), либо с помощью описания структуры информационных пакетов, принимаемых на стороне внешней системы – XSD. Реализованный клиент предоставляет функции взаимодействия с внешней системой, которые позволяют выстраивать логику бизнес-процессов, описанных регламентирующими документами. На рис. 3 изображена диаграмма деятельности (Activity Diagram) взаимодействия с веб-сервисами в нотации UML [6, 7, 8].

Рис. 3. Диаграмма взаимодействия с веб-сервисом

Независимо от подхода к реализации веб-сервиса основной блок информации передается в формате XML. Для эффективного взаимодействия с электронными площадками и официальным сайтом требуется универсальный модуль генерации XML-пакетов. Помимо модуля генерации требуется модуль анализа XML-пакетов, т.к. результаты обработки информационных пакетов, отправленных на площадки и официальный сайт, также передаются в формате XML.

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

Синтез XML-пакетов на основе XML-шаблонов

Структура и содержание информационных пакетов, как было отмечено выше, подвержены частым изменениям по многим причинам (изменения в законодательстве, дополнения или уточнения полей и пр.). В связи с этим разработан подход к синтезу XML-пакетов на основе XML-шаблонов.

Шаблон представляет собой описание структуры будущего пакета и содержит инструкции по ее заполнению данными из базы данных. Пример шаблона приведен на рис. 4.

Рис. 4. Фрагмент XML-шаблона

Подход к синтезу пакетов с помощью шаблонов требует реализации ряда дополнительных модулей. Одним из модулей является универсальный парсер XML-шаблонов. Парсер должен уметь анализировать произвольный шаблон, выполненный в формате XML, строить иерархическое дерево из XML-узлов и распознавать синтаксические конструкции (таблица 1), состоящие из ключевых слов и заданных для них значений. Помимо парсера требуется XML-генератор, выполняющий функцию генерации итогового пакета для отправки его на электронный ресурс. На вход генератора получает дерево XML-тегов, построенное XML-парсером. Парсер, в свою очередь, проходит по узлам этого дерева и на каждом шаге получает данные из базы данных путем выполнения SQL-запросов. Полученные данные размещаются в соответствующих узлах – происходит информационное наполнение пакетов.

Таблица 1

Синтаксические конструкции, используемые в XML-шаблонах

Предложенный подход к синтезу информационных пакетов имеет очевидные преимущества:

– при внесении изменений в структуру пакета нет необходимости вносить изменения в исходный код программного обеспечения, и исчезает необходимость «горячего» программирования;

– структура описания XML-шаблонов проста и не требует навыков программирования для внесения изменений – их могут редактировать неспециалисты в области информационных технологий.

Подход к межсистемному обмену данными

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

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

Предлагаемое решение обладает рядом преимуществ. Во-первых, нет необходимости дорабатывать информационную систему – подсистема обмена данными реализуется в виде отдельного программного комплекса и функционирует на сервере приложений и/или базы данных. В свою очередь обмен заданиями информационного обмена и результатами их выполнения  осуществляется через рабочую базу данных. Во-вторых, использование базы данных в качестве шлюза для обмена сообщениями позволяет выполнять задания информационного обмена асинхронно. В таком режиме работы пользователям информационных систем не приходится ждать завершения процесса информационного взаимодействия с внешней системой (при медленном интернет соединении и большом объеме пакетов процесс может занять несколько минут), и пользователь может работать пока задания информационного обмена выполняются в фоновом режиме. В-третьих, при модификации подсистемы обмена данными внесенные изменения (например, при добавлении новой информационной системы для взаимодействия, либо при изменении структуры или содержания информационных пакетов) вступают в силу без обновления основной системы.

Реализация

На основе предлагаемого подхода создан программный комплекс интеграции. Комплекс представляет собой Desktop-приложение, работающее в двух режимах – с графическим интерфейсом или в виде консольного приложения. Программное обеспечение разработано в бесплатной среде разработки NetBeans на языке Java. Разработанный комплекс является кроссплатформенным и может функционировать в любой системе, для которой реализована виртуальная Java-машина. Для функционирования программного комплекса требуется виртуальная Java-машина, сервер базы данных Oracle и развернутая на нем интегрируемая база данных.

Программный комплекс предназначен для автоматизации процесса интеграции муниципальных информационных систем с электронными торговыми площадками и официальным общероссийским сайтом. На рис. 5 показана схема использования программного комплекса в департаменте муниципального заказа города Красноярска. Представлены основные участники информационного взаимодействия: муниципальная информационная система (МИС), веб-сервисы официального общероссийского сайта (ООС) и электронных торговых площадок (ЭТП). Взаимодействие модуля интеграции с муниципальной системой происходит через базу данных путем обмена сообщениями через служебные таблицы. Основные функции программного комплекса:

– отправка извещения о предстоящих закупках на ООС;

– обновление ранее отправленного проекта извещения на ООС;

– получение с ЭТП первых частей заявок;

– получение с ЭТП вторых частей заявок;

– отправка на ЭТП результатов рассмотрения первых частей заявок;

– отправка на ЭТП результатов рассмотрения вторых частей заявок;

– получение с ЭТП информации о поставщиках;

– получение с ЭТП информации о действующих комиссиях и пр.

Рис. 5. Структурная схема программного комплекса интеграции

Для инициации процесса межсистемного обмена информацией пользователь с помощью графического интерфейса муниципальной системы добавляет новую запись в таблицу заданий информационного обмена. В зависимости от выбранной закупки в таблицу заданий автоматически добавляется необходимая служебная информация – тип закупки (открытый конкурс, запрос котировок, электронный аукцион и т. д.), идентификатор закупки, а также данные о пользователе. После этого планировщик заданий, обнаружив новую запись в таблице заданий, начинает процесс отправки информации по закупке на указанный веб-сервис. Если клиент веб-сервиса еще не был инициализирован, то происходит его инициализация и при необходимости подключаются модули для работы по криптографическим протоколам [11].

Заключение

Предложен подход, позволяющий автоматизировать процесс межсистемной интеграции. Решена проблема исключения «горячего программирования» при внесении минимальных изменений в структуру или содержание информационных пакетов за счет синтеза XML-пакетов на основе XML-шаблонов. XML обеспечивает универсальный формат информационных сообщений, а XSD – строго определенную семантику. Организация взаимодействия с основной информационной системой через служебные таблицы базы данных дает возможность асинхронного выполнения заданий информационного обмена с внешними веб-сервисами. Предложенный подход позволяет разработчикам реализовывать требуемый функционал для взаимодействия с веб-сервисами в отдельном модуле интеграции, функционирующем на сервере базы данных и/или приложений, и избавляет от необходимости дорабатывать основную информационную систему для нужд интеграции. При этом унифицированный транспортный протокол HTTP(S) обеспечивает взаимодействие через веб-сервисы. Важным плюсом разработанного подхода является автономность и кроссплатформенность разрабатываемых на его основе программных средств.

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

Литература:

1.      Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures (Ph.D.) // Roy Thomas Fielding. – University of California, Irvine, 2000. – 180 p.

2.      Спецификация SOAP. [Электронный ресурс]. – Режим доступа: http://www.w3.org/TR/soap/

3.      Бертран Портье. Обзор терминологии SOA: Часть 1. Сервис, архитектура, управление и бизнес-термины // IBM DeveloperWorks. – 2008. [Электронный ресурс]. –  Режим доступа: http://www.ibm.com/developerworks/ru/library/ws-soa-term1/

4.      Хохгуртль Брайан. С# и Java: межплатформные Web-сервисы // Брайан Хохгуртль. – М.: Связь, 2004. – 213 с.

5.      ООС. АЛЬБОМ ТФФ. Требования к форматам и способам передачи информации по телекоммуникационным каналам связи в рамках интеграции Общероссийского официального сайта со смежными системами // Официальный общероссийский сайт. – 2014. – 520 с.

6.      Буч Г., Рамбо Д., Джекобсон А. Язык UML Руководство пользователя // Г. Буч, Д. Рамбо, А. Джекобсон. – ДМК Пресс, 2007. – 496 с.

7.      Леоненков А. Самоучитель UML // Леоненков А. – БХВ-Петерург, 2004. – 551 с.

8.      Fowler Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language // Martin Fowler. Addison-Wesley Professional, 2003. – 208 p.

9.      Регламент информационного взаимодействия ЭТП «РТС-тендер» с региональными системами // ЭТП «РТС-тендер». – 2011. – 23 с.

10.  Регламент информационного взаимодействия электронной площадки ММВБ «ГОСЗАКУПКИ» с прикладными автоматизированными системами организаторов торгов // ЭТП ММВБ «Госзакупки». – 2012. – 11 с.

11.  Белорусов А.И., Жучков Д.В. Автоматизация взаимодействия муниципальной информационной системы с внешними веб-сервисами в сфере закупок // Информатизация и связь. – 2014. № 3. – С. 79–83.

12.  Федеральный закон от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд».

13.  Белорусов А.И., Жучков Д.В., Кочетков С.Н. Программный комплекс интеграции информационных систем в сфере государственных и муниципальных закупок. Свидетельство о государственной регистрации программы для ЭВМ №2014617599 от 28 июля 2014 года / Федеральная служба по интеллектуальной собственности. – 2014.