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

Значение одного из указанных идентификаторов в привязке к конкретной системе-подписчику и будут являться отдельной подпиской Хранилища для данного протокола обмена. Часть Хранилища, для рассматриваемого гипотетического протокола обмена «Рассылка изменений по классам опасностей», может выглядеть следующим образом:

№ подписки	Система-подписчик	Значение идентификатора	Примечание
1	АИС «Периметр»	1082468041611	Идентификатор объекта рассылок - ОГРН ОГВ «МИНИСТЕРСТВО ОБРАЗОВАНИЯ КРАСНОЯРСКОГО КРАЯ»
2	АИС «Периметр»	1082468039763	Идентификатор объекта рассылок - ОГРН ОГВ «МИНИСТЕРСТВО КУЛЬТУРЫ КРАСНОЯРСКОГО КРАЯ»
3	АИС «МинПромТорг»	1022402651677	Идентификатор объекта рассылок - ОГРН ЮЛ АКЦИОНЕРНОЕ ОБЩЕСТВО "КОНДИТЕРСКО-МАКАРОННАЯ ФАБРИКА "КРАСКОН"
4	АИС «МинПромТорг»	1082468041611	Идентификатор объекта рассылок - ОГРН ОГВ «МИНИСТЕРСТВО ОБРАЗОВАНИЯ КРАСНОЯРСКОГО КРАЯ»
5	АИС «МинЖКХ»	1072450001117	Идентификатор объекта рассылок - ОГРН ЮЛ « АБАНСКОГО РАЙОНА»
6	АИС «Командор-Ритейл»	bf364cf7-52e1-4e0f-9dd3-d4c344197559	Идентификатор объекта рассылок – ФИАС-код -РИТЕЙЛ» Красноярский край, г Зеленогорск, ул Песчаная, д 2
7	АИС «Периметр»	bf364cf7-52e1-4e0f-9dd3-d4c344197559	Идентификатор объекта рассылок – ФИАС-код -РИТЕЙЛ» Красноярский край, г Зеленогорск, ул Песчаная, д 2
8	АИС «МинТранс»	312774618400682	Идентификатор объекта рассылок - ОГРНИП ИП «»

Список систем-подписчиков, в адрес которых будет направлена копия данного СМЭВ-документа, определяется путем сопоставления списков значений Идентификаторов, которые передаются в сообщении-рассылке и значений Идентификаторов, которые указаны в подписках для данного протокола обмена в Хранилище.

Например, СМЭВ-документ сообщения-рассылки содержит следующий список значений идентификаторов: «1082468041611», «bf364cf7-52e1-4e0f-9dd3-d4c344197559». Тогда в результате сопоставления списков Идентификаторов, СМЭВ установит, что рассматриваемый СМЭВ-документ будет доставлен следующим системам-подписчикам:

АИС «Периметр», потому что в Хранилище существует подписка №1 («1082468041611») и №7 («bf364cf7-52e1-4e0f-9dd3-d4c344197559») АИС «МинПромТорг», потому что в Хранилище существует запись №4 («1082468041611») АИС «Командор-Ритейл», потому что Хранилище существует запись №6 («bf364cf7-52e1-4e0f-9dd3-d4c344197559»)

Нормативы формирования ответных сообщений

Ответными для режима «запрос-ответ» называются сообщения-ответы, а для режима «рассылка» - сообщения-квитанции.

В отношении ответных сообщений, для проектируемого протокола обмена (вида сведений) необходимо определить являются следующие нормативы:

Разрешенное максимальное количество ответных сообщений; Максимальный период формирования первого сообщения-ответа; Максимальная продолжительность сеанса обмена. Разрешенное максимальное количество ответных сообщений

Данный параметр определяет максимально допустимое правилами данного протокола обмена (вида сведений) количество ответных сообщений.

Его значение для режима «запрос-ответ», то есть применительно к сообщениям-ответам, не может быть меньше одного.

Для режима «рассылка», количество сообщений-квитанций может быть равным и больше нуля.

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

Данный параметр устанавливает максимальную продолжительность временного интервала, который отделяет два момента времени.

Первый - момент размещения клона исходного сообщения (сообщения-запроса или сообщения-рассылки) в очереди системы – получателя (системы-ответчика или системы-издателя).

Второй – момент – получения СМЭВ ответного сообщения (сообщения – ответа или сообщения-квитанции).

Максимальная продолжительность сеанса обмена

Данный параметр устанавливает максимальную продолжительность временного интервала, который отделяет два момента времени.

Первый - момент размещения клона исходного сообщения (сообщения-запроса или сообщения-рассылки) в очереди системы – получателя (системы-ответчика или системы-издателя).

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

Пропуская способность отвечающей стороны

Интенсивность осуществления сеансов обмена в рамках проектируемого протокола (вида сведений) имеет объективные ограничения.

