3.Требования к структуре сообщений 3.1.Общие положения
Электронные сообщения в системе межведомственного электронного взаимодействия передаются в формате XML в кодировке UTF-8 с указанием кодировки в заголовке сообщения. Соответствующие им WSDL и XSD файлы также должны использовать кодировку UTF-8 с указанием кодировки в заголовке сообщения.
ИС участников взаимодействия в теле электронных сообщений должны поддерживать применение блоков и элементов данных, а также электронных подписей, описанных в данном документе. Использование других блоков и элементов, отличных от описанных в данном документе, не допускается.
Для именования пространств имен элементов в сообщениях зарезервированы два источника со схемой URN (базовые URI):
urn://x-artefacts-smev-gov-ru/;
urn://smev-gov-ru/.
Процесс отправки ИС потребителя запроса и получения ответа на запрос от ИС поставщика представляет собой последовательность вызовов единого электронного сервиса СМЭВ информационными системами потребителя и поставщика:
передача в СМЭВ запроса из ИС потребителя (//SendRequestRequest);
получение из СМЭВ запроса в ИС поставщика (//GetRequestResponse);
подтверждение поставщиком получения запроса из СМЭВ (//AckRequest);
передача в СМЭВ ответа из ИС поставщика (//SendResponseRequest);
получение из СМЭВ ответа в ИС потребителя (//GetResponseResponse)
подтверждение потребителем получения ответа из СМЭВ (//AckRequest).
Перечисленные в скобках элементы являются, по своему назначению, конвертами сообщений (далее – СМЭВ-конверты), так как представляют собой «оболочку» для передачи сообщений в СМЭВ, включающих блоки и элементы служебных и бизнес данных, а также электронные подписи.
Наименования перечисленных элементов образуются из слов Send/Get и Request/Response, соответствующих назначению элемента. Первый слог в имени элемента образуется словом «Send» или «Get», которое соответствует выполняемому действию с точки зрения ИС участника взаимодействия. Например, с точки зрения потребителя, он посылает (Send) запрос, а с точки зрения поставщика, он получает (Get) этот же запрос. Второй слог образуется словом «Request» или «Response» и определяет назначение сообщения с точки зрения бизнес-логики: слово «Request» означает запрос от потребителя к поставщику, а слово «Response» означает ответ от поставщика к потребителю. Третий слог образуется также словом «Request» или «Response», но несет другой смысл: слово «Request» соответствует SOAP-запросу, а слово «Response» SOAP-ответу.
Элемент AckRequest (от acknowledgement request) является запросом на подтверждение и содержит ссылку на сообщение (идентификатор сообщения), получение которого подтверждается методом Ack.
3.2.Структура сообщения с запросом сведений, которое ИС потребителя передает в СМЭВ
Структура сообщения, соответствующая передаче в СМЭВ запроса от ИС потребителя к ИС поставщика, приведена на рисунке ниже (Рисунок ).
Рисунок – Структура сообщения с запросом сведений, которое ИС потребителя передает в СМЭВ
Элементы XML-структуры на рисунке изображены в виде прямоугольников со скругленными (за исключением СМЭВ-конверта) краями, с привязкой к элементам (имена соответствующих элементов XML-структуры приведены в верхнем левом углу прямоугольников). Обязательные элементы изображены непрерывной линией, а необязательные – пунктирной. Элементы, соответствующие СМЭВ-конвертам, имеют в верхних правых углах изображения конвертов, а также дополнительно выделены темно-зеленой утолщенной линией и заливкой.
СМЭВ-конверт с запросом сведений (//SendRequestRequest), направляемый ИС потребителя в СМЭВ (для последующей передачи запроса из СМЭВ в ИС поставщика), включает элементы:
блок данных запроса (//SenderProvidedRequestData), который включает структурированные сведения в соответствии с требованиями поставщика, а также служебные данные, заполняемые потребителем сведений;
блок содержимого вложений (//AttachmentContentList);
электронная подпись органа власти (ЭП-ОВ) (//CallerInformationSystemSignature).
3.2.1Блок данных запроса
Блок данных запроса может включать от одного до шести элементов, которые заполняются в ИС потребителя:
идентификатор сообщения (//MessageID), обязательный элемент, идентификатор сообщения в виде UUID, основанного на времени, сгенерированный отправителем. UUID необходимо генерировать по версии 1 (см. п. 4.2 «Algorithms for Creating a Time-Based UUID» RFC 4122 http://rfc.askapache.com/rfc4122/rfc4122.html#section-4.2). СМЭВ использует метку времени, содержащуюся в UUID, для проверки срока годности сообщения, к которому относится данный UUID. Для СМЭВ срок годности одного сообщения составляет 24 часа;
идентификатор первичного сообщения (//ReferenceMessageID), обязательный элемент, указывающий на первичный MessageID в цепочке запросов одной бизнес-транзакции. При отправке первичного запроса ReferenceMessageID и MessageID совпадают.
блок структурированных сведений в соответствии с требованиями поставщика (//MessagePrimaryContent), обязательный элемент, представляющий собой XML документ, заполненный по формату, разработанному поставщиком сведений. Поставщик, для которого предназначен запрос, определяется в СМЭВ по полному имени корневого элемента в этом блоке. Этот блок не предназначен для передачи вложений, при возникновении такой необходимости следует использовать блоки содержимого вложений, заголовков и ЭП-СП вложений;
электронная подпись должностного лица (далее - ЭП-СП), (//PersonalSignature). По требованиям поставщика сведений эта подпись может быть обязательной для подписи блока сведений по форматам поставщика. С помощью ЭП-СП подписывается элемент, находящийся в //MessagePrimaryContent (между открывающим и закрывающим тегами);
блок заголовков и ЭП-СП вложений (//AttachmentHeaderList), который содержит ссылки на идентификаторы вложений в блоке содержимого вложений, MIME-типы вложений, а также ЭП-СП этих вложений в формате PKCS#7 detached (подробнее о порядке формирования электронных подписей см. раздел 4. «Электронные подписи»);
блок атрибутов бизнес-процесса (//BusinessProcessMetadata). Состав данных этого блока – расширяемый, и описывается отдельной XML-схемой urn://x-artefacts-smev-gov-ru/services/message-exchange/business-process-metadata/1.0. В настоящее время в него входят код государственной услуги или государственной функции согласно реестру государственных услуг, признак услуги или функции, код ФРГУ информационной системы-отравителя запроса, а также номер дела, в рамках которых сформирован запрос. Эта информация не требуется для работы СМЭВ и в настоящее время не обязательна для заполнения, однако она может полезна для разрешения вопросов участников взаимодействия по взаимодействию с СМЭВ;
признак тестового взаимодействия //TestMessage. Если этот элемент присутствует, то это означает, что запрос – тестовый. Данный признак используется только в тестовом и разработческом контурах СМЭВ. Запросы с данным признаком маршрутизируются в Эмулятор СМЭВ.
Блок данных запроса подписывается ЭП-ОВ.
3.2.2Блок содержимого вложений
Блок содержимого вложений может быть добавлен, если потребителю необходимо передать в ИС поставщика информацию (в том числе неструктурированную), которая не входит в блок структурированных сведений в соответствии с требованиями поставщика. Вложенные файлы и идентификаторы вложений располагаются вне подписанного с помощью ЭП-ОВ блока данных запроса для корректной реализации кодирования вложений с помощью механизма оптимизации передачи сообщений MTOM.
Суммарный объем вложенных файлов не должен превышать 5Мб. В противном случае при пересылке файлов необходимо использовать механизм Файлового хранилища.
3.2.3Электронная подпись органа власти
Электронная подпись ЭП-ОВ, формируемая от имени органа власти, участвующего в межведомственном взаимодействии и выступающего в роли потребителя сведений, подписывает блок данных запроса. С помощью ЭП-ОВ обеспечивается целостность запроса и идентификация ИС отправителя.
|
