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

...

<xs:element name="Request">

<xs:annotation>

<xs:documentation>Запрос. Реестровый тип данных (для директивных ВВС)</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element ref="directive:Registry"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Response">

<xs:annotation>

<xs:documentation>Ответ. Реестровый тип данных (для директивных ВВС)</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element ref="directive:Registry"/>

</xs:sequence>

</xs:complexType>

</xs:element>

...

СМЭВ-вложения

Каждое СМЭВ-вложение описывается паспортом – перечнем параметров (метаданные) и комплектом взаимосвязанных схем, описывающих структурированное вложение. Паспорт формируется на этапе проектирования ФПД.

Метаданные паспорта вложения:

Уникальный идентификатор; Наименование; Тип вложения; Признак архива; Способ передачи вложения через СМЭВ; Планируемый размер вложения; Признак структурированного вложения.

Идентификатор вложения должен быть глобально уникальным. Для обеспечения уникальности в качестве идентификатора следует использовать target namespace, формируемый по описанному ранее правилу.

Тип вложения определяется согласно RFC 2045, RFC 2046, RFC 4288, RFC 4289 и RFC 4855.

Если необходимо передавать несколько отдельных файлов в одном архиве, то в паспорте вложения необходимо установить признак архива. При этом, для каждого файла в архиве требуется свой персональный паспорт.

Способ передачи вложения через СМЭВ выбирается из: МТОМ или с использованием Файлового хранилища.

При выборе способа передачи с использованием Файлового хранилища необходимо определить допустимый диапазон размеров: менее 5Мб, от 1 до 5 Мб, От 5 до 10 Мб, более 10Мб.

Если вложения является структурируемым, следует установить признак структурированного вложения и сформировать схему вложения. К схеме структурированного вложения предъявляются те же требования, что и к СМЭВ-заголовкам, приведённые в документе «Требования к XML-схемам, регистрируемым в СМЭВ». В качестве target namespace следует использовать значение идентификатора паспорта вложения.

Каждое вложение регистрируется в связке с сообщением-запрос или сообщением-ответ сообщения типа Запрос-ответ, или с сообщением-рассылка при типе - Рассылка.

Материалы для аттестации

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

Простые форматы передаваемых данных:
Запрос-ответ:
Тестирование возможности отправлять сообщения-запросы; Тестирование возможности отправлять сообщения-ответы.
Рассылка:
Тестирование возможности отправлять сообщения-рассылки.
Директивные форматы передаваемых данных:
Запрос-ответ:
Тестирование возможности отправлять сообщения-запросы; Тестирование возможности отправлять сообщения-ответы.
Рассылка:
Тестирование возможности отправлять сообщения-рассылки.

Материалы для проведения тестирования возможности отправлять сообщения-запросы

Для обеспечения автоматизированного тестирования возможности ИС отправлять сообщения-запросы необходимо подготовить следующие материалы для сценария тестирования:

Наименование сценария; XPath-выражение идентификатора варианта запроса. В XPath-выражениях контрольных примеров одного сценария названия одного элемента должно встречаться не более одного раза; Псевдоним пространства имён тестового сценария; XSLT преобразование для эмуляции ответа; Список контрольных примеров:
Наименование контрольного примера; XPath-выражение - условие контрольного примера.

Материалы для проведения тестирования возможности отправлять сообщения-ответы

Для обеспечения автоматизированного тестирования возможности ИС отправлять сообщения-ответы необходимо подготовить следующие материалы:

Тестовые эталонные запросы; Тестовые эталонные ответы.

Материалы для проведения тестирования возможности отправлять сообщения-рассылки

Для обеспечения автоматизированного тестирования возможности ИС отправлять сообщения-рассылки необходимо подготовить следующие материалы для сценария тестирования:

Наименование сценария; XPath-выражение идентификатора варианта рассылки. В XPath-выражениях контрольных примеров одного сценария названия одного элемента должно встречаться не более одного раза; Псевдоним пространства имён тестового сценария; Список контрольных примеров:
Наименование контрольного примера; XPath-выражение - условие контрольного примера.

Использование СМЭВ. КТДА для проектирования протокола обмена и отладки взаимодействия по протоколу

