Все, что вы хотели узнать о свободно распространяемом клиенте для межведомственного взаимодействия, но не знали, где искать информацию.
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 к Адаптеру можно получить полноценный клиент для межведомственного взаимодействия.
Для этого:
- В двух командных оболочках последовательно запускаем два приложения – Адаптер СМЭВ и GUI адаптера СМЭВ.
- Открываем интернет-браузер, и в строке адреса вводим «http://localhost:8082/».
- На форме авторизации вводим сначала логин и пароль администратора (admin и 123456 соответственно), поскольку нам нужно настроить информационную систему и виды сведений для нее.
- Откроется интерфейс администратора, в котором заполним сведения о нашей информационной системе.
Наименование системы может быть любым понятным пользователю.
Мнемоника системы должна совпадать с той, которая зарегистрирована в СМЭВ и настроена в адаптере СМЭВ.
Путь к файлу вложений должен совпадать с путем, настроенным в адаптере СМЭВ. Но может и вовсе отсутствовать, если виды сведений, обмен которыми предполагается реализовать, не используют вложений. - Переходим на закладку «Управление видами сведений» и добавляем описание вида сведений.
Наименование вида сведений может совпадать с приведенным на технологическом портале, а может быть любым, удобным и понятным пользователям участника взаимодействия.
Наименование схемы – необходимо указывать namespace из схемы вида сведений.
Загрузить файл схемы – прикрепляется либо сам XSD-файл, либо, если в схеме есть импортируемые схемы, zip-архив, содержащий все схемы, используемые для вида сведений.
Обычно в виде таких архивов схемы ВС хранятся на технологическом портале, но иногда их приходится собирать руками.
Наименования корневых элементов запроса и ответа копируются из схемы вида сведений.
В списке связанных информационных систем нужно указать те ИС, которые будут работать с создаваемым видом сведений. Для каждой ИС (если их много) могут быть указаны разные ВС (если их много).
Нажимаем кнопку «Добавить». - На закладке «Управление пользователями» происходит обычная админская работа с пользовательскими аккаунтами.
На этой форме, помимо прочих атрибутов, для пользователя можно задать путь к контейнеру персональной подписи (той самой ЭП-СП) и пароль к контейнеру.
В поставке по умолчанию настроены два пользователя – admin и user.Оба с паролями 123456, которые, естественно, в боевых условиях нужно немедленно поменять.
Добавим пользователю user возможность работы с только что созданной информационной системой (кнопка «Добавить ИС»). - Выходим из системы и осуществляем вход под учетной записью пользователя.
У простого пользователя есть возможность создавать и отправлять в СМЭВ запросы, просматривать полученные ответы, просматривать полученные запросы и писать на них ответы. - Создадим новый запрос в СМЭВ
Сначала выберем информационную систему, под чьей мнемоникой адаптер пошлет запрос в СМЭВ, а затем вид сведений, связанный администратором с этой системой.
GUI адаптера автоматически создает форму для ввода запроса на основании XSD-схемы, загруженной администратором.
Но это если схема не содержит ошибок и GUI адаптера может ее разобрать. Иначе беда – встроенного конструктора форм в GUI адаптера нет.
Наименования полей подтягиваются из элементов <xs:documentation>, поэтому если метки получаются слишком длинными и неудобочитаемыми, то схему вида сведений можно немного адаптировать к GUI адаптера, не меняя, разумеется, наименования и структуру самих элементов. Иначе наш запрос не поймет СМЭВ. - После заполнения полей запроса нажимаем кнопку «Отправить», и запрос уходит в СМЭВ.
- Пользователю предоставляется интерфейс, в котором он может отслеживать состояние всех отправленных запросов и просматривать полученные ответы.
- Пользователю предоставляется возможность просматривать как запрос, так и ответ на него.
Возможность вывода сообщений на печать у пользователя, к сожалению, отсутствует.
Работа с входящими запросами, где участник взаимодействия выступает в роли поставщика вида сведений, происходит аналогичным образом.
В качестве заключения
В настоящей статье приведен общий обзор Адаптера для СМЭВ и преимуществ его применения в интеграционных решениях.
Главный вывод заключается в том, что продукт вполне работоспособен, несмотря на несовершенство документации к нему и определенные трудности в установке и настройке, обусловленные этим несовершенством.
В одной из следующих статей мы расскажем о реальных решениях, построенных на базе Адаптера СМЭВ, а также о последней версии Адаптера, в которую внесен ряд существенных изменений.
______________________
Если у вас остались вопросы по данному материалу — пожалуйста, оставьте комментарий или свяжитесь с нами.
Также вы можете передать задачи организации СМЭВ-взаимодействия участникам нашего проекта. Качественная настройка СМЭВа и интеграция Адаптера с различными ИС — наш нехемульский долг.