Смэв запросы

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

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

Основные определения и понятия

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

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

Система упрощает и ускоряет обмен данными в электронном виде, а значит, гражданам не нужно часами простаивать в очереди, чтобы получить ответ на простой запрос. Благодаря СМЭВ реализуется принцип «единого окна». Человек обращается за услугой в одно из профильных ведомств, а специалисты собирают необходимые данные через систему межведомственного электронного взаимодействия. Никакой бумажной волокиты, потраченного времени и испорченных нервов.

Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации рассмотрело письмо Саморегулируемой организации Союз микрофинансовых организаций “Микрофинансирование и Развитие” от 28.03.2022 N 362 и в рамках компетенции сообщает следующее.

Использование вида сведений единой системы межведомственного электронного взаимодействия версии 3 “Упрощенная идентификация пользователей (УПРИД) в ЕСИА” (далее УПРИД) для проведения упрощенной идентификации в рамках Федерального закона от 07.08.2001 N 115-ФЗ “О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма” (далее – Федеральный закон № 115) заблокировано Министерством внутренних дел Российской Федерации 09.02.2022.

Пунктом 2(1) перечня документов (сведений), обмен которыми осуществляется с использованием СМЭВ, утвержденного распоряжением Правительства Российской Федерации от 15.08.2012 № 1471-р, Министерство внутренних дел Российской Федерации определено в качестве федерального округа исполнительной власти, участвующего в обмене с организациями сведениями о подтверждении соответствия фамилии, имени, отчества, серии и номера документа, удостоверяющего личность, предоставленных заявителем в кредитную организацию или иную организацию, уполномоченную на осуществление упрощенной идентификации клиента физического лица, в соответствии с Федеральным законом № 115

Предоставление необходимых сведений посредством СМЭВ может осуществляться с использованием электронного сервиса, а также видов сведений Министерства внутренних дел Российской Федерации “Проверка действительности Паспорта Гражданина РФ по серии и номеру”, “Сведения о действительности паспорта гражданина Российской Федерации, предъявляемого на определенное имя”.

Доступ к электронному сервису и видам сведений СМЭВ при наличии правовых оснований осуществляется посредством направления запросов в федеральную государственную информационную систему “Федеральный ситуационный центр электронного правительства”.

прямую
ссылку на статью

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

Для организации процесса получения данных из СМЭВ 4 нужно выполнить следующие обязательные условия:

• Зарегистрировать ИС (информационную систему) в СМЭВ;
• Зарегистрировать Агент ПОДД в ядре ПОДД;
• Получить доступ к необходимой витрине данных;
• Получить доступ к сетевой инфраструктуре продуктивной среды СМЭВ;
• Установить и настроить ПО «Агент ПОДД»;
• Организовать взаимодействие корпоративной информационной системы с ПО «Агент ПОДД».

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

Взаимодействие корпоративной ИС с ПО «Агент ПОДД»

Для обеспечения доступности данных Агент ПОДД предоставляет:

• REST-интерфейс для выполнения запросов к витринам поставщиков данных;
• Специализированный протокол для исполнения запросов с использованием JDBC-интерфейса Агента ПОДД.

Подробную информацию об организации обменов посредством интерфейсов REST и JDBC смотрите в документе Методические рекомендации по работе с ПОДД СМЭВ.

Использование регламентированных запросов и механизма подписки

Агент ПОДД может получать сведения с витрин данных поставщиков следующими способами:

1) Путём отправки регламентированных запросов или произвольных SQL-запросов, составленных потребителем данных (описание поддерживаемого ПОДД СМЭВ синтаксиса запросов на основе SQL 2003 см. в документе Методические рекомендации по работе с ПОДД СМЭВ);

2) Путём подписки на изменения сведений и получения сведений в виде:

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

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

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

Создание реплики данных витрины поставщика данных ПОДД СМЭВ выполняется на основании согласованной подписки потребителя данных ПОДД СМЭВ.

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

• Отсутствие необходимости развертывания и поддержания инфраструктуры для хранения данных в контуре потребителя;
• Гарантированное соответствие полученных данных первоисточнику в произвольный момент времени.
• Независимость от работоспособности витрины на стороне поставщика данных;
• Высокая скорость получения данных из локальной реплики витрины.

Правительство Российской Федерации постановляет:

