Описание бесплатного адаптера СМЭВ Минкомсвязи

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

UPD 03.01.2020

С момента опубликования статьи описываемая в ней версия Адаптера СМЭВ морально и функционально устарела. Решение не поддерживает:

• новый ГОСТ электронной подписи;
• версию 1.3 схем СМЭВ.

Техподдержка СМЭВ поддерживает только последние версии адаптера.
Первое, что отвечают коллеги на соответсвующие запросы пользователей: «Сначала обновитесь до последней версии»

В связи с этим команда Хемуль IT настоятельно рекомендует обновить решение до последней версии, опубликованной на технологическом портале СМЭВ. Все опубликованные версии ПО также можно найти в материале «История версий Адаптера СМЭВ«.

Бесплатные адаптеры СМЭВ

Те особо любознательные пользователи технологического портала СМЭВ, кто долистывал главную страницу техпортала до конца, могли видеть там следующие ссылки:

• Рекомендуемая версия библиотек для сборки клиента СМЭВ 3 (для схем версий 1.1 и 1.2);
• Адаптер для работы со СМЭВ 3 (для схем версий 1.1 и 1.2, эти ссылки сейчас перенесены на страницу «Часто задаваемые вопросы» в раздел «Устаревшая версия клиента Адаптера»);
• Адаптер СМЭВ 3.0 (для Windows и Linux).

В данной статье речь пойдет об Адаптере для работы со СМЭВ 3 (далее — Адаптер). Мы расскажем, какие преимущества можно извлечь из его использования в интеграционных решениях, кратко опишем процедуры установки, настройки и работы с интерфейсом.

В следующих статьях мы расскажем об Адаптере СМЭВ 3.0 и о библиотеке для сборки клиента СМЭВ 3.

Описание Адаптера для работы со СМЭВ 3

Интерфейсы

Адаптер для работы со СМЭВ 3 был создан по заказу Минкомсвязи для облегчения и ускорения процессов интеграции со СМЭВ 3 на стороне участников межведомственного взаимодействия.

Адаптер представляет собой Java-приложение, которое с одной стороны полностью интегрировано со СМЭВ 3, а с другой — предоставляет участнику взаимодействия 4 различных интерфейса:

• web-сервис;
• обмен сообщениями через файловую систему;
• обмен сообщениями через базу данных;
• обмен сообщениями через Java Message Service.

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

GUI адаптера взаимодействует с самим Адаптером только через web-сервис.

Требования

В силу того, что Адаптер написан на Java, он является кроссплатформенным, и его можно устанавливать как на Windows, так и на nix-системы.

Для установки Адаптера требуются следующий набор компонентов:

• дистрибутив с технологического портала (бесплатно) для схем версии 1.2 (версия 1.2 отличается от версии 1.1 наличием некоторых элементов в блоке метаданных СМЭВ-конверта, например, eol или nodeID, но в формате бизнес-блоков сообщений разницы нет);
• JRE (бесплатно);
• (КриптоПро CSP + Trusted Java) или (КриптоПро CSP + КриптоПро Java CSP) или КриптоПро JСP.

Для взаимодействия с Адаптером через JMS потребуется Apache ActiveMQ, а для взаимодействия с адаптером через базу данных потребуется одна из поддерживаемых им СУБД:

• Oracle;
• MySQL;
• PostgreSQL;
• MS SQL Server.

Структура

Функциональная схема Адаптера для работы со СМЭВ представлена на рисунке.

К Адаптеру СМЭВ можно подключить несколько информационных систем участника взаимодействия. При этом системы могут подключаться как к одному, так и к разным интерфейсам.

Анализ логов Адаптера позволяет предположить, что он состоит из следующих модулей:

Транспортный модуль обеспечивает взаимодействие Адаптера с системой генерации кодов транзакций и с транспортной подсистемой СМЭВ 3.

Интеграционный модуль обеспечивает взаимодействие адаптера с информационными системами участника взаимодействия и с GUI адаптера.

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

В качестве СУБД могут быть использованы базы данных Derby (этот режим устанавливается по умолчанию) или PostgreSQL (здесь потребуется исполнить пару простеньких па с бубном).

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

Преимущества использования Адаптера СМЭВ в интеграционных решениях

В чем же заключаются преимущества использования Адаптера СМЭВ перед разработкой интеграционного решения «с нуля»?

Во-первых, упрощаются форматы XML-сообщений.

