К какой информации могут получить доступ юридические лица, не являющиеся органами власти

Общая схема взаимодействия через СМЭВ

В цикле статей мы, команда Gems Development, расскажем о работе с «Госуслугами» по ту сторону экрана и о том, как оформить эффективное взаимодействие органов государственной власти с порталом.

Техническое описание системыПравить

СМЭВ состоит из сети защищенных каналов связи между узлами, расположенными в центрах обработки данных Ростелекома. Каждый узел СМЭВ — это шина на базе Oracle Enterprise Service Bus. Участники СМЭВ являются поставщиками и потребителями сведений:

Sokolko

4 года, 1 месяц назад

Как мы уже писали в статье про СМЭВ 3, Система Межведомственного Электронного Взаимодействия уже давно востребована не только государственным учреждениями и органами власти, но и рядом коммерческих организаций. У наших клиентов также возникла необходимость взаимодействия со СМЭВ. История взаимодействия была начата ещё во времена “расцвета” СМЭВ 2, для которой не было готового Адаптера СМЭВ (как для СМЭВ 3). В то время для взаимодействия со СМЭВ 2 нами был разработан собственный Адаптер СМЭВ. Он всё ещё остаётся актуальным для интеграции с некоторыми сервисами СМЭВ, которые остаются работать на СМЭВ 2 (например, отправка и регистрация сертификатов в ЕСИА для Удостоверяющих Центров). Ориентировочной датой переноса всех сервисов на СМЭВ 3 называют март 2019 года, но всё может круто поменяться, учитывая специфику функционирования СМЭВ. В данной статье речь пойдёт о запуске бесплатного Адаптера СМЭВ 3 для взаимодействия с ним.

В материале представлена пошаговая инструкция по предоставлению доступа к Личному кабинету участника межведомственного взаимодействия (ЛК УВ) для двух категорий пользователей: сотрудник организации (сотрудник УВ) и представитель разработчика.

Что такое ЛК УВ?

Тем временем, ЛК УВ предоставляет участникам СМЭВ и их подрядчикам широчайший функционал. В системе в течение 5 минут в автоматическом режиме можно провести следующие процедуры:

• регистрация информационной системы (ИС УВ) в тестовой и продуктивной среде;
• получение доступа к виду сведений в тестовой и продуктивной среде в роли Потребителя и Поставщика;
• мониторинг статуса или поиск пропавшего межведомственного запроса;
• добавление специальной очереди;
• регистрация вида сведений;
• и многие многие другие.

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

Как попасть в ЛК УВ?

• Авторизуемся на Портале госуслуг (в ЕСИА) под учетной записью организации — участника межведомственного взаимодействия
• Выбираем опцию «Расширенный поиск».Организация: Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации.Система: Личный кабинет участника взаимодействия (ЛК УВ).По итогам фильтрации остается только один вариант ИС. Для него выбираем опцию «Присоединить нового сотрудника».
• В открывшемся списке выбираем сотрудника организации, который еще не получил доступ к ЛК УВ, и подтверждаем выбор.

Предоставление доступа к ЛК УВ сотруднику организации-разработчика

• Переходим в ЛК УВ и авторизуемся под учетной записью организации-участника взаимодействия.https://lkuv.gosuslugi.ru/
• Выбираем опцию «Назначить представителя разработчика».
• Указываем СНИЛС физлица-представителя разработчика.
• Выбираем организацию-разработчика. Так как один человек на ЕПГУ может одновременно являться сотрудником нескольких организаций.
• Проверяем и подтверждаем выбор.

После успешного добавления разработчика его данные появляются в разделе «Представители разработчика», а сам разработчик может зайти в ЛК УВ, авторизовавшись в ЛК УВ под учетной записью своей организации.

Кстати, у нас есть публичное сообщество «Вопросы СМЭВ» в телеграме. Заходите — там всегда найдется оперативный ответ почти на любой вопрос по СМЭВ.

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

6 октября 2020 года на технологическом портале СМЭВ3 появился раздел «Интеграционный узел Адаптера, доработанного Адаптера СМЭВ 3.0 в соответствии с новыми возможностями СМЭВ 3».

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

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

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

В табличном виде представлен перечень всех информационных систем участников СМЭВ с указанием владельца и мнемоники. Данные актуальны на 29.12.2020. Источник данных — Технологический портал СМЭВ.

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

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

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

