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

Порядок проведения тестирования корректности данных, получаемых с
использованием продуктивной среды СМЭВ
по методическим рекомендациям
по разработке электронных сервисов
и применению технологии
электронной подписи версии 3.х
1.НАЗНАЧЕНИЕ ДОКУМЕНТА
Данный документ предназначен для участников электронного межведомственного
взаимодействия, использующих СМЭВ 2.0, которым требуется провести проверку
корректности данных, получаемых через СМЭВ 3.0. Документ используется участниками
пилотной эксплуатации СМЭВ 3.0, а также прочими участниками электронного
межведомственного взаимодействия при необходимости такой проверки.
В документе описано взаимодействие потребителя и поставщика вида сведений
(ВС) в продуктивной среде при получении данных по ВС, а также критерии успешного
прохождения проверки корректности данных.
2.ПОДКЛЮЧЕНИЕ К СТЕНДУ
В качестве стенда для проверки используется продуктивная среда СМЭВ 3.0,
находящаяся в закрытой промышленной зоне Электронного правительства. Адрес сервиса
СМЭВ: http://172.20.3.12:7500/ws?wsdl.
Общая инструкция по подключению к стенду приведена в Приложении 3.
3.ПОДГОТОВКА К ПРОВЕДЕНИЮ ТЕСТИРОВАНИЯ
Для проведения тестирования Поставщики сведений готовят описание видов
сведений в соответствии с Методическими рекомендациями СМЭВ3.0 и дорабатывают
свои информационные системы для предоставления сведений в форматах этих сведений.
Соответственно, Потребители сведений дорабатывают свои информационные системы
для формирования запросов разработанных видов сведений и обработки ответов.
Тестирование проводится на промышленных данных. Для проведения
тестирования Потребители сведений должны в режиме реального времени пересылать
запросы на получение сведений, а Поставщик должен так же в реальном режиме
обрабатывать приходящие запросы и отправлять в СМЭВ 3.0 соответствующие ответы.
Отправка запросов/ответов должны проходить параллельно с их отправкой
промышленный стенд СМЭВ 2.0.
Для участия в тестировании Поставщики и Потребители должны доработать свои
Информационные системы для отправки промышленных запросов/ответов в СМЭВ 3.0.
4.ПОРЯДОК ПРОВЕДЕНИЯ ТЕСТИРОВАНИЯ
Тестирование проводится в течение минимум одной рабочей недели. При этом
Потребители сведений в режиме реального времени пересылают запросы на получение
сведений, а Поставщик обрабатывает запросы и отправляет в СМЭВ соответствующие
ответы. Отправка запросов/ответов проходит параллельно с их отправкой промышленный
стенд СМЭВ 2.0.
Модератором проведения тестирования выступает Министерство связи и массовых
коммуникаций Российской Федерации.
Проведение тестирования инициируется Модератором тестирования. Модератор
направляет в адрес участников тестирования информационные письма о старте и о
завершении/приостановке тестирования. Так же Модератор информирует участников об
ошибках, возникающих в ходе проведения тестирования, и дает комментарии по
возникающим вопросам.
4. УСЛОВИЯ УСПЕШНОГО ПРОХОЖДЕНИЯ ТЕСТИРОВАНИЯ
Условием успешного прохождение тестирования является успешное тестирование
всех установленных пар Потребитель–Поставщик. Успешное тестирование пары
определяется наличием не менее 100 успешно обработанных подряд запросов данной
пары и эквивалентностью полученных результатов по этим же запросам в СМЭВ 2.0. Для
проверки качества ответов Потребитель должен проводить выборочную проверку (не
менее чем каждое пятое сообщение) на соответствие ответов из СМЭВ3.0 и СМЭВ 2.0.
В ходе проведения тестирования участники ежедневно фиксируют проведенное
тестирование в форме отчета вида:
№
А) для Потребителей
UUID
отправленного Дата и время запроса
запроса
Дата и время ответа
№
Б) для Поставщиков
UUID
полученного Дата и время запроса
запроса
Дата и время ответа
Отчет о проведенном тестировании направляется в адрес Министерства связи и
массовых коммуникаций Российской Федерации в рабочем порядке.
Модератор тестирования проводит сверку отчетов и делает заключение об
успешности тестирования.
По окончании тестирования подписывается протокол совместного тестирования
Вида сведений Единой системы межведомственного электронного взаимодействия,
приведенный в Приложении 4.
5.ПРОВЕДЕНИЕ ТЕСТИРОВАНИЯ С ИСПОЛЬЗОВАНИЕМ
ФАЙЛОВОГО ХРАНИЛИЩА
Для использования в ходе тестирования Файлового хранилища необходимо
провести мероприятия, описанные в Приложении 1.
6.ПРОВЕДЕНИЕ ТЕСТИРОВАНИЯ С ПРОВЕРКОЙ СПРАВОЧНИКОВ
ЕСНСИ
Для использования в ходе тестирования механизма проверки справочников ЕСНСИ
необходимо провести мероприятия, описанные в Приложении 2.
7.ЗАГРУЗКА ПЕРЕДАВАЕМЫХ ФАЙЛОВ ПОСРЕДСТВОМ FTP
Загрузка передаваемых файлов в файловое хранилище осуществляется при
передаче сообщений, сопровождаемых файлом или файлами большого размера. В
Файловом хранилище СМЭВ установлено ограничение на суммарный объем файлов,
передача которых осуществляется одним сообщением. Суммарный объем файлов,
передаваемых одним сообщением не должен превышать 1 Гб.
При создании сообщения, сопровождаемого файлами большого объема,
необходимо сформировать сообщение с передаваемыми данными, добавить в
сформированное сообщение тег «RefAttachmentHeaderList», для каждого из передаваемых
файлов выполнить следующие действия:
- сгенерировать универсальный уникальный идентификатор (UUID) для
передаваемого файла;
- подключиться к FTP сервису с именем пользователя «anonymous» и с
произвольным паролем. Для подключения используется следующая последовательность
команд FTP:
- user <логин>
- pass <пароль>
- создать на FTP сервере каталог с именем, соответствующим UUID, создаваемого
файла. Для создания каталога необходимо использовать команду FTP:
- mkdir <uuid>
- сделать созданную папку текущей с использованием команды FTP:
- cd <uuid>
- загрузить передаваемый файл в созданную папку с использованием команды FTP:
- put <имя файла>
- вычислить отпечаток файла по алгоритму вычисления хэш-функции,
соответствующему ГОСТ 34.11;
- подписать полученный отпечаток ЭП по стандарту PKCS #7;
- создать внутри тега «RefAttachmentHeaderList», сформированного сообщения тег
«RefAttachmentHeader»;
- в теге «RefAttachmentHeader» указать универсальный уникальный идентификатор
(UUID), отпечаток, ЭП, а также MIME – тип файла.
После выполнения указанных шагов сформированное сообщение подписывается
ЭП и передается в СМЭВ в соответствии МР3.x.
Пример заполнения тега «RefAttachmentHeaderList» приведен в Таблице 1.
Таблица 1 – Пример заполнения тега «RefAttachmentHeaderList»
<RefAttachmentHeaderList>
<RefAttachmentHeader>
<uuid>7b38b332-44aa-11e4-bbec-2cd4448f4af9</uuid>
<Hash>BaZD0TjZqyBwYIq49lnmYYML5n9P2fZ0dMdxAQby26w=</Hash>
<MimeType>application/pdf</MimeType>
<SignaturePKCS7>
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"
href="cid:f3a1d620-66b7-4a9c-a728dee0af0780d3@example.jaxws.sun.com"/>
</SignaturePKCS7>
</RefAttachmentHeader>
</RefAttachmentHeaderList>
8.ВЫГРУЗКА ПЕРЕДАВАЕМЫХ ФАЙЛОВ ПОСРЕДСТВОМ FTP
Выгрузка передаваемых файлов посредством FTP выполняется ИС потребителя
информации при получении ЭС, сопровождаемого файлами большого объема.
При выгрузке файлов из Файлового хранилища СМЭВ используются описания
передаваемых файлов, приведенные в теге «FSAttachmentsList». Информация для
получения каждого из передаваемых файлов приводится в теге «FSAttachment». Каждый
из тегов «FSAttachment» содержит:
- универсальный уникальный идентификатор (UUID) передаваемого файла;
- имя пользователя для подключения к Файловому хранилищу СМЭВ при выгрузке
передаваемого файла;
- пароль для подключения к Файловому хранилищу СМЭВ при выгрузке
передаваемого файла;
- имя передаваемого файла.
Пример заполнения тега «FSAttachmentsList» приведен в Таблице 2.
Таблица 2 – Пример заполнения тега «FSAttachmentsList»
<FSAttachmentsList>
<FSAttachment>
<uuid>7b38b332-44aa-11e4-bbec-2cd4448f4af9</uuid>
<UserName>JGIfOoKTFPR8hgKbjWS9ybr5SwlNQU</UserName>
<Password>i76yQce7JBnVnS8o2wHSDKZJ8Icbvv</Password>
<FileName>__ATT_ID_SMEV_C_AUTOGEN__1</FileName>
</FSAttachment>
</FSAttachmentsList>
Для выгрузки каждого из передаваемых файлов необходимо выполнить следующие
шаги:
- подключиться к FTP серверу с именем пользователя и паролем, полученными в
сообщении. Для подключения используется следующая последовательность команд FTP:
- user <логин>
- pass <пароль>
- перейти в каталог Файлового хранилища СМЭВ с именем, соответствующим
UUID файла. Для перехода в каталог используется команда FTP:
- cd <uuid>
- выгрузить файл с именем, указанным в сообщении. Для выгрузки используется
команда FTP:
- get <имя файла>.
9.ОРГАНИЗАЦИЯ ОЧЕРЕДЕЙ СТАТУСОВ
А.
Получение уведомления из очереди статусов
Очереди статусов в СМЭВ закреплены за отправителями сообщений. В очередь
статусов попадают уведомления, включающие сведения об ошибках асинхронной
обработки сообщения. При получении уведомления из очереди статусов ИС отправителя,
получатель выберет первое уведомление, имеющееся в очереди статусов данной ИС
отправителя. Для получения уведомления из очереди статусов ИС отправителя
необходимо вызвать метод getStatus. Перечень возможных ошибок, уведомления о
которых могут содержаться в очереди статусов ИС отправителя сообщения приведены в
Таблица 3.
Таблица 3 – Перечень возможных ошибок, уведомления о которых могут
содержаться в очереди статусов ИС отправителя сообщения
№
Наименование ошибки
Причины возникновения
1
Ошибка проверки ftp файлов
Не равен суммарный размер файлов
вложения. Файлы повреждены либо вложения сообщения, находящегося в
данные о файлах, переданные в
области долговременного хранения ФХ,
сообщении, некорректные. Код №3. суммарному размеру файлов вложения
сообщения, находившегося в директории
для записи ФХ.
Не равны хэши файлов вложения
сообщения находящихся в области
долговременного хранения ФХ, хэшам
файлов вложения сообщения,
находившихся в директории для записи
ФХ.
2
Сертификат ЭП-ОВ не
ИС ГУЦ в ответ на запрос вернул
действительный. Верификация в
результат о том, что сертификат ЭП-ОВ
ГУЦ не пройдена. Код №3.
не действительный.
Некорректные данные о сообщении в
БД сообщений, находящихся в очереди
асинхронной обработки.
Отсутствует обратный адрес для
сообщения, находящегося в очереди
асинхронных процессов.
Отсутствует запись о сообщений в БД
сообщений, находящихся в очереди
асинхронной обработки.
В записи о сообщении в БД сообщений,
находящихся в очереди асинхронной
обработки, присутствуют
противоречивые данные.
В случае отсутствия уведомлений в очереди статусов получатель получит пустое
уведомление.
a. Структура сообщения с запросом уведомления из очереди статусов
Структура сообщения, соответствующая передаче в СМЭВ запроса от ИС
отправителя на получение уведомления из очереди статусов, приведена на рисунке:
3
Ошибка асинхронного процессинга
СМЭВ. Данные сообщения
некорректные либо отсутствуют.
Код №3.
ИС отправителя
//GetStatusRequest
СМЭВ-конверт с запросом сведений
//Timestamp
Блок даты и времени отправки сообщения
//CallerInformationSystemSignature
ЭП-ОВ (подписан элемент//Timestamp)
ЭПОВ
СМЭВ
b. Структура сообщения с запросом уведомления, которое ИС
отправителя сообщения передает в СМЭВ
СМЭВ-конверт с запросом сведений (//GetStatusRequest), направляемый ИС
отправителя в СМЭВ для получения уведомления из очереди статусов, включает
элементы:
 блок даты и времени отправки сообщения (//Timestamp), который
включает сведения о дате и времени отправки сообщения для получения
уведомления из очереди статусов;
 электронная
подпись
органа
власти
(ЭП-ОВ)
(//CallerInformationSystemSignature).
c. Структура сообщения с уведомлением из очереди статусов
Структура сообщения, соответствующая передаче из СМЭВ уведомления ИС
отправителя из очереди статусов, приведена на рисунке:
СМЭВ
//GetStatusResponse
СМЭВ-конверт с запросом сведений
//SmevAsyncProcessingMessage
//AsyncProcessingStatus
Блок данных СМЭВ-конверта
//OriginalMessageId
UUID сообщения
//StatusCategory
Категория уведомления
//StatusDetails
Уведомление об ошибке асинхронной обработки сообщения
//SMEVSignature
ЭП-СМЭВ (подписан элемент //AsyncProcessingStatus)
ЭПСМЭВ
ИС отправителя
d. Структура сообщения с уведомлением, которое ИС отправителя
сообщения получает из СМЭВ
СМЭВ-конверт со сведениями (//GetStatusResponse), получаемый ИС отправителя
из СМЭВ, включающий уведомление из очереди статусов, включает элементы:
 блок данных СМЭВ-конверта (//AsyncProcessingStatus);
 электронная подпись СМЭВ (далее – ЭП-СМЭВ), (//SMEVSignature);
 Блок данных СМЭВ-конверта //AsyncProcessingStatus содержит элементы:
 UUID сообщения //OriginalMessageId, сформированный отправителем сообщения;
 категория статуса //StatusCategory;
 уведомление об ошибке асинхронной обработки сообщения //StatusDetails,
содержащее описание ошибки, возникшей в процессе асинхронной обработки
сообщения.
Приложение №1
Использование Файлового хранилища для пересылки файлов
посредством СМЭВ
Основным отличием ядра СМЭВ 3.0 2013 от ядра СМЭВ 3.0 2014 является
возможность отправки файлов более 5 Мб (до 1 Гб). Для этого необходимо на стороне
информационных систем поставщиков/потребителей:
 a. Разработать механизм генерации UID файлов с включением данных UID в состав
сообщения
 b. Разработать механизм взаимодействия с FTP-сервером файлового хранилища и
выкладки/чтения файлов Файлового хранилища посредством FTP
 c. Разработать механизм взаимодействия с очередью статусов через метод getStatus.
В статусную очередь возвращаются сообщения об ошибках при проверке
загруженных файлов и сообщений, связанных с ним.
Для упрощения данных работ поставляется java-библиотека клиента СМЭВ3.0, в
которой реализованы все необходимые функции.
Основные особенности работы с файловым хранилищем описаны в Разделе 7.
«Загрузка передаваемых файлов посредством FTP» и Разделе 8. «Выгрузка передаваемых
файлов посредством FTP».
Приложение №2
Подготовка к взаимодействию на пилотном проекте СМЭВ с
применением ЕСНСИ
Приведены требования к подготовке участников к применению ЕСНСИ при
взаимодействии в СМЭВ.
Использование ЕС НСИ при взаимодействии в СМЭВ нацелено на минимизацию:
 ошибок при формировании запросов информации, связанных с возможными
различиями в нормативно-справочной информации, используемой различными
ведомствами;
 изменений НСИ информационных систем, участвующих в СМЭВ и связанных
сними доработок.
Для применения ЕСНСИ участники взаимодействия на пилотном проекте должны
выполнить комплекс организационно-технических мероприятий, обеспечивающий
готовность к отработке взаимодействия.
В соответствии с существующими проектными решениями по созданию ЕСНСИ:
поставщики информации при взаимодействии с применением ЕСНСИ должны
использовать ЦНСИ для загрузки справочников, связанных с видами сведений, в рамках
которых осуществляется предоставление информации потребителям.
Потребители информации при взаимодействии с применением ЕСНСИ должны
использовать ТНСИ для:
 получения справочников, предоставленных поставщиками информации,
 ведения локальных справочников
 создания и корректировки правил перекодировки;
 перекодировки запросов, отправляемых в СМЭВ;
 перекодировки получаемых из СМЭВ сообщений.
1.Подготовительные мероприятия поставщиков информации
Перед началом использования ЦНСИ, поставщику информации необходимо
выполнить следующие подготовительные мероприятия:
а) запросить и получить у Оператора ЕСНСИ документацию на ЦНСИ:
 Руководство пользователя;
 Руководство администратора;
 Методические рекомендации;
 Регламент взаимодействия;
б) запросить и получить у Оператора ЕСНСИ доступ к ЦНСИ для всех сотрудников
ведомства, которые будут участвовать в пилотном проекте (см. «Регламент
взаимодействия»);
в) обеспечить регистрацию в ЕСИА сотрудников, которым предоставляется доступ в
ЦНСИ;
г) настроить в ЦНСИ права для полученных учётных записей (см. «Руководство
пользователя» и «Руководство администратора»);
д) доработать ИС, участвующую во взаимодействии, разработав компонент,
обеспечивающий загрузку справочников и их обновлений в ЦНСИ.
Разрабатываемый компонент должен обеспечивать вызов метода updateDirectory,
реализованного в ЦНСИ (см. «Методические рекомендации»);
е) подключить разработанный Компонент ИС к ЦНСИ (см. «Регламент
взаимодействия»);
ж) определить состав справочников, которые будут использоваться при
предоставлении информации (рекомендуемый состав справочников приведен в
таблице 4 данного приложения);
з) выполнить подготовку справочников для загрузки в ЦНСИ (справочники,
загружаемые в ЦНСИ доступны всем участникам взаимодействия и должны
содержать только открытую информацию);
и) выполнить загрузку подготовленных справочников;
к) скорректировать XSD схемы видов сведений, указав в описании каждого элемента,
заполняемого с использованием справочника, идентификатор соответствующего
справочника;
л) подготовить эталонные запросы и эталонные ответы для предоставляемых видов
сведений;
м) зарегистрировать скорректированные виды сведений в СМЭВ;
н) опубликовать скорректированные XSD схемы и эталонные запросы и ответы на
технологическом портале СМЭВ.
2.Подготовительные мероприятия потребителей информации
Перед началом использования ТНСИ, потребителю информации необходимо
выполнить следующие подготовительные мероприятия:
а) запросить и получить у Оператора ЕСНСИ документацию на ТНСИ:
 Руководство пользователя,
 Руководство администратора,
 Методические рекомендации,
 Регламент взаимодействия;