На следующих рисунках представлены: сверху — формат СМЭВ (из Методических рекомендаций по работе с ЕСМЭВ версии 3.4), снизу — формат Адаптера СМЭВ.

ЭП-ОВ – это электронная подпись информационной системы участника взаимодействия (органа власти).

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

При беглом анализе обоих схем бросается в глаза то, что в схеме Адаптера отсутствует подпись ЭП-ОВ. Эту функцию адаптер СМЭВ берет на себя – запросы, ответы и сообщения-тикеты (Ack) подписываются Адаптером автоматически.

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

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

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

Но могут быть использованы:

• библиотека для сборки клиента СМЭВ 3, о которой будет рассказано в одной из следующих статей;
• GUI адаптера СМЭВ, если взаимодействие осуществляется с его помощью (GUI адаптера описывается в последнем разделе данной статьи).

В-третьих, вместо элемента TransactionCode в схеме Адаптера применяются элементы комплексного типа createGroupIdentity или linkedGroupIdentity.

Первый из них используется в запросах и представляет собой нижеследующую последовательность элементов.

На основании значений этих элементов Адаптер СМЭВ самостоятельно получает код транзакции в СГКТ, используя сервис СПКТ.

Расшифровку этих непроизносимых аббревиатур можно посмотреть в Методических рекомендациях, но лучше не тратить на это время.

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

На практике же эта идея пока не используется, поэтому в качестве значений всех трех элементов CreateGroupIdentity можно передавать по двадцать нулей, и СПКТ вернет вполне годный код транзакции.

Элемент linkedGroupIdentity используется в ответах на запросы, полученные из СМЭВа, т.е. когда участник взаимодействия выступает в роли Поставщика вида сведений. Причем этот элемент заполняется Адаптером автоматически при обработке запроса.

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

Все вложения перемещаются в каталог файловой системы, а в элементах AttachmentHeader запроса передаются ссылки на них.

Адаптер самостоятельно принимает решение (на основании размера вложения), каким образом передавать вложения – MTOM или отдельным файлом через FTP.

Если вложение не подписано подписью должностного лица, то Адаптер совершенно самостоятельно подписывает его подписью ЭП-ОВ.

Еще два неочевидных преимущества работы через Адаптер СМЭВ – это возможность отправки в СМЭВ псевдосинхронных запросов (SendSyncRequest) при подключении информационной системы через web-интерфейс и реализация Адаптером службы приема от СМЭВ push-уведомлений.

SendSyncRequest со стороны информационной системы участника выглядит как запрос в СМЭВ с немедленным получением синхронного ответа на него.

Под капотом это реализуется с помощью стандартных асинхронных запросов и ответов СМЭВ.

Использование SendSyncRequest имеет смысл только в случае быстрой (секунды) реакции Поставщика на поступающие к нему запросы, а такие виды сведений еще нужно поискать.

Push-сервис – это замечательный компонент, который должен получать push-уведомления от СМЭВ о том, что в очереди участника взаимодействия появилось новое сообщение (например, ответ на запрос).

Но для того, чтобы сделать этот push-сервис видимым со стороны СМЭВ, нужно спуститься в организационно-бюрократический ад и пройти все семь его кругов сначала в одном направлении — с техническими службами Ростелекома, а потом в другом направлении — со службой безопасности.

Если бы push-уведомление содержало в себе сам ответ на запрос (для Потребителя ВС) или запрос от другого участника взаимодействия (для Поставщика ВС),  эти мытарства, может, и имели бы смысл.

Но push-уведомление от СМЭВ реализовано в семантике «Посмотри свою очередь – там что-то новенькое появилось». После такого уведомления все равно требуется посылать запрос в СМЭВ на чтение очереди.

А Адаптер СМЭВ и так непрерывно отправляет такие запросы.

Собственно, поэтому «синхронный» запрос и push-уведомления отнесены нами в разряд неочевидных преимуществ СМЭВ-Адаптера.

Работа с GUI-адаптера (готовое решение из бесплатной коробки)

Если взаимодействие участника со СМЭВ предполагается вдумчивым и неспешным, другими словами, если запросы и ответы будут обрабатываться вручную, а интеграция с информационной системой участника по тем или иным причинам нецелесообразна — за счет подключения GUI к Адаптеру  можно получить полноценный клиент для межведомственного взаимодействия.

Для этого:

1. В двух командных оболочках последовательно запускаем два приложения – Адаптер СМЭВ и GUI адаптера СМЭВ.
2. Открываем интернет-браузер, и в строке адреса вводим «http://localhost:8082/».
3. На форме авторизации вводим сначала логин и пароль администратора (admin и 123456 соответственно), поскольку нам нужно настроить информационную систему и виды сведений для нее.
4. Откроется интерфейс администратора, в котором заполним сведения о нашей информационной системе.
   
   Наименование системы может быть любым понятным пользователю.
   Мнемоника системы должна совпадать с той, которая зарегистрирована в СМЭВ и настроена в адаптере СМЭВ.
   Путь к файлу вложений должен совпадать с путем, настроенным в адаптере СМЭВ. Но может и вовсе отсутствовать, если виды сведений, обмен которыми предполагается реализовать, не используют вложений.
5. Переходим на закладку «Управление видами сведений» и добавляем описание вида сведений.
   
   Наименование вида сведений может совпадать с приведенным на технологическом портале, а может быть любым, удобным и понятным пользователям участника взаимодействия.
   Наименование схемы – необходимо указывать namespace из схемы вида сведений.
   Загрузить файл схемы – прикрепляется либо сам XSD-файл, либо, если в схеме есть импортируемые схемы, zip-архив, содержащий все схемы, используемые для вида сведений.
   Обычно в виде таких архивов схемы ВС хранятся на технологическом портале, но иногда их приходится собирать руками.
   Наименования корневых элементов запроса и ответа копируются из схемы вида сведений.
   В списке связанных информационных систем нужно указать те ИС, которые будут работать с создаваемым видом сведений. Для каждой ИС (если их много) могут быть указаны разные ВС (если их много).
   Нажимаем кнопку «Добавить».
6. На закладке «Управление пользователями» происходит обычная админская работа с пользовательскими аккаунтами.
   На этой форме, помимо прочих атрибутов, для пользователя можно задать путь к контейнеру персональной подписи (той самой ЭП-СП) и пароль к контейнеру.
   В поставке по умолчанию настроены два пользователя – admin и user.Оба с паролями 123456, которые, естественно, в боевых условиях нужно немедленно поменять.
   Добавим пользователю user возможность работы с только что созданной информационной системой (кнопка «Добавить ИС»).
7. Выходим из системы и осуществляем вход под учетной записью пользователя.
   
   У простого пользователя есть возможность создавать и отправлять в СМЭВ запросы, просматривать полученные ответы, просматривать полученные запросы и писать на них ответы.
8. Создадим новый запрос в СМЭВ
   
   Сначала выберем информационную систему, под чьей мнемоникой адаптер пошлет запрос в СМЭВ, а затем вид сведений, связанный администратором с этой системой.
   GUI адаптера автоматически создает форму для ввода запроса на основании XSD-схемы, загруженной администратором.
   
   Но это если схема не содержит ошибок и GUI адаптера может ее разобрать. Иначе беда – встроенного конструктора форм в GUI адаптера нет.
   Наименования полей подтягиваются из элементов <xs:documentation>, поэтому если метки получаются слишком длинными и неудобочитаемыми, то схему вида сведений можно немного адаптировать к GUI адаптера, не меняя, разумеется, наименования и структуру самих элементов. Иначе наш запрос не поймет СМЭВ.
9. После заполнения полей запроса нажимаем кнопку «Отправить», и запрос уходит в СМЭВ.
10. Пользователю предоставляется интерфейс, в котором он может отслеживать состояние всех отправленных запросов и просматривать полученные ответы.
11. Пользователю предоставляется возможность просматривать как запрос, так и ответ на него.
    
    Возможность вывода сообщений на печать у пользователя, к сожалению, отсутствует.

Работа с входящими запросами, где участник взаимодействия выступает в роли поставщика вида сведений, происходит аналогичным образом.

В качестве заключения

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

Главный вывод заключается в том, что продукт вполне работоспособен, несмотря на несовершенство документации к нему и определенные трудности в установке и настройке, обусловленные этим несовершенством.

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

______________________

Если у вас остались вопросы по данному материалу — пожалуйста, оставьте комментарий или свяжитесь с нами.

Также вы можете передать задачи организации СМЭВ-взаимодействия участникам нашего проекта. Качественная настройка СМЭВа и интеграция Адаптера с различными ИС — наш нехемульский долг.