7.Правила заполнения служебных элементов электронных сообщений в СМЭВ
Унифицированный служебный блок атрибутов сообщения играет ключевую роль в сборе статистики прохождения электронных запросов через СМЭВ и формировании целостных отчетов о межведомственном обмене.
Правила заполнения элементов для идентификации субъектов межведомственного взаимодействия
Элементы smev:Sender, smev:Recipient и smev:Originator используются для передачи сведений о субъектах межведомственного взаимодействия. Для каждого субъекта взаимодействия достаточно передачи его наименования и кода (мнемоники) точки подключения информационной системы.
В случае цепочки обменов между участниками, в структуре smev:Originator всегда указываются сведения о субъекте, инициировавшем цепочку, а не потребителя, отправившего последнее сообщение поставщику.
Участники должны корректно заполнять сведения об инициаторе цепочки сообщений при различных сценариях взаимодействия. Инициатором взаимодействия в рамках оказания государственной услуги в электронном виде выступает ЕПГУ, а в рамках исполнения государственной функции – один из органов исполнительной власти.
Каждый из этих элементов содержит дочерние элементы, описанные ниже:
Код (мнемоника) точки подключения ИС
|
smev:Code
|
Код информационной системы по унифицированному справочнику мнемоник точек подключения информационных систем.
|
Наименование участника
|
smev:NameCode
|
Текстовое наименование участника межведомственного обмена, являющегося владельцем информационной системы.
|
Мнемоники точек подключения информационных систем формируются по следующему шаблону:
XXXXNNRRM,
где XXXX – четырехсимвольная мнемоника участника;
NN – двухзначный номер информационной системы ведомства;
RR – двузначный код региона, к которому относится точка подключения;
M – однозначный номер экземпляра точки подключения в регионе.
|
Например, если у Федеральной миграционной службы России используется 2 информационные системы для взаимодействия через СМЭВ, подключенные к федеральному узлу СМЭВ, то мнемоники точек подключения для них будут:
FMS001001 – первая информационная система (Сервисный концентратор), подключенная к федеральному СМЭВ (00 – соответствует федеральному узлу).
FMS002001 – вторая информационная система (ПАК ГИСМУ Интеграция), подключенная к федеральному СМЭВ.
Для каждой информационной системы требуется использование отдельных сертификатов электронной подписи в независимости от количества точек подключения.
Мнемоника точки подключения предоставляется участнику взаимодействия в процессе регистрации информационной системы.
Правила заполнения элементов для взаимосвязи электронных сообщений
Корректное заполнение элементов smev:OriginRequestIdRef и smev:RequestIdRef, применяемых для взаимосвязи различных электронных сообщений в рамках одного процесса, является основополагающим для формирования целостных отчетов об истории взаимодействий через СМЭВ в рамках одного процесса.
При обработке электронного сообщения, для которого корректно осуществляются проверки в подсистеме регламентации доступа СМЭВ осуществляется добавление перед отправкой поставщику универсального служебного заголовока СМЭВ, содержащего метку времени (smev:TimeStamp), а также идентификатор сообщения (smev:MessageId).
Идентификатор сообщения всегда является GUID унифицированной структуры (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
Для связи различных электронных сообщений между собой участники взаимодействия должны сохранять идентификаторы сообщений в СМЭВ, и использовать их в качестве коррелирующих для отражения взаимосвязи сообщений в рамках процесса информационного обмена.
Правила заполнения элементов smev:OriginRequestIdRef и smev:RequestIdRef описываются ниже для различных сценариев взаимодействия.
7.2.1. Синхронный режим взаимодействия
Синхронный режим взаимодействия описан в разделе 6 данного документа.
При заполнении служебных элементов smev:OriginRequestIdRef и smev:RequestIdRef отправляющая сторона (потребитель) должна выполнять следующие последовательности операций:
Потребитель отправляет через СМЭВ запрос к Поставщику.
В связи с тем, что на этом этапе потребитель не знает идентификатор сообщения в СМЭВ, то унифицированный служебный блок атрибутов запроса не должен содержать элементы smev:OriginRequestIdRef и smev:RequestIdRef.
СМЭВ, получив запрос и убедившись в корректности значений подписи и валидности сертификата ключа ЭП отправителя, устанавливает свою подпись и добавляет в заголовок электронного сообщения (в soap:Header) универсальный служебный заголовок, содержащий элемент smev:MessageId, содержащий идентификатор сообщения в СМЭВ.
Далее СМЭВ передает сообщение Поставщику.
Поставщик производит обработку сообщения-запроса и подготовку сообщения-ответа.
При этом поставщик указывает значение элемента smev:MessageId электронного сообщения-запроса в smev:OriginRequestIdRef и smev:RequestIdRef электронного сообщения-ответа.
СМЭВ осуществляет проверку подписи поставщика в электронном сообщении-ответе, после чего добавляет в него универсальный служебный заголовок СМЭВ, содержащий элемент smev:MessageId с идентификатором сообщения-ответа.
Потребитель сохраняет у себя номер электронного сообщения-запроса и электронного сообщения-ответа: номер сообщения-запроса из элемента smev:RequestIdRef и номер сообщения-ответа из элемента smev:MessageId.
Сохранение значений smev:RequestIdRef и smev:OriginRequestIdRef на стороне потребителя необходимо для возможности разбора конфликтных ситуаций с использованием номера сообщения СМЭВ.
Таким образом, потребитель:
При синхронном взаимодействии не должен заполнять элементы smev:OriginRequestIdRef и smev:RequestIdRef в своих запросах;
Должен сохранять номера сообщений СМЭВ сообщения-запроса и сообщения-ответа на основании сведений из ответа от поставщика в рамках сессии взаимодействия.
Таким образом, поставщик:
При синхронном взаимодействии должен записать в элемент smev:RequestIdRef и smev:OriginRequestIdRef ответа значение элемента smev:MessageId сообщения-запроса;
Должен сохранить на своей стороне номер сообщения запроса к нему;
Не может сохранить номер сообщения ответа от себя, этот номер будет известен только потребителю, которому будет доставлен ответ через СМЭВ.
Примерная диаграмма заполнения служебных элементов для синхронного взаимодействия представлена на рисунке ниже:
Рисунок 5 - Заполнение служебных элементов при синхронном взаимодействии
Первый блок отражает заполнение полей при формировании электронного сообщения на стороне Потребителя и обработке сообщения при прохождении через СМЭВ.
Второй блок отражает заполнение полей при формировании ответа на стороне Поставщика и обработке сообщения при его прохождении через СМЭВ.
Асинхронный режим взаимодействия
Под асинхронным взаимодействием подразумевается многоэтапный (более, чем одна пара запрос-ответ) обмен электронными сообщениями через СМЭВ.
Потребитель отправляет через СМЭВ запрос к Поставщику.
Унифицированный служебный блок атрибутов запроса не должен содержать элементы smev:OriginRequestIdRef и smev:RequestIdRef.
СМЭВ, получив запрос и убедившись в валидности подписи, устанавливает свою подпись и добавляет в сообщение (в soapenv:Header) универсальный служебный заголовок, содержащий элемент smev:MessageId сообщения запроса.
Далее СМЭВ передает сообщение Поставщику.
Поставщик записывает значение элемента smev:MessageId первого запроса в элементы smev:RequestIdRef и smev:OriginRequestIdRef..
Далее поставщик передает сообщение-квитанцию, свидетельствующую о начале асинхронной обработки, в СМЭВ. Формат сообщения-квитанции определяется в соответствии с требованиями поставщика сервиса.
СМЭВ, получив ответ-квитанцию и убедившись в валидности подписи, устанавливает свою подпись и добавляет в сообщение (в soapenv:Header) универсальный служебный заголовок, содержащий элемент smev:MessageId (идентификатор сообщения-квитанции).
Далее СМЭВ отправляет сообщение-квитанцию Потребителю.
Потребитель получает ответ в виде сообщения-квитанции.
Через определенное регламентом взаимодействия время потребитель осуществляет запрос на получение статуса/результата (или повторные запросы) через СМЭВ к сервису поставщика.
При отправлении запроса на получениея/ статуса/ результата потребитель должен указать значения элемента smev:OriginRequestIdRef, соответствующее номеру запроса, инициировавшему цепочку асинхронного взаимодействия (смотри шаг 2).
При отправлении запроса на получение статуса/результата потребитель должен указать значения элемента smev: RequestIdRef, соответствующее номеру запроса, инициировавшему последний сеанс в рамках асинхронного взаимодействия (смотри шаг 2).
В случае, если асинхронное взаимодействие предусматривает обмен более, чем между двумя участниками, то потребитель должен сохранять неизменный smev:OriginRequestIdRef, но при заполнении smev:RequestIdRef – указывать номер сообщения-запроса, квиток на который он ранее получил от поставщика.
Примерная диаграмма заполнения служебных элементов для асинхронного взаимодействия, реализуемого в виде нескольких синхронных вызовов, представлена на рисунке ниже:
Рисунок 6 - Заполнение служебных элементов при асинхронном взаимодействии (межведомственное взаимодействие)
1 - первый запрос к Поставщику в рамках асинхронного взаимодействия (подача заявления). Поставщик его принимает, отвечая сообщением со статусом ACCEPT
2 - второй запрос к Поставщику для получения результата. Поставщик передает результат - отвечает сообщением со статусом RESULT.
При асинхронном взаимодействии с ЕПГУ реализуется схема, при которой Поставщик возвращает результат Потребителю самостоятельно:
Рисунок 7 - Заполнение служебных элементов при асинхронном взаимодействии (подача заявлений с ЕПГУ)
1 - первый запрос к Поставщику в рамках асинхронного взаимодействия (подача заявления). Поставщик его принимает, отвечая сообщением со статусом ACCEPT.
2 - Поставщик возвращает Потребителю результат (сообщение со статусом RESULT). Потребитель принимает результат - отвечает сообщением со статусом ACCEPT.
|