Очереди сообщений и процесс взаимодействия

В процессе взаимодействия сообщения помещаются в очереди входящих запросов и очереди входящих ответов. По сути очереди — это контейнеры, в которых содержатся сообщения по видам сведений.

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

Следует помнить: чтобы забрать сообщение из очереди, необходимо подтвердить его получение с помощью Ack-запроса. В противном случае СМЭВ посчитает сообщение недоставленным и вернёт его в очередь через 15 минут после извлечения.

На каждый запрос может поступить как успешный, так и неуспешный ответ.

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

• Произошло расхождение справочных данных на портале и у поставщика;
• Нужного соответствия просто нет в настройках системы поставщика.

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

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

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

Виды сведений

Участники обмениваются данным через виды сведений (протоколы обмена) — правила формирования пакетов данных для передачи от одного участника другому.

Хороший пример вида сведений — Всероссийская перепись населения 2020. Данные о переписи передают федеральным органам исполнительной власти в электронном виде. В полученных данных существует чёткая структура сведений: ФИО, пол, дата рождения, гражданство, семейное положение. Также в рамках вида сведений описан ответ, который должен быть получен, если обработка запроса прошла успешно.

На июнь 2020 года в СМЭВ зарегистрировано более 1000 промышленных (рабочих) и 2000 тестовых видов.

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

Данные передаются по протоколу SOAP, при этом каждое сообщение представляет собой вложенную структуру:

Виды сведений делятся на две группы — простые и универсальные. Рассмотрим схему обмена данными по простому виду сведений:

На схеме видно, что данные форм отображаются непосредственно в конверты обмена данными. Из-за этого появляется ограничение: необходимо разработать структуру блока данных, запроса/ответа для каждого такого вида сведений.

Обмен по универсальному виду сведений можно представить так:

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

• номер заявления портала и сведения, позволяющие определить услугу;
• целевое подразделение, к которому пользователь обращается за услугой.

Данные формы, заполненные пользователем портала, пакуются во вложение к основному сообщению.

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

Положительный эффектПравить

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

Функции СМЭВПравить

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

СсылкиПравить

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

В 2009 году обеспечена возможность взаимодействия между Единым порталом государственных услуг (ЕПГУ) и информационными системами федеральных органов исполнительной власти (ФОИВ) для заказа государственных услуг в электронном виде. Взаимодействие обеспечивалось с использованием синхронных электронных сервисов. На конец года было зарегистрировано порядка 30 электронных сервисов.

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

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

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

Кредитные организации (банки) получили доступ к СМЭВ под контролем ЦБ согласно постановлению Правительства Российской Федерации от 22.12.2012 № 1382. В Федеральном законе от 07.08.2001 № 115-ФЗ также определена возможность доступа к СМЭВ для упрощенной идентификации негосударственных пенсионных фондов, части страховых организаций, организаций федеральной почтовой связи и некоторых других организаций, осуществляющих операции с денежными средствами или иным имуществом.

Постановлением Правительства Российской Федерации от 19 ноября 2014 года № 1222 «О дальнейшем развитии единой системы межведомственного электронного взаимодействия» с 1 января 2015 года запрещена разработка электронных сервисов в СМЭВ согласно Методическим рекомендациям по работе в СМЭВ версии 2.X. Новые сведения следует предоставлять согласно Методическим рекомендациям по работе в СМЭВ версии 3.X. — таким образом третья версия СМЭВ официально введена в эксплуатацию с начала 2015 года.

Участники взаимодействия

Представим, что «Госуслуги» — это магазин, на витрине которого представлены сервисы для граждан и организаций. Запрос «покупателя» на услугу передаётся соответствующим органам через систему межведомственного электронного взаимодействия (СМЭВ). Система передаёт сообщения между порталом и ведомством.

Работа через СМЭВ происходит по протоколу SOAP (Simple Object Access Protocol — простой протокол для доступа к объектам).

Участники взаимодействия, как в магазине, делятся на поставщиков и потребителей. Поставщик — это информационная система (ИС), которая предоставляет сведения по запросу, а потребитель — система, запрашивает сведения.

Одна и та же ИС может действовать сразу в двух ролях. Например, в процессе предоставления услуги нужно уведомить портал о смене её статуса. В этом случае ИС-поставщик исполняет роль потребителя — проводит информационный обмен по статусам.

