Настройка Адаптера СМЭВ выполняется в веб-интерфейсе и не зависит от операционной системы, в которой установлено ПО. Описание основных настроек, добавление ИС и ВС в Адаптер указаны в описании Устанавливаем и настраиваем экземпляр Адаптера.
Настройки, на которые нужно обратить внимание в разделе Конфигурация:
1) Оба вида сведений используют схему 1.3. Поэтому в поле Предустановленные настройки выбирается СМЭВ 1.3 с соответствующей средой (Рисунок 1). Для сохранения изменения выбрать кнопку Применить и сохранить.
Рисунок 1 – Настройки конфигурации адаптера.
Также необходимо убедиться, что в пункте СМЭВ транспорт верно проставились поля Адрес, Версия и Адрес маркировщика транзакций:
- п. 2.1: http://smev3-n0.test.gosuslugi.ru:5000/transport_1_0_2 – для тестовой среды, http://172.20.3.12:5000/transport_1_0_2/ – для продуктивной среды;
- п. 2.2: 1.3 для всех сред;
- п. 2.4: http://smev3-n0.test.gosuslugi.ru:5000/ws/smev-message-exchange-service-1.3.wsdl – для тестовой среды, http://172.20.3.12:5000/ws/smev-message-exchange-service-1.3.wsdl- для продуктивной среды.
2) Настройки архивации (пункт 14) – важно выставить значения так, чтобы таблица message_state не разрасталась. Большой размер таблицы может повлиять на время запуска GetRequest, что может привести к задержкам в опросе очереди.
3) В случае необходимости уменьшения периодичности отправки сообщений (пункт 4.2), рекомендовано уменьшить количество забираемых сообщений из СМЭВ (пункт 4.1 Конфигурации информационной системы).
Для настройки ИС необходимо обратить внимание на следующие параметры:
1. Обязательно должен быть включен опрос getResponse (пункт 4.5). В противном случае опрос очереди на наличие сообщений не будет производиться, а значит не будут доходить ответы.
2. В настройках добавленной ИС уделить внимание настройке Количество сообщений, забираемых из СМЭВ (пункт 4.1). Необходима для регулировки вычитывания сообщений из очереди. Если объем приходящих ответов большой, очередь скапливается, то необходимо увеличить количество забираемых сообщений.
Загрузку очереди можно проверить в ЛК УВ в описании своей ИС в разделе Очереди (Рисунок 2).
Рисунок 2 – Очереди информационной системы.
Рисунок 3 – Создание учетной записи для информационной системы.
Необходимо знать, что в Адаптере СМЭВ доступно несколько вариантов использования интерфейсов:
– Базы данных;
Каждый из вариантов настраивается по-своему. Выбрать интерфейс необходимо опираясь на удобство и потребности использования.
Сообщение запроса для интерфейса БД вносится через SQL команды в соответствующую таблицу Send_Table. Подробнее о том, как настроить интерфейс БД и формировать через него сообщения, можно узнать тут.
Проверить входящую очередь сообщений можно в созданной таблице, чаще именуемой Receive_Table. Очередь отправляемых сообщений – в таблице Send_Table. Содержимое сообщений хранится в таблице core.message_content.
Отправленные и полученные сообщения для любого интерфейса можно проверить в самом адаптере в разделе Обработанные сообщения (Рисунок 4). На форме отображаются данные из таблицы core.delivery_log.
Рисунок 4 – Раздел “Обработанные сообщения” Адаптера.
Нажав на одну из записей, можно увидеть карточку сообщения (Рисунок 5). В ней помимо основных данных из общего меню можно найти сообщения и сам конверт запроса.
Рисунок 5 – Карточка обработанного сообщения.
При использовании файлового интерфейса сообщения размещаются в директории /opt/adapter/integration для Linux, либо в директории C:Program FilesSmevAdapterintegrationiles для Windows. Запросы кладутся в виде xml в папку out. Далее спустя небольшой промежуток времени корректно сформированный конверт автоматически преобразуется Адаптером. Дополненный конверт ClientMessage помещается в подпапку sent, и направляется в СМЭВ. Невалидные конверты будут перемещены в подпапку error с описанием ошибок. Ответы хранятся в папке in.
Встроенный интерфейс предполагает отправку запросов через web-интерфейс адаптера. Но в случае обмена с Госключом данный интерфейс интересен для взаимодействия по SOAP или REST API протоколам. Наиболее часто встречающийся вариант – использование связки Адаптера с ПО Soap UI. Поэтому рекомендуем ознакомиться с описанием данного варианта в статье «Обмен сообщениями с помощью SOAP UI» (ссылка).
Статусная информация по процессам адаптера записывается в лог файл в папке /opt/adapter/logs для Linux, и в C:Program FilesSmevAdapterlogs для Windows. Она пригодится для анализа возможных проблем. Также в данный лог могут записываться конверты сообщений. Но для этого необходимо включить соответствующую настройку Адаптера – пункты 2.7, 2.8 настроек конфигурации.
Рисунок 6 – Определение oid значения в файлах cookie браузера.
Подробнее об используемых сообщениях и их содержании поговорим в описании Разбор примеров сообщений в обменах СМЭВ при интеграции с Госключом.
В настоящей статье представлена подробная инструкция по тестированию видов сведений в тестовой и продуктивной средах с использованием бесплатного Адаптера СМЭВ.
Общее описание процесса тестирования
Процесс тестирования видов сведений разбивается на два этапа:
- тестирование в тестовой среде СМЭВ;
- тестирование в продуктивной среде СМЭВ.
Тестирование в тестовой среде СМЭВ производится с использованием эмуляторов информационных систем поставщиков данных и эталонных запросов, прилагаемых к описанию видов сведений на технологическом портале СМЭВ.
Эмулятор представляет собой процессор XSL-преобразований, который возвращает потребителю определенный эталонный ответ в зависимости от значения определенного элемента в эталонном запросе.
Эталонные запросы, эталонные ответы и правила XSL-преобразования описываются в Руководстве пользователя вида сведений.
Для того, чтобы эталонный запрос был переадресован эмулятору, необходимо включить в запрос элемент testMessage со значением true.
Тестирование в продуктивной среде СМЭВ производится с использованием реальных запросов к реальным информационным системам поставщиков.
В обоих вариантах тестирования конечным результатом с точки зрения Ситуационного центра СМЭВ, который выносит заключение о технической готовности ИС потребителя к обмену сообщениями по виду сведений, является набор запросов и ответов в формате СМЭВ.
В обычном режиме работы СМЭВ-адаптер не сохраняет сообщения в формате СМЭВ.
Для перевода СМЭВ-адаптера в отладочный режим необходимо установить параметр development.transport.persist.soap в значение true и перезапустить СМЭВ-адаптер.
Для СМЭВ-адаптера устаревшей версии параметр development.transport.persist.soap располагается в конфигурационном файле core.properties.
Для СМЭВ-адаптера текущей версии параметр development.transport.persist.soap устанавливается в интерфейсе администратора, в разделе «Настройка конфигурации адаптера».
Для перехода в этот раздел необходимо в меню выбрать пункт «Настройка конфигурации» и в открывшейся форме выбрать режим «Показать расширенные настройки» (см. рисунок).
Расширенные настройки конфигурации СМЭВ-адаптера
В расширенном режиме необходимо развернуть раздел «Отладка» и установить флаг «Сохранение входящих/исходящих сообщений СМЭВ» (см. рисунок), после чего нажать кнопку «Сохранить».
Выбор параметров отладки
Установка параметра сохранения входящих/исходящих сообщений СМЭВ
После сохранения изменений в параметрах адаптера, необходимо его перезапустить, чтобы он смог прочитать новые значения параметров при запуске.
Для этого необходимо в командной панели перейти в каталог установки СМЭВ-адаптера и выполнить команду adapter.exe restart (или sh adaper.sh restart для CentOS), а если СМЭВ-адаптер установлен как служба Windows, перезапустить службу из консоли управления службами.
СМЭВ-адаптер устаревшей версии можно перезапустить двумя способами:
- Перезагрузкой сервера (если запуск адаптера проиводится автоматически при загрузке ОС);
- Удалением процесса адаптера и повторным его запуском из консоли.
Второй вариант более предпочтительный, потому что после окончания тестирования необходимо восстановить значение параметра development.transport.persist.soap=false, и только после этого перезагружать сервер (или адаптер).
Для повторного запуска адаптера необходимо в консоли перейти в каталог установки адаптера и выполнить команду sh startup.sh.
Тестирование в тестовой среде СМЭВ
Диаграмма активностей процесса тестирования ВС в тестовой среде СМЭВ представлена на рисунке.
Подготовка тестового запроса
Тестовый запрос должен быть сформирован в формате СМЭВ-адаптера, т.е. в виде сообщения ClientMessage.
Структура ClientMessage для запроса представлена на рисунке.
Сообщение ClientMessage для запроса
Значение элемента itSystem должно соответствовать мнемонике информационной системы Потребителя. В тестовой среде СМЭВ мнемоники ИС участников взаимодействия имеют, как правило, суффикс «_3T», в отличие от продуктивной среды, где мнемоники оканчиваются на «_3S».
Содержимое эталонного запроса вида сведений должно быть вставлено в элемент MessagePrimaryContent.
Содержимое элемента RequestMetadata заполняется следующим образом:
Пример сообщения ClientMessage:
Размещение тестового запроса в каталоге OUT СМЭВ-адаптера
Местоположение каталога OUT зависит от версии СМЭВ-адаптера.
Созданные файлы с сообщениями ClientMessage необходимо разместить в каталоге OUT.
Запуск СМЭВ-адаптера
Если в момент размещения ClientMessage в каталоге OUT СМЭВ-адаптер уже запущен, то эти сообщения будут отправлены в СМЭВ сразу же после их размещения в указанном каталоге.
В противном случае требуется запустить СМЭВ-адаптер.
Для этого необходимо открыть консоль и перейти в ней в каталог установки СМЭВ-адаптера.
Адаптер устаревшей версии запускается из консоли командой startup.bat (или sh startup.sh для CentOS).
Адаптер текущей версии запускается из консоли командой adapter.exe start (или sh adapter.sh start для CentOS).
Поиск СМЭВ-сообщений запроса и ответа
Для поиска сообщений, соответствующих отправленному сообщению и полученному ответу, необходимо узнать, с каким messageID был отправлен запрос в СМЭВ.
Для этого нужно открыть найти сообщение в каталоге OUT/Sent по clientID:
Для поиска файлов по их содержимому необходимо включить соответствующий параметр в эксплорере Windows:
В найденном сообщении, в элементе MessageId, будет содержаться идентификатор сообщения, отправленного в СМЭВ:
Должны быть найдены три сообщения:
Для последнего сообщения (GetResponseResponse) необходимо найти сообщение с опросом очереди (GetResponseRequest). Оно имеет тот же GUID в наименовании файла, что и сообщение GetResponseResponse).
Сообщения Ack, о которых упоминается в Регламенте подключения ИС Участника к СМЭВ и в письмах от Ситуационного центра, СМЭВ-адаптером не фиксируются! Но СЦ, будучи информирован об использовании Потребителем СМЭВ-адаптера, не настаивает на включении Ack в результаты тестирования.
Взаимодействие с СЦ СМЭВ
Четыре найденных сообщения в формате СМЭВ необходимо упаковать в архив со значащим именем (например, «MNEM01_3T-ЕГРЮЛ-Request0.zip») и направить в Ситуационный центр СМЭВ в виде результатов тестирования.
Если тестировалось несколько эталонных запросов (а обычно так и происходит), то по четыре СМЭВ-сообщения для каждого эталонного запроса размещаются в отдельных каталогах, соответствующих эталонным запросам, например, «Request0», «Request1» и т.д.
Затем эти каталоги упаковываются в один архив, например, «MNEM01_3T-ЕГРЮЛ.zip», который отправляется в СЦ СМЭВ.
Тестирование в продуктивной среде СМЭВ
Тестирование в продуктивной среде СМЭВ должно производиться на сервере, имеющем доступ к продуктивной среде СМЭВ.
В СМЭВ-адаптере должен быть включен режим сохранения отладочных сообщений в формате СМЭВ (см. п. 1), после чего СМЭВ-адаптер должен быть перезапущен.
Формат сообщения ClientMessage отличается от формата, приведенного в п. 2.1, отсутствием элемента testMessage:
Содержимое запроса к виду сведений должно соответствовать реальному объекту или субъекту, сведения о котором необходимо получить.
Если в качестве запроса использовать один из эталонных запросов, то в ответ вернется, скорее всего, сообщение reject с признаком отсутствия данных в ИС Поставщика.
После окончания тестирования необходимо отключить режим сохранения отладочных сообщений в формате СМЭВ и перезапустить СМЭВ-адаптер.
Также вы можете передать задачи организации СМЭВ-взаимодействия участникам нашего проекта. Качественная настройка СМЭВа и интеграция Адаптера с различными ИС — наш нехемульский долг.
В процессе использования ИУА участники взаимодействия могут столкнуться с необходимостью повышения скорости обмена сообщениями со СМЭВ3. Следует понимать, что скорость обмена ограничивается, прежде всего, со стороны СМЭВ3, подробнее об этих ограничениях Вы можете прочитать в документе Методические рекомендации СМЭВ 3. Однако, в зависимости от ресурсов хоста на котором развернут и работает ИУА, могут существовать сценарии повышения скорости обмена, достижимые путем изменения его настроек.
ИУА поставляется с набором настроек по умолчанию, которые являются оптимальными для большинства сценариев обмена, поэтому с осторожностью изменяйте настройки, поскольку необдуманные действия могут спровоцировать снижение скорости работы. В каждом конкретном случае использования ИУА в обменах, оптимизированные настройки будут отличаться.
Вот основные факторы, приводящие к таким различиям:
- Средний размер сообщения
- Способ передачи вложений (при их использовании)
- Количество используемых информационных систем
- Общий объем переданных сообщений
- Глубина и периодичность архивации данных
По этой причине статья не содержит универсальных описаний оптимизации. Цель статьи – предоставление администратору достаточной информации о происходящих в ИУА процессах и влиянии настроек на них.
Базовые настройки ИУА
Зайдите в панель администрирования ИУА и ознакомьтесь со следующими параметрами, способными оказать влияние на скорость обменов:
Определяет время простоя после старта ИУА, по истечении которого будет начат обмен со СМЭВ и через внутренние интерфейсы адаптера. Технологический параметр, изменять который не рекомендуется.
Периодичность генерации команд на прием сообщений от СМЭВ. В рамках запуска каждого сеанса приема сообщений может генерироваться несколько команд, в зависимости от настроек многопоточности.
В ИУА встроен механизм, позволяющий кратно увеличить количество сообщений из СМЭВ, получаемых в рамках одного сеанса обмена. Признак необходимости увеличения количества принимаемых сообщений устанавливается в настройках каждой информационной системы индивидуально.
Количество потоков, обрабатывающих входящие сообщения из СМЭВ в каждом поде (для ИУА Enterprise). Параметр оказывает виляние как на количество потоков обмена ИУА со СМЭВ, так и на количество потоков во внутренних интерфейсах ИУА, предназначенных для обмена с ИС участника взаимодействия (напр. AMQP).
Настройки информационных систем
Рассмотрим индивидуальные настройки информационных систем, влияющие на производительность обменов:
Ограничение максимального количества сообщений, забираемых из СМЭВ в рамках одного потока и сеанса обмена.
Важно: При слишком большом количестве забираемых сообщений есть риск, что их получение займет времени больше, чем задано в настройках Kafka (для ИУА Enterprise), это приведет к ресурсоемкой операции по ребалансировке, что в конечном итоге снизит общую скорость получения. Для single-версии ИУА так же имеется опасность замедления обмена в случаях, когда запущенный сеанс обмена не успевает получить указанное количество сообщений до запуска следующего сеанса.
Количество команд (потоков) на получение сообщений, генерируемых в режиме получения сообщений «NORMAL».
Пример: при значении 10 в рамках одной сессии в СМЭВ будет отправлено 10 GetRequest (команд на получение запросов) и 10 GetResponse (команд на получение ответов). Действует суммарно на все поды http-adapter.
Количество команд на прием сообщений, генерируемых в режиме получения сообщений «MAX» для одного пода http-adapter.Пример: при значении 10 в рамках одной сессии в СМЭВ будет отправлено 10 GetRequest и 10 GetResponse.
Параметр предназначен для случаев, когда в ИУА создано несколько информационных систем и некоторые из них требуется периодически переключать в отличный от стандартного режим приема сообщений. В случае, если в ИУА создана одна информационная система или все информационные системы должны работать в равнозначном режиме, не рекомендуем изменять значение этого параметра. Помните, что при его изменении ИУА лишь переключается на использование других полей настроек, никаких дополнительных изменений алгоритмов обработки сообщений не происходит. В то же время, использование различных режимов может запутать вас и усложнить анализ поведения ИУА. В абсолютном большинстве случаев для достижения результата достаточно оперирования цифровыми значениями параметров, использующихся в нормальном режиме работы информационной системы.
Схема взаимодействия микросервисов ИУА при получении сообщений из СМЭВ
Теперь, когда вы понимаете суть настроек, ознакомьтесь со схемой взаимодействия микросервисов Enterprise-версии ИУА:
Если вы применяете Single-версию ИУА, помните, что от Enterprise- версии она отличается отсутствием сервиса Apache Kafka, а также невозможностью горизонтального масштабирования, поэтому для нее схема будет выглядеть следующим образом:
Взаимосвязь параметров конфигурации ИУА
Исходя из приведенных схем и описания взаимосвязи параметров конфигурации, выделим несколько правил, соблюдая которые вы повысите вероятность достижения прироста производительности путем корректировки настроек ИУА:
Деградация производительности ИУА при большом объеме хранимых сообщений
В процессе работы ИУА, данные о переданных и принятых сообщениях сохраняются в служебных таблицах базы данных. По мере возрастания количества хранимых сообщений, происходит постепенная деградация производительности БД, приводящая к увеличению времени обработки сообщений. Для решения этой проблемы ИУА имеет механизм архивации сообщений, в процессе которого старые сообщения, а также сообщения, взаимодействие по которым успешно закончено, переносятся из БД в файловое хранилище.
Параметры работы механизма архивации доступны в панели администрирования после нажатия кнопки Показать расширенные настройки:
По умолчанию, через 14 суток (336 часов) после создания в архив переносятся сообщения, взаимодействие по которым не закончено, а сообщения с завершенным процессом взаимодействия переносятся в архив через 24 часа (86400 сек.) после завершения взаимодействия.
Данные значения настроек оптимальны в большинстве случаев. Рекомендуется изменять их в сторону уменьшения только в случаях аномального повышения нагрузки (количества отправляемых/принимаемых сообщений) в течение последних суток.
По умолчанию процесс архивации запускается ежесуточно в полночь.
Корректность работы службы архивации можно проверить по записям лог-файла. Процесс начинается записью вида:
INFO r.r.s.a.u.b.s.RsArchivingService – process archive start
И заканчивается записью вида:
INFO r.r.s.a.u.b.s.RsArchivingService – process processArchiveScheduler end
Помните, что после удаления (переноса в архив) значительного количества записей БД PostgreSQL, для достижения наибольшего эффекта требуется запуск процедуры освобождения неиспользуемого пространства командой VACUUM. Обратитесь к документации используемой вами БД для изучения подробностей.
Все, что вы хотели узнать о свободно распространяемом клиенте для межведомственного взаимодействия, но не знали, где искать информацию.
UPD 03. 2020
С момента опубликования статьи описываемая в ней версия Адаптера СМЭВ морально и функционально устарела. Решение не поддерживает:
- новый ГОСТ электронной подписи;
- версию 1.3 схем СМЭВ.
Техподдержка СМЭВ поддерживает только последние версии адаптера.
Первое, что отвечают коллеги на соответсвующие запросы пользователей: «Сначала обновитесь до последней версии»
В связи с этим команда Хемуль IT настоятельно рекомендует обновить решение до последней версии, опубликованной на технологическом портале СМЭВ. Все опубликованные версии ПО также можно найти в материале «История версий Адаптера СМЭВ«.
Бесплатные адаптеры СМЭВ
Те особо любознательные пользователи технологического портала СМЭВ, кто долистывал главную страницу техпортала до конца, могли видеть там следующие ссылки:
В данной статье речь пойдет об Адаптере для работы со СМЭВ 3 (далее — Адаптер). Мы расскажем, какие преимущества можно извлечь из его использования в интеграционных решениях, кратко опишем процедуры установки, настройки и работы с интерфейсом.
В следующих статьях мы расскажем об Адаптере СМЭВ 3.0 и о библиотеке для сборки клиента СМЭВ 3.
Описание Адаптера для работы со СМЭВ 3
Адаптер для работы со СМЭВ 3 был создан по заказу Минкомсвязи для облегчения и ускорения процессов интеграции со СМЭВ 3 на стороне участников межведомственного взаимодействия.
Адаптер представляет собой Java-приложение, которое с одной стороны полностью интегрировано со СМЭВ 3, а с другой — предоставляет участнику взаимодействия 4 различных интерфейса:
- web-сервис;
- обмен сообщениями через файловую систему;
- обмен сообщениями через базу данных;
- обмен сообщениями через Java Message Service.
Кроме того, к Адаптеру прилагается графическое пользовательское приложение (GUI адаптера), с помощью которого можно реализовать простейшее интеграционное решение без создания дополнительной информационной системы. При этом все запросы к Поставщикам видов сведений и ответы на запросы Потребителей создаются пользователями в ручном режиме посредством графического интерфейса.
GUI адаптера взаимодействует с самим Адаптером только через web-сервис.
Требования
В силу того, что Адаптер написан на Java, он является кроссплатформенным, и его можно устанавливать как на Windows, так и на nix-системы.
Для установки Адаптера требуются следующий набор компонентов:
- JRE (бесплатно);
- (КриптоПро CSP + Trusted Java) или (КриптоПро CSP + КриптоПро Java CSP) или КриптоПро JСP.
Для взаимодействия с Адаптером через JMS потребуется Apache ActiveMQ, а для взаимодействия с адаптером через базу данных потребуется одна из поддерживаемых им СУБД:
- Oracle;
- MySQL;
- PostgreSQL;
- MS SQL Server.
Структура
Функциональная схема Адаптера для работы со СМЭВ представлена на рисунке.
К Адаптеру СМЭВ можно подключить несколько информационных систем участника взаимодействия. При этом системы могут подключаться как к одному, так и к разным интерфейсам.
Анализ логов Адаптера позволяет предположить, что он состоит из следующих модулей:
Интеграционный модуль обеспечивает взаимодействие адаптера с информационными системами участника взаимодействия и с 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/».
- Откроется интерфейс администратора, в котором заполним сведения о нашей информационной системе.
Наименование системы может быть любым понятным пользователю.
Мнемоника системы должна совпадать с той, которая зарегистрирована в СМЭВ и настроена в адаптере СМЭВ.
Путь к файлу вложений должен совпадать с путем, настроенным в адаптере СМЭВ. Но может и вовсе отсутствовать, если виды сведений, обмен которыми предполагается реализовать, не используют вложений. - Переходим на закладку «Управление видами сведений» и добавляем описание вида сведений.
Наименование вида сведений может совпадать с приведенным на технологическом портале, а может быть любым, удобным и понятным пользователям участника взаимодействия.
Наименование схемы – необходимо указывать namespace из схемы вида сведений.
Загрузить файл схемы – прикрепляется либо сам XSD-файл, либо, если в схеме есть импортируемые схемы, zip-архив, содержащий все схемы, используемые для вида сведений.
Обычно в виде таких архивов схемы ВС хранятся на технологическом портале, но иногда их приходится собирать руками.
Наименования корневых элементов запроса и ответа копируются из схемы вида сведений.
В списке связанных информационных систем нужно указать те ИС, которые будут работать с создаваемым видом сведений. Для каждой ИС (если их много) могут быть указаны разные ВС (если их много).
Нажимаем кнопку «Добавить». - Выходим из системы и осуществляем вход под учетной записью пользователя.
У простого пользователя есть возможность создавать и отправлять в СМЭВ запросы, просматривать полученные ответы, просматривать полученные запросы и писать на них ответы.
- Пользователю предоставляется интерфейс, в котором он может отслеживать состояние всех отправленных запросов и просматривать полученные ответы.
- Пользователю предоставляется возможность просматривать как запрос, так и ответ на него.
Возможность вывода сообщений на печать у пользователя, к сожалению, отсутствует.
Работа с входящими запросами, где участник взаимодействия выступает в роли поставщика вида сведений, происходит аналогичным образом.
В качестве заключения
В настоящей статье приведен общий обзор Адаптера для СМЭВ и преимуществ его применения в интеграционных решениях.
Главный вывод заключается в том, что продукт вполне работоспособен, несмотря на несовершенство документации к нему и определенные трудности в установке и настройке, обусловленные этим несовершенством.
В одной из следующих статей мы расскажем о реальных решениях, построенных на базе Адаптера СМЭВ, а также о последней версии Адаптера, в которую внесен ряд существенных изменений.
Система исполнения регламентов
Назначение СИР — автоматизация процессов предоставления государственных и муниципальных услуг гражданам и организациям (Заявителям) по заявлениям, поступающим с Портала Государственных услуг, а также, при личном обращении Заявителей в РОИВ, ОМСУ и в подведомственные им учреждения; регламентированное взаимодействие между различными РОИВ и ОМСУ и иными информационными системами, с использованием системы межведомственного электронного взаимодействия (СМЭВ).
Описание систем исполнения регламентов
Руководство пользователя СИР 3.0
Состав процедур, необходимых для обеспечения возможности работать в СИР и последовательность их выполнения описаны в документе «Технологическая карта процесса подготовки и предоставления услуг РОИВ и ОМСУ»
Порядок действий пользователей СИР по настройке рабочих мест с переходом на аутентификацию через ЕСИА
1. Настройка ПК пользователя.
- Зарегистрировать себя, как физическое лицо на сайте ЕСИА https://esia.gosuslugi.ru, согласно Инструкции по переходу на аутентификацию с использованием ЕСИА. Результатом регистрации должно быть получение подтвержденной учетной записи физ. лица в ЕСИА
- Уполномоченный сотрудник ведомства, к которому относится Пользователь (руководитель или администратор), должен выполнить в ЕСИА процедуру присоединения сотрудника к органу власти (ведомству) — см. Инструкции по переходу на аутентификацию с использованием ЕСИА
3. Порядок входа Пользователя в СИР по окончании настроeк
- Открыть браузер Mozilla Firefox, и очистить в нем КЭШ и КУКи
- Ввести в адресную ссылку https://66.sir.egov.local/tp-manager/
- Подтвердить выбор своего сертификата, если система предложит — выполнится переход на ЕСИА автоматически
- Подтвердить себя в ЕСИА. Подтвердить выбор своего сертификата, если система предложит. Выполнится переход на СИР автоматически.
СМЭВ-Интегратор
Получение персональных данных зарегистрированного пользователя ЕСИА
Подписание документов электронной подписью УКЭП и УНЭП через сервис «Госключ»
Получение данных о лицах, призванных по частичной мобилизации
Розыск банковских счетов должника, взыскания и аресты
Обращения, подаваемые в ФССП, и результаты их рассмотрения
Проверка присутствия организации в реестре недобросовестных поставщиков
Обмен банков и ФНС электронными сообщениями по форматам 440-П посредством СМЭВ
Запрос ИНН физического лица
Групповой запрос ИНН физических лиц на основе паспортных данных
Запрос выписки ЕГРЮЛ / ЕГРИП
Список ЮЛ или ИП, по которым за период были произведены обновления ЕГРЮЛ или ЕГРИП
Проверка ФЛ, ЮЛ или ИП на наличие решения ФНС о приостановлении операций по счетам
Передача в ФНС сведений о суммах выплаченных процентов по вкладам физических лиц
Проверка корректности указанных клиентом паспортных данных и ИНН
Получение пенсии через выбранную организацию, занимающуюся доставкой пенсии
Проверка бухгалтерской отчетности организации по данным ГИР БО
Подтверждение факта включения организации в Реестр малого и среднего предпринимательства
Проверка присутствия организации в реестре дисквалифицированных лиц
Сведения действительности паспорта РФ
Залог движимого имущества
Сведения об объектах недвижимости и их правообладателях
Оформление, учет и хранение электронных закладных
Проверка бухгалтерской (финансовой) отчетности организации (клиента, контрагента)
Сбор и верификация данных о юрлице по данным официальной статистической отчетности
Регистрации и подтверждения учетных записей пользователей ЕСИА (gosuslugi.ru)
Сбор и отправка в ЕБС биометрических данных физических лиц
Запрос выписки по лицевому счету
Обмен с ПФР для погашения ипотеки средствами материнского капитала
Сопровождение кредитных сделок по соглашениям под субсидированный МСХ процент
Передача клиенту заказных и простых писем в электронном виде
Проверка корректности указания физлицом ФИО и номера ОМС
Обмен сведениями по электронным листкам нетрудоспособности
Система межведомственного электронного взаимодействия
C 1 июня 2022 года получение доступа к ВС с фиксированным и табличным типами маршрутизации планируется перенести из Ситуационного центра в Личный кабинет Участника взаимодействия – ЛК УВ. Возможность подачи заявки в СЦ будет заблокирована.
С подробной информацией о выполнении указанных процедур можно ознакомиться в п. 5.4.3, 5.4.4 Руководства пользователя ЛК УВ.
Обращаем внимание, что процедура получения доступа к ВС с прочими типами маршрутизации остается прежней – через Ситуационный центр.
C 22 июня 2021 года процедура Плановая/внеплановая замена сертификата в СМЭВ 3 перенесена из Ситуационного центра в Личный кабинет Участника взаимодействия – ЛК УВ
Техническая поддержка регионального сегмента инфраструктуры электронного правительства осуществляется Екатеринбургским филиалом ПАО «Ростелеком»
Контакты центра поддержки пользователей:
Краткая характеристика Системы межведомственного взаимодействия СМЭВ
Приобрести усиленную квалифицированную электронную подпись органа власти в аккредитованном удостоверяющем центре. Перечень аккредитованных удостоверяющих центров доступен на сайте Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации по ссылке.