Утвердить прилагаемые изменения, которые вносятся в постановление Правительства Российской Федерации от 8 сентября 2010 г. N 697 “О единой системе межведомственного электронного взаимодействия” (Собрание законодательства Российской Федерации, 2010, N 38, ст. 4823; 2011, N 24, ст. 3503; 2013, N 45, ст. 5827; 2014, N 12, ст. 1303; N 42, ст. 5746; N 48, ст. 6862, 6876; 2016, N 34, ст. 5243; 2017, N 29, ст. 4380; N 30, ст. 4672; N 41, ст. 5981; N 45, ст. 6661; 2018, N 28, ст. 4234; N 49, ст. 7600; 2020, N 37, ст. 5722; 2021, N 21, ст. 3585; N 27, ст. 5371).

УТВЕРЖДЕНЫпостановлением ПравительстваРоссийской Федерацииот 13 июля 2022 г. N 1242

Изменения,которые вносятся в постановление Правительства Российской Федерации от 8 сентября 2010 г. N 697

1. В абзацах первом и третьем пункта 5 слова “государственной власти” исключить.

2. Дополнить пунктом 9 следующего содержания:

“9. Установить, что датой и временем поступления зарегистрированного запроса к витринам данных в информационную систему, подключенную к единому сервису доступа к данным единой системы межведомственного электронного взаимодействия, представляющему собой единый технологический способ предоставления данных из информационных систем федеральных органов исполнительной власти, государственных внебюджетных фондов, исполнительных органов субъектов Российской Федерации, органов местного самоуправления, государственных и муниципальных учреждений, многофункциональных центров предоставления государственных и муниципальных услуг, иных органов и организаций, считаются дата и время помещения указанного запроса в программный модуль, обеспечивающий функциональность по формированию, отправке, получению и обработке запросов единой системы межведомственного электронного взаимодействия.”.

3. В Положении о единой системе межведомственного электронного взаимодействия, утвержденном указанным постановлением:

а) в пункте 1 слова “государственной власти” исключить;

б) пункт 2 изложить в следующей редакции:

“2. Система взаимодействия представляет собой федеральную государственную информационную систему, позволяющую органам и организациям осуществлять информационный обмен на основе унифицированных правил взаимодействия между информационными системами органов и организаций (далее – электронные сервисы), а также обеспечивать единый технологический способ взаимодействия информационных систем органов и организаций (далее – единый электронный сервис) посредством технологии очередей электронных сообщений в соответствии с зарегистрированными форматами передаваемых сведений (далее – виды сведений) и единый технологический способ предоставления данных из информационных систем органов и организаций (далее – единый сервис доступа к данным) посредством исполнения зарегистрированных запросов к витринам данных (далее – регламентированные запросы) и фиксацию фактов движения электронных сообщений в системе взаимодействия.”;

в) пункт 4 дополнить абзацем следующего содержания:

“обеспечение информационного взаимодействия по предоставлению органами и организациями аналитических данных для принятия управленческих решений.”;

г) абзац первый пункта 5 изложить в следующей редакции:

“5. Технологическое обеспечение информационного взаимодействия органов и организаций с применением системы взаимодействия достигается путем использования:

сервис-ориентированной архитектуры, представляющей собой совокупность единого электронного сервиса системы взаимодействия и электронных сервисов;

архитектурного подхода к логическому объединению сведений органов и организаций и их передачи с применением единого сервиса доступа к данным.”;

д) дополнить пунктом 5 следующего содержания:

“5. Управление параметрами доступа к системе взаимодействия органами и организациями может осуществляться посредством личного кабинета участника взаимодействия системы взаимодействия.”;

е) в пункте 6:

в подпункте “а”:

слово “получения” заменить словом “предоставления”;

слова “и поданных заявителями через единый портал,” заменить словами “, через единый портал”;

в подпункте “г” слово “утверждаемыми” заменить словом “определяемыми”;

в подпункте “ж” слова “(в части использования единого электронного сервиса)” заменить словами “(в части использования видов сведений единого электронного сервиса и (или) регламентированных запросов единого сервиса доступа к данным)”;

в подпункте “з” слова “предварительно настроенной” исключить;

в подпункте “к” слова “состоянии технологических очередей запросов и ответов единого электронного сервиса и других технологических параметров” заменить словами “технологических параметрах”;