Для автоматизации разработки протоколов обмена рекомендуется воспользоваться СМЭВ. КТДА.

СМЭВ. КТДА предназначен для упрощения проектирования межведомственного электронного взаимодействия за счет автоматизации процедур формирования, согласования, поиска и использования документов КТДА, типов данных атрибутов, протоколов обмена, используемых при межведомственном взаимодействии, а также для помощи в отладке взаимодействия в РСМЭВ.

СМЭВ. КТДА позволяет:

Описывать модели данных сущностей, участвующих в межведомственном взаимодействии:
Создавать атрибуты сущностей; Определять типы значений атрибутов сущностей.
Управлять перечнем ИС, принадлежащих УВ:
Регистрировать ИС в РСМЭВ; Регистрировать сертификаты ИС в РСМЭВ, ТСМЭВ и ПСМЭВ.
Проектировать протоколы обмена:
Управлять версиями протоколов обмена:
Проектировать ФПД запросов, ответов и рассылок; Проектировать паспорта вложений;
Подготавливать материалы для аттестации:
Управлять тестовыми эталонными запросами, ответами и рассылками; Управлять тестовыми сценариями.
Управлять правами доступа ИС к протоколу;
Получать логи тестовых взаимодействий через РСМЭВ; Управлять подписками на широковещательные рассылки по идентификаторам.

Описание функционала представлено в руководстве пользователя СМЭВ. КТДА.

Единый сервис СМЭВ Общие положения

Электронные сообщения в системе межведомственного электронного взаимодействия передаются в формате XML в кодировке UTF-8 с указанием кодировки в заголовке сообщения. Соответствующие им WSDL и XSD файлы также должны использовать кодировку UTF-8 с указанием кодировки в заголовке сообщения.

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

ИС участников взаимодействия в теле электронных сообщений должны поддерживать применение блоков и элементов данных, а также электронных подписей, описанных в данном документе. Использование других блоков и элементов, отличных от описанных в данном документе, не допускается.

Для именования пространств имен элементов в сообщениях зарезервированы два источника со схемой URN (базовые URI):

urn://x-artefacts-smev-gov-ru/; urn://smev-gov-ru/.

Процесс отправки ИС потребителя запроса и получения ответа на запрос от ИС поставщика представляет собой последовательность вызовов единого электронного сервиса СМЭВ информационными системами потребителя и поставщика:

передача в СМЭВ запроса из ИС потребителя (//SendRequestRequest); получение из СМЭВ запроса в ИС поставщика (//GetRequestResponse); подтверждение поставщиком получения запроса из СМЭВ (//AckRequest); передача в СМЭВ ответа из ИС поставщика (//SendResponseRequest); получение из СМЭВ ответа либо ответа со статусом в ИС потребителя (//GetResponseResponse) подтверждение потребителем получения ответа из СМЭВ (//AckRequest).

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

Метод Get реализован в соответствии со стандартом http://www. w3.org/TR/2005/REC-soap12-mtom-20050125/.

Наименования перечисленных элементов образуются из слов Send/Get и Request/Response, соответствующих назначению элемента. Первый слог в имени элемента образуется словом «Send» или «Get», которое соответствует выполняемому действию с точки зрения ИС участника взаимодействия. Например, с точки зрения потребителя, он посылает (Send) запрос, а с точки зрения поставщика, он получает (Get) этот же запрос. Второй слог образуется словом «Request» или «Response» и определяет назначение сообщения с точки зрения бизнес-логики: слово «Request» означает запрос от потребителя к поставщику, а слово «Response» означает ответ от поставщика к потребителю. Третий слог образуется также словом «Request» или «Response», но несет другой смысл: слово «Request» соответствует SOAP-запросу, а слово «Response» SOAP-ответу.

Элемент AckRequest (от acknowledgement request) является запросом на подтверждение и содержит ссылку на сообщение (идентификатор сообщения), получение которого подтверждается методом Ack.

Внимание! Метод получения статистики входящих очередей //GetIncomingQueueStatistics исключен из состава методов единого электронного сервиса версии 1.2. Данный метод заменен push-нотификациями (раздел 11).

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

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

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

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