Методические рекомендации по работе с единой системой межведомственного электронного взаимодействия версия 3.5.0.0 (стр. 12 )

Электронная подпись СМЭВ

Структура ЭП-СМЭВ (//SMEVSignature) аналогична одноименному элементу в //RequestMessage запроса (см. п. 3.3.3).

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

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

Структура сообщения, соответствующего передаче в СМЭВ ответа от ИС отправителя, приведена на рисунке ниже (рисунок 25).

Рисунок 25 – Общая структура сообщения с ответом, которое ИС потребителя получает из СМЭВ (без указания элементов RequestRejected, RequestStatus или AsyncProcessingStatus)

Структура сообщения аналогичная простому протоколу обмена и включает в себя

блок данных СМЭВ-конверта (//Response); блок содержимого вложений, передаваемых MTOM (//AttachmentContentList); электронная подпись СМЭВ (//SMEVSignature).

Блок данных СМЭВ-конверта

Блок данных СМЭВ-конверта (//Response) аналогичен простому протоколу обмена, за исключением:

блок данных ответа //SenderProvidedResponseData, сформированный отправителем ответа (см. п. 3.4.1) не содержит блоков заголовков и ЭП-СП вложений, передаваемых посредством ФХ или МТОМ. Они располагаются в записях реестра; электронную подпись должностного лица (//PersonalSignature) допускается не указывать, при обязательном наличии ЭП-СП в каждой записи реестра.

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

Структура блока содержимого вложений, передаваемых MTOM //AttachmentContentList, аналогична одноименному элементу в сообщении с ответом, направленном из ИС отправителя ответа в СМЭВ (см. п.3.4.2).

Электронная подпись СМЭВ

Структура ЭП-СМЭВ (//SMEVSignature) аналогична одноименному элементу в //RequestMessage запроса (см. п. 3.3.3).

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

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

При получении из СМЭВ SOAP-ответа, ИС потребителя проверяет в СМЭВ-конверте наличие элемента //ResponseMessage (присутствует, если очередь ответов не пуста). Элемент //ResponseMessage включает два элемента (рисунок 26):

блок данных СМЭВ-конверта (//Response); электронная подпись СМЭВ (//SMEVSignature).

Рисунок 26 – Общая структура сообщения с блоком AsyncProcessingStatus, которое ИС потребителя получает из СМЭВ

Блок данных СМЭВ-конверта

Блок данных СМЭВ-конверта //Response содержит элементы:

идентификатор запроса (//OriginalMessageId), заполняемый СМЭВ значением идентификатора запроса, на который высылается ответ; код транзакции (//OriginalTransactionCode), заполняемый СМЭВ значением кода транзакции, в рамках которой высылается ответ; идентификатор первичного запроса (//ReferenceMessageID), заполняемый СМЭВ значение идентификатора запроса, являющегося источником цепочки запросов. Если в целочке запросов всего один запрос, то этот элемент заполняется значением элемента //OriginalMessageId; блок данных ответа //SenderProvidedResponseData, сформированный отправителем ответа; блок маршрутной информации СМЭВ (//MessageMetaData) с метаданными (раздел 5.2.5).

Блок данных ответа включает три элемента, которые заполняются в СМЭВ:

идентификатор сообщения (//MessageID), обязательный элемент, идентификатор сообщения в виде UUID, основанного на времени, сгенерированный отправителем. UUID необходимо генерировать по версии 1 (см. п. 4.2 «Algorithms for Creating a Time-Based UUID» RFC 4122 http://rfc. /rfc4122/rfc4122.html#section-4.2); адрес доставки ответа (//To), обязательный элемент, в который копируется содержимое элемента //GetRequestResponse/RequestMessage/ Request/ReplyTo запроса, на который отправляется ответ; блок данных статуса сообщения (//AsyncProcessingStatus) содержит элементы:
идентификатор сообщения (//OriginalMessageId), сформированный отправителем сообщения; категория статуса (//StatusCategory), содержащий одно из следующих возможных значений:
requestIsQueued (Сообщение находится в очереди асинхронной обработки / Сообщение помещено в очередь получателя (запрос или ответ)); requestIsRejectedBySmev (Сообщение не прошло асинхронную обработку); messageIsArchived (Сообщение, получение которого не подтверждено получателем, переведено в архив); messageIsDelivered (Сообщение получено получателем, т. е. получение сообщения подтверждено получателем).
уведомление об описании статуса сообщения (//StatusDetails), содержащий описание статуса сообщения; элемент типа //SmevFault, содержащий в себе элемент //Code, определяющий код ошибки, и элемент //Description, содержащий описание ошибки.

Электронная подпись СМЭВ

Структура ЭП-СМЭВ //SMEVSignature аналогична одноименному элементу в //RequestMessage запроса (раздел 5.2.3).

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

Структура сообщения с вложением

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

Использование вложений включает в себя два этапа:

описание форматов вложений, которые предполагается передавать; непосредственная передача вложений.

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

Непосредственная передача вложений осуществляется путем заполнения блоков:

Блок заголовков и ЭП-СП вложений, передаваемых посредством ФХ (//RefAttachmentHeaderList); Блок заголовков и ЭП-СП вложений, передаваемых МТОМ (//AttachmentHeaderList); Блок содержимого вложений, передаваемых МТОМ (//AttachmentContentList).

При использовании простого протокола обмена заголовки и ЭП-СП вложений могут располагаться только в блоке данных запроса (/SenderProvidedRequestData).

При использовании директивного протокола обмена заголовки и ЭП-СП вложений могут располагаться только в записях реестра (/Registry/RegistryRecord/Record).

Расположение содержимого вложений не зависит от используемого протокола обмена.

Блок заголовков и ЭП-СП вложений, передаваемых посредством файлового хранилища

Структура блока заголовков и ЭП-СП приведена на рисунке 27.

Рисунок 27 – Структура блока заголовков и ЭП-СП, передаваемых посредством ФХ

Блок заголовков и ЭП-СП включает следующие элементы:

Ссылка на директорию (//uuid), расположенную в ФХ, содержащую размещённый в ней передаваемый файл. Обязательный элемент; Имя файла (//FileName), находящегося в директории. Необязательный элемент; Идентификатор паспорта передаваемого вложения (//NamespaceUri). Для простых протоколов обмена - необязательный элемент. Для директивных протоколов обмена - обязательный; Хэш передаваемого файла (//Hash). Обязательный элемент; Тип передаваемого файла (//MimeType). Обязательный элемент. Тип вложения определяется согласно RFC 2045, RFC 2046, RFC 4288, RFC 4289 и RFC 4855; Отсоединённая ЭЦП передаваемого файла в формате PKCS#7 (//SignaturePKCS7). Необязательный элемент; Блок, содержащий перечень файлов в архиве (//Archive). Для простых протоколов обмена - необязательный элемент. Для директивных - обязательный, если передаётся архив. В состав информации по каждому файлу входит наименование файла (//Name) и идентификатор паспорта этого файла (//NamespaceUri).

Пример использования:

<RefAttachmentHeaderList>        <RefAttachmentHeader>                <uuid>04a5bc90-5e81-11e4-a9ff-d4c9eff07b77</uuid>                <NamespaceUri>urn://x-artefacts-data-provider/protex/attachments/archive/1.0.0</NamespaceUri>                <Hash>VpT3sc999CJI8TVYX35ZZfXpc/dCWO5e1MgoUg8YiJA=</Hash>                <MimeType>application/zip</MimeType>                <SignaturePKCS7>                        <xop:Include href="cid:*****@***" xmlns:xop="http://www. w3.org/2004/08/xop/include"/>                </SignaturePKCS7>                <Archive>                        <File>                                <Name>attach. jpg</Name>                                <NamespaceUri>urn://x-artefacts-data-provider/protex/attachments/jpg/1.0.0</NamespaceUri>                        </File>                        <File>                                <Name>increment. xml</Name>                                <NamespaceUri>urn://x-artefacts-data-provider/protex/attachments/increment/1.0.0</NamespaceUri>                        </File>                </Archive>        </RefAttachmentHeader> </RefAttachmentHeaderList>

Блок заголовков и ЭП-СП вложений, передаваемых МТОМ

Структура блока заголовков и ЭП-СП приведена на рисунке.