подпункт “л” изложить в следующей редакции:

“л) обеспечение в соответствии с техническими требованиями блокировки электронных сообщений при обмене сообщениями в случае несоответствия структуры сообщений или вложений технологическим правилам выполнения запросов или рассылок сообщений, зарегистрированным в системе взаимодействия, и в иных случаях нарушения правил информационного взаимодействия в соответствии с техническими требованиями;”;

подпункт “п” признать утратившим силу;

подпункт “р” изложить в следующей редакции:

“р) обеспечение возможности самостоятельной регистрации и изменения органами и организациями параметров информационных систем, видов сведений единого электронного сервиса и регламентированных запросов единого сервиса доступа к данным, используемых при обмене сообщениями, настройки правил доступа к видам сведений и регламентированным запросам, а также обеспечение использования других средств самообслуживания в соответствии с техническими требованиями, в том числе посредством федеральной государственной информационной системы “Единая информационная платформа национальной системы управления данными” (далее – единая информационная платформа) и личного кабинета участника взаимодействия системы взаимодействия;”;

подпункты “с”, “т” и “х” признать утратившими силу;

подпункт “ц” изложить в следующей редакции:

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

ж) в пункте 7:

подпункт “а” после слов “доступ к единому электронному сервису” дополнить словами “, единому сервису доступа к данным”;

подпункт “е” изложить в следующей редакции:

“е) хранение информации, содержащейся в реестре регламентированных запросов, формируемом с использованием личного кабинета участника взаимодействия системы взаимодействия, и осуществление обмена этой информацией с внешними иными информационными системами, в том числе с единой информационной платформой;”;

подпункт “з” изложить в следующей редакции:

“з) формирование единой матрицы доступа к сведениям и данным участников взаимодействия на основании реестра видов сведений и реестра регламентированных запросов, а также соответствующих правил доступа.”;

з) дополнить пунктом 7 следующего содержания:

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

и) в пункте 9:

в подпункте “в” слова “типов и атрибутов” заменить словами “регламентированных запросов”;

подпункт “д” после слова “разработку” дополнить словами “и актуализацию”;

в подпункте “з” слова “государственной власти” исключить;

к) в подпункте “б” пункта 10 слова “государственной власти” исключить;

л) дополнить пунктом 10 следующего содержания:

“10. В целях подключения к системе взаимодействия органы и организации обеспечивают:

а) защищенный канал связи между своей информационной системой и системой взаимодействия;

б) разработку взаимодействия с системой взаимодействия.”;

м) в пункте 11:

абзац первый после слов “в соответствии с техническими требованиями” дополнить словами “и требованиями к качеству”;

подпункт “а” изложить в следующей редакции:

“а) разрабатывают форматы сведений, а именно виды сведений единого электронного сервиса и регламентированные запросы единого сервиса доступа к данным, используемые при обмене сообщениями, и поддерживают их работоспособность;”;

в подпункте “в” слова “государственной власти” исключить;

подпункт “д” дополнить словами “, в том числе путем оперативного реагирования на инциденты качества данных, связанные с качеством предоставляемых данных, в соответствии с требованиями к качеству;”;

подпункты “з” и “л” признать утратившими силу;

дополнить подпунктами “н” – “п” следующего содержания:

“н) используют агент системы взаимодействия, представляющий собой программный модуль, обеспечивающий функциональность по формированию, отправке, получению и обработке запросов системы взаимодействия;

о) поддерживают применение блоков, элементов данных и электронных подписей в сообщениях, направляемых посредством системы взаимодействия (при этом использование отличных от описанных в технических требованиях блоков и элементов данных не допускается);

п) несут ответственность за содержание реквизитов отправленного электронного сообщения, если иное не предусмотрено техническими требованиями.”.

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

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

Изменен функционал СМЭВ.

Статья написана в развитие темы, поднятой в предыдущей публикации – «Шишки, набитые при работе с адаптером СМЭВ». Рассматривается практический опыт реализации интеграционного решения на базе Адаптера СМЭВ. В роли адаптера используется бесплатное решение, представленное на технологическом портале СМЭВ 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 для Адаптера СМЭВ или сделать отдельную площадку для обмена опытом;
• создать и разместить на технологическом портале обучающие ролики по особо сложным темам.

