5.2.2. Структура сообщения-запроса (от ИС инициатора в СМЭВ)

5.2.2.1. Простые протоколы обмена

Структура сообщения, передаваемого в СМЭВ от ИС отправителя к ИС получателя в случае простых протоколов обмена, приведена на рисунке 20.

Рисунок 20 - Структура сообщения с запросом сведений, которое ИС отправителя передаёт в СМЭВ

Элементы XML-структуры на рисунке изображены в виде прямоугольников со скруглёнными (за исключением СМЭВ-конверта) краями, с привязкой к элементам (имена соответствующих элементов XML-структуры приведены в верхнем левом углу прямоугольников). Обязательные элементы изображены непрерывной линией, а необязательные – пунктирной. Если элемент подписывается ЭП, то в его состав должен быть добавлен атрибут с наименованием «Id».

СМЭВ-конверт с запросом сведений по простому протоколу обмена (//SendRequestRequest), направляемый ИС отправителя в СМЭВ (для последующей передачи запроса из СМЭВ в ИС получателя), включает следующие элементы:

5.2.2.1.1. Блок данных запроса

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

• идентификатор сообщения (//MessageID), обязательный элемент, идентификатор сообщения в виде UUID, основанного на времени, сгенерированный отправителем. UUID необходимо генерировать по версии 1 (см. п. 4.2 «Algorithms for Creating a Time-Based UUID» RFC 4122 https://datatracker.ietf.org/doc/html/rfc4122#section-4.2). СМЭВ использует метку времени, содержащуюся в UUID, для проверки срока годности сообщения, к которому относится данный UUID. Для СМЭВ срок годности одного сообщения составляет 24 часа;
• идентификатор первичного сообщения (//ReferenceMessageID), опциональный элемент, указывающий на первичный MessageID в цепочке запросов одной бизнес-транзакции. При отправке первичного запроса ReferenceMessageID и MessageID совпадают.
• код транзакции (//TransactionCode), опциональный элемент, указывающий на транзакцию оказания государственной услуги или выполнения государственной функции, в рамках которой посылается запрос. Если в транзакции запрос является первым, то данный элемент следует заполнять значением, полученным в СГКТ. Если в транзакции запрос является промежуточным, то данный элемент следует заполнять значением, полученным в запросе, на основании которого посылается данный запрос. Правила получения и использования кода транзакции приведены в разделе 10;
• время жизни запроса (//EOL), опциональный элемент, определяющий время, до истечения которого запрос является для системы-инициатора актуальным;
• блок структурированных сведений в соответствии требованиям Владельца сведений (//MessagePrimaryContent), обязательный элемент, представляющий собой XML документ, заполненный по формату, разработанному Владельцем сведений. Ответчик, для которого предназначен запрос, определяется в СМЭВ по полному имени корневого элемента в этом блоке (//Request). Этот блок не предназначен для передачи вложений, при возникновении такой необходимости следует использовать блоки содержимого вложений, заголовков и ЭП-СП вложений;
• электронная подпись должностного лица (далее - ЭП-СП) (//PersonalSignature). Подпись ЭП-СП является не обязательной и может отсутствовать. С помощью ЭП-СП подписывается элемент, находящийся в //MessagePrimaryContent (между открывающим и закрывающим тегами), содержащий атрибут Id
• блок заголовков и ЭП-СП вложений, передаваемых посредством ФХ (//RefAttachmentHeaderList), который содержит идентификаторы вложений, хэш коды вложений, MIME-типы вложений, а также ЭП-СП этих вложений в формате PKCS#7 detached (подробнее о порядке формирования электронных подписей см. раздел 6). Перед отправкой сообщения вложения должны быть загружены в файловое хранилище СМЭВ средствами FTP;
  
• блок заголовков и ЭП-СП вложений, передаваемых MTOM (//AttachmentHeaderList), который содержит ссылки на идентификаторы вложений в блоке содержимого вложений, MIME-типы вложений, а также ЭП-СП этих вложений в формате PKCS#7 detached (подробнее о порядке формирования электронных подписей см. раздел 6);
• блок атрибутов бизнес-процесса (//BusinessProcessMetadata). Состав данных этого блока расширяемый и описывается отдельной XML-схемой urn://x-artefacts-smev-gov-ru/services/message-exchange/business-process-metadata/1.0. В настоящее время в него входят код государственной услуги или государственной функции согласно реестру государственных услуг, признак услуги или функции, код ФРГУ информационной системы-отправителя запроса, а также номер дела, в рамках которого сформирован запрос. Эта информация не требуется для работы СМЭВ и в настоящее время не обязательна для заполнения, однако она может быть полезна для разрешения вопросов участников взаимодействия по взаимодействию с СМЭВ;
• признак тестового взаимодействия (//TestMessage). Если этот элемент присутствует, то это означает, что запрос – тестовый. Данный признак используется для тестирования видов сведений.

Блок данных запроса подписывается ЭП-ОВ.

5.2.2.1.2. Блок содержимого вложений

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

Вложенные файлы и идентификаторы вложений располагаются вне подписанного с помощью ЭП-ОВ блока данных запроса для корректной реализации кодирования вложений с помощью механизма оптимизации передачи сообщений MTOM с обязательным применением технологии XML-binary Optimized Packaging.

Если на стороне отправителя сообщения в отношении вложения, приложенного к сообщению, не будет применена технология XML-binary Optimized Packaging, оптимизация MTOM/XOP в отношении каждого вложения будет выполняться СМЭВ принудительно. При отправке неоптимизированного вложения необходимо исключить заголовки типа multipart, определяющие МТОМ-вложение.

В связи с этим, после оптимизации MTOM/XOP содержимое элемента //Content типа //AttachmentContentType должно представлять собой значение вида:

<xop:include xmlns:xop='http://www.w3.org/2004/08/xop/include' href=“…”/>,

где значение конструкции «href» должно удовлетворять требованиям спецификации XML-binary Optimized Packaging и должно соответствовать фактическому Content-Id вложения бинарного формата.

Значение элемента Content-Id не должно превышать ограничение в 255 символов. В случае несоответствия будет сформирован синхронный ответ с ошибкой «Количество символов в идентификаторе файла вложения превышает допустимое»

Суммарный объем вложенных файлов не должен превышать 5МБ. В противном случае при пересылке файлов необходимо использовать механизм Файлового хранилища (см. раздел 7).

Обращаем внимание, что значение элемента //Id блока содержимого вложений должно заполняться согласно паттерну <xsd:pattern value="[i-[:]][c-[:]]*"/>

<xsd:simpleType name="ID" id="ID"> <xsd:restriction base="xsd:NCName"/> </xsd:simpleType> ...... <xsd:simpleType name="NCName" id="NCName">  <xsd:restriction base="xsd:Name">  <xsd:pattern value="[i-[:]][c-[:]]*"/> </xsd:restriction> </xsd:simpleType>

Кириллица допустима в данном элементе.

5.2.2.1.3. Электронная подпись органа власти

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

5.2.2.2. Директивные протоколы обмена

Структура сообщения, передаваемого в СМЭВ от ИС отправителя к ИС получателя в случае директивных протоколов обмена, приведена на рисунке 21.

Рисунок 21 - Структура сообщения с запросом сведений, которое ИС отправителя передаёт в СМЭВ.

СМЭВ-конверт с запросом сведений по директивному протоколу обмена (//SendRequestRequest), направляемый ИС отправителя сообщения в СМЭВ (для последующей передачи запроса из СМЭВ в ИС получателя сообщения), включает следующие элементы:

• блок данных запроса (//SenderProvidedRequestData), который включает структурированные сведения в соответствии с требованиями Владельца сведений, а также служебные данные, заполняемые системой-инициатором запроса;
• блок содержимого вложений (//AttachmentContentList);
• электронная подпись органа власти (ЭП-ОВ) (//CallerInformationSystemSignature).

5.2.2.2.1. Блок данных запроса

Блок данных сообщения-запроса по директивному протоколу обмена содержит элементы, аналогичные, сообщению-запросу по простому протоколу обмена, за исключением:

• блок структурированных сведений (//MessagePrimaryContent), обязательный элемент, представляющий собой XML документ, содержащий реестр однотипных записей, заполненный по формату, разработанному Владельцем сведений. Получатель сообщения, для которого предназначена запись реестра, определяется в СМЭВ одним из способов:
• по полному имени корневого элемента в этом блоке (//Request);
• по значению элемента, определённому в выражении XPath табличной маршрутизации;
• по информации, размещённой в блоке маршрутной информации (//Routing).
• электронная подпись должностного лица (//PersonalSignature) является не обязательной и может отсутствовать;
• блок заголовков и ЭП-СП вложений, передаваемых посредством ФХ (//RefAttachmentHeaderList) находится в каждой записи реестра (//Record).  Данный элемент (//RefAttachmentHeaderList)  необходимо дополнительно разместить в блоке данных запроса (//SenderProvidedRequestData) после блока структурированных сведений (//MessagePrimaryContent), аналогично простому протоколу обмена (5.2.2.1), и включить в него ссылки на вложения из всех реестровых записей;
• блок заголовков и ЭП-СП вложений, передаваемых MTOM (//AttachmentHeaderList) находится в каждой записи реестра (//Record).  Данный элемент (//AttachmentHeaderList) необходимо дополнительно разместить в блоке данных запроса (//SenderProvidedRequestData) после блока структурированных сведений (//MessagePrimaryContent), аналогично простому протоколу обмена (5.2.2.1), и включить в него ссылки на вложения из всех реестровых записей.

5.2.2.2.1.1. Блок структурированных сведений

Блок структурированных сведений содержит реестр однотипных записей. В каждую запись реестра входит:

• уникальный, в данном сообщении, идентификатор записи реестра (//RecordId). Обязательный элемент;
• блок структурированных сведений в соответствии с требованиями Владельца сведений (//RecordContent), обязательный элемент, представляющий собой XML документ, заполненный по формату, разработанному Владельцем сведений. Этот блок не предназначен для передачи вложений, при возникновении такой необходимости следует использовать блоки содержимого вложений, заголовков и ЭП-СП вложений для каждой записи реестра;
• блок заголовков и ЭП-СП вложений, передаваемых MTOM (//AttachmentHeaderList), который содержит ссылки на идентификаторы вложений в блоке содержимого вложений, MIME-типы вложений, а также ЭП-СП этих вложений в формате PKCS#7 detached;
• блок заголовков и ЭП-СП вложений, передаваемых посредством ФХ (//RefAttachmentHeaderList);
• электронная подпись должностного лица (//PersonalSignature). Блок содержит электронную подпись данных элемента, находящегося в //RecordContent (между открывающим и закрывающим тегами), и содержащего атрибут Id. ЭП-СП может отсутствовать при условии доставки получателю всех записей реестра без изменений и при обязательном наличии ЭП-СП в блоке данных запроса (//SenderProvidedRequestData);
• блок электронной подписи органа власти (//RecordSignature). Блок содержит электронную подпись данных элемента, находящегося в элементе //Record.
  

5.2.2.2.2. Блок маршрутной информации

Блок маршрутной информации (//Routing) –обязательный элемент для протоколов обмена, описанных в пп. 4.6.2.3, пп.4.6.2.4, пп.4.6.3.2, пп.4.6.3.3, на основе содержимого которого определяется получатель каждой записи реестра, размещённой в блоке структурированных сведений (//MessagePrimaryContent).

Блок маршрутной информации в сообщении с запросом сведений, которое система-инициатора передаёт в СМЭВ, приведён на рисунке 22.

Рисунок 22 – Блок маршрутной информации в сообщении с запросом сведений, которое ИС отправителя передаёт в СМЭВ.

Необязательный блок маршрутной информации (//Routing) включает следующие элементы:

• Непосредственно сама маршрутная информация (//RoutingInformation);
• Электронная подпись ЭП-ОВ (//RoutingSignature).

Рисунок 23 – Пример формирования блока RoutingInformation для протокола обмена с реестровой маршрутизацией по мнемоникам.

5.2.2.2.3. Маршрутная информация

Маршрутная информация включает в себя:

• идентификатор сообщения (//MessageID). Обязательный элемент, значение которого равно идентификатору сообщения из элемента //MessageID блока данных запроса;
• блок общей динамической маршрутизации (//DynamicRouting). Используется для протоколов обмена с маршрутизацией, описанной в пп.4.6.2.4, пп.4.6.2.5, содержит перечень мнемоник ИС-получателей сообщений;
• блок маршрутизации по идентификатору (//IdentifierRouting). Используется для протоколов обмена с маршрутизацией, описанной в пп.4.6.3.2, пп.4.6.3.3, содержит перечень идентификаторов. На основе значений идентификатора СМЭВ определяет подписчика и формирует в его адрес сообщение-клон;
• блок маршрутизации записей реестра (//RegistryRouting). Обязательный элемент для протоколов обмена с маршрутизацией, описанной в пп.4.6.2.5, пп.4.6.3.3, содержит маршрутную информацию по каждой записи реестра, которые были указаны в блоке RegistryRecord:
• уникальный идентификатор записи реестра (//RecordId). Для протоколов обмена с маршрутизацией, описанной в пп.4.6.2.5 , пп.4.6.3.3 обязательный элемент, содержит значение, равное значению элемента //RecordId записи реестра;
• признак использования общей маршрутизации для данной записи реестра (//UseGeneralRouting). Обязательный элемент. Определяет какую маршрутную информацию использовать для данной записи реестра. При значении «false» запись реестра будет передана получателям сообщения, указанным в //RegistryRecordRouting/DynamicRouting (или //RegistryRecordRouting/IdentifierRouting). При значении «true» запись реестра будет передана получателям сообщения, указанным в //RegistryRecordRouting/DynamicRouting (или //RegistryRecordRouting/IdentifierRouting), а также в //RoutingInformation/DynamicRouting (или //RoutingInformation/ IdentifierRouting);
• блок динамической маршрутизации (//DynamicRouting). Для протоколов обмена с маршрутизацией, описанной в пп.4.6.2.5  обязательный элемент, содержит перечень мнемоник ИС-получателей данной записи реестра. В адрес каждой ИС-получателя сообщения формируется сообщение-клон, содержащее данную запись реестра
• блок маршрутизации по идентификатору (//IdentifierRouting). Для протоколов обмена с маршрутизацией, описанной в пп.4.6.3.3 обязательный элемент, содержит перечень идентификаторов. На основе значений идентификатора СМЭВ определяет подписчика данной записи реестра и формирует в его адрес сообщение-клон.
  

5.2.2.2.4. Электронная подпись органа власти

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