б) получить Оператора ЕСНСИ реквизиты доступа к ЦНСИ для загрузки
справочников;
в) получить у Оператора ЕСНСИ дистрибутив ТНСИ;
г) установить и настроить ТНСИ (см. «Руководство администратора»);
д) доработать ИС, участвующую во взаимодействии, разработав компонент,
обеспечивающий использование сервисов ТСНСИ по перекодировке сообщений
(методы Recode, RecodeByAlias см. «Методические рекомендации»):
 при формировании запроса в адрес поставщика для подстановки в запрос НСИ,
корректной с точки зрения поставщика информации (перекодировка «локальный
справочник потребителя – справочник поставщика»);
 при обработке ответа поставщика информации (перекодировка «справочник
поставщика – локальный справочник потребителя»).
е) подключить разработанный компонент к ТНСИ (см. «Регламент взаимодействия»).
ж) выполнить загрузку в ТНСИ справочников ИС потребителя информации
(локальной ИС);
з) задать в ТНСИ правила перекодировки, сопоставив значениям локальных
справочников значения справочников, полученных из ЦНСИ;
и) получить на технологическом портале СМЭВ XSD-схемы видов сведений,
информация по которым предоставляется с использованием справочников ЦНСИ,
эталонные запросы и эталонные ответы по видам сведений;
к) выполнить доработку ИС, обеспечив формирование запросов к видам сведений,
соответствующим полученным XSD-схемам. Сообщения должны формироваться с
использованием локальных справочников.
3.Термины и определения
Таблица 4 – Термины, определения и сокращения
№
Термин
1
2
ГКН
Локальный справочник
3
МВД
4
Перекодировка
5
Правило перекодировки
6
7
ПФР
Росреестр
8
СМЭВ
9
10
11
12
13
Справочник
Справочник ЦНСИ
ТНСИ
ФНС
ЦНСИ
Определение
Государственный кадастр недвижимости
Копия
справочника
или
классификатора,
использующаяся
Оператором
ИС
в
его
технологических процессах, загруженная в ТНСИ.
Справочники ЦНСИ не относятся к локальным
справочникам.
Министерство
внутренних
дел
Российской
Федерации
Преобразование элемента справочника ЦНСИ в
элемент локального справочника (или наоборот,
преобразование элемента локального справочника в
элемент справочника ЦНСИ).
Однонаправленное соответствие между элементом
справочника ЦНСИ и элементом локального
справочника (или наоборот, соответствие между
элементом локального справочника и элементом
справочника ЦНСИ).
Пенсионный фонд Российской Федерации
Федеральная служба
государственной
регистрации,
кадастра
и
картографии
Система
межведомственного
электронного
взаимодействия.
См. Компонент НСИ.
Справочник поставщика, размещённый в ЦНСИ.
Терминальный модуль ЕСНСИ.
Федеральная налоговая служба
Центральный модуль ЕСНСИ.
4.Рекомендуемые справочники
Состав справочников рекомендуемых для использования на пилотном проекте при
взаимодействии с применением ЕСНСИ приведен в таблице 5.
Для рекомендуемых справочников приведены:
 поставщик информации (кроме общих справочников);
 примерное наименование справочника;
 вид сведений, при предоставлении которого предполагается использование