Выбор программной платформы для адаптера

Согласно официальной документации на Адатер СМЭВ 3, поддерживается как Windows, так и Linux. Это неудивительно, т.к. он написан на Java и изначально задумывался как кроссплатформенное программное обеспечение. Тем не менее, после более детального изучения документации, стало ясно, что поддержка Linux только номинальная. В частности, в руководстве администратора адаптера СМЭВ детально расписано, какие библиотеки для Java необходимо установить на Windows, представлены сведения о криптопровайдерах и т.д. В разделе об установке на Linux написано дословно “1. Развернуть и настроить java JRE в среде Linux.”. Это максимум информации, которую можно почерпнуть из официального руководства по вопросу установки на Linux. После нашего запроса в техподдержку пришла стандартная отписка, что нужно “настроить те же компоненты, что и в варианте с Windows”. После этого вопрос с выбором платформы был решён в пользу ОС Microsoft.

Тестовое взаимодействие со СМЭВ 3

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

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

Для того, чтобы отправить эталонные сообщения, нам необходимо подготовить файлы отправки. Т.к. мы выбрали интеграцию через файловое хранилище, адаптер будет забирать файлы из папки %ADAPTER_ROOT%integrationiles%MNEMONIC%out и на их основании отправлять сообщения. Тут проблема заключается в том, что у адаптера несколько иной формат конверта (сообщения), чем у сервиса ЕСМЭВ. Подробнее о формате можно почитать в руководстве администратора адаптера СМЭВ. Ниже приводится пример содержимого файла в формате адаптера для отправки эталонного сообщения тестирования вида сведений “Выписки из ЕГРЮЛ по запросам органов государственной власти”:

Здесь 111111 – мнемоника системы, 3e83e83a-6a23-4908-b0d2-e3ad08fe2602 – идентификатор запроса. Он должен меняться при каждом запросе. Можно воспользоваться онлайн-генератором по ссылке:

Как видно из примера, в блок MessagePrimaryContent помещается тело эталонного сообщения.

После отправки сообщения нужно подождать некоторое время и в папке  %ADAPTER_ROOT%messages%MNEMONIC% появятся файлы, в которых будут находиться XML-сообщения запроса и ответа. Данные файлы следует сохранить и впоследствии прикрепить к заявке на доступ к виду сведений производственного контура СМЭВ. Операцию по тестированию следует повторить для всех эталонных сообщений в архиве.

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

Надеемся, наш опыт был Вам полезен. Удачи в работе со СМЭВ!

Подготовка к запуску

В нашем случае, организация уже имела доступ к СМЭВ 2, была зарегистрирована в СМЭВ и имела все необходимые учётные записи. Но, как оказалось, для подключения к СМЭВ 3 этого недостаточно. Для получения учётной записи СМЭВ 3 необходимо снова собрать все документы и пройти процедуру подключения. Процедура описана в на Технологическом портале СМЭВ. После успешного подключения, на электронную почту будет направлено зарегистрированное наименование участника (название организации) и мнемоника, которая понадобится в дальнейшем для настройки Адаптера СМЭВ.

Установка адаптера СМЭВ

Для установки под Windows мы использовали полезную с технологического портала СМЭВ 3. Единственное. что следует учитывать: для настройки лицензии Trusted Java необходимо установить VC++ redistributable (из состава меню самой Trusted Java). Без неё окошко ввода лицензии не появляется. После установки и запуска адаптера он настраивается полностью по видеоинструкции на работу с тестовой средой (). Нужно не забыть настроить мнемонику системы и указать интеграцию через файловое хранилище (это потребуется дальше). Если планируется использовать web-интерфейс адаптера, рекомендую после установки сделать резервную копию машины: добавляемые в систему виды сведений никогда не удаляются. Такая уж особенность адаптера.

Отличия СМЭВ 2 от СМЭВ 3

