Войти
Назад

5.2.4. Структура сообщения-ответа (от ИС ответчика в СМЭВ)

link
Скопировать прямую ссылку на статью

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

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

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

24.jpg

Рисунок 27 – Структура сообщения с ответом, которое ИС отправителя передаёт в СМЭВ (простые протоколы обмена).

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

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

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

5.2.4.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 часа;
  • адрес доставки ответа (//To), обязательный элемент, в который должно быть скопировано содержимое элемента //GetRequestResponse/RequestMessage/ Request/ReplyTo запроса, на который отправляется ответ;
  • блок структурированных сведений в соответствии с требованиями Владельца сведений (//MessagePrimaryContent), обязательный элемент, представляющий собой XML документ, заполненный по формату, разработанному Владельцем сведений. Этот блок не предназначен для передачи вложений, при возникновении такой необходимости следует использовать блоки содержимого вложений, заголовков и ЭП-СП вложений;
  • электронная подпись должностного лица (далее - ЭП-СП), (//PersonalSignature). Подпись ЭП-СП является не обязательной и может отсутствовать. С помощью ЭП-СП подписывается элемент, находящийся в //MessagePrimaryContent (между открывающим и закрывающим тегами), имеющий атрибут Id;
  • блок заголовков и ЭП-СП вложений, передаваемых посредством ФХ (//RefAttachmentHeaderList), который содержит идентификаторы вложений, хэш коды вложений, MIME-типы вложений, а также ЭП-СП этих вложений в формате PKCS#7 detached (подробнее о порядке формирования электронных подписей см. раздел 6). Перед отправкой сообщения вложения должны быть загружены в файловое хранилище СМЭВ средствами FTP;
  • блок заголовков и ЭП-СП вложений, передаваемых MTOM (//AttachmentHeaderList), который содержит ссылки на идентификаторы вложений в блоке содержимого вложений, MIME-типы вложений, а также ЭП-СП этих вложений в формате PKCS#7 detached (подробнее о порядке формирования электронных подписей см. раздел 6).

А также дополнительные (//choice) элементы:

  • Отклонение запроса (//RequestRejected), который может быть использован для информирования ИС отправителя запроса об отклонении его запроса. Содержит код причины отклонения запроса (//RejectionReasonCode) (раздел 8) и описание причины отклонения запроса, в человекочитаемом виде (//RejectionReasonDescription). Заполняется ИС отправителя ответа;
  • Статус запроса (//RequestStatus), который может быть использован для информирования о статусе обработки запроса. Содержит код бизнес-статуса запроса (//StatusCode) и описание бизнес-статуса запроса, в человекочитаемом виде (//StatusDescription). Заполняется ИС отправителем ответа;
  • Статус обработки сообщения (запроса либо ответа на запрос) в СМЭВ (//AsyncProcessingStatus) (раздел 5.2.8.1). Данный элемент предназначен для использования только СМЭВ для информирования ИС о статусе обработки их сообщений в СМЭВ. В то же время данный элемент не предназначен для использования ИС ответчиков для информирования систем-инициаторов о статусах обработки их сообщений. В случае использования системы-ответчика данного элемента в отправляемом ею ответе СМЭВ вернёт данной ИС ошибку.

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

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

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

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

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

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

Атрибут <xs:attribute name="href"> принадлежит типу <type="xs:anyURI">. Атрибут должен быть заполнен согласно спецификации: http://www.faqs.org/rfcs/rfc2392.html (см.: https://www.w3.org/2000/xp/Group/3/06/Attachments/XOP.html#xop_href). Сам тип anyURI (https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#anyURI) должен соответствовать спецификации https://www.ietf.org/rfc/rfc2396.txt. Значения anyURI с URI определяется процедурой экранирования ссылки URI (https://www.w3.org/TR/2001/WD-charmod-20010126/#sec-URIs).

При направлении запроса с оптимизированным МТОМ вложением, в наименовании которого присутствует кириллица, СЭ СМЭВ рекомендует использовать дополнительную URL кодировку для мультипарт заголовка "Content-Id" вложения и в элементе xml запроса "Content". Значение атрибута  href должно соответствовать значению мультипарт заголовка "Content-Id" вложения.

Суммарный объем вложенных файлов вместе с конвертом не должен превышать 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.4.1.3. Электронная подпись органа власти

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

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

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

25.jpg

Рисунок 28 – Структура сообщения с ответом, которое ИС отправителя передаёт в СМЭВ (директивные протоколы обмена).

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

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

5.2.4.2.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 часа;
  • адрес доставки ответа (//To), обязательный элемент, в который должно быть скопировано содержимое элемента //GetRequestResponse/RequestMessage/ Request/ReplyTo запроса, на который отправляется ответ;
  • блок структурированных сведений в соответствии с требованиями Владельца сведений (//MessagePrimaryContent), обязательный элемент, представляющий собой XML документ, содержащий реестр однотипных записей, заполненных по формату, разработанному Владельцем сведений. Этот блок не предназначен для передачи вложений, при возникновении такой необходимости следует использовать блоки содержимого вложений, заголовков и ЭП-СП вложений в каждой записи реестра. В случае, если получатель сообщения получает все записи реестра сообщения без изменений, допускается не указывать ЭП-СП в каждой записи реестра при условии наличия ЭП-СП, наложенной на весь блок структурированных сведений;
  • электронная подпись должностного лица (//PersonalSignature). Подпись ЭП-СП является необязательной и может отсутствовать. С помощью ЭП-СП подписывается элемент, находящийся в //MessagePrimaryContent (между открывающим и закрывающим тегами) и имеющий атрибут Id. Допускается не указывать ЭП-СП, при наличии ЭП-СП в каждой записи реестра.
  • блок заголовков и ЭП-СП вложений, передаваемых посредством ФХ (//RefAttachmentHeaderList). Заполнять элемент необходимо аналогично простому протоколу обмена (5.2.4.1), и включить в него ссылки на вложения из всех реестровых записей.
  • блок заголовков и ЭП-СП вложений, передаваемых MTOM (//AttachmentHeaderList). Заполнять элемент необходимо аналогично простому протоколу обмена (5.2.4.1), и включить в него ссылки на вложения из всех реестровых записей.

Кроме того, блок данных ответа может содержать дополнительные (//choice) элементы:

  • Отклонение запроса (//RequestRejected), который может быть использован для информирования системы-отправителя запроса об отклонении его запроса. Содержит код причины отклонения запроса (//RejectionReasonCode) (раздел 8) и описание причины отклонения запроса, в человекочитаемом виде (//RejectionReasonDescription). Заполняется системой-отправителем ответа;
  • Статус запроса (//RequestStatus), который может быть использован для информирования о статусе обработки запроса. Содержит код бизнес-статуса запроса (//StatusCode) (раздел 8) и описание бизнес-статуса запроса, в человекочитаемом виде (//StatusDescription). Заполняется системой-отправителем ответа;
  • Статус обработки сообщения (запроса либо ответа на запрос) в СМЭВ (//AsyncProcessingStatus) (раздел 5.2.8.1). Данный элемент предназначен для использования только СМЭВ для информирования ИС о статусе обработки их сообщений в СМЭВ. В то же время данный элемент не предназначен для использования системами-ответчиками в целях информирования систем-инициаторов о статусах обработки их сообщений. Если система-ответчик использует данный элемент в отправляемом ею ответе, СМЭВ вернёт данной ИС ошибку

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

Аналогично простому протоколу обмена (5.2.4.1).

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

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

Авторизуйтесь, чтобы оставить комментарий к статье