Несмотря на определенные сложности с настройкой, бесплатный Адаптер СМЭВ является гибким, надёжным инструментом, который позволяет реализовывать высоконагруженные проекты. Он облегчает работу интеграторам и экономит средства Заказчиков.

Следите за нашим Телеграм-каналом, чтобы не пропускать самое важное!

Поделиться

МВД 9 февраля 2022 г. заблокировало использование вида сведений единой СМЭВ версии 3 “Упрощенная идентификация пользователей (УПРИД) в ЕСИА” для проведения упрощенной идентификации в антиотмывочных целях.

Министерство участвует в обмене с организациями сведениями о подтверждении соответствия ФИО, серии и номера паспорта, предоставленных заявителем в кредитную или иную организацию, уполномоченную на осуществление упрощенной идентификации клиента – физлица.

Необходимые сведения могут предоставляться посредством СМЭВ с использованием электронного сервиса, а также видов сведений МВД “Проверка действительности Паспорта Гражданина РФ по серии и номеру”, “Сведения о действительности паспорта гражданина Российской Федерации, предъявляемого на определенное имя”. Для доступа к электронному сервису и видам сведений СМЭВ при наличии правовых оснований нужно направлять запросы в ФГИС “Федеральный ситуационный центр электронного правительства”.

Для просмотра актуального текста документа и получения полной информации о вступлении в силу, изменениях и порядке применения документа, воспользуйтесь поиском в Интернет-версии системы ГАРАНТ:

СМЭВ-Интегратор

Получение персональных данных зарегистрированного пользователя ЕСИА

Подписание документов электронной подписью УКЭП и УНЭП через сервис «Госключ»

Получение данных о лицах, призванных по частичной мобилизации

Розыск банковских счетов должника, взыскания и аресты

Обращения, подаваемые в ФССП, и результаты их рассмотрения

Проверка присутствия организации в реестре недобросовестных поставщиков

Обмен банков и ФНС электронными сообщениями по форматам 440-П посредством СМЭВ

Запрос ИНН физического лица

Групповой запрос ИНН физических лиц на основе паспортных данных

Запрос выписки ЕГРЮЛ / ЕГРИП

Список ЮЛ или ИП, по которым за период были произведены обновления ЕГРЮЛ или ЕГРИП

Проверка ФЛ, ЮЛ или ИП на наличие решения ФНС о приостановлении операций по счетам

Передача в ФНС сведений о суммах выплаченных процентов по вкладам физических лиц

Проверка корректности указанных клиентом паспортных данных и ИНН

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

Проверка бухгалтерской отчетности организации по данным ГИР БО

Подтверждение факта включения организации в Реестр малого и среднего предпринимательства

Проверка присутствия организации в реестре дисквалифицированных лиц

Сведения действительности паспорта РФ

Залог движимого имущества

Сведения об объектах недвижимости и их правообладателях

Оформление, учет и хранение электронных закладных

Проверка бухгалтерской (финансовой) отчетности организации (клиента, контрагента)

Сбор и верификация данных о юрлице по данным официальной статистической отчетности

Регистрации и подтверждения учетных записей пользователей ЕСИА (gosuslugi.ru)

Сбор и отправка в ЕБС биометрических данных физических лиц

Запрос выписки по лицевому счету

Обмен с ПФР для погашения ипотеки средствами материнского капитала

Сопровождение кредитных сделок по соглашениям под субсидированный МСХ процент

Передача клиенту заказных и простых писем в электронном виде

Проверка корректности указания физлицом ФИО и номера ОМС

Обмен сведениями по электронным листкам нетрудоспособности

Функционал СМЭВ и обеспечение

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

• Требуется разработать электронные интерфейсы и сервисы, которые можно использовать при подключении к единой системы. Здесь есть два пути — можно обратиться к разработчику используемой инфосистемы, чтобы доработать сервисы и интерфейсы, а можно упростить задачу и использовать готовое решение. Об одном из таких продуктов расскажем далее в этой статье.
• Второе правило, которое нужно учесть, заключается в том, что оператору узла системы нужно будет предоставить доступ к электронному сервису для регистрации и внесения компании в реестр. Потребуется паспорт электронного сервиса. Также организация должна обеспечить доступность сервера, что необходимо для успешной приемки.
• Необходимо организовать защищенный канал связи между, по которому будет передаваться информация от инфосистемы организации в СМЭВ и обратно.

