прямую
ссылку на статью
Адреса FTP-серверов ФХ СМЭВ 3:
Для выгрузки файла на стороне информационной системы получателя необходимо сформировать запрос вида:
Только после получения вложения Участник-получатель должен направить ACK, после чего вложение удаляется из зоны долгосрочного хранения.
Важно! Если получатель, не скачав или не полностью скачав вложение подтвердит получение сообщения, т.е. направит ACK, то вложение удалится и будет недоступно для повторного скачивания.
прямую
ссылку на статью
Адреса размещения Единого электронного сервиса
Продуктивная среда СМЭВ 3 (СМЭВ 3):
- Схема 1.1 http://172.20.3.12:7500/smev/v1.1/ws?wsdl. Адрес для обращения к транспорту http://172.20.3.12:7500/smev/v1.1/ws
- Схема 1.2 http://172.20.3.12:7500/smev/v1.2/ws?wsdl. Адрес для обращения к транспорту http://172.20.3.12:7500/smev/v1.2/ws
- Схема 1.3 http://172.20.3.12:5000/ws/smev-message-exchange-service-1.3.wsdl. Адрес для обращения к транспорту http://172.20.3.12:5000/transport_1_0_2/
Тестовая среда СМЭВ 3 (ТСМЭВ 3):
- Схема 1.1 http://smev3-n0.test.gosuslugi.ru:7500/smev/v1.1/ws?wsdl. Адрес для обращения к транспорту http://smev3-n0.test.gosuslugi.ru:7500/smev/v1.1/ws
- Схема 1.2 http://smev3-n0.test.gosuslugi.ru:7500/smev/v1.2/ws?wsdl. Адрес для обращения к транспорту http://smev3-n0.test.gosuslugi.ru:7500/smev/v1.2/ws
- Схема 1.3 http://smev3-n0.test.gosuslugi.ru:5000/ws/smev-message-exchange-service-1.3.wsdl. Адрес для обращения к транспорту http://smev3-n0.test.gosuslugi.ru:5000/transport_1_0_2/
Среда разработки СМЭВ 3 (СР СМЭВ 3):
- Схема 1.1 http://smev3-d.test.gosuslugi.ru:7500/smev/v1.1/ws?wsdl. Адрес для обращения к транспорту http://smev3-d.test.gosuslugi.ru:7500/smev/v1.1/ws
- Схема 1.2 http://smev3-d.test.gosuslugi.ru:7500/smev/v1.2/ws?wsdl. Адрес для обращения к транспорту http://smev3-d.test.gosuslugi.ru:7500/smev/v1.2/ws
- Схема 1.3 http://smev3-d.test.gosuslugi.ru:5000/ws/smev-message-exchange-service-1.3.wsdl. Адрес для обращения к транспорту http://smev3-d.test.gosuslugi.ru:5000/transport_1_0_2/
При отправке сообщения на стороне Участника-отправителя формируется HTTP-заголовок. Необходимо заполнять атрибтут HOST в HTTP-заголовке сообщения в соответствии со средой, с которой происходит обмен данными. Например, для продуктивной среды (схема 1.3): Host: 172.20.3.12:5000.
Адреса FTP-серверов файлового хранилища (ФХ) СМЭВ 3
Режим FTP-сервера – пассивный. Диапазон предоставляемых портов: 21, 4000 – 6000.
Пересылка вложений с использованием файлового хранилища описана в п.7 Методических рекомендаций по работе с СМЭВ версия 3.5.X.X:
Загрузка файлов в Файловое хранилище осуществляется по протоколу FTP. Каждый участник взаимодействия получает доступ к отдельной директории FTP-сервера Файлового хранилища для загрузки файлов вложений. Для каждого файла ИС отправителя должна создать отдельную директорию, в качестве названия которой должен быть использован UUID, сгенерированный по алгоритму, аналогичному генерации UUID сообщения (см. п. 4.2 «Algorithms for Creating a Time-Based UUID» RFC 4122).
Адреса Сервиса предоставления кодов транзакций (СГКТ)
С середины июня 2022 года учреждения СПО будут обязаны принимать заявления абитуриентов через сайт Госуслуг. В статье обозначена правовая база нововведения; рассмотрена схема взаимодействия участников процесса; даны рекомендации руководителям колледжей и техникумов, как эффективно подготовить учреждение к новому формату приема на обучение.
Содержание
Правовое основание приема на обучение в колледжи и техникумы в электронном формате
В середине декабря 2021 года Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации известило в письме глав субъектов РФ, что разработаны единые технические требования к интеграции (ЕФТТ) региональных ведомственных информационных систем (РИС) с формой-концентратором федеральной информационной системы “Единый портал государственных и муниципальных услуг” (ЕПГУ). Речь идет о разделе “Прием на обучение по программам среднего профессионального образования” на сайте Госуслуги. Несколькими годами ранее такая возможность стала доступна всем поступающим в высшие учебные заведения.
К письму от Минцифры России прилагаются сами Единые технические требования к интеграции на 96 страницах.
Возможность подачи заявления на поступление в колледжи и техникумы страны в электронном виде инициировано на правительственном уровне в целях улучшения качества жизни и условий ведения предпринимательской деятельности. Это улучшение, на ряду с другими, изложено в Плане перевода массовых социально-значимых государственных и муниципальных услуг (План МСЗУ) в электронный формат и утверждено протоколом №19 от 25 июня 2021 года на заседании Президиума Правительственной комиссии по цифровому развитию.
План МСЗУ разработан Правительством на основании Поручений президента РФ от 10.10.2020 №ПР-1648. В действующем Приказе Минпросвещения РФ от 02.09.2020 г. №457 (п. 24.) о “Порядке приема на обучение по образовательным программа СПО” указано право поступающего подать заявление через портал Госуслуг.
На основании вышеперечисленных документов перед представителями среднего профессионального образования уже встал вопрос, как организовать процесс приема на обучение в СПО через Госуслуги.
Как будет построен процесс подачи заявления через ЕПГУ
Министерство цифрового развития, связи и массовых коммуникаций для выполнения задачи по организации возможности подачи заявления в учреждения СПО предлагает следующую схему взаимодействия:
- Абитуриент авторизуется на сайте ЕПГУ, выбирает колледж и специальность, подает заявление через сайт ЕПГУ. Справочная информация о колледжах и специальностях агрегирована в двух справочниках через ЕСНСИ (Единую систему нормативной справочной информации).
- ЕПГУ пересылает заявление абитуриента в Региональную информационную систему (РИС).
- Региональная информационная система, получив заявление от ЕПГУ, передает данные в колледж.
- Колледж обрабатывает заявление (передает статус заявления, формулирует информацию о вступительных испытаниях и допуске к участию абитуриента в конкурсе; после прохождения вступительных испытаний составляет конкурсные списки) и возвращает обработанную информацию в РИС.
- РИС пересылает данные в ЕПГУ.
- ЕПГУ отображает полученную информацию в личном кабинете абитуриента.
Рис.1. Процесс подачи заявлений абитуриентов через ЕПГУ в учреждения СПО
За абитуриента, не достигшего совершеннолетия, заявление подает его законный представитель. Для этого заполняются отдельные поля в форме заявления в личном авторизованном подтвержденном кабинете ЕПГУ абитуриента.
Абитуриент в процессе подачи заявления может подать документы в несколько колледжей вне зависимости от региона.
Глядя на схему предоставления услуги “Прием на обучение по программам СПО”, возникает закономерный вопрос, почему нельзя связать ЕПГУ напрямую с колледжами. На него ответила Ирина Николаевна Сафронова, представитель Минцифры, руководитель проекта по подключению учреждений СПО к ЕПГУ. Объяснив, что в целях безопасности и сохранения конфиденциальности передача данных может осуществляться только между защищенными государственными информационными системами.
За создание и регистрацию сайтов в качестве РИС отвечают региональные Министерства цифрового развития.
Для граждан и организаций СМЭВ позволяет получать услугу по принципу “единого окна”: они избавлены от сбора документов в различных государственных структурах для получения одной услуги. Государственный орган, в свою очередь, не вправе требовать от заявителя документа, который уже есть в базе СМЭВ.
От РИС также потребуется зарегистрировать через ЕСНСИ два региональных справочника – по названиям и по специальностям СПО. Справочники регистрируются и заполняются в ЕСНСИ, которая связана с ЕПГУ. Вход в систему ЕСНСИ происходит через авторизацию на ЕПГУ. Таким образом, данные из справочников автоматически будут доступны в ЕПГУ. В итоге поступающий на программу СПО взаимодействует с данными из справочников через форму-концентратор на сайте Госуслуг при подаче заявления на поступление.
Рис. 2. Пример РИС – сайт портала образовательных услуг Челябинской области
Колледжи взаимодействуют с ЕПГУ только через РИС.
Текущая ситуация
С конца 2021 года в рамках осуществления Плана перевода МСЗУ в электронный формат работают пилотные проекты в регионах на выбранных для отладки системы колледжах. Компания “Онлайн-Консалтинг” (разработчик программного продукта “1С:Колледж”, “1С:Колледж ПРОФ”) уже готовит программную часть с учетом инструкции ЕФТТ, чтобы была возможность интеграции “1С:Колледж” с РИС.
Какие варианты разработчик предлагает для учреждений СПО, использующих продукт “1С:Колледж” и “1С:Колледж ПРОФ”.
На сегодняшний день разрабатываются способы интеграции продуктов “1С:Колледж” и “1С:Колледж ПРОФ” с региональными информационными системами и рассматриваются следующие варианты взаимодействия:
- Использование в качестве РИС адаптера СМЭВ.
В этом случае адаптер, являющийся программным продуктом, принимает и отправляет пакеты СМЭВ в форматах xml и http-сервисов.
Пришедшие пакеты адаптер выкладывает на защищенный ftp-ресурс в виде файлов xml. Информационная система на базе “1С:Колледж” мониторит ресурс и забирает нужные файлы. После обработки пакетов в СПО “1С:Колледж” формирует файл и выкладывает на ftp. Адаптер “забирает” файл и отправляет в СМЭВ.
- Разработка РИС на платформе “1С”.
По словам директора “Онлайн-Консалтинг” И.Г. Вдовина, уже ведутся работы по встраиванию облачной системы “1С:Фреш” в “1С:Колледж ПРОФ”; готовится выпуск специальной версии для регионов, которые захотят централизованно работать “в облаке”. В этом случае в качестве РИС и будет выступать облако “1С:Фреш”.
- Взаимодействие “1С” с РИС других поставщиков.
В случае разработки региональной информационной системы другими поставщиками, разработчик будет находить отдельные решения для ее интеграции с “1С:Колледж” в рамках отдельных региональных проектов. Потому как продукты других поставщиков могут не иметь возможности интегрироваться с “1С” и обладать совершенно различными спецификациями обмена. Тогда представителям СПО-пользователям “1С:Колледж” придется вводить поступающую от РИС информацию в облаке, потом вручную вводить ее в “1С:Колледж”.
В качестве РИС могут выступать и региональные порталы государственных услуг, если они регистрируются в качестве региональных информационных систем.
Что важно знать пользователям “1С:Колледж”
Разработчик “1С:Колледж” продолжает работу с партнерами-разработчиками РИС, готовя программную часть взаимодействия со стороны “1С:Колледж”. Это означает, что пользователи продукта смогут интегрироваться с ЕПГУ, чтобы с начала приемной кампании 2022 года оперативно обрабатывать заявления абитуриентов через портал “Госуслуги”.
Если в каких-либо регионах РИС будет разрабатывать компания “Онлайн-Консалтинг”, в планах фирмы интегрировать “1С:Колледж” с РИС, чтобы не заполнять региональные справочники в ЕСНСИ вручную. Разработчик планирует обойтись типовыми редакциями без дополнительной оплаты через простое обновления версии продукта.
Кроме того, ведется работа по встраиванию технологии “1С:Фреш” в “1С:Колледж ПРОФ”, подготовлен выпуск специальной версии для регионов, которые захотят централизованно работать “в облаке”.
Что делать представителям среднего профессионального образования на местах
Подачу заявления и поступление в учреждение СПО в электронном формате через сайт ЕПГУ необходимо обеспечить до июня 2022 года, поэтому, если в регионе еще нет видимого движения в этом направлении, представителям колледжей и техникумов рекомендуем узнать:
- какой поставщик в вашем регионе занимается созданием региональной информационной системы;
- какой колледж выбран в качестве тестового;
- что предполагается использовать в качестве РИС;
- наконец, заявить о своих интересах интеграции системы с продуктом “1С:Колледж”. Иначе может получиться, что выстроенная система не будет предусматривать интеграцию с “1С”.
Для консультации по всем этим вопросам в письме Минцифры указан электронный адрес ответственного за организацию поступления в колледжи через ЕПГУ. В случае, если в вашем регионе пока не ведутся работы по решению этой задачи, обратитесь к нам.
Если ваше образовательное учреждение пока не использует комплексного решения для управления деятельностью организаций СПО “1С:Колледж”, самое время позаботиться о его внедрении.
Программный продукт “1С:Колледж” решает для вас задачи:
- автоматизации управления деятельности по созданию приемной кампании; учета контингента; учета успеваемости и посещаемости; расписания, ежедневных замен и еще десятка процессов образовательной среды;
- создания электронного журнала;
- интеграции с решениями фирмы “1С” для бухгалтерии и отдела кадров;
- приема заявлений на обучение в электронном виде для выполнения Приказа Минпросвещения РФ от 02.09.2020 г. №457.
В июне 2022 года Центр компетенции по образованию «Русские Решения» реализовал подключение учреждений среднего специального образования Санкт-Петербурга к ЕПГУ. Подробнее о возможностях расширения «Интеграция СПО (СПб)» для «1С:Колледж» читайте в нашей статье.
Интегрируем Ваш колледж с ЕПГУ “Госуслуги”. Обращайтесь за услугой интеграции и дополнительной информацией о продукте “1С:Колледж” в Центр компетенции по образованию “Русские Решения”.
В СМЭВ реализована возможность отправки вложений двумя способами: МТОМ и через файловое хранилище (ФХ). Принципиальное отличие заключается в том, что при передаче МТОМ вложение отправляется в самом конверте. А при передаче через ФХ отдельно от СМЭВ документа.
При этом требования к размеру вложения разные. Для МТОМ ограничение составляет 5МБ. Если вложение имеет размер более 5МБ, тогда необходимо использовать его передачу через ФХ. Предельный размер файла, переданного через ФХ по ftp ограничивается лимитом на использование ФХ – стандартно 1ГБ.
Использование метода МТОМ в ИУА
В случае, если выбирается метод передачи вложений в СМЭВ документе, т.е. МТОМ, необходимо добавить ссылку на файл в блок заголовков //AttachmentHeaderList. Ниже представлен пример элемента:
Стоит обратить внимание, что директория размещения файла указывается в элементе.
Перед отправкой СМЭВ конверт будет преобразован, вложение и сообщение будут подписаны ЭП, и элемент будет выглядеть следующим образом:
Где contentId – Идентификатор (наименование) вложения;
MimeType – тип передаваемого файла согласно RFC 2045, RFC 2046, RFC 4288, RFC 4289 и RFC 4855;
SignaturePKCS7 – подпись вложения.
Помимо блока заголовков будет добавлен блок содержимого вложений (AttachmentContentList), передаваемых МТОМ:
<xop:Include data-hren=”Наименование_файла.xml” xmlns:xop=”
Где ID – идентификатор вложения, соответствующий фактическому Id вложения (Content-Id);
Content – содержимое файла в формате Base64.
Для всех используемых вариантов интерфейса Адаптера достаточно добавить элемент AttachmentHeaderList в формируемый конверт. Исключение составляет только передача через встроенный интерфейс, где внесение данных осуществляется в специальных разделах интернет-браузера. И необходимости в самостоятельном формировании xml конвертов нет.
О том, как отправлять сообщения в каждом из интерфейсов подробнее описано в соответствующих статьях раздела «Интерфейсы Адаптера».
Использование передачи вложений через ФХ в ИУА
При передаче файлов более 5МБ через ИУА блок с заголовками вложений может выглядеть так же, как и в случае использования МТОМ, т.е. так:
Таким образом, проделывать отдельные шаги под разные методы нет необходимости. Адаптер определит по размеру, какой метод использовать, и преобразует сформированный блок с заголовками в соответствии с требованиями СМЭВ. Для нашего примера он будет выглядеть следующим образом:
Где uuid – уникальный идентификатор вложения, с которым оно будет размещено в ФХ;
Hash – хэш-сумма переданного файла;
MimeType – тип передаваемого файла согласно RFC 2045, RFC 2046, RFC 4288, RFC 4289 и RFC 4855;
SignaturePKCS7 – подпись вложения.
При отправке конверта файл также будет размещен в ФХ. При успешном прохождении проверок СМЭВ добавит в конверт сообщения (GetRequestResponse поставщику или GetResponseResponse потребителю) учетные данные для доступа к ФХ.
Пример блока заголовков вложений в конверте получателя:
Стоит отметить, что в одном сообщении можно передать несколько вложений. И если в случае МТОМ количество ограничивается размером СМЭВ документа, то в случае передачи через ФХ допустимый лимит – 150 вложений. В случае превышения допустимого количества участнику будет отправлено синхронное уведомление с текстом «SMEV-200: Количество ФТП-вложений превышает допустимое».
Общая структура заголовков обоих методов представлена на рисунке 1 на примере запроса. Подробное описание используемых элементов представлено в Методических рекомендациях по работе со СМЭВ 3.
Рисунок 1 – Структура сообщения-запроса, переданного ИС в СМЭВ.
Система межведомственного электронного взаимодействия (СМЭВ) задумывалась как цифровая среда предоставления услуг и исполнения государственных и муниципальных функций в электронной форме.
В настоящее время СМЭВ продолжает расширять свои возможности и вовлекать все большее количество участников взаимодействия.
Что оказалось как нельзя кстати, в том числе для коммерческих организаций, в частности банков, которые все больше стремятся перевести свои услуги в цифру и сериализовать процессы.
В этой статье мы поговорим о том, как своими силами подписать запросы и проверить электронные подписи ответов СМЭВ версии 3.0, и о паре интересных нюансов, с которыми пришлось при этом столкнуться.
Здравствуйте!
Может возникнуть вопрос. Почему своими силами? Когда для СМЭВ 3 есть целый Технологический портал, где
- опубликована вся документация и методические указания,
- есть раздел с часто задаваемыми вопросами,
- можно скачать актуальную версию библиотек клиента СМЭВ 3,
- предоставлены примеры полных конвертов сообщений с подписями,
- можно даже проверить онлайн свое сообщение или из примера на соответствие схемам сервиса СМЭВ и на предмет валидности его электронной подписи
Все верно, портал, безусловно, крайне полезный, и всеми его подсказками и инструментами можно и нужно пользоваться, но вот код на Java напишем свой.
По той простой причине, что уже есть собственная информационная система, работающая с форматами электронной подписи XMLDSig, XAdES, в которой применяются библиотеки проекта Apache Santuario, реализующие основные стандарты безопасности для XML. А также библиотеки, входящие в состав КриптоПро JCSP, помимо работы с XML, обеспечивающие API криптографических функций СКЗИ КриптоПро CSP.
Написание собственных методов для работы с электронными подписями СМЭВ 3 в данном случае выглядит более целесообразно, нежели разворачивание полного клиента поставляемого:
ФГБУ НИИ «Восход» (до 21 марта 2016 года ФГУП НИИ «Восход») или интеграция, его отдельных классов и пакетов.
В то же время заглянуть в открытый код клиента всегда полезно, а его наличие само по себе говорит о зрелости системы и высоком уровне поддержки.
Анализ исходных данных
Загружаем с портала СМЭВ 3:
Если уже умеем формировать обычный XMLDSig или подписывать, например, конверты сообщений СМЭВ 2, то больше всего начинает интересовать, чем же отличается конверт с подписью СМЭВ 3 от СМЭВ 2.
Открываем пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1">
<S:Body>
<ns2:SendRequestRequest xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1">
<ns:SenderProvidedRequestData Id="SIGNED_BY_CONSUMER" xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"> <ns:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns:MessageID><ns2:MessagePrimaryContent><ns1:BreachRequest xmlns:ns1="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" xmlns:ns2="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0" xmlns:ns3="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1" Id="PERSONAL_SIGNATURE"> <ns1:RequestedInformation> <ns2:RegPointNum>Т785ЕС57</ns2:RegPointNum> </ns1:RequestedInformation> <ns1:Governance> <ns2:Name>ГИБДД РФ</ns2:Name> <ns2:Code>GIBDD</ns2:Code> <ns2:OfficialPerson> <ns3:FamilyName>Загурский</ns3:FamilyName> <ns3:FirstName>Андрей</ns3:FirstName> <ns3:Patronymic>Петрович</ns3:Patronymic> </ns2:OfficialPerson></ns1:Governance> </ns1:BreachRequest> </ns2:MessagePrimaryContent> <ns:TestMessage/></ns:SenderProvidedRequestData>
<ns2:CallerInformationSystemSignature><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"/><ds:Reference URI="#SIGNED_BY_CONSUMER"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:Transform Algorithm="urn://smev-gov-ru/xmldsig/transform"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/><ds:DigestValue>/jXl70XwnttJB5sSokwh8SaVHwo2gjgILSu0qBaLUAo=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>J3746ks34pOcPGQpKzc0sz3n9+gjPtzZbSEEs4c3sTwbtfdaY7N/hxXzEIvXc+3ad9bc35Y8yBhZ/BYbloGt+Q==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIBcDCCAR2gAwIBAgIEHVmVKDAKBgYqhQMCAgMFADAtMRAwDgYDVQQLEwdTWVNURU0xMQwwCgYDVQQKEwNJUzIxCzAJBgNVBAYTAlJVMB4XDTE1MDUwNzEyMTUzMFoXDTE4MDUwNjEyMTUzMFowLTEQMA4GA1UECxMHU1lTVEVNMTEMMAoGA1UEChMDSVMyMQswCQYDVQQGEwJSVTBjMBwGBiqFAwICEzASBgcqhQMCAiMBBgcqhQMCAh4BA0MABEDoWGZlTUWD43G1N7TEm14+QyXrJWProrzoDoCJRem169q4bezFOUODcNooQJNg3PtAizkWeFcX4b93u8fpVy7RoyEwHzAdBgNVHQ4EFgQUaRG++MAcPZvK/E2vR1BBl5G7s5EwCgYGKoUDAgIDBQADQQCg25vA3RJL3kgcJhVOHA86vnkMAtZYr6HBPa7LpEo0HJrbBF0ygKk50app1lzPdZ5TtK2itfmNgTYiuQHX3+nE</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></ns2:CallerInformationSystemSignature>
</ns2:SendRequestRequest>
</S:Body>
</S:Envelope>Дедуктивным методом выясняется что:
- больше не используется прием с выносом из содержимого тега Signature в Security заголовок элемента BinarySecurityToken с сертификатом открытого ключа проверки электронной подписи и ссылкой на него через SecurityTokenReference в теле самого Signature, как, например, в СМЭВ 2.4.6. Теперь сертификат должен находиться внутри Signature.
- второе и, по сути, самое существенное и важное изменение, оказывающее большое влияние на процесс подписи — это добавление новой проприетарной трансформации:
<ds:Transform Algorithm="urn://smev-gov-ru/xmldsig/transform"/>
Через эту трансформацию распространяются собственные правила каноникализации СМЭВ 3.
Каноникализация — процесс приведения данных, имеющих несколько возможных форм представления, к одному нормализованному стандартному виду.
Перед тем как посчитать хэш подписываемого атрибута в XML-конверте и подписать, необходимо выполнить его конвертацию в заданный правилами СМЭВ 3 вид.
В поисках описания трансформации urn://smev-gov-ru/xmldsig/transform открываем Методические рекомендации 3.4.0.3
Знакомимся с пунктом 4.4.2.1 Правила формирования электронной подписи сообщений
Формат подписи XMLDSig detached (https://www.w3.org/TR/xmldsig-core/)
Трансформация, дополнительно к канонизации urn://smev-gov-ru/xmldsig/transform
Требования к форматированию В XML-структуре подписи между элементами не допускается наличие текстовых узлов, в том числе переводов строки.
Пункт Методических указаний 12.4. ПРИЛОЖЕНИЕ 4: ОБРАЗЦОВАЯ РЕАЛИЗАЦИЯ ТРАНСФОРМАЦИИ URN://SMEV-GOV-RU/XMLDSIG/TRANSFORM
содержит Java класс SmevTransformSpi.java, реализующий алгоритм трансформации «urn://smev-gov-ru/xmldsig/transform», наследник org.apache.xml.security.transforms.TransformSpi из библиотеки Apache Santuario.
Таким образом, чтобы обеспечить каноникализацию подписываемого конверта СМЭВ 3, можно использовать в своем коде этот класс трансформации.
Единственным условием и ограничением в этом случае будет, что для обработки XML-документа при формировании подписи или ее проверки нужно использовать именно org.apache.xml.security.signature.XMLSignature из проекта Apache Santuario.
Задействовать инструменты из пакетов javax.xml.crypto.dsig или ru.CryptoPro.JCPxml.xmldsig просто так уже не получится.
Подготовка к подписи по правилам СМЭВ 3
Apache Santuario изначально ничего не знает про ГОСТ криптографические алгоритмы и СКЗИ КриптоПро.
В библиотеке xmlsec-1.5.0.jar в файле \org\apache\xml\security\resource\config.xml содержатся настройки только для работы с зарубежными криптографическими алгоритмами.
Чтобы он начал распознавать и применять ГОСТ, нужно выполнить его инициализацию.
По старинке это делалось так:
//APACHE-SANTUARIO INIT WITH CryptoPro JCP
System.setProperty("org.apache.xml.security.resource.config", "resource/jcp.xml");
org.apache.xml.security.Init.init();
String cfile1 = System.getProperty("org.apache.xml.security.resource.config");
LOGGER.log(Level.INFO, "Init class URL: " + org.apache.xml.security.Init.class.getProtectionDomain().getCodeSource().getLocation());
LOGGER.log(Level.INFO, cfile1);
В новых версиях КриптоПро JCP (JCSP) инициализацию выполнит одна строчка:
ru.CryptoPro.JCPxml.xmldsig.JCPXMLDSigInit.init();Теперь нужно Apache Santuario научить новым правилам трансформации, которые диктует СМЭВ 3. Для этого регистрируем класс трансформации:
try {
Transform.register(SmevTransformSpi.ALGORITHM_URN, SmevTransformSpi.class.getName());
santuarioIgnoreLineBreaks(true);
LOGGER.log(Level.INFO, "SmevTransformSpi has been initialized");
} catch (AlgorithmAlreadyRegisteredException e) {
LOGGER.log(Level.INFO, "SmevTransformSpi Algorithm already registered: " + e.getMessage());
}
Заодно сразу выполняем требование из Методических указаний:
Требования к форматированию В XML-структуре подписи между элементами не допускается наличие текстовых узлов, в том числе переводов строки.
santuarioIgnoreLineBreaks(true);
private static final String IGNORE_LINE_BREAKS_FIELD = "ignoreLineBreaks";
/**
* Apache Santuario privileged switch IgnoreLineBreaks property
*
* @param mode
*/
private void santuarioIgnoreLineBreaks(Boolean mode) {
try {
Boolean currMode = mode;
AccessController.doPrivileged(new PrivilegedExceptionAction<Boolean>() {
public Boolean run() throws Exception {
Field f = XMLUtils.class.getDeclaredField(IGNORE_LINE_BREAKS_FIELD);
f.setAccessible(true);
f.set(null, currMode);
return false;
}
});
} catch (Exception e) {
LOGGER.warning("santuarioIgnoreLineBreaks " + ExceptionUtils.getFullStackTrace(e));
}
}
Делается это в привилегированном блоке AccessController.doPrivileged
и через reflection, из-за особенности реализации свойства ignoreLineBreaks в Santuario.
Просто через настройку системного свойства:
System.setProperty("org.apache.xml.security.ignoreLineBreaks", "true");
Через настройку опции JVM:
-Dcom.sun.org.apache.xml.internal.security.ignoreLineBreaks=trueЕсли взглянуть на код класса org.apache.xml.security.utils.XMLUtils, то можно увидеть, что поле ignoreLineBreaks статическое, инициализируется в привилегированном блоке из системного свойства «org.apache.xml.security.ignoreLineBreaks».
private static boolean ignoreLineBreaks =
AccessController.doPrivileged(new PrivilegedAction<Boolean>() {
public Boolean run() {
return Boolean.valueOf(Boolean.getBoolean
("org.apache.xml.security.ignoreLineBreaks"));
}
}).booleanValue();
public static boolean ignoreLineBreaks() {
return ignoreLineBreaks;
}
Такая реализация приводит к невозможности гибко настроить в одном Java процессе для части методов игнорировать перевод строк, а для другой части не игнорировать.
Т.е., если одно приложение выполняет подписи XMLDsig, СМЭВ 2 и СМЭВ 3, все XML документы, обработанные Santuario должны на выходе лишиться перевода строк.
С этим свойством, конечно, возникает вопрос к Apache Santuario:
Подпись сообщений СМЭВ 3
Для подписи документов СМЭВ 3 все готово.
Код подписания выглядит следующим образом:
private static final String XMLDSIG_MORE_GOSTR34102001_GOSTR3411 = "http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411";
private static final String XMLDSIG_MORE_GOSTR3411 = "http://www.w3.org/2001/04/xmldsig-more#gostr3411";
private static final String CANONICALIZATION_METHOD = "http://www.w3.org/2001/10/xml-exc-c14n#";
private static final String DS_SIGNATURE = "//ds:Signature";
private static final String SIG_ID = "sigID";
private static final String COULD_NOT_FIND_XML_ELEMENT_NAME = "ERROR! Could not find xmlElementName = ";
private static final String GRID = "#";
private static final String XML_SIGNATURE_ERROR = "xmlDSignature ERROR: ";
try {
// инициализация объекта чтения XML-документа
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
// установка флага, определяющего игнорирование пробелов в
// содержимом элементов при обработке XML-документа
dbf.setIgnoringElementContentWhitespace(true);
// установка флага, определяющего преобразование узлов CDATA в
// текстовые узлы при обработке XML-документа
dbf.setCoalescing(true);
// установка флага, определяющего поддержку пространств имен при
// обработке XML-документа
dbf.setNamespaceAware(true);
// загрузка содержимого подписываемого документа на основе
// установленных флагами правил из массива байтов data DocumentBuilder documentBuilder = dbf.newDocumentBuilder();
Document doc = documentBuilder.parse(new ByteArrayInputStream(data));
/*
* Добавление узла подписи <ds:Signature> в загруженный XML-документ
*/
// алгоритм подписи (ГОСТ Р 34.10-2001)
final String signMethod = XMLDSIG_MORE_GOSTR34102001_GOSTR3411;
// алгоритм хеширования, используемый при подписи (ГОСТ Р 34.11-94)
final String digestMethod = XMLDSIG_MORE_GOSTR3411;
final String canonicalizationMethod = CANONICALIZATION_METHOD;
String[][] filters = {{XPath2FilterContainer.SUBTRACT, DS_SIGNATURE}};
String sigId = SIG_ID;
// инициализация объекта формирования ЭЦП в соответствии с
// алгоритмом ГОСТ Р 34.10-2001
XMLSignature sig = new XMLSignature(doc, "", signMethod, canonicalizationMethod);
// определение идентификатора первого узла подписи
sig.setId(sigId);
// получение корневого узла XML-документа
Element anElement = null;
if (xmlElementName == null) {
anElement = doc.getDocumentElement();
} else {
NodeList nodeList = doc.getElementsByTagName(xmlElementName);
anElement = (Element) nodeList.item(0);
}
// = doc.getElementById("#AppData");
// добавление в корневой узел XML-документа узла подписи
if (anElement != null) {
anElement.appendChild(sig.getElement());
} else {
throw new SignatureProcessorException(COULD_NOT_FIND_XML_ELEMENT_NAME + xmlElementName);
}
/*
* Определение правил работы с XML-документом и добавление в узел подписи этих
* правил
*/
// создание узла преобразований <ds:Transforms> обрабатываемого
// XML-документа
Transforms transforms = new Transforms(doc);
// добавление в узел преобразований правил работы с документом
// transforms.addTransform(Transforms.TRANSFORM_ENVELOPED_SIGNATURE);
transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS);
transforms.addTransform(SmevTransformSpi.ALGORITHM_URN);
// добавление в узел подписи ссылок (узла <ds:Reference>),
// определяющих правила работы с
// XML-документом (обрабатывается текущий документ с заданными в
// узле <ds:Transforms> правилами
// и заданным алгоритмом хеширования)
sig.addDocument(xmlElementID == null ? "" : GRID + xmlElementID, transforms, digestMethod);
/*
* Создание подписи всего содержимого XML-документа на основе закрытого ключа,
* заданных правил и алгоритмов
*/
// создание внутри узла подписи узла <ds:KeyInfo> информации об
// открытом ключе на основе
// сертификата
sig.addKeyInfo(x509Cert);
// создание подписи XML-документа
sig.sign(privateKey);
// определение потока, в который осуществляется запись подписанного
// XML-документа
bais = new ByteArrayOutputStream();
// инициализация объекта копирования содержимого XML-документа в
// поток
TransformerFactory tf = TransformerFactory.newInstance();
// создание объекта копирования содержимого XML-документа в поток
Transformer trans = tf.newTransformer();
// копирование содержимого XML-документа в поток
trans.transform(new DOMSource(doc), new StreamResult(bais));
bais.close();
} catch (TransformationException e) {
throw new SignatureProcessorException("TransformationException " + XML_SIGNATURE_ERROR + e.getMessage());
} catch (XMLSignatureException e) {
throw new SignatureProcessorException("XMLSignatureException " + XML_SIGNATURE_ERROR + e.getMessage());
} catch (TransformerException e) {
throw new SignatureProcessorException("TransformerException " + XML_SIGNATURE_ERROR + e.getMessage());
} catch (IOException e) {
throw new SignatureProcessorException("IOException " + XML_SIGNATURE_ERROR + e.getMessage());
} catch (XMLSecurityException e) {
throw new SignatureProcessorException("XMLSecurityException " + XML_SIGNATURE_ERROR + e.getMessage());
} catch (SAXException e) {
throw new SignatureProcessorException("SAXException " + XML_SIGNATURE_ERROR + e.getMessage());
} catch (ParserConfigurationException e) {
throw new SignatureProcessorException(
"ParserConfigurationException " + XML_SIGNATURE_ERROR + e.getMessage());
}
return bais.toByteArray();
Основными параметрами здесь являются:
byte[] data, // XML сообщение в виде массива байтов
String xmlElementName, // имя элемента в XML вместе с префиксом, в который следует добавить подпись, для СМЭВ-3 в общем случае "ns2:CallerInformationSystemSignature"
String xmlElementID // ID элемента в XML (если присутствует) вместе с префиксом, на который следует поставить подпись, для СМЭВ-3 в общем случае "SIGNED_BY_CONSUMER"
X509Certificate certificate // сертификат открытого ключа проверки подписи
PrivateKey privateKey // закрытый ключ подписи
Проверка подписи сообщения СМЭВ 3
Код проверки подписи выглядит следующим образом:
private static final QName QNAME_SIGNATURE = new QName("http://www.w3.org/2000/09/xmldsig#", "Signature", "ds");
private static final String SIGNATURE_NOT_FOUND = "Signature not found!";
private static final String SIGNATURE_NOT_VALID = "Signature not valid";
private static final String SMEV_SIGNATURE_PASSED_CORE_VALIDATION = "SmevSignature passed core validation";
private static final String VERIFY_SIGNATURE_ON_XML_IO_EXCEPTION = "Verify signature on XML IOException: ";
private static final String VERIFY_SIGNATURE_ON_XML_PARSER_CONFIGURATION_EXCEPTION = "Verify signature on XML ParserConfigurationException: ";
private static final String VERIFY_SIGNATURE_ON_XML_SAX_EXCEPTION = "Verify signature on XML SAXException: ";
private static final String VERIFY_SIGNATURE_ON_XML_XML_SIGNATURE_EXCEPTION = "Verify signature on XML XMLSignatureException: ";
private static final String VERIFY_SIGNATURE_ON_XML_XML_SECURITY_EXCEPTION = "Verify signature on XML XMLSecurityException: ";
private static final String ID = "Id";
boolean coreValidity = true;
try {
DocumentBuilderFactory bf = DocumentBuilderFactory.newInstance();
bf.setNamespaceAware(true);
DocumentBuilder b = bf.newDocumentBuilder();
Document doc = b.parse(new InputSource(new ByteArrayInputStream(signedXmlData)));
NodeList sigs = doc.getElementsByTagNameNS(QNAME_SIGNATURE.getNamespaceURI(), QNAME_SIGNATURE.getLocalPart());
org.apache.xml.security.signature.XMLSignature sig = null;
sigSearch: {
for (int i = 0; i < sigs.getLength(); i++) {
Element sigElement = (Element) sigs.item(i);
String sigId = sigElement.getAttribute(ID);
if (sigId != null) {
sig = new org.apache.xml.security.signature.XMLSignature(sigElement, "");
break sigSearch;
}
}
throw new XMLSignatureVerificationException(SIGNATURE_NOT_FOUND);
}
org.apache.xml.security.keys.KeyInfo ki = (org.apache.xml.security.keys.KeyInfo) sig.getKeyInfo();
X509Certificate certificate = ki.getX509Certificate();
if (!sig.checkSignatureValue(certificate.getPublicKey())) {
coreValidity = false;
LOGGER.log(Level.INFO, SIGNATURE_NOT_VALID);
} else {
LOGGER.log(Level.INFO, String.format(SMEV_SIGNATURE_PASSED_CORE_VALIDATION));
}
} catch (IOException e) {
throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_IO_EXCEPTION + ExceptionUtils.getStackTrace(e));
} catch (ParserConfigurationException e) {
throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_PARSER_CONFIGURATION_EXCEPTION + ExceptionUtils.getStackTrace(e));
} catch (SAXException e) {
throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_SAX_EXCEPTION + ExceptionUtils.getStackTrace(e));
} catch (org.apache.xml.security.signature.XMLSignatureException e) {
throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_XML_SIGNATURE_EXCEPTION + ExceptionUtils.getStackTrace(e));
} catch (XMLSecurityException e) {
throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_XML_SECURITY_EXCEPTION + ExceptionUtils.getStackTrace(e));
}
return coreValidity;
Проблемы. Хэш не совпадает
Для отладки использовался пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml
Из него был удален элемент ds:Signature с целью подписать сообщение заново и сверить с оригиналом.
Несмотря на то, что метод подписи и трансформация SmevTransformSpi, взятая из Методических указаний, отрабатывали, на выходе был подписанный документ, подпись которого при онлайн-проверке на портале СМЭВ 3 трактовалась как
ЭП-ОВ не подтверждена: Ошибка проверки ЭП: Нарушена целостность ЭП
<ds:DigestValue>e76oVeYGapFDE+PV6glsj0XDjLHydLMd0cSkFPY8fWk=</ds:DigestValue>не совпадал с оригинальным примером:
<ds:DigestValue>/jXl70XwnttJB5sSokwh8SaVHwo2gjgILSu0qBaLUAo==</ds:DigestValue>Для диагностики причин в класс SmevTransformSpi в метод process был добавлен свой XMLEventWriter.
ByteArrayOutputStream baos = new ByteArrayOutputStream();
XMLEventWriter bdst =
outputFactory.get().createXMLEventWriter(baos, ENCODING_UTF_8);
для параллельного анализа всех этапов трансформации.
Нормализованный элемент XML, на который требуется поставить подпись, выглядел следующим образом:
<ns1:SenderProvidedRequestData xmlns:ns1="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" Id="SIGNED_BY_CONSUMER"><ns1:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns1:MessageID><ns2:MessagePrimaryContent xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"><ns3:BreachRequest xmlns:ns3="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" Id="PERSONAL_SIGNATURE"><ns3:RequestedInformation><ns4:RegPointNum xmlns:ns4="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">Т785ЕС57</ns4:RegPointNum></ns3:RequestedInformation><ns3:Governance><ns4:Name>ГИБДД РФ</ns4:Name><ns4:Code>GIBDD</ns4:Code><ns4:OfficialPerson><ns5:FamilyName xmlns:ns5="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Загурский</ns5:FamilyName><ns5:FirstName>Андрей</ns5:FirstName><ns5:Patronymic>Петрович</ns5:Patronymic></ns4:OfficialPerson></ns3:Governance></ns3:BreachRequest></ns2:MessagePrimaryContent><ns1:TestMessage></ns1:TestMessage></ns1:SenderProvidedRequestData>Поиск решения показал, что, во-первых форум КриптоПро, нормализованный документ может выглядеть на самом деле иначе и соответственно его хэш будет другой и возможно правильный.
Во-вторых, привел в GitHub, где был выложен класс SmevTransformSpi более старой версии.
Старая версия класса трансформации выдала следующий нормализованный документ:
<ns1:SenderProvidedRequestData xmlns:ns1="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" Id="SIGNED_BY_CONSUMER"><ns1:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns1:MessageID><ns2:MessagePrimaryContent xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"><ns3:BreachRequest xmlns:ns3="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" Id="PERSONAL_SIGNATURE"><ns3:RequestedInformation><ns4:RegPointNum xmlns:ns4="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">Т785ЕС57</ns4:RegPointNum></ns3:RequestedInformation><ns3:Governance><ns5:Name xmlns:ns5="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">ГИБДД РФ</ns5:Name><ns6:Code xmlns:ns6="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">GIBDD</ns6:Code><ns7:OfficialPerson xmlns:ns7="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0"><ns8:FamilyName xmlns:ns8="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Загурский</ns8:FamilyName><ns9:FirstName xmlns:ns9="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Андрей</ns9:FirstName><ns10:Patronymic xmlns:ns10="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Петрович</ns10:Patronymic></ns7:OfficialPerson></ns3:Governance></ns3:BreachRequest></ns2:MessagePrimaryContent><ns1:TestMessage></ns1:TestMessage></ns1:SenderProvidedRequestData>С ним хэш стал совпадать, а подпись успешно проходить валидацию.
Сравнение версий класса SmevTransformSpi показала, что помимо добавленных в новой реализации дополнительных функций логирования и диагностики в debug режиме:
if (logger.isDebugEnabled()) {
debugStream = new DebugOutputStream(argDst);
dst = outputFactory.get().createXMLEventWriter(debugStream, ENCODING_UTF_8);
} else {
dst = outputFactory.get().createXMLEventWriter(argDst, ENCODING_UTF_8);
}
Класс из Методических указаний не содержит нужную строчку, или содержит опечатку:
prefixMappingStack.pop();, которая удаляет первый объект из стека с префиксами
Stack<List<Namespace>> prefixMappingStack = new Stack<List<Namespace>>();, что приводило к неверной работе SmevTransformSpi.
Добавление этой строки в новую версию SmevTransformSpi.java решило проблему.
Работающий класс трансформации и конверт с подписью можно посмотреть в github.com/VBurmistrov/Smev3
Результаты
Подписание конвертов СМЭВ 3 выполняется успешно.
Сообщения проходят проверку на портале Электронного правительства Госуслуги
И в собственном приложении:
В цикле статей мы, команда Gems Development, расскажем о работе с «Госуслугами» по ту сторону экрана и о том, как оформить эффективное взаимодействие органов государственной власти с порталом.
Общая схема взаимодействия через СМЭВ
Участники взаимодействия
Представим, что «Госуслуги» — это магазин, на витрине которого представлены сервисы для граждан и организаций. Запрос «покупателя» на услугу передаётся соответствующим органам через систему межведомственного электронного взаимодействия (СМЭВ). Система передаёт сообщения между порталом и ведомством.
Работа через СМЭВ происходит по протоколу SOAP (Simple Object Access Protocol — простой протокол для доступа к объектам).
Участники взаимодействия, как в магазине, делятся на поставщиков и потребителей. Поставщик — это информационная система (ИС), которая предоставляет сведения по запросу, а потребитель — система, запрашивает сведения.
Одна и та же ИС может действовать сразу в двух ролях. Например, в процессе предоставления услуги нужно уведомить портал о смене её статуса. В этом случае ИС-поставщик исполняет роль потребителя — проводит информационный обмен по статусам.
Виды сведений
Участники обмениваются данным через виды сведений (протоколы обмена) — правила формирования пакетов данных для передачи от одного участника другому.
Хороший пример вида сведений — Всероссийская перепись населения 2020. Данные о переписи передают федеральным органам исполнительной власти в электронном виде. В полученных данных существует чёткая структура сведений: ФИО, пол, дата рождения, гражданство, семейное положение. Также в рамках вида сведений описан ответ, который должен быть получен, если обработка запроса прошла успешно.
На июнь 2020 года в СМЭВ зарегистрировано более 1000 промышленных (рабочих) и 2000 тестовых видов.
Обмен данными в промышленной среде по всем видам сведений ведётся через защищённые каналы связи. Все передаваемые данные сопровождаются электронной цифровой подписью, с помощью которой СМЭВ идентифицирует участников взаимодействия.
Данные передаются по протоколу SOAP, при этом каждое сообщение представляет собой вложенную структуру:
Виды сведений делятся на две группы — простые и универсальные. Рассмотрим схему обмена данными по простому виду сведений:
На схеме видно, что данные форм отображаются непосредственно в конверты обмена данными. Из-за этого появляется ограничение: необходимо разработать структуру блока данных, запроса/ответа для каждого такого вида сведений.
Обмен по универсальному виду сведений можно представить так:
На первый взгляд схема может показаться более сложной, однако она демонстрирует принципиальную разницу, которая в итоге упрощает взаимодействие между участниками по универсальному виду сведений (УВС). Специфические данные форм передаются во вложении к конверту СМЭВ, а признаки УВС, позволяющие идентифицировать вид сведений, передаются непосредственно в конверте и имеют одинаковую для любого ВС структуру:
- номер заявления портала и сведения, позволяющие определить услугу;
- целевое подразделение, к которому пользователь обращается за услугой.
Данные формы, заполненные пользователем портала, пакуются во вложение к основному сообщению.
Таким образом можно оформить предоставление практически любых услуг без необходимости проходить трудную регистрацию нового вида сведений.
Очереди сообщений и процесс взаимодействия
В процессе взаимодействия сообщения помещаются в очереди входящих запросов и очереди входящих ответов. По сути очереди — это контейнеры, в которых содержатся сообщения по видам сведений.
Взаимодействие с очередями происходит с помощью специальных запросов. Более подробно они описаны в методических рекомендациях по работе со СМЭВ. Отметим только то, что благодаря очередям становится возможным асинхронный обмен данными: потребитель может оставить заявку на получение сведений, а поставщик — разместить ответ.
Следует помнить: чтобы забрать сообщение из очереди, необходимо подтвердить его получение с помощью Ack-запроса. В противном случае СМЭВ посчитает сообщение недоставленным и вернёт его в очередь через 15 минут после извлечения.
На каждый запрос может поступить как успешный, так и неуспешный ответ.
Представим себя в роли поставщика сведений: по запросу мы выдаём пользователю градостроительный план земельного участка, причём в рамках нашего ведомства действуют несколько территориальных подразделений, некоторые из которых такую услугу вовсе не оказывают. Допустим, пользователь портала при формировании заявления на получение услуги указал подразделение, не оказывающее услугу. Такая ситуация может возникнуть по двум причинам:
- Произошло расхождение справочных данных на портале и у поставщика;
- Нужного соответствия просто нет в настройках системы поставщика.
В любом случае поставщик должен ответить на запрос так, чтобы принимающая сторона могла понять, что запрос завершился неудачно, и, возможно предпринять ответные действия. Ответ на такой запрос оформляется в специальном пакете данных со сведениями о причине отказа.
Успешный ответ предполагает сценарий, в котором результат услуги — это набор файлов (что бывает довольно часто). Перед отправкой результата необходимо выгрузить файлы в файловое хранилище СМЭВ на основе FTP-сервера. Названия файлов и их контрольные суммы нужно зафиксировать в пакете, который отправляем через SOAP. Таким образом, есть две операции по передачи данных, которые нужно связать общим контекстом — сведениями о файлах.
На практике встречаются случаи, когда во время взаимодействия СМЭВ находится в режиме обслуживания, и запросы участника оборачиваются неудачей и требуют повторной отправки. Неудачу нужно зафиксировать и отправить запрос повторно.
Постановка задачи
С учётом приведённых выше особенностей, нашей команде предстояло обеспечить интеграцию ИС заказчика с «Госуслугами» по универсальному виду сведений. Информационная система заказчика — ИАС «Градоустройство». С её помощью пользователи ведомств, ответственные за оказания услуг, могут собирать пакеты документов и формировать результаты для дальнейшей передачи на портал через СМЭВ.
Итак, СМЭВ, как в поговорке про слова в песне, нельзя исключить из решения задачи интеграции с порталом государственных услуг. Но это к лучшему: благодаря системе у всех участников есть универсальная среда взаимодействия. Это позволяет опираться на определённый стандарт и не изобретать велосипед.
В следующих статьях мы рассмотрим, как на стороне поставщика сведений организовать обработку заявлений по данным пользователя с использованием движка автоматизации бизнес-процессов Workflow Core.