Новости 
База знаний 
Документация 
Форум 
ЛК УВ 
Назад
Результатом проектирования протокола обмена (вида сведений)
является комплект следующих материалов:
- Руководство пользователя;
- Схемы СМЭВ-документов;
- Материалы для аттестации.
5.1.1. Подготовка руководства пользователя протокола обмена (вида сведений)
Основные настройки протокола обмена:
- Наименование;
- Назначение;
- Содержание;
- Тип маршрутизации - один из возможных способов маршрутизации описан в пункте текущего документа 4.6 Маршрутизация;
- Область применения;
- Версия методических рекомендация (далее – МР);
- Режим обмена;
- Предполагается ли обмен с ЕПГУ;
- Наименование протокола обмена представляет собой имя, позволяющее идентифицировать протокол обмена среди других протоколов;
- Назначение – краткое описание назначения данного протокола обмена;
- Содержание – краткое описание информации, передаваемой посредством данного протокола обмена;
- Область применения – Межведомственное взаимодействие/Приём заявлений с ЕПГУ/Приём заявлений с ЕПГУ или МФЦ.
- Межведомственное взаимодействие – взаимодействие осуществляется между категориями участников, указанных в Регламенте 3.5 «Приложение 3 Правила и процедуры работы в СМЭВ по Методическим рекомендациям версии 3.х» пп. 6.1 Общие положения.
- Приём заявлений с ЕПГУ- единственно возможной системой-инициатором взаимодействия является ИС ЕПГУ.
- Приём заявлений с ЕПГУ или МФЦ. - системами-инициаторами взаимодействия является ИС УВ ЕПГУ или ИС УВ, принадлежащая к категории МФЦ.
- Версия МР – «Методических рекомендаций по работе с Единой системой межведомственного электронного взаимодействия», согласно которым проектировался данный протокол обмена.
- Владелец ВС - могут выступать участники, указанные в Регламенте версии 3.5 «Приложение 3 Правила и процедуры работы в СМЭВ по Методическим рекомендациям версии 3.х» пп. 10.7 Регистрация Вида сведений в СМЭВ.
- Критерии доступа для участников в роли Инициатора и Ответчика.
- Тип запроса – тип взаимодействия по данному протоколу: запрос-ответ или рассылка.
5.1.2. Проектирование форматов передаваемых данных
Форматы передаваемых данных (ФПД) разрабатываются Владельцем сведения с использованием языка описания схем данных XML Schema Definition (XSD) и должны соответствовать следующим правилам:
- Для каждого протокола обмена один из элементов СМЭВ-заголовка, описанных на корневом уровне схемы, должен представлять собой «элемент запроса», содержащий бизнес-данные запроса или рассылки;
- Для каждого протокола обмена, один из элементов СМЭВ-заголовка, описанных на корневом уровне схемы, должен представлять собой «элемент ответа», содержащий бизнес-данные ответа;
- Для каждого протокола обмена корневой элемент запроса, и корневой элемент ответа должны быть описаны в одной схеме (иметь одно и то же пространство имен схемы). При этом схема может быть разбита на несколько XML-документов (конструкция xs:include), а также ссылаться на другие XML-схемы (конструкция xs:import);
- Для директивных протоколов обмена необходимо включать в состав элементов, описанных на корневом уровне схемы, специализированные инструкции, содержащие директивы для процессинга СМЭВ;
- Для директивных протоколов обмена в состав форматов передаваемых данных необходимо включать схемы СМЭВ-вложений;
XML схемы протоколов обмена, причём как СМЭВ-заголовков, так и СМЭВ-вложений, регистрируемые в СМЭВ, должны удовлетворять требованиям документа «Требования к XML-схемам, регистрируемым в СМЭВ».
ИС участников взаимодействия в теле электронных сообщений должны поддерживать применение блоков и элементов данных, а также электронных подписей, описанных в данном документе. Использование других блоков и элементов, отличных от описанных в данном документе, не допускается.
Целевое пространство имён (target namespace) любой схемы, используемой в СМЭВ, должно быть глобально уникально.
Чтобы облегчить соблюдение этого требования, в СМЭВ каждому ОИВ – Владельцу данных должен присваиваться базовый URI. Все схемы, регистрируемые в СМЭВ этим Владельцем данных, должны иметь target namespace, начинающиеся с базового URI этого Владельца. Таким образом, ответственность за уникальность базовых URI несёт оператор СМЭВ, а Владелец данных отвечает за уникальность target namespace в области действия своего базового URI.
Рекомендуемые правила присвоения target namespace приведены в таблице 1.
Таблица 1– Рекомендуемые правила присвоения target namespace.
|
Объект |
Правило |
Пример |
|
URI владельца сведений |
|
|
|
Версия протокола обмена |
Состоит из следующих частей, разделённых косой чертой «/»:
|
|
|
СМЭВ-вложение |
Состоит из следующих частей, разделённых косой чертой «/»:
|
urn://x-artefacts-data-provider/protex/attachments/increment/1.0.0 |
В target namespace разрешены только латинские буквы, цифры, символы подчёркивания «_», минус «-», косая черта «/», двоеточие «:», точка «.». Значение target namespace не должно превышать ограничение в 500 символов.
Базовые URI urn://x-artefacts-smev-gov-ru/ и urn://smev-gov-ru/ для именования пространств имён элементов в сообщениях зарезервированы для источника со схемой URN. Использование их в схемах протоколов обмена не допускается.
При необходимости внесения изменений в протокол обмена, в СМЭВ необходимо зарегистрировать новую версию протокола обмена. Чтобы обеспечить корректную маршрутизацию сообщений, соответствующих устаревшим версиям протоколов обмена, в СМЭВ сохраняется полная история всех изменений, включая все предыдущие версии протоколов обмена.
Для каждой новой версии протокола обмена XML-схема должна иметь target namespace, отличающийся от предыдущих версий, для обеспечения этого требования рекомендуется в target namespace включать номер версии протокола обмена (таблица 1).
5.1.2.1. Использование шаблонов типовых данных и наборов данных
Использование шаблонов типовых данных и наборов данных осуществляется аналогично использованию атрибутов модели данных УВ. Подробное описание использования приведено в документе «Требования к XML-схемам, регистрируемым в СМЭВ».
5.1.2.2. Простые форматы передаваемых данных
5.1.2.2.1. Запрос-ответ
Простой формат передаваемых данных состоит из схемы СМЭВ-заголовка, состоящей из одного, или разнесённой по нескольким файлам. Допустимо использование только одного варианта запроса и связанного с ним варианта ответа.
Бизнес-данные запроса должны описываться одним элементом, расположенным на корневом уровне схемы (рисунок 11). Элементы с наименованиями «family» и «name» даны для примера.
Рисунок 11 – Корневой элемент запроса
Бизнес-данные ответа должны описываться одним элементом, расположенным на корневом уровне схемы (рисунок 12). Элементы с наименованиями «family» и «name» даны для примера.
Рисунок 12 – Корневой элемент ответа
Пример схемы простого протокола обмена (вида сведений):
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn://x-artefacts-data-provider/protex/1.0.0" xmlns:schema1="urn://x-artefacts-data-provider/schematic/protex/1.0.0" targetNamespace="urn://x-artefacts-data-provider/protex/1.0.0" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn://x-artefacts-data-provider/schematic/protex/1.0.0" schemaLocation="schematic/document.xsd"/>
<xs:annotation>
<xs:documentation>-------------------------------------------------Бизнес данные-------------------------------------------------</xs:documentation>
</xs:annotation>
<xs:element name="Request">
<xs:annotation>
<xs:documentation>Корневой элемент запроса</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="family" type="schema1:family"/>
<xs:element name="name" type="schema1:name"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Response">
<xs:annotation>
<xs:documentation>Корневой элемент ответа</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="schema1:name"/>
<xs:element name="family" type="schema1:family"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
5.1.2.2.2. Рассылка
Простой формат передаваемых данных состоит из схемы СМЭВ-заголовка, состоящей из одного, или разнесённой по нескольким файлам. Допустимо использование только одного варианта рассылки.
Бизнес-данные рассылки должны описываться одним элементом, расположенным на корневом уровне схемы (рисунок 13). Элементы с наименованиями «family» и «name» даны для примера.
Рисунок 14 – Корневой элемент рассылки
Пример схемы рассылки с использованием простого протокола обмена:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn://x-artefacts-data-provider/protex/1.0.0" xmlns:schema1="urn://x-artefacts-data-provider/schematic/protex/1.0.0" targetNamespace="urn://x-artefacts-data-provider/protex/1.0.0" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn://x-artefacts-data-provider/schematic/protex/1.0.0" schemaLocation="schematic/document.xsd"/>
<xs:annotation>
<xs:documentation>-------------------------------------------------Бизнес данные-------------------------------------------------</xs:documentation>
</xs:annotation>
<xs:element name="Broadcast">
<xs:annotation>
<xs:documentation>Корневой элемент рассылки</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="family" type="schema1:family"/>
<xs:element name="name" type="schema1:name"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
5.1.2.3. Директивные форматы передаваемых данных
Для описания элемента, содержащего директивы, необходимо использовать элемент Registry, описанные в схеме сервиса. Для этого следует с помощью инструкции import определить пространство имён, на компоненты схемы которого ссылается схема текущего протокола обмена:
…
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn://x-artefacts-data-provider/directive-protex/1.0.0" xmlns:directive="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/directive/1.3" xmlns:schema1="urn://x-artefacts-data-provider/schematic/protex/1.0.0" targetNamespace="urn://x-artefacts-data-provider/directive-protex/1.0.0" elementFormDefault="qualified" attributeFormDefault="unqualified">
…
<xs:import namespace="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/directive/1.3" schemaLocation="smev-message-exchange-directive-1.2.xsd"/>
…
Затем добавить элементы Request и Response, содержащие директивы, и назначить им ссылку на элемент Registry, описанный в определённом ранее пространстве имён:
...
<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>
...
5.1.2.3.1. Запрос-ответ
Директивный формат передаваемых данных состоит из схемы СМЭВ-заголовка и необязательных СМЭВ-вложений, передаваемых в запросе или ответе, состоящей из одного, или разнесённой по нескольким файлам. Допустимо использование только одного варианта запроса и связанный с ним вариант ответа.
В составе корневых элементов запроса должен присутствовать элемент, содержащий бизнес-данные и элемент, содержащий директивы (рисунки 14, 15). Элементы с наименованиями «family» и «name» даны для примера.
Рисунок 14 – Корневой элемент запроса
Рисунок 15 – Корневой элемент запроса с директивами
В составе корневых элементов ответа должен присутствовать элемент, содержащий бизнес-данные и элемент, содержащий директивы (рисунки 16, 17). Элементы с наименованиями «family» и «name» даны для примера.
Рисунок 16 – Корневой элемент ответа
Рисунок 17 – Корневой элемент ответа с директивами
Пример схемы директивного протокола обмена (вида сведений):
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn://x-artefacts-data-provider/directive-protex/1.0.0" xmlns:directive="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/directive/1.3" xmlns:schema1="urn://x-artefacts-data-provider/schematic/protex/1.0.0" targetNamespace="urn://x-artefacts-data-provider/directive-protex/1.0.0" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation>-------------------------------------------------Подключение описания модели данных-------------------------------------------------</xs:documentation>
</xs:annotation>
<xs:import namespace="urn://x-artefacts-data-provider/schematic/protex/1.0.0" schemaLocation="schematic/document.xsd"/>
<xs:annotation>
<xs:documentation>-------------------------------------------------Обязательные элементы схемы ВС-------------------------------------------------</xs:documentation>
</xs:annotation>
<xs:import namespace="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/directive/1.3" schemaLocation="smev-message-exchange-directive-1.2.xsd"/>
<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>
<xs:annotation>
<xs:documentation>-------------------------------------------------Бизнес данные-------------------------------------------------</xs:documentation>
</xs:annotation>
<xs:element name="MBRequest">
<xs:annotation>
<xs:documentation>Корневой элемент запроса</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="family" type="schema1:family"/>
<xs:element name="name" type="schema1:name"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="MBResponse">
<xs:annotation>
<xs:documentation>Корневой элемент ответа</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="schema1:name"/>
<xs:element name="family" type="schema1:family"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
5.1.2.3.2. Рассылка
Директивный формат передаваемых данных состоит из схемы СМЭВ-заголовка и необязательных СМЭВ-вложений, передаваемых в рассылке, состоящей из одного, или разнесённой по нескольким файлам. Допустимо использование только одного варианта рассылки.
В составе корневых элементов рассылки должен присутствовать элемент, содержащий бизнес-данные и элемент, содержащий директивы (рисунки 18, 19). Элементы с наименованиями «family» и «name» даны для примера.
Рисунок 18 – Корневой элемент запроса
Рисунок 19 – Корневой элемент запроса с директивами
Пример схемы рассылки с использованием директивного протокола обмена:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn://x-artefacts-data-provider/directive-protex/1.0.0" xmlns:directive="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/directive/1.3" xmlns:schema1="urn://x-artefacts-data-provider/schematic/protex/1.0.0" targetNamespace="urn://x-artefacts-data-provider/directive-protex/1.0.0" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn://x-artefacts-data-provider/schematic/protex/1.0.0" schemaLocation="schematic/document.xsd"/>
<xs:annotation>
<xs:documentation>-------------------------------------------------Обязательные элементы схемы ВС-------------------------------------------------</xs:documentation>
</xs:annotation>
<xs:import namespace="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/directive/1.3" schemaLocation="smev-message-exchange-directive-1.2.xsd"/>
<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:annotation>
<xs:documentation>-------------------------------------------------Бизнес данные-------------------------------------------------</xs:documentation>
</xs:annotation>
<xs:element name="Broadcast">
<xs:annotation>
<xs:documentation>Корневой элемент рассылки</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="family" type="schema1:family"/>
<xs:element name="name" type="schema1:name"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
5.1.3. Материалы для аттестации
Для прохождения процедуры аттестации технической готовности протокола обмена и ИС, его использующей, необходимо подготовить следующие материалы:
Для простых Протоколов обмена:
Для режима обмена «Запрос-ответ»:
- Материалы для проведения тестирования возможности отправлять сообщения-запросы;
- Материалы для проведения тестирования возможности отправлять сообщения-ответы.
Для режима обмена «Рассылка»:
- Материалы для проведения тестирования возможности отправлять сообщения-рассылки.
Для директивных Протоколов обмена:
Для режима обмена «Запрос-ответ»:
- Материалы для проведения тестирования возможности отправлять сообщения-запросы;
- Материалы для проведения тестирования
возможности отправлять сообщения-ответы.
Для режима обмена «Рассылка»:
- Материалы для проведения тестирования возможности отправлять сообщения-рассылки.
5.1.3.1. Материалы для проведения тестирования возможности отправлять сообщения-запросы
Для обеспечения автоматизированного тестирования возможности ИС отправлять сообщения-запросы необходимо подготовить следующие материалы для сценария тестирования:
- Наименование сценария;
- XPath-выражение идентификатора варианта запроса.
В XPath-выражениях контрольных примеров одного сценария, название одного
элемента должно встречаться не более одного раза;
- Псевдоним пространства имён тестового сценария;
- XSLT преобразование для эмуляции ответа;
- Список контрольных примеров:
- Наименование контрольного примера;
- XPath-выражение - условие контрольного примера.
5.1.3.2. Материалы для проведения тестирования возможности отправлять сообщения-ответы
Для обеспечения автоматизированного тестирования возможности ИС отправлять сообщения-ответы необходимо подготовить следующие материалы:
- Тестовые эталонные запросы;
- Тестовые эталонные ответы.
5.1.3.3. Материалы для проведения тестирования возможности отправлять сообщения-рассылки
Для обеспечения автоматизированного тестирования возможности ИС отправлять сообщения-рассылки необходимо подготовить следующие материалы для сценария тестирования:
- Наименование сценария;
- XPath-выражение идентификатора варианта
рассылки. В XPath-выражениях контрольных примеров одного сценария название
одного элемента должно встречаться не более одного раза;
- Псевдоним пространства имён тестового сценария;
- Список контрольных примеров:
- Наименование контрольного примера;
- XPath-выражение - условие контрольного примера.
5.1.4. Обмен справочными данными в составе сообщений по видам сведений в СМЭВ
5.1.4.1. Проверка ссылочной целостности передаваемых справочных данных
Для передачи в составе сообщения справочных данных, содержащихся в справочниках ЕСНСИ, следует указывать только ссылки на требуемые данные. Ссылки представляют собой значения ключевых атрибутов справочника ЕСНСИ. Ключевой атрибут назначается при создании справочника, процедура указана в руководстве пользователя в разделе «Управление справочниками».
Имеется возможность проверки ссылочной целостности передаваемых данных средствами СМЭВ3.Х.
Пример: требуется передать сообщение по определённому протоколу обмена (виду сведений), с условием, чтобы элемент сообщения «Gender» (рисунок 48), содержал только значения, указанные в ключевом атрибуте «ID» справочника ЕСНСИ «Справочник полов» (таблица 11).
Таким образом, при передаче в элементе «Gender» значения «0003», СМЭВ данное сообщение пропускать не должен. В обратном случае, при указании значения «0001» или «0002», сообщение будет удовлетворять схеме Вида сведений и сообщение поступит к получателю.
Для использования проверки необходимо выполнить следующие действия:
1. Владельцем справочных данных:
- Создать в ЕСНСИ справочник со справочными данными. У справочника должен быть обязательно назначен ключевой атрибут;
- Обеспечить возможность публикации справочника ЕСНСИ для проведения проверки: регламентная процедура «Публикация справочника ЕСНСИ для проведения контроля ссылочной целостности»;
- Наполнить справочник данными через пользовательский веб-интерфейс, либо с использованием вида сведений «Обновление содержимого справочников ЦНСИ»;
- Опубликовать справочник в СМЭВ3.Х через пользовательский веб-интерфейс. Процесс публикации приведён в руководстве пользователя, раздел «Публикация справочника в СМЭВ3.Х». Форма заявки на публикацию приведена в приложении К.
2. Разработчиком вида сведений:
- Скачать XSD опубликованной ревизии справочника через пользовательский веб-интерфейс ЕСНСИ2.0 (http://esnsi.gosuslugi.ru/). Процесс скачивания XSD справочника проведён в руководстве пользователя в разделе «Выгрузка XSD справочника»;
- Включить
XSD справочника ЕСНСИ в схему вида сведений с помощью инструкции import.
Формирование схемы вида сведений с использованием схем справочников приведено в
приложении Ж.
5.1.4.2. Ограничения использования справочников ЕСНСИ при межведомственном обмене:
- При внесении изменений в структуру справочника требуется регистрация новых версий видов сведений, использующие данный справочник;
- Справочник должен содержать не более 2000 записей;
- Для проверки используется только ключевой атрибут справочника.