Изначально мы планировали доработать наш Адаптер СМЭВ 2 собственной разработки для взаимодействия со СМЭВ 3. Но, как выяснилось, отличия двух систем не просто значительные, а радикальные. По сути, с точки зрения интеграции СМЭВ 2 не имеет почти ничего общего со СМЭВ 3. В СМЭВ 2 каждый поставщик данных (ФНС, ПФР, МВД) имел свой SOAP-сервис со своим файлом WSDL и особенностями работы. В СМЭВ 3 присутствует единый сервис, который является посредником между запрашивающей стороной (нами) и поставщиками информации. Более детально СМЭВ 3 описан в документе Методические рекомендации по работе с ЕСМЭВ

При выборе способа интеграции нужно учитывать, что передаваемые сообщения подписываются электронной подписью (ЭП) организации. Кроме того, при взаимодействии с единым сервисом СМЭВ 3 нужно использовать протокол SOAP с нестандартным алгоритмом каноникализации. Не совсем понятно, почему разработчики СМЭВ решили использовать свою каноникализацию, это уже останется на их совести. Само собой, свободных и открытых библиотек для данного алгоритма нет. Трудности есть и с подписыванием запросов SOAP по ГОСТ, т.к. не все языки программирования поддерживают ГОСТ “из коробки”. Эталонная реализация алгоритма каноникализации доступна только на Java, так что разработчики, использующие другие языки должны либо реализовывать данный алгоритм самостоятельно, либо отказаться от работы со СМЭВ.

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

Полностью собственное решение на удобном нам языке (Python)

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

Реализация собственного адаптера на Java

Данный способ использует для хранения закрытой части ключа КриптоПРО JCP. Такое решение соответствует законодательным требованиям РФ по защите ЭП, т.к. используется сертифицированный криптопровайдер. К недостаткам можно отнести поддержку не всех носителей ЭП и необходимость приобретения лицензии на КриптоПРО JCP. Библиотека для Java распространяется свободно.

Мы решили не останавливаться на этом способе, т.к. он “прибит гвоздями” к Java, а для нас удобнее несколько иные технологии разработки.

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

Мы выбрали за основу последний способ. При данном подходе за взаимодействие со СМЭВ 3 отвечает бесплатный адаптер СМЭВ от Ростелекома. Он полностью реализует функции асинхронной работы с единым сервисом СМЭВ (постановка в очередь запросов и формирование ответов). Подпись вычисляется через Trusted Java, ключ хранится в стандартном КриптоПРО CSP, который поддерживает очень большое количество носителей ЭП и имеет все необходимые сертификаты. Тут следует отметить, что требуется приобретение лицензий на Trusted Java и КриптоПРО CSP, но они довольно бюджетные и не оказали существенного влияния на общую смету проекта (порядка 3 000 руб. суммарно).

На схеме цветом выделены те сервисы, которые реализуются непосредственно нами на удобной нам технологии разработки ПО (Python). Благодаря возможности выбора способа интеграции (база данных, файловый обмен, SOAP) мы не привязаны к Java или каким-либо другим языкам программирования. Более подробно интерфейсы интеграции Адаптера СМЭВ описаны в руководстве администратора Адаптера.

Что делать, если нужно срочно вывести государственную услугу на портал Госуслуги

Привет, Хабр! Меня зовут Софья, я работаю в РЕД СОФТ. Не так давно наша компания ускорила в два раза вывод государственных услуг на портал www.gosuslugi.ru, используя РЕДШЛЮЗ и Визуальный конструктор услуг. В этой статье я расскажу, как нам это удалось.

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

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

Что изменилось? В апреле 2022 года на Госуслугах заработали новые формы подачи заявлений – простые, с пошаговым заполнением и написанные на понятном для обывателя языке. Страницы таких форм строятся при помощи нового инструмента – визуального конструктора услуг (ВКУ).

ВКУ позволяет визуализировать шаги оказания услуги сразу на этапе проектирования, которое ведомство может осуществлять самостоятельно, без привлечения разработчиков Минцифры России. Срок разработки услуги занимает вдвое меньше времени. Однако процесс имеет свои особенности и накладывает определенные ограничения, которые я постаралась осветить в данной статье на основании собственного опыта работы с ВКУ.

Сегодня я научу вас работать с РЕДШЛЮЗ и ВКУ. Поехали!

Этапы разработки услуги

Разработка услуги при помощи ВКУ состоит из следующих этапов:

• получение учетной записи разработчика и тестового пользователя, регистрация сервисного кода услуги;
• конструирование услуги в среде разработки (DEV) с помощью визуального редактора, тестирование и согласование с заказчиком;
• публикация услуги в предпродуктивную среду (UAT);
• настройка взаимодействия с ИС ведомства, оказывающего услугу;
• публикация услуги в продуктивную среду (PROD).

Из чего состоит ВКУ

Процесс сборки услуги при помощи ВКУ заключается в составлении последовательных цепочек («флоу») из статичного набора «экранов».

Рисунок 2 – Страница услуги

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

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

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

Рисунок 3 – Версии услуги

Типы экранов

Разработчиками ВКУ предлагаются следующие типы экранов:

• Экран с разводящим вопросом («квиз»).
• Экран со сложным компонентом.
• Экран для повторяющегося набора компонентов.
• Составной гендерный экран.
• Специальный экран, содержащий компонент типа Redirect. Позволяет осуществлять перенаправление по адресу, указанному в компоненте Redirect.
• Экран отображения информации.

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

Изначально поле услуги пустое. Нажатием на «+» в левой панели добавляется первый экран (по умолчанию должен иметь тип «Экран отображения информации», т.к. является приветственным), а в правой панели добавляются его составляющие.

Рисунок 4 – Параметры нового экрана и возможные действия над ним

Настройка экрана доступна по действию «Настроить». Обязательные для заполнения поля отмечены значком *. Идентификатор экрана должен быть уникален (имеет вид sN, где N – уникальный номер, присваиваемый в порядке добавления экранов). Название должно отражать суть содержимого экрана для последующего удобного поиска. Заголовок и подзаголовок экрана отображаются заявителю.

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

Рекомендация: хотелось бы отличать поля, скрытые от заявителя, от технических полей

Все текстовые поля экранов и компонентов распознают html-разметку. Содержимое текстов должно соответствовать редакционной политике Госуслуг.

html-разметка добавляет наглядности текстам, позволяет сделать список, выделить предупреждение и т.п. Однако приходится пользоваться сторонними редакторами, т.к. поля, предполагающие ввод многострочного текста, содержат всего одну строку.

Рекомендация: обеспечить возможность редактирования html-разметки непосредственно в компонентах ВКУ

Рисунок 5 – Карточка настроек экрана

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

Рисунок 6 – Признаки первого и последнего экранов

Отдельные типы экранов и компонентов предполагают сложную настройку компонентов.

Рекомендация: добавить функцию создания экрана с копированием

Рисунок 7 – Форма «превью» экрана

В режиме «превью» становятся доступными действия:

• «Настроить экран» – открывает форму настройки экрана.
• «Проверить экран» – автоматически проверяет экран на наличие ошибок.

Рисунок 8 – Модальное окно с предупреждением об ошибках на экране

Рисунок 9 – Превью и опубликованный приветственный экран услуги

Типы компонентов

Таблица 1 – Соответствие отдельных типов экранов и присущих им компонентов

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

Рисунок 10 – Форма добавления компонентов на экран

Обязательные для заполнения поля отмечены значком *. Идентификатор компонента должен быть уникален (имеет вид сN, где c – латинская, N – уникальный номер, присваиваемый в порядке добавления компонентов). Удобочитаемое имя компонента должно отражать суть его содержимого для последующего удобного поиска. Заголовок компонента отображается заявителю услуги.

Каждый компонент имеет свои особенности. Отдельные типы компонентов, например, «Выпадающий список со строкой поиска (Lookup)», допускают возможность использования внешних справочников, опубликованных в Единой системе нормативно-справочной информации (ЕС НСИ). При этом при настройке компонента описывается маппинг полей.

«Компонент для загрузки файлов (FileUploadComponent)» позволяет обеспечить загрузку как одного, так и множества файлов, ограничивать их формат, размер и количество. Доступна разбивка на смысловые группы путем добавления уникальных «загрузчиков».

«Компонент для объединения повторяющегося набора компонентов» (RepeatableFields)) позволяет объединять добавленные на экран компоненты в группы для последовательного заполнения однотипных данных.

Рисунок 11 – Пример реализации повторяющегося компонента Lookup

Рисунок 12 – Настройка компонента загрузки файлов и пример отображения заявителю

Рисунок 13 – Настройка ссылки на внешний справочник и пример отображения заявителю

Форма настройки компонента открывается нажатием левой кнопки мыши на его название.

