Специальные возможности Промежуточные запросы к сервису при заполнении ИФ В ходе заполнения заявления может возникнуть необходимость сделать запрос к сервису ведомства для получения дополнительной информации для отображения пользователю. При этом следует избегать и минимизировать подобные взаимодействия, по причине замедления процесса заполнения формы и зависимости возможности заполнения заявления от доступности сторонних для ЕПГУ сервисов и систем.
Использование словарей 1.1.1.1.Встроенные словари На интерактивных формах может потребоваться выбор значений из справочников.
Компоненты, реализующие данную функциональность содержатся в библиотеках типового функционала ЕПГУ и их изменение не рекомендуется.
Справочники могут иметь плоскую (одноуровневую) или иерархическую (многоуровневую) структуру. Иерархия может быть как внутри одного справочника, так и между несколькими справочниками.
На форме заявителю доступен выбор единственного элемента из значений справочника.
В случае если справочник содержит малое количество значений (в пределах 5), с точки зрения пользователя, удобнее представлять его на интерактивной форме в виде радиокнопок.
Справочники можно разделить на несколько типов:
Общероссийские справочники, состав которых закреплен нормативными документами. К ним относятся: ОКАТО – справочник территорий, ФИАС – справочник адресов, ОКСМ – общероссийский классификатор стран мира.
Справочники, специфические для ведомства (ОИВ). В случае если справочник не обновляется и содержит не более 500 значений, его возможно хранить в БД ЕПГУ. В этом случае необходимо в разделе «Приложение 1» технического описания интерактивной формы (на услугу) привести описание справочника.
Описание ведомственного справочника рекомендуется предоставить в виде файла с расширением .csv (в качестве разделителя должна быть выбрана запятая). Файл должен содержать 6 столбцов в определенном порядке:
1. Код - Код элемента, который необходимо присвоить элементу справочника. Внутри справочника коды элементов должны быть уникальны. Данный атрибут обязателен для каждого элемента.
2. Название – Название элемента справочника, т.е. то, что будет отображаться пользователю на форме. Данный атрибут обязателен для каждого элемента.
3. Код родительского элемента – Родительский элемент, на который ссылается текущий. Необходимо, чтобы код самого родительского элемента содержался в первом столбцев одной из строк таблицы. Также, необходимо избегать циклических зависимостей: т.е. чтобы родительский элемент не ссылался на дочерний элемент, как на родителя. Если хотя бы у одной из строк в столбце «Код родительского элемента» не пусто, значит, тип справочника – многоуровневый, иначе, справочник одноуровневый.
4. Дополнительный код – Например, внешний код элемента справочника.
5. Порядковый номер – Номер элемента в справочнике, может использоваться для вывода элементов на форму с учетом указанного порядка.
6. Статус – Активный или деактивированный элемент { A , D }.
Пример файла, содержащего описание справочника:
Файл должен быть приложен в разделе «Приложение 1» технического описания интерактивной формы (на услугу).
Допускается описание справочника в виде таблице в разделе «Приложение 1» технического описания интерактивной формы (на услугу).
Таблица 3 Пример представления справочника ведомства в техническом описании интерактивной формы
-
Название справочника
| Код элемента справочника (передаваемый в ИС ФОИВ)
| Значение элемента справочника
| Порядковый номер элемента в справочнике
| Калибр оружия
| 1057X
| 10,57X72
| 1
| 57X
| 5,7X49
| 2
| Типы лицензий и разрешений
| RLSA
| Разрешение на хранение и ношение при исполнении служебных обязанностей. Служебного оружия
| 1
| RNGA
| Разрешение на право хранения и ношения наградного оружия
| 2
|
Таблица 4 Пример представления иерархического справочника ведомства в техническом описании интерактивной формы
-
Название справочника
| Код родительского элемента справочника (пустой для корневых элементов)
| Код элемента справочника (передаваемый в ИС ФОИВ)
| Значение элемента справочника
| Порядковый номер элемента в справочнике
| Отделения службы судебных приставов
| -
| 77000
| УФССП по г. Москва
| 1
| -
| 02000
| УФССП по Республике Адыгея
| 2
| 02000
| 02001
| Майкопский ГОСП
| 3
|
В случае если справочник содержит один дополнительный атрибут, который должен присутствовать на интерактивной форме (например, Регион (субъект РФ) и Наименование соответствующего ему территориального отделения ОИВ), это может быть реализовано на стороне ЕПГУ (храниться в БД ЕПГУ) в виде двух справочников, между которыми установлена иерархия (для приведенного примера справочник «Регионы» будет являться родительским, справочник «Территориальные отделения ОИВ» - дочерним).
1.1.1.2.Вызываемые словари В случае если справочник содержит дополнительные атрибуты (более одного), которые должны присутствовать на интерактивной форме, его необходимо получать от сервиса органа власти. Шаблон, преобразующий данные, полученные от сервиса ведомства в формат типового элемента формы, разрабатывается для каждого ведомственного справочника (или ИФ).
В случае если справочник ИС ФОИВ часто обновляется (пополняется) или содержит большое количество элементов, ФОИВ необходимо реализовать отдельный вид сведений для получения значений справочника, и зарегистрировать его в СМЭВ 3.0.
В случае если справочник является динамическим (например, запись граждан на прием в ведомстве, запись в ГИБДД, и т.д.), также необходимо реализовывать отдельный вид сведений для получения значений справочника, и зарегистрировать его в СМЭВ 3.0.
Сообщения, содержащие запросы к виду сведений для получения значений справочника, должны соответствовать использованной при регистрации вида сведений версии методических рекомендаций по работе с Единой системой межведомственного электронного взаимодействия версии 3.0.
Примеры запросов приведены в Приложении 2.
Работа с ЭП Согласно методическим рекомендациям по работе с Единой системой межведомственного электронного взаимодействия версии 3.0. все заявления, отправляемые с ЕПГУ в ИС ФОИВ, подписываются электронной подписью ЕПГУ (подписывается блок SenderProvidedRequestData сообщения). При наличии соответствующих требований заявление и приложенные к нему файлы могут подписываться ЭП пользователя.
Для всех интерактивных форм устанавливается один из признаков работы с ЭП заявителя:
Подпись заявления ЭП заявителя не требуется.
Подпись заявления личной подписью заявителя обязательна.
В случае если подпись заявления обязательна, после заполнения всех полей интерактивной формы пользователь выполняется подписание ЭП заявления в следующей последовательности:
Пользователю отображается шаг просмотра и подписания всех приложенных к заявлению документов (см. рис. 15);
После подписания выполняется возвращение на форму заявления;
Пользователю отображается шаг просмотра и подписания заявления.
Рисунок 27. Шаг услуги с подписанием заявления и вложений ЭП
Подписание документов возможно только в том случае, если пользователь подтвердил факт просмотра всех подписываемых документов.
При клике на кнопку «Подписать» у пользователя запрашивается ПИН-код электронного носителя ЭП (пароль, выдаваемый вместе с электронным носителем ЭП):
Рисунок 28. Модальное окно для ввода ПИН-кода электронного носителя ЭП
В случае успешного формирования подписи пользователю отобразятся сведения о сформированных электронных подписях:
Рисунок 29. Информационный блок, содержащий сведения об электронных подписях
При клике на кнопку «Вернуться» происходит возврат на интерактивную форму заявления, с которого осуществлялся переход на подписание ЭП.
Компоненты, реализующие данную функциональность, относятся к общему функционалу ЕПГУ и не подлежат изменению при разработке ИФ.
Пописание ЭП заявителя В виде сведений должен быть предусмотрен блок описания прилагаемых файлов:
Группа вложений описывается элементом запроса вида сведений AppliedDocuments.
Каждое вложение описывается одним элементом AppliedDocument.
Каждый элемент AppliedDocument должен содержать следующие элементы:
Имя поля
| Тип поля
| Назначение
| CodeDocument
| digits-4
| Номер документа.
| Name
| string-200
| Имя файла загруженного документа.
| URL
| string-200
| Относительный путь к файлу внутри архива.
| BusinessName
| string-200
| Имя приложения в соответствии с бизнес-правилами
| Type
| string-200
| Тип контента (например: application/pdf или любой другой общепринятый MIME-тип)
| DigestValue
| string-100
| Хэш файла в соответствии с ГОСТ
| Все типы полей указаны в пространстве имен urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1.
Поле URL формируется из мнемоники элемента «Загрузка файла».
Поле BusinessName формируется из атрибута «Бизнес-наименование документа» элемента управления «Загрузка файла».
Атрибут «Бизнес-наименование документа» элементов «Загрузка файла» указывается в соответствии с атрибутом «Название переменной в XML» описания полей (раздел 5 типового Технического задания на размещение услуги). Бизнес-наименования документов должны быть уникальны в рамках формы. При использовании поля «клонируемая панель» с элементами «Загрузка файла» бизнес-наименования элементов остаются неизменными во всех клонируемых панелях.
Файл XML-запроса вида сведений в блок описания вложений не вносится.
Ниже схема данных в формате ERD на примере запроса EIPApprovalRequestService.
Рисунок 30 схема данных описания вложений
Из файлов и ЭП в формате PKCS#6 detached ЕПГУ сформирует архив в формате zip содержащий:
Заявление в информационную систему Поставщика вида сведений в формате запроса вида сведений с описью прилагаемых файлов.
Электронную подпись пользователя ЕПГУ, соответствующую файлу заявления на основе стандарта PKCS#7 (detached).
Вложения в виде файлов форматов, согласованных с поставщиком сервиса (при наличии);
Электронные подписи пользователя ЕПГУ, соответствующие каждому из файлов вложений, передаваемых в архиве, на основе стандарта PKCS#7 (etached).
Имя файла заявления в формате XML вкладываемого в архив фиксировано: Request.xml.
Файл заявления должен лежать в корневом каталоге архива.
Имя архива является фиксированным: SignedContent.zip.
Электронные документы и их электронные подписи могут находиться на любом уровне вложенности в архиве, но пути должны быть указаны в xml-файле заявления в соответствии с форматом, указанным выше.
Файлы электронной подписи для заявлений и вложений в формате PKCS#7 (detached) имеют формализованное правило именования, при котором к имени исходного файла добавляется постфикс *.sig.
Пример именования файла подписи указан в таблице ниже.
Наименование файла
| Наименование файла подписи
| Request.xml
| Request.xml.sig
| attachment.txt
| attachment.txt.sig
| Подписание производится КСКП заявителя в соответствии с требованиями п. 4.2.1 МР СМЭВ 3, и в соответствии с правилами 4.4.2.1 МР СМЭВ 3.
Запрос вида сведений, передаваемый в составе СМЭВ 3-конверта (//MessagePrimaryContent) и в архиве должны быть полностью идентичны.
|