Методические рекомендации по работе с Единой системой межведомственного электронного взаимодействия версия 0 2 (проект) Москва 201

1.Введение 4

1.1.Назначение документа 4

1.2.Цели и требования 5

1.3.Термины, определения, соглашения 6

2.Основы взаимодействия 7

2.1.Основные понятия и правила обмена информацией 7

2.2.Концепция «Виды сведений» 8

2.2.1Толкование термина 8

2.2.2Маршрутизация запросов на основании передаваемых сведений 9

2.2.3Маршрутизация запросов по ОКТМО 9

2.2.4Требования к описанию форматов сведений 9

2.2.5Включение схем справочников в схему видов сведений 10

2.2.6Версионность форматов сведений 10

2.2.7Структура вида сведений в СМЭВ 10

2.3.Типы сообщений 10

2.3.1Сообщения типа «Запрос» 10

2.3.2Сообщения типа «Ответ» 11

2.3.3Широковещательные рассылки 11

2.3.4Приоритетная доставка 11

2.3.5Сообщения об отказах в ответе на уровне схемы СМЭВ 12

2.3.6Возврат статусов запросов на уровне схемы СМЭВ 12

2.3.7Указание мнемоники сервера отправки сообщения 12

2.4.Жизненный цикл сообщений 13

2.4.1Жизненный цикл сообщения типа «Запрос» 13

2.4.2Жизненный цикл сообщения типа «Ответ» 14

2.4.3Жизненный цикл бизнес-взаимодействия 15

2.5.Организация очередей 15

2.5.1Получение сообщения с фильтрацией по виду сведений 16

2.5.2Подтверждение приёма сообщения 17

2.5.3Получение статистики входящих очередей 18

2.5.4Ограничения на частоту опроса очередей 18

2.6.Организация очередей статусов 19

2.6.1Получение уведомления из очереди статусов 19

2.6.2Структура сообщения с запросом уведомления из очереди статусов 20

2.6.3Структура сообщения с уведомлением из очереди статусов 20

3.Требования к структуре сообщений 22

3.1.Общие положения 22

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

3.2.1Блок данных запроса 23

3.2.2Блок содержимого вложений 24

3.2.3Электронная подпись органа власти 24

3.3.Структура сообщения с запросом сведений, которое ИС поставщика получает из СМЭВ 25

3.3.1Блок данных СМЭВ-конверта 26

3.3.2Блок содержимого вложений 26

3.3.3Электронная подпись СМЭВ 27

3.4.Структура сообщения с ответом, которое ИС поставщика передает в СМЭВ 27

3.4.1Блок данных ответа 28

3.4.2Блок содержимого вложений 28

3.4.3Электронная подпись органа власти 28

3.5.Структура сообщения с ответом, которое ИС потребителя получает из смэв 28

3.5.1Блок данных СМЭВ-конверта 29

3.5.2Блок содержимого вложений 29

3.5.3Электронная подпись СМЭВ 29

4.Электронные подписи 31

4.1.Виды электронных подписей 31

4.2.Порядок использования электронных подписей 31

4.2.1Использование электронных подписей при передаче запроса 31

4.2.2Использование электронных подписей при передаче ответа 33

4.3.Правила формирования ЭП 34

4.3.1Подписи в формате PKCS#7 35

4.4.Электронные подписи субъектов взаимодействия – физических лиц 35

4.4.1Общие требования к электронной подписи, формируемой от имени должностных лиц органов власти при межведомственном информационном обмене 35

4.4.2Электронная подпись при межведомственном взаимодействии 36

4.5.Электронные подписи субъектов взаимодействия – информационных систем 37

4.5.1Общие требования электронной подписи, формируемой от имени органа власти при межведомственном информационном обмене 37

4.5.2Общие требования к электронной подписи, формируемой узлами СМЭВ 38

4.5.3Правила формирования электронной подписи информационной системы 38

4.5.4Подписание вложений электронной подписью информационной системы 39

5.Пересылка вложений с использованием Файлового хранилища 40

6.Сценарии асинхронного взаимодействия 43

6.1.Межведомственный запрос 43

6.2.Пакет запросов – пакет ответов 47

7.ВЗАимодействие череЗ системы-агрегаторы 50

8.Приложения 51

8.1.Приложение 1: Аглоритм нормализации XML 51

9.Если текстовый узел содержит только пробельные символы (код символа меньше или равен '\u0020'), этот текстовый узел вырезается. 51

10.После применения правил 1 и 2, если даже у элемента нет дочерних узлов, элемент не может быть представлен в виде empty element tag (http://www.w3.org/TR/2008/REC-xml-20081126/#sec-starttags, правило [44]), а должен быть преобразован в пару start-tag + end-tag. 51

11.Удалить namespace prefix, которые на текущем уровне объявляются, но не используются. 51

12.Проверить, что namespace текущего элемента объявлен либо выше по дереву, либо в текущем элементе. Если не объявлен, объявить в текущем элементе. 51

13.Namespace prefix элементов и атрибутов должны заменены на автоматически сгенерированные. Сгенерированный префикс состоит из литерала «ns», и порядкового номера сгенерированного префикса в рамках обрабатываемого XML-фрагмента, начиная с единицы. При генерации префиксов должно устраняться их дублирование.
51

14.Атрибуты должны быть отсортированы в алфавитном порядке: сначала по namespace URI (если атрибут - в qualified form), затем – по local name. Атрибуты в unqualified form после сортировки идут после атрибутов в qualified form. 52

15.Объявления namespace prefix должны находиться перед атрибутами. Объявления префиксов должны быть отсортированы в порядке объявления, а именно: 52

15.1.Приложение 2: Результат трансформации urn://smev-gov-ru/xmldsig/transform 52

15.2.Приложение 3: Профиль формата PKCS#7, которому должны удовлетворять подписи вложенных файлов 54

15.3.Приложение 4: Образцовая реализация трансформации urn://smev-gov-ru/xmldsig/transform 55

15.4.Приложение 5: Сценарии тестирования алгоритма нормализации XML 61

15.4.1Сценарий 1: тестирование правил 1, 2, 6 (здесь и далее под правилами понимаются подпункты алгоритма нормализации, описанного в Приложении 1). 61

15.4.2Сценарий 2: тестирование правил 4, 5 61

15.4.3Сценарий 3: тестирование правил 3, 7, 8 62

15.5.Приложение 6: Перечень ошибок, возвращаемых транспортной подсистемой СМЭВ 63

15.6.Приложение 7: формирование видов сведений с включением справочников 74