Правила разработки форматов ВС СМЭВ 3

Правила
разработки форматов взаимодействия с использованием
Единого электронного сервиса
Единой системы межведомственного электронного взаимодействия.
Общие положения:
1. Данный документ разработан разработан для определения порядка
разработки форматов взаимодействия с использованием Единого
электронного сервиса Единой системы межведомственного электронного
взаимодействия (далее – в СМЭВ) в целях реализации федеральными
органами исполнительной власти части 7 статьи 7.1 Федерального закона от
27 июля 2010 г. № 210-ФЗ «Об организации предоставления государственных
и муниципальных услуг» (далее – сведения)
2. Предоставление сведений осуществляется путем обмена
электронными сообщениями через СМЭВ.
3. Электронные сообщения формируются в виде файлов в формате
XML с использованием правил, определенных в файлах описания структуры
XML- документов.
4. Передача электронных сообщений, содержащих сведения,
осуществляется с использованием соответствующих видов сведений СМЭВ.
5. Таким образом, установление требований к формату
взаимодействия в СМЭВ подразумевает разработку вида сведений.
6. Вид сведений представляет собой комплект документации,
определяющий технические требования и особенности предоставления
конкретных сведений в СМЭВ.
7. Вид сведений разрабатывается федеральным органом власти или
государственным
внебюджетным
фондом
Российской
Федерации,
определенным Правительством Российской Федерации в качестве
ответственного за разработку формата взаимодействия в СМЭВ и (или)
требований к формату предоставления сведений, рекомендаций по
определению форматов предоставления сведений.
8. Вид сведений считается утвержденным после прохождения
экспертизы в Минкомсвязи России и публикации на Технологическом
портале СМЭВ 3.
9. Все поставщики и потребители вида сведений обязаны
осуществлять взаимодействие в соответствии с документацией по виду
сведений.
10. При разработке видов сведений следует руководствоваться
актуальной версией Методических рекомендаций по работе в СМЭВ,
опубликованной на технологическом портале.
Состав документации по виду сведений.
1
11. В момент подачи на регистрацию в СМЭВ вида сведений,
подготовленное руководство пользователя предоставляется оператору СМЭВ
в zip-архиве специальной структуры, содержащем помимо данного
руководства:
11.1.Заявку на регистрацию вида сведений;
11.2.XSD-схема(ы) вида сведений. Если схема вида сведений содержит
вложенные схемы, необходимо предоставлять zip-архив, со следующей
структурой: в корневой папке находится целевая схема и папка, в этой папке –
все импортируемые схемы;
11.3.Эталонный(е) запрос(ы) и ответ(ы). Эталонные запросы и ответы
для вида сведений необходимо именовать Request.xml и Response.xml
соответственно (если эталонных запросов и ответов не одна пара, а несколько,
тогда они должны быть заархивированы в zip-архив, причем каждая пара
запрос-ответ в отдельной папке):
11.4.Описание тестового сценария и XSL-схема(ы) тестового(ых)
сценария(ев).
11.5.Формат zip-архива должен быть следующей структуры:
- \Руководство пользователя
- \Заявка на регистрацию вида сведений
- \Схема.zip
- \Эталоны.zip
- \Тестовый сценарий.zip
Правила разработки руководства пользователя вида сведений.
12. Последующее
документирование
вида
сведений,
с
использованием которого будут передаваться сведения, осуществляется на
основе руководства пользователя.
13. При
разработке
руководства
пользователя
необходимо
использовать
Формат
руководства
пользователя
разработанный
Минкомсвязью России.
14. При разработке вида сведений заполняются следующие разделы
руководства пользователя:
12.1. В разделе «Общие сведения»:
Описание вида сведений:
При описании вида сведений необходимо указать наименование вида
сведений, ID вида сведений в ФРГУ, содержание, поставщика, потребителя,
назначение вида сведений, область применения, тип запроса, тип
маршрутизации, версию вида сведений, версию методических рекомендаций,
в соответствии с которой разработан формат вида сведений
12.2. В разделе «Схема вида сведений и эталонные запросы и ответы»:
Схема вида сведений:
Указывается наименование основной XSD–схемы вида сведений и
приводится ее полный текст. Если основная схема содержит
импортированные схемы, их наименования и текст также необходимо указать
2
отдельно.
При описании структур данных (XSD-схем) обязательной является
жесткая типизация всех элементов, как содержащих прикладные сведения, так
и технологические элементы, используемые при взаимодействии, а также
иерархии данных элементов. Не допускается использовать при описании
элементов конструкций, допускающих двоякое трактование сведений,
содержащихся внутри элементов (например, таких как xsd:anySimpleType,
xsd:AnyURI, где пространство имен xsd описано в соответствии http://www.w3
.org/2001/XMLSchema).
Эталонные запросы и ответы:
Указывается не полный конверт, а часть бизнес-данных запроса и
ответа. Если у вида сведений существует несколько пар эталонных запросов и
ответов, тогда необходимо указывать их все, причем в связке запрос–ответ
12.3. В разделе «Тестовые сценарии»:
Тестовый сценарий:
Указывается наименование сценария, идентификатор сценария (xpath),
пространство имен используемое в xpath идентификатора сценария,
наименование XSL-файла, используемого для генерации автоматического
ответа в данном сценарии, текст XSL-файла, наименование контрольного
примера, идентификатор контрольного примера (xpath) и пространство имен,
используемое в xpath идентификатора контрольного примера. Если у вида
сведений несколько тестовых сценариев, необходимо указывать каждый
сценарий с полным его описанием в отдельном пункте.
12.4. В разделе «Состав передаваемой информации»:
Описание полей запроса:
Для каждого поля указывается код поля в XSD-схеме, описание
информации (передаваемой в поле), описание требований к содержанию поля,
описание типа заполнения, при необходимости указывается дополнительная
информация.
Описание полей ответа на запрос:
Для каждого поля указывается код поля в XSD-схеме, описание
информации (передаваемой в поле), описание требований к содержанию поля,
описание типа заполнения, при необходимости указывается дополнительная
информация.
Описание комплексных типов полей (при наличии):
Для каждого поля указывается код поля в XSD-схеме, описание
информации (передаваемой в поле), описание требований к содержанию поля,
описание типа заполнения, при необходимости указывается дополнительная
информация.
Описание проверок запроса на стороне поставщика:
Для каждого поля указывается местоположение поля (технологические
поля СМЭВ, бизнес поля запроса или блок ЭП), код поля, описание
процедуры проверки, описание возможных результатов проверки и
соответствующих ответов сервиса, при необходимости указывается
дополнительная информация.
3
Описание кодов возвратов при ошибках и неуспешных проверках:
Для каждого поля указывается код поля, описание значения
(содержащегося в поле), описание причины возникновения ошибки/отказа в
предоставлении сведений, при необходимости указывается дополнительная
информация. Обязательно должны в явном виде присутствовать коды
мотивированного отказа в предоставлении сведений по причинам отсутствия
запрашиваемой информации и отказа в предоставлении доступа к
запрашиваемой информации.
Описание вложений:
Если вид сведения подразумевает наличие вложений, то необходимо в
данном разделе описать требования по формату файлов, особенности
связанные с работой файлового хранилища СМЭВ, и ограничение по объему
вложений, с учетом ограничения СМЭВ: суммарный объем файлов,
передаваемых одним сообщением не должен превышать 1 Гб.
12.5. В разделе «Дополнительная информация»:
Состав справочной информации:
Указывается
перечень
используемых
справочников.
При
использовании справочников, владельцем которых не является разработчик
вида сведения, необходимо давать прямую отсылку на ресурс где
опубликован справочник и размещать актуальную версию с обязательным
указанием даты в приложении к руководству пользователя.
Контактная информация:
Указываются контактные данные представителя разработчика формата
вида сведений для обращения пользователей в случае возникновения
вопросов. Заполнение контактной информации обязательно только в случае
отсутствия разработчика формата вида сведения в Ситуационном центре
электронного правительства (далее - СЦ). В случае, когда разработчик
формата вида сведения, подключен к СЦ, предоставление иной контактной
информации является добровольным.
Примечания:
Указываются иные сведения, которые необходимы потребителям и
поставщикам вида сведения.
4