Vashkontrol.ru – Официальный сайт «Госуслуги» прочно вошли в нашу жизнь как средство взаимодействия с органами власти. Больше не нужно стоять в очередях, чтобы заменить паспорт, оплатить налог или записаться на прием к врачу — достаточно внести личные данные и сделать пару кликов. Однако все эти операции включают в себя шаги и состояния, скрытые от пользователя за простыми записями и оповещениями.
В цикле статей мы, команда Gems Development, расскажем о работе с «Госуслугами» по ту сторону экрана и о том, как оформить эффективное взаимодействие органов государственной власти с порталом.
Настраиваю взаимодействие со СМЭВ-3 с помощью java-клиента от НИИ Восход.
Первоначальный запрос поставщику услуг SendRequestRequest проходит синхронную проверку сервиса и уходит на асинхронную. После этого я ставлю sleep 1 минуту и пробую отправить GetResponseRequest с помощью метода getResponse класса ru.voskhod.smev.message_exchange_service_clientMessageExchangeEndpoint. В ответ получаю пустой ответ
<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:GetResponseResponse xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1"/> </S:Body>
</S:Envelope>При этом тело ответа отсутствует.
Документация что по клиенту, что от поставщиков, что официальная – основной момент уделяет отправке запроса SendRequestRequest, опуская дальнейшее взаимодействие. При этом, судя по форуму Криптопро, достаточно много людей пользуется СМЭВ-клиентом. Хотелось бы у тех, кто имеет опыт работы либо с клиентом, либо со СМЭВ непосредственно, спросить как правильно получить результат обработки запроса?
smev3_adapter_service
Назначение
Архитектура системы
smev3_adapter_service использует Mongo и Sanic
Примеры запросов и поддерживаемые маршруты
Примеры отправки запроса для получения выписок ЕГРЮЛ и ЕГРИП
http: : : :
http: : : :
Для получения ответов используется URL /get_document/<тип_запроса>/<идентификатор_запроса>
Примеры получения ответа для получения выписок ЕГРЮЛ и ЕГРИП:
http:
http:
Допустимые типы запросов и идентификаторы для каждого типа запросов определяются настройками
Настройки приложения
MONGO_URL – адрес для доступа к mongo
ADAPTER_SETTINGS – словарь с настройками адаптера. Содержит параметры:
- url – адрес WSDL адаптера СМЭВ 3 (например, http://192.168.1.1:7575/ws?wsdl)
- mnemonic – мнемоника ИС в адаптере СМЭВ 3
- test_mode – boolean-параметр тестового режима. Если True, в XML будет подставлен соответствующий элемент для маркирования тестового режима. В производственном режиме всегда False
{ : , : , : , : , }Кроме того, в папке xsd содержатся типы данных запросов и ответов СМЭВ. Каждая подпапка называется по ID типа данных с технологического портала СМЭВ3 и содержит распакованный zip-файл формата данных, скачанный с технологического портала СМЭВ 3. За счёт добавления новых типов поддерживается хоршая расширяемость проекта. После добавления типа нужно занести соответствующую настройку в словарь DOCUMENT_IDENTIFIERS.
Запуск приложения
Для запуска нужно отредактировать файл settings.py в корне проекта, а затем выполнить
make run
Авторские права и лицензия
Коллеги, всем добрый день!
Если есть у кого опыт взаимодействия, и советы, буду признателен
Вводные:
У нас возникла необходимость подключения организации к видам сведений Росреестра, через СМЭВ3.
Провели тестирование, и оказалось, что у Росреестра на 2021г и начало 2022г отсутствовала тестовая зона, о чем нам сообщила поддержка СМЭВ спустя полгода (насколько я знаю, на текущий момент, ситуация не изменилась).
Единственный вариант тестирования, это закидывание XML из эталона под форматы СМЭВ3, и вложения вы при этом не получите, т.к. СМЭВ3 их на тестовом контуре не выдаёт, ровно как и на продуктиве при проверке эталонов для подключения.
Организация уже была подключена к СМЭВ, поэтому, подключили вид сведений, через обращение в ЛК Министерства Связи. Время заняло до полугода, т.к. требовалось согласование Росреестра (никаких ключей Росреестр не выдавал и не запрашивал).
Подключили следующий вид сведений на продуктив: Прием обращений в ФГИС ЕГРН VS00376v004-RRTR02
Ссылка для ознакомления: https://smev3.gosuslugi.ru/portal/inquirytype_one.jsp?id=70074&zone=fed&page=1&dTest=false
После подключения начались безуспешные попытки формирования XML, для получения искомой выписки ЕГРН. Наш кейс достаточно простой, нам как организации, необходимо получить выписку ЕГРН по ЮЛ или ФЛ, путем указания кадастрового номера, соответственное запрос идет от организации.
Для этого мы используем тестовый сценарий №25: «Предоставление сведений, содержащихся в Едином государственном реестре недвижимости, посредством обеспечения доступа к федеральной государственной информационной системе ведения Единого государственного реестра недвижимости»
Т.к. у него в эталоне, именно такая выписка, которая нам нужна.
На протяжении длительного времени писали в разные поддержки, но в ответ либо молчание, либо «отфутболивание» друг на друга (СМЭВ на Росреестр и обратно, т.к. СМЭВ пишет, что не является поставщиком видов сведений Росреестра, а Росреестр в свою очередь отвечает, что поддержкой СМЭВ занимается сам СМЭВ)
Спустя время, мы отладили наши запросы из нашей ИС в СМЭВ (SendRequestRequest, GetResponseRequest)
Проверили отладку наших XML формируемых в СМЭВ, на странице СМЭВ, под версию сведений Росреестра (1.1)
Ссылка для ознакомления: https://smev3.gosuslugi.ru/portal/checkxmlform.jsp
Далее мы проверили отладку XML (app.xml, request.xml), которые формируются под схемы Росреестра
Полезная ссылка для верхнеуровневой отладки сообщений именно под схемы Росреестра (надеюсь кому-то поможет): https://pbprog.ru/webservices/xsd/
На выходе мы получается вот такое сообщение в статусе GetResponseResponse:
Успешно создано обращение с идентификатором Vedomstvo-2022-03-05-347453
Поддержка СМЭВ разводит руками, т.к. данное сообщение приходит от Росреестра
Поддержка Росреестра ответила конструктивно один раз за 1 год, и сообщило, что сообщение не проходит проверку на внутреннее заявление app.xml, т.е. «Не проходит проверку ФЛК», ошибку выдает только в системе Росреестра, а на шлюз СМЭВ приходит уже ответ: Успешно создано обращение с идентификатором Vedomstvo-2022-03-05-347453. Дополнительно закинули коллег сообщениями в поддержку с комментариями, по исправлению, но в ответ снова тишина.
Пояснить нам до сих пор не смогли по какой причине так происходит, и что надо исправить.
Прикладываю наш app.xml (отметил поля, которые мы заполняем). EgrnRequest и Declarant _id видоизменены как и уникальные данные исходного запроса.
Есть несколько вопросов:
1) Как должен выглядеть корректный app.xml по которому можно нормально запросить выписку по ЮЛ и ФЛ, от организации? Если у вас есть примеры, по которым данное сообщение работает, будет супер.
2) Корректный ли тестовый сценарий используется? Мы используем 25 сценарий. Но 24 и 25 сценарий различаются довольно странно, и выписки которые должен формировать Росреестр ответом – разные.
3) Как происходит оплата если используется взаимодействие ИС Организации – СМЭВ3- Росреестр? (вот этот момент коллеги, темный лес)
Подмечу, что используется электронная подпись СМЭВ, которая летит в исходном запросе для самого СМЭВ, и никаких дополнительных ключей Росреестр (accessKey, validKey, token и тому подобное) не выдавал. Предполагается, что при запросе через СМЭВ3, такие ключи не требуются, т.к. используется основной ключ СМЭВ3.
Если у вас тоже есть вопросы, постараюсь помочь со своей стороны
СМЭВ3 и настройка Адаптера ЦФТ Госуслуги
На страницу Пред. 1, 2, 3, 4 След.
| Предыдущая тема :: Следующая тема | |||||||||||||
| Автор | Сообщение | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ykrasutskiy Участник Неподтвержденный Вступление в Клуб: 05.10.2018 |
| ||||||||||||
 | |||||||||||||