Для быстрого и эффективного подключения предлагаем использовать готовое решение от «КСК. Технологии». Дальше рассказываем о продукте и его преимуществах.

Как направить запрос

В открывшейся карточке запроса введите необходимые сведения:

• Для запроса выписки ЕГРИП – ИНН (12 цифр) или ОГРН (15 цифр) индивидуального предпринимателя;
• Для запроса выписки ЕГРЮЛ – ИНН (10 цифр) или ОГРН (13 цифр) юридического лица;

Нажмите кнопку , чтобы сохранить карточку.

В таблице раздела «Межведомственные запросы» появится новый исходящий запрос.

У запросов, созданных пользователем самостоятельно в поле «Способ создания» будет написано – «Ручной».

Когда запрос будет подготовлен в ИАС и поставлен в очередь на отправку ему присвоится статус «Готов к отправке». После успешной отправки статус исходящего запроса изменится на «Отправлен запрос». Запрос появится в каталоге «Отправленные запросы» в папке «Межведомственные запросы» в панели навигации.

Актуальная информация о запросах в рамках услуги отображается в карточке услуги:

Автоматическое отправление запроса

Межведомственный запрос создается автоматически, если заявление поступило с РПГУ/МФЦ для предоставления таких услуг, как:

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

Когда поступает заявление, в карточке соответствующей услуги в Системе автоматически создается межведомственный запрос «Запрос выписки из ЕГРН (ЗУ)».

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

Межведомственный запрос для заявлений с РПГУ/МФЦ по указанным выше услугам создается Системой всегда. Понять, что запрос был создан автоматически, можно по полю «Способ создания», в котором будет написано – «Автоматически».

Какие запросы можно направлять

Система позволяет направлять в органы власти следующие запросы:

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

Как посмотреть ответ на запрос

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

Если на межведомственные запросы Запрос выписки из ЕГРН (ЗУ) , Запрос выписки из ЕГРН (ОКС), Запрос КПТ получены запрашиваемые сведения, то автоматически начнется их импорт в Систему.

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

Как проходит межведомственное взаимодействие

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

С помощью сервисов запроса сведений в Системе можно работать с запросами в электронной форме. Взаимодействие проходит с помощью СМЭВ. Все запросы, отправленные через СМЭВ находятся в каталоге «Запросы СМЭВ» в папке «Межведомственные запросы» в панели навигации.

Работа с исходящими запросами выглядит следующим образом:

Интеграция СМЭВ

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

• Оформить заявку на присоединение к регламенту, а также заявку на регистрацию.
• Доработать собственную информационную систему. Возможно потребуется разработать электронные сервисы/интерфейсы для взаимодействия СМЭВ. В этом вопросе необходимо отталкиваться от требований оператора узла и следовать методическим рекомендациям.
• Задействовать мероприятия для защищенности канал связи между используемой в организации системой и непосредственно СМЭВ. При подаче заявки важно проконтролировать доступность сервиса.
• Получить разрешение на предоставление доступа к сервису.

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

Узайте больше о возможностях КСК. Шлюз

Простое ваимодействие множества разнородных информационных систем

• Единый протокол интеграции
• Гарантированная доставка сообщений
• Более 1000 готовых адаптеров
• Мониторинг цепочек взаимодействия
• Совместимость с технологиями СМЭВ 2 и СМЭВ 3

Законодательная база

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

Для исполнения этого закона и реализации принципа «одного окна» ведомства самостоятельно осуществляют взаимодействия через СМЭВ — инстанции могут быстро обменяться документами и всей информацией, которая может потребоваться при оказании услуг. Такой подход ускоряет удобен для обеих сторон — ускоряет и упрощает предоставление услуги, гарантирует конфиденциальность и сохранность данных.

Также межведомственное взаимодействие регламентируется постановлениями РФ № 697 и № 1222.

Решение для интеграции

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

Архитектура продукта состоит из таких элементов:

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

Продукт разработан российской компанией на открытом ПО, соответствует требованиям импортозамещения. Эксперты «КСК ТЕХНОЛОГИИ» готовы проконсультировать и помочь с интеграцией, а также обучением сотрудников. Помимо «КСК. Шлюз» компания предлагает и другие отраслевые решения, например, «КСК. СИУМВВ» для межведомственного взаимодействия, «КСК. Реестр услуг» и другие.