Новости 
База знаний 
Документация 
Форум 
ЛК УВ 
Назад
5.2.7.Структура сообщения с вложением
Сведения могут передаваться как в теле сообщения, так и во вложении. Для передачи неструктурированной информации (файлы бинарного формата) могут использоваться механизм МТОМ и файловое хранилище СМЭВ (раздел 7).
Непосредственная передача вложений осуществляется путём заполнения блоков:
- Блок заголовков и ЭП-СП вложений, передаваемых посредством ФХ (//RefAttachmentHeaderList);
- Блок заголовков и ЭП-СП вложений, передаваемых МТОМ (//AttachmentHeaderList);
- Блок содержимого вложений, передаваемых МТОМ (//AttachmentContentList).
При использовании простого протокола обмена заголовки и ЭП-СП вложений могут располагаться только в блоке данных запроса (/SenderProvidedRequestData).
При использовании директивного протокола обмена заголовки и ЭП-СП вложений могут располагаться только в записях реестра (/Registry/RegistryRecord/Record).
Расположение непосредственно содержимого вложений не зависит от используемого протокола обмена.
5.2.7.1. Блок заголовков и ЭП-СП вложений, передаваемых посредством файлового хранилища
Структура блока заголовков и ЭП-СП приведена на рисунке 32.
Рисунок 32 – Структура блока заголовков и ЭП-СП, передаваемых посредством ФХ.
Количество передаваемых вложений в сообщении ограничено. В случае превышения допустимого количества передаваемых вложений на стороне отправтеля сообщения будет получено синхронное уведомление с текстом «SMEV-200:Количество ФТП-вложений превышает допустимое». Целевой лимит количества вложений указан в синхронном ответе в блоке PermittedTotalAttachmentSize. На текущий момент допустимый лимит – 150 вложений.
Блок заголовков и ЭП-СП включает следующие элементы:
- Ссылка на директорию (//uuid), расположенную в ФХ, содержащую размещённый в ней передаваемый файл. Обязательный элемент;
- Имя файла (//FileName), находящегося в упомянутой выше директории. Необязательный элемент;
- Хэш передаваемого файла (//Hash). Обязательный элемент;
- Тип передаваемого файла (//MimeType). Обязательный элемент. Тип вложения определяется согласно RFC 2045, RFC 2046, RFC 4288, RFC 4289 и RFC 4855. По значению, указанному в MimeType, СМЭВ проводит ФЛК вложений.
- Отсоединённая ЭП передаваемого файла в формате PKCS#7 (//SignaturePKCS7). Необязательный элемент.
Пример использования:
|
<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>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</SignaturePKCS7>
</RefAttachmentHeader> </RefAttachmentHeaderList> |
5.2.7.2. Блок заголовков и ЭП-СП вложений, передаваемых МТОМ
Структура блока заголовков и ЭП-СП приведена на рисунке 33.
Рисунок 33 – Структура блока заголовков и ЭП-СП, передаваемых МТОМ.
Блок заголовков и ЭП-СП включает следующие элементы:
|
<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> |
- Тип передаваемого файла (//MimeType). Обязательный элемент. Тип вложения определяется согласно RFC 2045, RFC 2046, RFC 4288, RFC 4289 и RFC 4855. По значению, указанному в MimeType, СМЭВ проводит ФЛК вложений.
- Отсоединённая ЭП передаваемого файла в формате PKCS#7 (//SignaturePKCS7). Необязательный элемент;
Пример использования:
|
<AttachmentHeaderList> <AttachmentHeader> <contentId>attach.zip</contentId> <NamespaceUri>urn://x-artefacts-data-provider/protex/attachments/archive/1.0.0</NamespaceUri> <MimeType>application/zip</MimeType> <SignaturePKCS7>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</SignaturePKCS7>
</AttachmentHeader> </AttachmentHeaderList> |
5.2.7.3. Блок содержимого вложений, передаваемых МТОМ
Структура блока содержимого вложений приведена на рисунке 34.
Рисунок 34 – Структура блока содержимого вложений.
Блок содержимого вложений включает следующие элементы:
Идентификатор вложения (//Id). Обязательный элемент. Должен соответствовать фактическому Id вложения (Content-Id), формируемом при создании файла бинарного формата.
Обращаем внимание, что значение элемента //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> |
- Значение поля ContentId не должно превышать 255 символов. В случае превышения допустимого количества на стороне УВ будет получено синхронное уведомление с текстом: SMEV-206:Количество символов в идентификаторе файла вложения превышает допустимое,
- Содержимое файла (//Content), в формате base64. Обязательный элемент.
После оптимизации MTOM/XOP содержимое элемента //Content типа //AttachmentContentType должно представлять собой значение вида:
<xop:include xmlns:xop='http://www.w3.org/2004/08/xop/include' href=“…”/>,
где значение конструкции «href» должно удовлетворять требованиям спецификации XML-binary Optimized Packaging и должно соответствовать фактическому Content-Id вложения бинарного формата.
Пример использования блока заголовков и ЭП-СП вложений приведён на рисунке 35.
|
<AttachmentContentList> <AttachmentContent> <Id>ile_request.jpg</Id> <Content> <xop:Include href="cid:file_request.jpg" xmlns:xop="http://www.w3.org/2004/08/xop/include"/> </Content> </AttachmentContent> </AttachmentContentList> |
Рисунок 35 – Пример использования блока заголовков и ЭП-СП вложений.
Атрибут <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" вложения.