В режиме «запрос-ответ» она ограничена пропускной способностью системы-ответчика. Поэтому для протокола обмена по режиму «запрос-ответ» должны быть определены следующие параметры:

Максимальное количество клонов исходных сообщений-запросов, которые должна извлекать из своей очереди система-ответчик за:

1 секунду; 1 сутки.

СМЭВ. Техника Использование СМЭВ Проектирование протокола обмена (вида сведений)

Результатом проектирования протокола обмена (вида сведений) является комплект следующих материалов:

Руководство пользователя; Схемы СМЭВ-документов; Материалы для аттестации.

Подготовка руководства пользователя протокола обмена (вида сведений)

Основные настройки протокола обмена:

Наименование; Назначение; Содержание; Критерии доступа; Маршрутизация сообщений; Область применения; Версия МР; Режим обмена; Предполагается ли обмен с ЕПГУ.

Наименование протокола обмена представляет собой наименование, позволяющее идентифицировать протокол среди других протоколов.

Назначение - краткое описание назначения данного протокола обмена.

Содержание - краткое описание передаваемой информации, посредством данного протокола обмена.

Критерии доступа - описание критериев которым должен удовлетворять Участник взаимодействия, на основе которых принимается решение о предоставлении доступа к данному протоколу обмена.

Маршрутизация сообщений - один из возможных способов маршрутизации: фиксированная, табличная, динамическая или рассылка по идентификаторам.

Область применения - Государственные услуги/государственные функции/обеспечивающие взаимодействие.

Версия МР - версия методических рекомендаций, согласно которым проектировался данный протокол обмена.

Режим обмена - тип взаимодействия по данному протоколу: запрос-ответ или рассылка.

Предполагается ли обмен с ЕПГУ - признак того, что данный протокол спроектирован по правилам ЕПГУ.

Проектирование форматов передаваемых данных

Форматы передаваемых данных разрабатываются поставщиком с использованием языка описания схем данных XML Schema Definition (XSD) и должны соответствовать следующим правилам:

Для каждого протокола обмена один из элементов СМЭВ-заголовка, описанных на корневом уровне схемы, должен представлять собой «элемент запроса», содержащий бизнес-данные запроса или рассылки; Для каждого протокола обмена, один из элементов СМЭВ-заголовка, описанных на корневом уровне схемы, должен представлять собой «элемент ответа», содержащий бизнес-данные ответа; Для каждого протокола обмена корневой элемент запроса, и корневой элемент ответа должны быть описаны в одной схеме (иметь одно и то же пространство имен схемы). При этом схема может быть разбита на несколько XML-документов (конструкция xs:include), а также ссылаться на другие XML-схемы (конструкция xs:import); Для директивных протоколов обмена необходимо включать в состав элементов, описанных на корневом уровне схемы, специализированные инструкции, содержащие директивы для процессинга СМЭВ; Для директивных протоколов обмена в состав форматов передаваемых данных необходимо включать схемы СМЭВ-вложений; Вновь регистрируемые протоколы обмена, как СМЭВ-заголовки, так и СМЭВ-вложения, должны использовать типы данных, описанные в модели данных в СМЭВ. КТДА. Использование протоколов обмена без отражения модели данных в СМЭВ. КТДА - не допускается.

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

Целевое пространство имен (target namespace) любой схемы, используемой в СМЭВ, должно быть глобально уникально.

Чтобы облегчить соблюдение этого требования, в СМЭВ каждому ОИВ – поставщику данных должен присваиваться базовый URI. Все схемы, регистрируемые в СМЭВ этим поставщиком данных, должны иметь target namespace, начинающиеся с базового URI этого поставщика. Таким образом, ответственность за уникальность базовых URI несет оператор СМЭВ, а поставщик данных отвечает за уникальность target namespace в области действия своего базового URI.

Рекомендуемые правила присвоения target namespace:

Объект	Правило	Пример
URI поставщика	Базовый URI	urn://x-artefacts-data-provider
Версия протокола обмена	Базовый URI поставщика+наименование протокола обмена+номер версии	urn://x-artefacts-data-provider/protex/1.0.0
СМЭВ-вложение	Базовый URI поставщика+наименование протокола обмена+«attachments»+наименование вложения+номер версии	urn://x-artefacts-data-provider/protex/attachments/increment/1.0.0
Документ КТДА	Базовый URI владельца+«schematic»+наименование документа КТДА+версия Документа КТДА	urn://x-artefacts-data-provider/schematic/protex/1.0.0

Базовые URI urn://x-artefacts-smev-gov-ru/ и urn://smev-gov-ru/ для именования пространств имён элементов в сообщениях зарезервированы для источника со схемой URN. Использование их в схемах протоколов обмена не допускается.