справочника;
 элементы xsd – схем, при заполнении которых предполагается использование
справочника.
Таблица 5 – Справочники, рекомендуемые для использования на пилотном
проекте СМЭВ
Поставщи Наименование
Вид сведений
Элементы
к
справочника
информац
ии
ExecDepartment;
МВД
Справочник подразделений Сведения о
DepartmentDecid
(код подразделения,
нарушениях
ed
наименование
(gibdd-breachподразделения)
commons.xsd)
Все виды, в которых
Элементы Issuer
приводятся сведения
о документах,
удостоверяющих
личность
(smev-supplementarycommons.xsd)
ExecutionState
Справочник состояний
Сведения о
делопроизводства по
нарушениях
нарушению
(gibdd-breachcommons.xsd)
Penalty
Справочник видов
Сведения о
административных
нарушениях
наказаний
(gibdd-breachcommons.xsd)
VehicleCategory
Справочник категорий
Сведения о
транспортных средств
нарушениях
(gibdd-breachcommons.xsd)
VehicleOwnerCat
Справочник категорий
Сведения о
egory
владельцев транспортных
нарушениях
средств
(gibdd-breachcommons.xsd)
StateName
Справочник состояний дела Сведения о
нарушениях
(gibdd-breachcommons.xsd)
ErrorCode;
Справочник возможных
Сведения о
ErrorDescriptio
ошибок при
нарушениях
n
предоставлении сведений о (gibdd-breachнарушениях
commons.xsd)
Справочник статусов
квитанций
ПФР
ФНС
Росреестр
Сведения о
нарушениях
(gibdd-breachcommons.xsd)
Справочник полов
Предоставление
СНИЛС (pfr –snilsroot.xsd)
Справочник ошибок при
Предоставление
предоставлении СНИЛС
СНИЛС (pfr –snilsroot.xsd)
Справочник кодов
Предоставление
обработки запроса о
информации о
среднесписочной
среднесписочной
численности юридического численности
лица
организаций
(fns-sspch-root.xsd)
Справочник Субъектов РФ Предоставление
сведений
(dRegionsRF)
государственного
кадастра
недвижимости
(RequestGKN_v03.xsd)
Справочник 2-й уровень –
Предоставление
районы (улусы) республик, сведений
краев, областей,
государственного
автономной области,
кадастра
автономных округов,
недвижимости (ГКН)
входящих в состав
(RequestGKN_v03.xsd,
Российской Федерации
_AddressInp_v02.xsd)
(dDistrict)
Справочник 3-й уровень
Предоставление
административносведений ГКН
территориальное
(RequestGKN_v03.xsd,
образование (АТО)
_AddressInp_v02.xsd)
районного подчинения
(dCity)
Description
Справочник 4-й уровень –
тип населенного пункта
(dInhabitedLocalitie
)
Предоставление
сведений ГКН
(RequestGKN_v03.xsd,
_AddressInp_v02.xsd)
Location
(RequestGKN_v03.xsd)
;
Locality
(_AddressInp_v02.xsd)
Справочник 5-й уровень
(геоним) (dStreets)
Предоставление
сведений ГКН
(RequestGKN_v03.xsd,
_AddressInp_v02.xsd)
Location
(RequestGKN_v03.xsd)
;
Street
(_AddressInp_v02.xsd)
Справочник типов
адресных элементов
первого уровня
Предоставление
сведений ГКН
(RequestGKN_v03.xsd,
Location
(RequestGKN_v03.xsd)
;
gender
Fault
ProcessingCode
Location
(RequestGKN_v03.xsd)
;
Region
(_AddressInp_v02.xsd)
Location
(RequestGKN_v03.xsd)
;
District
(_AddressInp_v02.xsd)
Location
(RequestGKN_v03.xsd)
;
City
(_AddressInp_v02.xsd)
(dLocationLevel1Type) _AddressInp_v02.xsd)
Level1
(_AddressInp_v02.xsd)
Location
(RequestGKN_v03.xsd)
;
Level2
(_AddressInp_v02.xsd)
Location
(RequestGKN_v03.xsd)
;
Level3
(_AddressInp_v02.xsd)
Location
(RequestGKN_v03.xsd)
;
Apartment
(_AddressInp_v02.xsd)
ObjKind – вид
объекта
недвижимости по
классификатору
Справочник типов
адресных элементов
второго уровня
(dLocationLevel2Type)
Предоставление
сведений ГКН
(RequestGKN_v03.xsd,
_AddressInp_v02.xsd)
Справочник типов
адресных элементов
третьего уровня
(dLocationLevel3Type)
Предоставление
сведений ГКН
(RequestGKN_v03.xsd,
_AddressInp_v02.xsd)
Справочник типов
адресных элементов
четвертого уровня
(dApartmentType)
Предоставление
сведений ГКН
(RequestGKN_v03.xsd,
_AddressInp_v02.xsd)
Справочник видов объектов
государственного кадастра
недвижимости (ГКН) и
Единого государственного
реестра прав на
недвижимое имущество и
сделок с ним (ЕГРП)
(dRealty)
Справочник типов ранее
присвоенного номера
(dOldNumber)
Предоставление
сведений ГКН
(RequestGKN_v03.xsd)
Предоставление
сведений ГКН
(CadastralCostDoc_v0
3.xsd,
_Numbers_v01.xsd)
OldNumbers
(CadastralCostDoc_v0
3.xsd);
Type
(_Numbers_v01.xsd)
Справочник типов
субъектов правоотношений
(dGovernanceCode)
Предоставление
сведений ГКН
(RequestGKN_v03.xsd,
_Governance_v01.xsd)
Предоставление
сведений ГКН
(RequestGKN_v03.xsd)
Предоставление
сведений ГКН
(RequestGKN_v03.xsd)
Governance
(RequestGKN_v03.xsd)
GovernanceCode
(_Governance_v01.xsd)
declarantKind
Предоставление
сведений ГКН
(RequestGKN_v03.xsd)
Предоставление
сведений ГКН
(RequestGKN_v03.xsd,
_Document_v01
v03.xsd)
RecipientType
Справочник категорий
подателей запросов
(dDeclarantKind)
Справочник лиц,
выступающих в качестве
представителей
правообладателя, стороны
договора
(dAgentKind)
Справочник видов адресата
(dAddressee)
Классификатор
документов
(dAllDocuments)
agentKind
CodeDocument
Общие
справочни
ки
Справочник типов
приложенных файлов
(dApplied_file)
Предоставление
сведений ГКН
(RequestGKN_v03.xsd,
_Document_v01
v03.xsd)
Справочник типов
документов,
удостоверяющих личность
Все виды, в которых
приводятся сведения
о документах,
удостоверяющих
личность
(smev-supplementarycommons.xsd)
Например,
предоставление
сведений ГКН
(RequestGKN_v03.xsd),
(_MunicipalService_v0
1.xsd)
Справочник
государственных и
муниципальных услуг
AppliedFile
(RequestGKN_v03.xsd)
;
Kind
(_Document_v01
v03.xsd)
Например,
CopyDocument
(RequestGKN_v03.xsd)
MunicipalServic
e
(RequestGKN_v03.xsd)
;
Service
(_MunicipalService_v0
1.xsd)
Приложение №3
Порядок подключения к стенду тестирования СМЭВ 3.0
При наличии настроенного канала для подключения к ФСМЭВ необходимо только
настроить маршрутизацию на оборудовании ФОИВ к адресу СМЭВ 3.0 "172.20.3.12" ,
аналогично продуктивному ФСМЭВ 172.16.90.14.
Для подключения новых участников к СМЭВ необходимо:
 Выполнить требования п.1 данной инструкции
 Заполненный опросник (Форма технических сведений Участника п.3 данной
инструкции) необходимо направить на smev@gosuslugi.ru
 Использовать для обращения к СМЭВ ip - 172.20.3.12