Большинство заголовков и описаний настроек компонентов написаны техническими терминами.

Рекомендация: добавить подсказки с описанием принципа заполнения настроек и их влияние на поведение компонента

Рисунок 14 – Действия над компонентом и карточка настроек компонента

Взаимосвязь экранов

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

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

Рисунок 15 – Форма настройки кнопки

Правило перехода – это подробное описание логики перехода между экранами. Правильная настройка правил перехода – залог качественной разработки услуги.

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

Обязательные для заполнения поля карточки настройки правила перехода отмечены значком «*». Экран, с которого осуществляется настраиваемый переход, выбирается из раскрывающегося списка экранов, добавленных ранее. Название правила перехода обычно имеет вид: s1-s2. Для настройки правила предназначен блок «Условия перехода». Условие может быть простым или сложным.

В ходе разработки были освоены следующие условия перехода:

Рисунок 16 – Пример простого перехода с посещением экрана

• простое с выбранным значением в квизе, радиокнопке или чек-боксе (см. Рисунок 17);
• сложное с выбором типа учетной записи пользователя (см. Рисунок 18).

Рисунок 17 – Пример простого перехода с выбором значением в компоненте

Рисунок 18 – Пример сложного перехода с выбором типа учетной записи пользователя

VM-шаблоны

VM-шаблон XML – это шаблон, написанный с применением синтаксиса Apache Velocity. VM-шаблон служит для создания XML-документа заявления, который направляется непосредственно в ведомство для получения услуги, на основании ответов заявителя, которые автоматически сохраняются в виде сценария DTO в ходе заполнения интерактивной формы заявления.

VM-шаблоны составляются вручную путем заполнения полей XML, необходимых для конкретного сценария, значениями переменных из предварительно выгруженного сценария DTO:

• xxxxxxxx_Applicant.vm – шаблон, генерирующий бизнес-данные заявления;
• pdf_xxxxxxxx_Applicant.vm – шаблон, используемый для генерации PDF-файла заявления в личном кабинете заявителя;
• t_xxxxxxxx.vm – шаблон, на основе которого генерируется транспортная XML,

где xxxxxxxx – сервисный код услуги (ServiceId).

Все составленные шаблоны необходимо загрузить в ВКУ, выбрав соответствующее действие в меню главной страницы услуги.

Рисунок 19 – Загруженные VM шаблоны

XML заявления создается Адаптером SP, который собирает XML, заполняя его данными из VM-шаблона, черновика заявления и глобальных переменных профиля пользователя. После этого Адаптер SP отправляет XML в Service Processing (SP), где и происходит отправка в ведомство.

Сопряжение экранов со СМЭВ

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

Этапы перевода услуги в продуктивную среду

Конструирование услуги ведется в среде разработки (DEV), где хранятся все доработки, которые первично выполнены разработчиками, в том числе черновики. Для DEV-среды используется отдельный набор тестовых учетных записей, настраивается доступ к тестовой ЕС НСИ для корректного отображения внешних справочников.

Следующим шагом является публикация услуги в предпродуктивной среде (UAT), куда попадают только успешно протестированные в DEV доработки, заявленные для релиза в продуктивной среде.

Финальным шагом является публикация услуги в продуктивной среде (PROD).

Ограничения ВКУ

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

Тем не менее, главным ограничением является то, что не все компоненты старой версии среды разработки Госуслуг были перенесены в ВКУ.

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

При поиске конкретного экрана и выборе его в дереве экранов черновика была бы удобной функция автоматического перехода к выбранному экрану на форме (помимо подсветки). Также недоступен поиск по коду компонента.

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

Не хватает функции принудительного сохранения черновика после внесения изменений (включая сообщение о том, что сохранение не успешно). Столкнулись с тем, что если в процессе внесения изменений ВКУ отключали на время проведения технических работ, изменения не сохранялись, что приводило к трудозатратам на их восстановление.

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

ВКУ позволяет выгрузить текущую версию услуги в файл формата json. На случай потери данных «флоу» из-за сбоя ВКУ было бы полезно иметь инструмент, позволяющий загрузить json в ВКУ, чтобы на его основе выстроился «флоу».

Для выявления ошибок в VM-шаблонах на основании сформированного заявления не хватает автотеста. Есть возможность либо написать запрос для генерации XML бизнес-данных самостоятельно, либо запросить отчет у техподдержки.