| Blackmore64 Профи Неподтвержденный Вступление в Клуб: 17.01.2017 |
| ||||||||||||
| |||||||||||||
| Blackmore64 Профи Неподтвержденный Вступление в Клуб: 17.01.2017 |
| ||||||||||||
| |||||||||||||
| ykrasutskiy Участник Неподтвержденный Вступление в Клуб: 05.10.2018 |
| ||||||||||||
| |||||||||||||
| Evgeny071 Участник со стажем Неподтвержденный Вступление в Клуб: 25.10.2017 |
| ||||||||||||
| |||||||||||||
| Blackmore64 Профи Неподтвержденный Вступление в Клуб: 17.01.2017 |
| ||||||||||||
| |||||||||||||
| Evgeny071 Участник со стажем Неподтвержденный Вступление в Клуб: 25.10.2017 |
| ||||||||||||
| |||||||||||||
| Blackmore64 Профи Неподтвержденный Вступление в Клуб: 17.01.2017 |
| ||||||||||||
| |||||||||||||
| Evgeny071 Участник со стажем Неподтвержденный Вступление в Клуб: 25.10.2017 |
| ||||||||||||
| |||||||||||||
| Blackmore64 Профи Неподтвержденный Вступление в Клуб: 17.01.2017 |
| ||||||||||||
| |||||||||||||
| Evgeny071 Участник со стажем Неподтвержденный Вступление в Клуб: 25.10.2017 |
| ||||||||||||
| |||||||||||||
| Blackmore64 Профи Неподтвержденный Вступление в Клуб: 17.01.2017 |
| ||||||||||||
| |||||||||||||
| Evgeny071 Участник со стажем Неподтвержденный Вступление в Клуб: 25.10.2017 |
| ||||||||||||
| |||||||||||||
| Blackmore64 Профи Неподтвержденный Вступление в Клуб: 17.01.2017 |
| ||||||||||||
| |||||||||||||
| Evgeny071 Участник со стажем Неподтвержденный Вступление в Клуб: 25.10.2017 |
| ||||||||||||
| |||||||||||||
| |||||||||||||
Вы не можете начинать темы |
Статья написана в развитие темы, поднятой в предыдущей публикации – «Шишки, набитые при работе с адаптером СМЭВ». Рассматривается практический опыт реализации интеграционного решения на базе Адаптера СМЭВ. В роли адаптера используется бесплатное решение, представленное на технологическом портале СМЭВ 3 в разделе «Полезные ссылки». Текст подготовлен коллективом авторов – участников экспертного проекта «Хемуль IT».
Исходные положения проекта
Масштаб межведомственного взаимодействия: Заказчик выступает потребителем порядка 20 различных видов сведений.
Интенсивность взаимодействия: 100 тысяч запросов в сутки.
Особенности архитектуры решения:
- для подготовки данных СМЭВ-запросов и обработки данных ответов Заказчик использует собственную информационную систему (ИС);
- ИС расположена в закрытом контуре, перенос информации из ИС в СМЭВ-проект осуществляется в полуавтоматическом режиме посредством файлового обмена;
- часть видов сведений требует подписания запроса ЭП должностного лица;
- все сертификаты хранятся на физических токенах и являются неэкспортируемыми.
Дополнительные требования:
- администратор решения должен иметь возможность контролировать статус обработки СМЭВ-запросов, скорость ответа Поставщика, timeout-ы;
- администратор решения должен видеть расширенный набор статусов обработки СМЭВ-запросов, в том числе уведомления о поступлении запроса в ИС Поставщика;
- администратор решения не должен иметь доступ к содержанию сообщений, т.к. данные запросов и ответов СМЭВ включают информацию ограниченного доступа.
Описание реализации
Оборудование
Сервер приложений развернут на виртуальной машине CentOS под управлением VMWare. Характеристики сервера довольно средние: 4 ядра, 4 ГБ оперативной памяти, 500 ГБ дискового пространства.
У Заказчика используется криптошлюз ПАК ViPNet Coordinator HW1000.
Лицензии
Для взаимодействия со СМЭВ был выбран Адаптер из раздела «Полезные ссылки» технологического портала СМЭВ 3, к которому ИС заказчика подключается в режиме файлового обмена.
В качестве криптопровайдера установлена связка КриптоПро CSP 4.0 + Trusted Java 2.0. Лицензии на оба продукта были приобретены заранее, причем клиентские, поскольку CentOS по классификации КриптоПро не относится к серверным операционным системам.
Здесь требуется отметить один нюанс, связанный с Trusted Java. В отличие от КриптоПро, который сразу поставляется с пробной лицензией, пробную лицензию на Trusted Java нужно заказывать по электронной почте, указанной на сайте производителя.
СУБД
Поскольку Заказчику необходимо получать информацию о состоянии запросов, в Адаптере была использована СУБД PostgreSQL. Такое решение показалось нам с точки зрения самостоятельного развития и доработки проекта более предпочтительным, чем использование штатной СУБД Derby.
Сложность заключается в том, что при установке PostgreSQL в ней требуется вручную создавать схемы для каждой ИС участника взаимодействия. Для Derby это делается автоматически.
SQL-файл со скриптами схемы обнаружился в одном из jar-файлов из поставки Адаптера, а именно в smev-service-adapter-storage-postgresql-1.1.8.jar. Там в папке sql находится файл с названием amalgamation.sql. Этот файл был извлечен из jar-архива, модифицирован (название схемы TEST1 заменено на мнемонику ИС Заказчика) и выполнен в psql.
В документации на Адаптер все эти манипуляции, к сожалению, не описаны, поэтому у некоторых разработчиков складывается мнение, что Адаптер не поддерживает PostgreSQL.
Для сбора интересующих Заказчика данных о состоянии запросов в стандартной схеме Адаптера была создана дополнительная таблица state.
Общая архитектура в первом приближении
Первая реализация СМЭВ-проекта имела следующий вид:
Internal Gateway – набор каталогов файловой системы, с которым взаимодействует ИС Заказчика. В каталог Requests помещаются запросы в СМЭВ, а из каталога Responses забираются ответы (и иногда сообщения об ошибках). В каталоге Logs просматриваются лог обработки запросов, в том числе информация о статусах, достижении суточного лимита запросов на один вид сведений (в соответствии с заявкой на доступ к ВС), ошибках и таймаутах.
External Gateway – набор штатных каталогов Адаптера СМЭВ, которые он использует для взаимодействия с ИС УВ в режиме подключения через файловую систему.
PostgreSQL – это база данных Адаптера СМЭВ (слегка доработанная).
PHP-адаптер – это консольное приложение Transformer, написанное на PHP и выполняющее следующие функции:
- чтение файла с запросом из каталога Requests (если есть файл вложения, то ИС заказчика передает его в одном архиве с запросом);
- формирование client_id;
- подпись запроса (и вложения, если есть) ЭЦП должностного лица (если требуется в виде сведений);
- преобразование запроса в формат Адаптера СМЭВ (XSLT-преобразование, которое в конверт ClientMessage вставляет мнемонику ИС Заказчика, сформированный clientId, MessagePrimaryContent с исходным запросом и PersonalSignature, если она нужна, обработка файла вложения, если он есть);
- сохранение преобразованного запроса в папку OUT, а файла вложения (если есть) в папку local-storage;
- регистрацию факта обработки запроса в таблице state БД Адаптера;
- чтение файла с ответом из каталога OUT и вложения (если есть) из каталога base_storage;
- получение (через XSLT) из конверта ответа содержимого элемента MessagePrimaryContent;
- сохранение бизнесовой части ответа в каталоге Responses (если ответ с вложением, то вложение упаковывается в один архив с бизнес-ответом);
- обновление статусов отправленных запросов в таблице state БД Адаптера;
- выгрузка статусов отправленных запросов из таблицы БД в noSQL-формат в каталог Logs.
Как видно из приведенной схемы, все работает очень просто. ИС Заказчика оперирует с форматами видов сведений в том виде, как они опубликованы на технологическом портале СМЭВ, и не заботится о каких-либо СМЭВ- или Адаптер-конвертах.
Реализации подписи СМЭВ-запросов и обновленная архитектура решения
Подпись должностного лица сначала создавалась с помощью утилиты signertool, которая входит в состав «Рекомендуемой версии библиотек для сборки клиента СМЭВ 3» (см. раздел «Полезные ссылки» технологического портала СМЭВ 3). На вход утилите подаётся команда -cmd signXml, имя файла с запросом и имя файла, в который нужно положить подпись.
И тут начинаются проблемы. Если контейнер с подписью находится на физическом токене, его поиск с виртуальной машины осуществляется очень долго (20-30 секунд). В нашем случае обе подписи (ИС УВ и должностного лица) находились на RuToken’ах и были неэкспортируемыми. Поэтому, как только началась передача большого количества запросов с подписью должностного лица, общая производительность решения кардинально сократилась. Задерживалась вся очередь запросов, поскольку её обработка производилась последовательно.
Первое, что было сделано – вынос процесса подписи запросов в отдельный поток. Файлы с видами сведений, которые требуют подписи ЭП-СП, фильтруются Transformer’ом по маске в имени файла и оставляются в папке Requests без обработки. К их обработке привлекли отдельное приложение Signer, которое подписывает запрос с помощью той же утилиты signertool и запаковывает его вместе с подписью в архив. Архив возвращается в папку Requests, где уже обрабатывается Transformer’ом.
Теперь запросы, не требующие подписи должностного лица, стали уходить быстрее. Но в целом проблему это не решило – запросы по-прежнему подписывались слишком медленно. Даже запуск Signer’а в нескольких параллельных потоках не спас ситуацию. 10 потоков увеличивали скорость подписания всего в 1,5 раза.
Тогда мы провели доработку приложения signertool. Приложение, как и вся библиотека, поставляется с исходными кодами. Теперь вместо одного файла подписываются все файлы, находящиеся в папке, имя которой передаётся в командной строке, а подписи помещаются в другую папку, передаваемую там же.
Поиск контейнера происходит по-прежнему долго, но найденной подписью подписывается сразу несколько тысяч файлов.
Просьба к коллегам
Если у кого-нибудь найдётся решение проблемы с физическими токенами под виртуальными машинами, и вы можете им поделиться – будем весьма признательны. Сообщить о том, что такое решение существует, можно в редакцию D-Russia.ru.
Таким образом, схема решения приняла окончательный вид:
Расширение перечня стандартных статусов обработки СМЭВ-запросов
При больших объёмах межведомственного взаимодействия запросы иногда «теряются» – запрос направлен, ответ отсутствует. Поставщик не может оперативно ответить, получен ли и отработан ли запрос. Когда в ходе промышленной эксплуатации решения количество спорных ситуаций вида «кто виноват в том, что нет ответа на запрос» превысило порог терпения разработчиков, было решено воспользоваться возможностью отслеживания расширенных статусов запросов, предоставляемой по запросу в ситуационный центр (СЦ) СМЭВ.
Существует процедура, позволяющая подключить два дополнительных статуса обработки СМЭВ-запроса – «запрос поступил в очередь Поставщика» и «Поставщик забрал запрос из очереди». После одобрения соответствующей заявки, направляемой через СЦ электронного правительства, из СМЭВ начали поступать новые сообщения о статусах запросов, эти статусы Адаптер преобразовывал в сообщения ClientMessage с элементом status.
Потребовалось доработать PHP-адаптер для того, чтобы он мог правильно интерпретировать сообщения о статусах, после чего в файле с состоянием запросов появились статусы POSTED (запрос помещён в очередь поставщика) и DELIVERED (запрос прочитан поставщиком из очереди).
С учетом того, что ранее были реализованы статусы PREPARED (запрос обработан в PHP-адаптере и помещен в каталог Адаптера СМЭВ), TIMEOUT (запрос, который пробыл в статусе SENT более 30 дней и по нему не пришло сообщений о статусе), OVERLIMIT (запрос, необработанный PHP-адаптером по причине превышения суточного лимита по виду сведений), REJECTED (вернулся ответ с элементом reject), а также с учётом стандартных статусов SENT, QUEUE, ANSWERED и FAILED от Адаптера, модель статусов запроса приобрела следующий вид:
Интерфейс администратора для контроля состояния запросов
Ведение логов обработки СМЭВ-запросов – очень удобный инструмент разработки на этапе тестирования и запуска проекта. Однако для текущего контроля межведомственного взаимодействия администратором они не подходят. Администратору неудобно регулярно открывать лог и проверять изменения за прошедший день, час или пять минут.
В связи с этим в дополнение к функционалу логирования был разработан отдельный инструмент, представляющий собой веб-интерфейс со списком всех запросов, их текущих статусов и дополнительной информации. Кроме того, в интерфейсе реализован функционал простой и сложной (по нескольким атрибутам) фильтрации списка запросов.
По каждому запросу в веб-интерфейсе отображаются данные о названии исходного файла запроса, текущем статусе запроса, СМЭВ-id запроса и ответа, времени направления запроса и последнего обновления его статуса, возвращаемых СМЭВ ошибках (при их наличии).
Таким образом, администратор видит полную картину обмена сообщениями в режиме реального времени, но при этом не может получить доступ к конфиденциальному содержанию запросов и ответов.
Техническая реализация функционала выстроена следующим образом:
- при обработке нового файла с запросом в таблице state фиксируется его наименование, штамп времени обработки, clientID, наименование ВС, ключевые параметры запроса (например, ФИО при запросе ИНН или ОГРН при запросе выписки из ЕГРЮЛ), статус PREPARED (или OVERLIMIT, если по данному ВС превышен суточный лимит запросов);
- созданная запись обогащается из штатной таблицы Адаптера message, которая связывается с таблицей state по clientID, значениями messageID (идентификатор запроса в СМЭВ), штампом времени отправки запроса в СМЭВ, новым статусом (SENT, QUEUE или FAILED);
- при обработке ответа в таблицу state из той же таблицы message добавляются СМЭВ-идентификатор ответа, штамп времени получения ответа и новый статус (FAILED, ANSWERED, POSTED, DELIVERED, REJECTED). Причем, последние три статуса Адаптер интерпретирует в своей таблице как ANSWERED, поэтому при обновлении state PHP-адаптер анализирует не только таблицу message, но и содержимое ответа;
- для всех статусов, кроме ANSWERED, в таблице state заполняются поля «Источник сообщения», «Код сообщения» и «Текст сообщения» для предоставления пользователю более подробной информации о статусе запроса;
- ежедневно все запросы в статусе SENT, отправленные более 30 дней назад (этот параметр настраивается в properties PHP-адаптера), переводятся в статус TIMEOUT.
- Веб-интерфейс обращается к постоянно пополняемой и обновляемой таблице state и таким образом предоставляет пользователю в реальном времени полную картину состояния отправленных запросов.
Особенности проведения тестирования видов сведений
Для тестирования новых видов сведений в тестовом СМЭВ был собран стенд, аналогичный описанному выше. Стенд работает под Windows на рабочем компьютере администратора.
Перед тестированием параметр development.transport.persist.soap Адаптера СМЭВ включается в положение true (этим обеспечивается сохранение Адаптером сообщений в формате СМЭВ), в настройках PHP-адаптера включается режим isTesting (этим обеспечивается вставка элемента testMessage в конверт Адаптера и затем в конверт СМЭВ), токены с подписями переносятся на тестовый стенд (да, основной процесс при этом ставится на паузу, но подписи, напоминаем, неэкспортируемые) и производится отправка тестовых запросов к тестовому СМЭВ.
При этом на вход подаются эталонные запросы из документации на ВС, которые проходя через всю цепочку превращаются в запросы СМЭВ и помещаются вместе с ответами в корневой каталог Адаптера. Запросы и ответы в формате СМЭВ затем вручную подбираются попарно, запаковываются в архив и отправляются в СЦ СМЭВ в качестве результатов тестирования ВС.
Результаты проекта
Решение стабильно работает у Заказчика на протяжении года и практически не нуждается в сопровождении. Администраторы Заказчика периодически проверяют факт наличия запущенного процесса Адаптера СМЭВ, доступность контейнеров с подписями и их актуальность (срок действия), объем свободного места на диске. Эти действия проводятся регулярно при регламентных профилактических работах.
Все проектные работы выполнялись двумя IT-специалистами – разработчиком (90% работ) и linux-администратором (10% работ). Наличие готового и работоспособного Адаптера СМЭВ позволило нам в короткие сроки и с относительно невысокими затратами реализовать полноценное (включающее этап тестирования видов сведений) интеграционное решение, к тому же высоконагруженное.
GUI Адаптера не использовался. Общение с системой производилось через настроечные файлы (properties) в одну сторону и noSQL-логи и «самописный» интерфейс Мониторига СМЭВ в другую.
Благодарности
Наличие бесплатного полнофункционального Адаптера СМЭВ – настоящий подарок для исполнителя работ по обеспечению межведомственного взаимодействия. Выражаем благодарность разработчикам решения и Минкомсвязи за этот проект.
Со своей стороны хотели бы предложить коллегам продолжать развитие решения по следующим направлениям:
- поработать над полнотой и прозрачностью документации, т.к. некоторые знания в настоящий момент можно получить только опытным путем;
- сформировать wiki для Адаптера СМЭВ или сделать отдельную площадку для обмена опытом;
- создать и разместить на технологическом портале обучающие ролики по особо сложным темам.
Несмотря на определенные сложности с настройкой, бесплатный Адаптер СМЭВ является гибким, надёжным инструментом, который позволяет реализовывать высоконагруженные проекты. Он облегчает работу интеграторам и экономит средства Заказчиков.
Следите за нашим Телеграм-каналом, чтобы не пропускать самое важное!
Поделиться:
Участники взаимодействия
Представим, что «Госуслуги» — это магазин, на витрине которого представлены сервисы для граждан и организаций. Запрос «покупателя» на услугу передаётся соответствующим органам через систему межведомственного электронного взаимодействия (СМЭВ). Система передаёт сообщения между порталом и ведомством.
Работа через СМЭВ происходит по протоколу SOAP (Simple Object Access Protocol — простой протокол для доступа к объектам).
Участники взаимодействия, как в магазине, делятся на поставщиков и потребителей. Поставщик — это информационная система (ИС), которая предоставляет сведения по запросу, а потребитель — система, запрашивает сведения.
Одна и та же ИС может действовать сразу в двух ролях. Например, в процессе предоставления услуги нужно уведомить портал о смене её статуса. В этом случае ИС-поставщик исполняет роль потребителя — проводит информационный обмен по статусам.
Виды сведений
Участники обмениваются данным через виды сведений (протоколы обмена) — правила формирования пакетов данных для передачи от одного участника другому.
Хороший пример вида сведений — Всероссийская перепись населения 2020. Данные о переписи передают федеральным органам исполнительной власти в электронном виде. В полученных данных существует чёткая структура сведений: ФИО, пол, дата рождения, гражданство, семейное положение. Также в рамках вида сведений описан ответ, который должен быть получен, если обработка запроса прошла успешно.
На июнь 2020 года в СМЭВ зарегистрировано более 1000 промышленных (рабочих) и 2000 тестовых видов.
Обмен данными в промышленной среде по всем видам сведений ведётся через защищённые каналы связи. Все передаваемые данные сопровождаются электронной цифровой подписью, с помощью которой СМЭВ идентифицирует участников взаимодействия.
Данные передаются по протоколу SOAP, при этом каждое сообщение представляет собой вложенную структуру:
Виды сведений делятся на две группы — простые и универсальные. Рассмотрим схему обмена данными по простому виду сведений:
На схеме видно, что данные форм отображаются непосредственно в конверты обмена данными. Из-за этого появляется ограничение: необходимо разработать структуру блока данных, запроса/ответа для каждого такого вида сведений.
Обмен по универсальному виду сведений можно представить так:
На первый взгляд схема может показаться более сложной, однако она демонстрирует принципиальную разницу, которая в итоге упрощает взаимодействие между участниками по универсальному виду сведений (УВС). Специфические данные форм передаются во вложении к конверту СМЭВ, а признаки УВС, позволяющие идентифицировать вид сведений, передаются непосредственно в конверте и имеют одинаковую для любого ВС структуру:
- номер заявления портала и сведения, позволяющие определить услугу;
- целевое подразделение, к которому пользователь обращается за услугой.
Данные формы, заполненные пользователем портала, пакуются во вложение к основному сообщению.
Таким образом можно оформить предоставление практически любых услуг без необходимости проходить трудную регистрацию нового вида сведений.
Очереди сообщений и процесс взаимодействия
В процессе взаимодействия сообщения помещаются в очереди входящих запросов и очереди входящих ответов. По сути очереди — это контейнеры, в которых содержатся сообщения по видам сведений.
Взаимодействие с очередями происходит с помощью специальных запросов. Более подробно они описаны в методических рекомендациях по работе со СМЭВ. Отметим только то, что благодаря очередям становится возможным асинхронный обмен данными: потребитель может оставить заявку на получение сведений, а поставщик — разместить ответ.
Следует помнить: чтобы забрать сообщение из очереди, необходимо подтвердить его получение с помощью Ack-запроса. В противном случае СМЭВ посчитает сообщение недоставленным и вернёт его в очередь через 15 минут после извлечения.
На каждый запрос может поступить как успешный, так и неуспешный ответ.
Представим себя в роли поставщика сведений: по запросу мы выдаём пользователю градостроительный план земельного участка, причём в рамках нашего ведомства действуют несколько территориальных подразделений, некоторые из которых такую услугу вовсе не оказывают. Допустим, пользователь портала при формировании заявления на получение услуги указал подразделение, не оказывающее услугу. Такая ситуация может возникнуть по двум причинам:
- Произошло расхождение справочных данных на портале и у поставщика;
- Нужного соответствия просто нет в настройках системы поставщика.
В любом случае поставщик должен ответить на запрос так, чтобы принимающая сторона могла понять, что запрос завершился неудачно, и, возможно предпринять ответные действия. Ответ на такой запрос оформляется в специальном пакете данных со сведениями о причине отказа.
Успешный ответ предполагает сценарий, в котором результат услуги — это набор файлов (что бывает довольно часто). Перед отправкой результата необходимо выгрузить файлы в файловое хранилище СМЭВ на основе FTP-сервера. Названия файлов и их контрольные суммы нужно зафиксировать в пакете, который отправляем через SOAP. Таким образом, есть две операции по передачи данных, которые нужно связать общим контекстом — сведениями о файлах.
На практике встречаются случаи, когда во время взаимодействия СМЭВ находится в режиме обслуживания, и запросы участника оборачиваются неудачей и требуют повторной отправки. Неудачу нужно зафиксировать и отправить запрос повторно.
Постановка задачи
С учётом приведённых выше особенностей, нашей команде предстояло обеспечить интеграцию ИС заказчика с «Госуслугами» по универсальному виду сведений. Информационная система заказчика — ИАС «Градоустройство». С её помощью пользователи ведомств, ответственные за оказания услуг, могут собирать пакеты документов и формировать результаты для дальнейшей передачи на портал через СМЭВ.
Итак, СМЭВ, как в поговорке про слова в песне, нельзя исключить из решения задачи интеграции с порталом государственных услуг. Но это к лучшему: благодаря системе у всех участников есть универсальная среда взаимодействия. Это позволяет опираться на определённый стандарт и не изобретать велосипед.
В следующих статьях мы рассмотрим, как на стороне поставщика сведений организовать обработку заявлений по данным пользователя с использованием движка автоматизации бизнес-процессов Workflow Core.