1. Требования к Участникам информационного взаимодействия при подключении
криптомаршрутизатора VipNet
1.Обеспечить физическое размещение оборудования VipNet HW1000 на площадке
Участника (2 (двух) мест размером 19 дюймов Rack 1U (для установки в стойку глубиной
от 480 мм и более) 432х43х355 (ШхВхГ) каждое);
2.Обеспечить подключение оборудования максимальной потребляемой мощностью
200 Вт к сети гарантированного электропитания питания 220 В с помощью кабеля типа
С13 – СЕЕ7/7 (евровилка);
3. Обеспечить возможность подключение к сетевому оборудованию Участника
интерфейсов криптомаршрутизатора с использованием интерфейсов Ethernet Base T
100/1000;
4.Обеспечить связность на втором уровне модели OSI/ISO внутренних интерфейсов
криптошлюзов при кластерном подключении, другими словами, разместить двух
физических интерфейсов в одном широковещательном сегменте.
5.При подключении через сеть Интернет обеспечение доступности внешнего
интерфейса криптошлюза (IP внеш.) из сети Интернет одним из следующих способов:
5.1.Обеспечение NAT-трансляции частного IP-адреса в публичный IP-адрес
(трафик по протоколу UDP, порт 55777).
5.2.Выделение для интерфейса публичного IP-адреса.
5.3.Обеспечение отсутствия логических препятствий для прохождения трафика по
порту UDP 55777 между внешним интерфейсом криптошлюза (IP внеш.) и адресом
криптошлюза ЦОД.
6.Обеспечить маршрутизацию в локальной сети Участника таким образом, чтобы
трафик с адресов серверов Участника, отправляемый на серверы ЦОД, направлялся на
внутренний интерфейс криптомаршрутизатора;
7.При подключении АРМов, обеспечить трансляцию адресов АРМов в один адрес,
принадлежащий сети внутреннего интерфейса криптошлюза.
Допускается не использовать трансляцию адресов при подключении единственного
АРМа.
8.Обеспечить выделение IP-адресов в соответствии с требованиями указанными в
форме технических сведений Участника и типовыми схемами организации подключения.
9.Обеспечить возможность взаимодействия с реальными IP адресами серверов
информационных систем СМЭВ.
10.Настройка, администрирование и управление оборудованием, обеспечивающим
криптографическую защиту каналов связи со СМЭВ в части сегмента Участника,
осуществляется оператором эксплуатации ИЭП. Самостоятельная настройка,
администрирование и управление оборудованием, обеспечивающим криптографическую
защиту каналов связи со СМЭВ в части сегмента Участника, со стороны Участника не
допускается.
2. Типовые схемы организации подключения
Подключение Участников к защищенной сети передачи данных производится в
соответствии с одной из двух приведенных в настоящем разделе типовых схем, с учетом
следующих условий:
1. Подключение Участника являющегося поставщиком информации должно быть
реализовано в соответствии с типовой схемой 1
2. Подключение Участника являющегося только потребителем информации,
рекомендуется реализовать в соответствии с типовой схемой 1, по согласованию
Оператора эксплуатации ИЭП допускается реализация в соответствии с типовой схемой 2.
Типовая схема 1
Типовая схема 2
3. Форма технических сведений Участника
Наименование
Участника
Федеральный
Статус
Почтовый адрес
Юр. адрес
Потребность в
услугах ЭП
Контактные
данные
Адм. лицо,
ответственное за
подключение
Ф
ИО
Сетевой
инженер
Ф
ИО
Лицо,
ответственное за ИБ
Ф
ИО
Объект
подключения
Региональный
Пилотное тестирование СМЭВ 3,х
Рабочий
телефон
Адрес
Мобильн
ый телефон
Этаж
Е-mail
Помещ
ение
Наличие
подключения
Интерне
т
IP/MPLS
сеть
ОАО
«Ростелеком»
Отсутс
твует
Предпочтитель
ный
вариант
подключения
Предпочтитель
6.1
6.2
ная
типовая
схема
подключения согласно
п. 6.1, 6.2 ТТ
Параметры
Интерфе
Парам
имеющегося
Тип
йс
етры
оборудования
Коммутатор
Ethernet
Граничный
маршрутизатор ЛВС
Наличие и тип
H
H
H
HW100
имеющегося
для
W1000
W100A
W100B
C
подключения
х
оборудования ViPNet
Кол-во
оборудования
ViPNet
успользуемого конкретно
для подключения к ИЭП
ОАО «Ростелеком»
Потребность
в
закупке
оборудования
ViPNet
через
ОАО
«Ростелеком»
№
IP
Назначение
адрес/маска
1
IP
IP-адрес и маска сети внешнего интерфейса криптошлюза.
1.1 внеш./маска
Может быть как из частного, так и из публичного адресного
1.2
пространства.
1.3
В случае отказоустойчивого кластера должны быть выделены
3 адреса одной подсети.
В случае подключения через IP/MPLS-сеть ОАО
«Ростелеком» данные адреса не указываются.
2
IP gw внеш.
Адрес шлюза по умолчанию в сети, в которую включается
внешний интерфейс криптошлюза.
В случае подключения через IP/MPLS-сеть ОАО
«Ростелеком» данные адреса не указываются.
3
IP fw (NAT)
Публичный Интернет адрес NAT-трансляции, через который
осуществляется доступ к внешнему интерфейсу криптошлюза.
Указывается в случае использования частного адреса на
внешнем интерфейсе криптошлюза при подключении через
сеть Интернет.
4
IP внут./маска
4.1
4.2
4.3
5
IP gw внут.
6
IP сер.
7
IP арм
8
Серийные
номера
Адрес и маска сети внутреннего интерфейса криптошлюза.
В случае отказоустойчивого кластера должны быть выделены
3 адреса одной подсети.
IP внеш. и IP внут. обязательно должны принадлежать разным
подсетям.
Адрес шлюза для доступа к внутренним ресурсам ведомства.
Указывается в случае нахождения ресурсов ведомства и
внутреннего интерфейса криптошлюза в разных сетях.
Адрес (а) сервера (ов) ОИВ, которые будут взаимодействовать
с серверами ЦОД.
Адрес устройства NAT, через который осуществляется
взаимодействие АРМов и серверов ЦОД.
Серийные номера криптошлюзов («Лицензионный номер
ПАК», начинается с 30-…).
ПРИЛОЖЕНИЕ №4
ПРОТОКОЛ
совместного тестирования Вида сведений Единой системы
межведомственного электронного взаимодействия
г. _________
«___» _______ 20___
В рамках реализации мероприятий по переходу на электронное межведомственное
взаимодействие при оказании государственных услуг <Наименование Поставщика
сведений> (далее – Поставщик информации) <осуществил> проектирование и разработку
следующего Вида сведений1 Единой системы межведомственного электронного
взаимодействия версии 3.х (далее – СМЭВ):
<Наименование Вида сведений, краткое описание>
Министерство связи и массовых коммуникаций Российской Федерации (далее –
Оператор СМЭВ) на основе полученных от Поставщика информации описаний
указанного Вида сведений и контрольных примеров проверки их функционирования
обеспечило регистрацию разработанного Вида сведений в реестре Видов сведений СМЭВ
и доступность данного Вида сведений для использования при оказании государственных
(муниципальных) услуг (функций).
<Наименование Потребителя сведений> (далее - Потребитель информации)
<осуществил> тестирование электронного Вида сведений Поставщика информации с
использованием продуктивной среды СМЭВ и подтверждает его работоспособность, а
также соответствие реквизитного состава Вида сведений, предоставляемых Поставщиком
информации, перечню Вида сведений из согласованных описаний Видов сведений.
Совместное тестирование проводилось в соответствии с Методикой проведения
тестирования взаимодействия в продуктивном контуре СМЭВ по Методическим
рекомендациям по разработке электронных сервисов и применению технологии
электронной подписи версии 3.х (далее – Методические рекомендации). Успешность
тестирования определяется наличием не менее 100 успешно обработанных подряд пар
запросов и ответов по Виду сведений в СМЭВ 3.0 в течение недели, а также
эквивалентностью полученных результатов по этим же запросам в СМЭВ 2.0.
Результаты проведения совместного тестирования Вида сведений системы
межведомственного электронного взаимодействия приведены в Таблице 1.
Таблица 1. Результаты тестирования
№
п.п.
Оцениваемый показатель
Оценка выполнения
1
Успешная обработка запросов и ответов по Виду сведений (не
менее 100 успешно обработанных подряд пар запросов и ответов
по Виду сведений в СМЭВ 3.0 в течение недели)
2
Проведение тестирования с использованием Файлового хранилища
<выполнено/
не проводилось>
3
Проведение тестирования с проверкой справочников ЕСНСИ
<выполнено/
не проводилось>
<выполнено>
Вид сведений в тестовой среде и в продуктивной среде СМЭВ разработан в соответствии с
Методическими рекомендациями версии 3.х
1
Поставщик информации не возражает против публикации документации на
разработанный Вид сведений (описание Вида сведений, контрольный пример).
От Поставщика информации:
<Должность>
__________<Подпись>_________
<ФИО>
От Потребителя информации:
<Должность>
__________<Подпись>_________
<ФИО>
__________<Подпись>_________
<ФИО>
От оператора СМЭВ:
<Должность>