ВКУ не позволяет загрузить справочники ЕС НСИ с типом «Иерархический».

Прием заявлений с Госуслуг

Для организации межведомственного электронного взаимодействия и предоставления государственных услуг в электронном виде использовали РЕДШЛЮЗ.

Использование в качестве шлюза

В РЕДШЛЮЗ есть собственный модуль, предназначенный для взаимодействия со СМЭВ 3, который позволяет относительно быстро разработать клиент (толстый и тонкий) для ведомства, ответственного за оказание госуслуги, включая адаптеры и маппинг.

Рисунок 20 – Параметры универсального адаптера СМЭВ 3.0 РЕДШЛЮЗ

Использование для оказания госуслуги

Функционал РЕДШЛЮЗ позволяет не только отправлять / получать сообщения через СМЭВ 3, но и реализовать пользовательский интерфейс для сотрудников ведомства, при помощи которого они могут проводить входящие электронные заявления на оказание госуслуги по этапам их жизненного цикла внутри ведомства.

Рисунок 21 – Карточка электронного заявления на оказание услуги «Запрос сведений о наличии судимости» МВД (РЕДШЛЮЗ)

Вывод

Функционал ВКУ и РЕДШЛЮЗ существенно сократил сроки технологического процесса по выводу интерактивных форм услуги в промышленную эксплуатацию: весь процесс занял около трех месяцев. Процедура создания экранных форм включает интуитивно понятный интерфейс добавления компонентов услуги, есть возможность оперативно вносить правки и отслеживать результат без ожидания публикаций в среде разработки. Транспорт через СМЭВ, организованный РЕДШЛЮЗ, в очередной раз показал свою эффективность. Теперь мы и дальше планируем при работе с органами государственной власти самостоятельно собирать интерактивные формы, используя комбинированное решение.

Ждем актуальных доработок!

Технические подробности взаимодействияПравить

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

Для передачи электронных сообщений используется протокол SOAP поверх HTTP.

Ограничение доступа реализовано на основании сведений, передаваемых в сообщении с использованием стандарта WS-Security.

СМЭВ обладает функциями протоколирования взаимодействия. Также СМЭВ позволяет установить кто, в каком объёме и на основании каких привилегий делал запрос информации.

Постановка задачи

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

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

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

Система межведомственного электронного взаимодействия

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 1 февраля 2022 года; проверки требуют 2 правки.

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

• Федеральный закон от 27 июля 2010 г. N 210-ФЗ «Об организации предоставления государственных и муниципальных услуг». Дата обращения: 23 октября 2018. Архивировано 9 февраля 2022 года.
• CNEWS 2013 № 65. Дата обращения: 23 марта 2013. Архивировано 12 марта 2013 года.
• Постановление Правительства РФ от 28 ноября 2011 г. № 697 «О единой системе межведомственного электронного взаимодействия». Дата обращения: 23 октября 2018. Архивировано 23 октября 2018 года.
• Технологический портал СМЭВ
• Проект «Электронное правительство». Дата обращения: 10 января 2013. Архивировано 10 января 2013 года.
• Telekomza. Минкомсвязи определилось с форматом документов для СМЭВ — PDF/А + реквизиты в XML. Дата обращения: 1 октября 2014. Архивировано 6 октября 2014 года.
• Приказ Минкомсвязи РФ от 27.12.2010 года № 190 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия». URL: http://smev.gosuslugi.ru/portal/api/files/get/424 Архивная копия от 7 сентября 2014 на Wayback Machine
• Методические рекомендации по разработке электронных сервисов и применению технологии электронной подписи. URL: http://smev.gosuslugi.ru/portal/api/files/get/6671 Архивная копия от 6 октября 2014 на Wayback Machine
• Николай Никифоров: «Электронные сервисы в СМЭВ должны функционировать круглосуточно». Минкомсвязь России. Дата обращения: 1 июня 2016. Архивировано 20 сентября 2016 года.
• Сервис ФМС «умирает» под давлением запросов через СМЭВ. Дата обращения: 23 октября 2018. Архивировано 23 октября 2018 года.
• Шквал запросов через СМЭВ физически ломает оборудование Росреестра. Дата обращения: 23 октября 2018. Архивировано 23 октября 2018 года.