Инструкция по витринам данных

Содержание статьи

• Термины и сокращения
• Общая информация
• Создание и подготовка витрин к использованию
• Получение доступа к витрине данных на ЕПГУ
• Внедрение витрин на ЕПГУ. Разработка шаблона ВКУ по встраиванию витрин в услуги
• Разработка справочников NSI под РЗ
• Разработка экранов шаблона
• Вызов справочников с экранов шаблона
• Компонент BackRestCall
• Настройка атрибутов BackRestCall

Термины и сокращения

Витрина данных — комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ.

Регламентированный запрос (РЗ) — SQL-запрос, выраженный в терминах Модели данных, загруженной в ПОДД, и зарегистрированный в Ядре ПОДД СМЭВ под символической мнемоникой, используемой ИС Потребителя ПОДД СМЭВ для выполнения регламентированного запроса. Может иметь параметры, значения которых задаются Потребителем данных ПОДД СМЭВ при выполнении регламентированного запроса.

ПОДД СМЭВ — подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещённым на витринах данных.

Агент ПОДД — типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ.

ЕИП НСУД (ФГИС ЕИП НСУД) — федеральная государственная информационная система «Единая информационная платформа Национальной системы управления данными».

Единая система контекстных справок (ЕСКС) — справочный интернет-ресурс, посвящённый СМЭВ, в том числе содержащий методические рекомендации, иную документацию по работе со СМЭВ, обеспечивающий информирование участников взаимодействия об изменении такой документации, изменениях в работе со СМЭВ, иных изменениях, функционирующий согласно Методическим рекомендациям по работе со СМЭВ. Доступен по адресу https://info.gosuslugi.ru

Шаблон ВКУ — набор настраиваемых экранов, который заключает в себе единую бизнес-функцию, а также позволяющий быстро разработать услугу, не вникая в детали реализации этой бизнес-функции.

Платформа обратной связи (ПОС) — информационный ресурс ЕПГУ, предназначенный для обеспечения возможности подачи обращений гражданами через единое окно подачи обращений — электронные формы, размещенные на официальных сайтах органов государственной власти (учреждений) в сети «Интернет» и на ЕПГУ.

Общая информация

Цель создания витрин данных:

• ускорение оказания государственных и муниципальных услуг путём сокращения времени на межведомственное взаимодействие посредством получения автоматических ответов из информационных систем органов и организаций государственного сектора;
• предоставление списка доступных данных из информационных систем органов и организаций государственного сектора, которые необходимы заявителю в ходе оказания государственных и муниципальных услуг;
• проверка корректности введенных данных заявителя при оказании государственных и муниципальных услуг;
• получение выписок (юридически значимых и информационного характера) из информационных систем органов и организаций государственного сектора по данным заявителя для дальнейшего использования их в оказании других государственных и муниципальных услуг, а также просто для информирования заявителя. Выписки в формате pdf всегда формирует на своей стороне поставщик данных (на стороне витрины).

Рисунок 1 — информационный обмен с использованием витрин данных

Подсистема обеспечения доступа к данным (ПОДД) — системы межведомственного электронного взаимодействия (СМЭВ 4) предназначена для передачи сведений между информационными системами (ИС) участников взаимодействия (УВ). Каждый УВ может быть, как потребителем, так и поставщиком данных.

Сведения, предоставляемые поставщиком, хранятся в витринах данных. Для получения сведений из витрин поставщиков ИС потребителя отправляет SQL-запрос через ПОДД, которая обеспечивает передачу запрошенной информации с учетом разграничения доступа к сведениям.

В качестве SQL-запроса может быть использован РЗ, который является зафиксированным SQL-запросом к витрине данных, заранее зарегистрированным в ПОДД. РЗ может содержать параметры, задаваемые при его вызове.

На стороне поставщика устанавливается ПО для поддержки витрины данных и ПО Агента ПОДД для связи с ядром ПОДД. Поставщик через ЕИП НСУД регистрирует модель данных витрины, содержащую структуру таблиц витрины, а также РЗ для данной витрины в ядре ПОДД. Агент ПОДД поставщика и витрины поставщика взаимодействуют через зарезервированные топики Kafka.

Загрузка данных в витрины осуществляется через JDBC-драйвер, REST API или CSV-файлы (через web-интерфейс или настроенную общую папку).

На стороне потребителя устанавливается ПО Агента ПОДД, который обеспечивает связь с ядром ПОДД для получения данных витрин поставщиков.

При информационном взаимодействии поставщика и потребителя выполняется следующий порядок действий:

1. ИС потребителя формирует РЗ к витрине данных поставщика.
2. РЗ передается агенту ПОДД через REST API.
3. Агент ПОДД подписывает запрос электронной подписью (ЭП) органа власти (ОВ) и передает его в ядро ПОДД.
4. Ядро ПОДД:
• проверяет корректность ЭП ОВ;
• проверяет полномочия на получение данных;
• выполняет преобразование РЗ в SQL-выражение, согласно метаданным, установленным при его регистрации РЗ в ПОДД. В результате формируется один или несколько SQL-запросов в витрину;
• проверяются технические ограничения на выполнение запросов (на объем данных, интенсивность запросов отправителя).
5. Каждый SQL-запрос передается соответствующему агенту ПОДД поставщика данных.
6. Агент ПОДД поставщика:
• проверяет корректность ЭП ОВ;
• проверяет условия доступа к запрошенным данным;
• помещает SQL-запрос в топик Kafka.
7. Витрина данных поставщика получает SQL-запрос из Kafka, выполняет его и отправляет результат в Kafka.
8. Агент ПОДД поставщика получает результат запроса из Kafka, подписывает его ЭП ОВ и отправляет в ядро ПОДД.
9. Ядро ПОДД проверяет ЭП ОВ и ожидает завершения всех отправленных SQL-запросов.
10. После получения результатов по всем SQL-запросам ядро ПОДД отправляет общий результат агенту ПОДД потребителю, отправившему запрос.
11. Агент ПОДД потребителя проверяет ЭП ОВ и отправляет результат в ответе на соответствующий запрос REST API.

Подробное описание работы ПОДД содержится в «Методические рекомендации по работе с ПОДД СМЭВ».

Создание и подготовка витрин к использованию

Для использования витрин данных в оказании государственных и муниципальных услуг необходимо проделать ряд мероприятий:

1. Описать информационные ресурсы и их атрибуты, а также пройти согласование (стр. 18-32 Инстркция ЕИП НСУД).
2. Описать информационную систему, её атрибуты и группы атрибутов (стр. 36-52 Инстркция ЕИП НСУД).
3. Описать модель витрины данных (стр. 69-91 Инстркция ЕИП НСУД).
4. Подписать и отправить на согласование введенную информацию о витрине данных.
5. Подключить витрину данных к ПОДД СМЭВ в тестовой и продуктивной среде (стр. 91-102 Инстркция ЕИП НСУД) с предварительным развертыванием витрины данных и агента подд на этих средах (Руководство администратора агента ПОДД СМЭВ).
6. Обеспечить постоянное функционирование тестовой витрины данных, обеспечить ее наполнение тестовыми данными, а также их дальнейшую поддержку в процессе тестирования с потребителями витрины данных.
7. Описать регламентные запросы в витрину и согласовать их (стр 132-139).
8. Зарегистрировать регламентный запрос в тестовой и продуктивной среде (стр. 444-448 Руководство пользователя ЛК УВ). Обращаем внимание, что ведомство должно самостоятельно контролировать переход на новые версии РЗ своих потребителей, а также вывод из эксплуатации старых версий РЗ.
9. Ведомство определяет плановые нагрузки на витрину и направляют в адрес ЕПГУ (в чат по координации разработки услуг ВКУ для ведомств) в соответствии с плановыми нагрузками отчет о прохождении нагрузочного тестирования.

Получение доступа к витрине данных на ЕПГУ

После проведения всех регламентных работ по созданию витрины и регламентных запросов необходимо организовать подключение ИС ЕПГУ на тестовой (мнемоника MNSV05) и продуктивной (мнемоника MNSV03) средах:

1. Отправить запрос в чат по координации разработки услуг ВКУ для ведомств на подключение ИС ЕПГУ на тестовой среде к регламентному запросу.
2. После проведения всех этапов разработки на тестовой среде (svcdev) необходимо отправить запрос в чат по координации разработки услуг ВКУ для ведомств на подключение ИС ЕПГУ на продуктивной среде к регламентному запросу.

Внедрение витрин на ЕПГУ. Разработка шаблона ВКУ по встраиванию витрин в услуги

Разработка справочников NSI под РЗ

После получения доступа ИС ЕПГУ к РЗ витрины данных необходимо создать соответствующий справочник на ЕПГУ под каждый РЗ (либо те РЗ, которые планируется использовать в шаблоне ВКУ).

Для заведения справочника необходимо отправить запрос в чат по координации разработки услуг ВКУ для ведомств с указанием следующей информации:

• наименование РЗ и его версии в НСУД;
• cсылка на ЛК УВ РЗ;
• описание РЗ;
• описание параметров вызова РЗ

Разработка экранов шаблона

Рисунок 2

Экраны шаблона вызова витрины должны строиться по логике, которая предполагает после вызова РЗ отображение экранов с данными из витрины, либо экранов с ошибками витрины:

• ошибки, код ответа, отличный от 200 — происходит переход к экрану «Недоступность витрины». На экране требуется показать пользователю, что на текущий момент времени наблюдаются проблемы с доступностью витрины ПОДД;
• пустой ответ, отсутствуют данные и код 200 — происходит переход к экрану «Данные в витрине отсутствуют». На экране требуется показать пользователю, что по запрашиваемым данным отсутствуют сведения в витрине ПОДД;
• ответ с данными, код 200 — происходит переход к экрану «Информация, найденная в витрине». На экране требуется показать пользователю данные, пришедшие из витрины ПОДД.

В случае, если витрина возвращает пустой ответ и ответ с данными (код 200), то на таких экранах обязательно необходимо предусматривать ссылку на ПОС ведомства, которое является ответственным за витрину данных.

Вызов справочников с экранов шаблона

Компонент BackRestCall

Для вызова РЗ с формы услуги используется REST-запрос к справочнику, связанному с РЗ. Вызов осуществляется с помощью компонента BackRestCall.

BackRestCall — компонент, предназначенный для выполнения, сформированного на backend ЕПГУ REST-запроса во внешнюю систему в синхронном режиме с последующей обработкой полученного ответа.

В ВКУ компонент находится в разделе логические компоненты и называется «компонент предназначен для выполнения REST-запроса в синхронном режиме с последующей обработкой полученного ответа от внешней системы».

Рисунок 3

Настройка атрибутов BackRestCall

Рисунок 4

1. URL вызываемого сервиса. Не нужно проставлять данный атрибут, т.к. URL определяется автоматически.
2. HTTP-метод. Атрибут является обязательным. Для обращения к справочнику необходимо использовать метод POST.



Рисунок 5



3. Путь до сервиса. Атрибут является обязательным. Необходимо прописать путь до необходимого справочника.



Рисунок 6

Примеры:
/nsiv2/internal/api/nsi/v1/dictionary/ShowcaseVIN
/api/nsi/v1/dictionary/MFC_PRINT_DISCLAIMER

Значение данного поля предоставит специалист ВКУ при регистрации справочника в ЕПГУ по РЗ.



4. Тело запроса. Атрибут является обязательным. Необходимо расписать все необходимые для получения желаемого ответа от справочника параметры (входные параметры). Входные параметры передаются в виде JSON.

Для корректной настройки необходимо:

• Определить, сколько параметров должно быть передано в запросе.
  Пример: в запросе информации о ТС по VIN необходимо передавать всего один параметр - VIN-номер.
• Сформировать JSON запроса с нужным кол-вом входных параметров, указав название параметра в поле attributeName и его значение в поле value (в примере ниже attributeName - VIN, а value – "asString": "${vin}".

Пример с одним входным параметром:

{   "filter": {     "union": {       "unionKind": "AND",       "subs": [         {           "simple": {             "attributeName": "VIN",             "condition": "EQUALS",             "value": {               "asString": "${vin}"             }           }         }       ]     }   },   "treeFiltering": "ONELEVEL",   "pageNum": 1,   "pageSize": "10000",   "parentRefItemValue": "",   "selectAttributes": [     "*"   ],   "tx": "" }

Пример с двумя входными параметрами:

{   "filter": {     "union": {       "unionKind": "AND",       "subs": [         {           "simple": {             "attributeName": "GovRegNumber",             "condition": "EQUALS",             "value": {               "asString": "${GovRegNum}"             }           }         },         {           "simple": {             "attributeName": "RegDocSeriesNumber",             "condition": "EQUALS",             "value": {               "asString": "${RegDocSeriesNum}"             }           }         }       ]     }   },   "treeFiltering": "ONELEVEL",   "pageNum": 1,   "pageSize": "10000",   "parentRefItemValue": "",   "selectAttributes": [     "*"   ],   "tx": "" }

Если для запроса требуется передать на вход более двух параметров, то можно воспользоваться примерами выше и просто добавить в них нужное количество полей. Воспользуемся шаблоном выше для запроса по двум параметрам и скопируем фрагмент с блоком параметра:

{           "simple": {             "attributeName": "GovRegNumber",             "condition": "EQUALS",             "value": {               "asString": "${GovRegNum}"             }           }         }

Далее необходимо вставить ранее скопированный фрагмент в блок subs. Для реализации большего количества входных параметров, необходимо повторить данную вставку нужное количество раз.

Далее обязательно необходимо прописать корректные attributeName и его значение в поле value.

{   "filter": {     "union": {       "unionKind": "AND",       "subs": [         {           "simple": {             "attributeName": "test",             "condition": "EQUALS",             "value": {               "asString": "${test}"             }           }         },         {           "simple": {             "attributeName": "GovRegNumber",             "condition": "EQUALS",             "value": {               "asString": "${GovRegNum}"             }           }         },         {           "simple": {             "attributeName": "RegDocSeriesNumber",             "condition": "EQUALS",             "value": {               "asString": "${RegDocSeriesNum}"             }           }         }       ]     }   },   "treeFiltering": "ONELEVEL",   "pageNum": 1,   "pageSize": "10000",   "parentRefItemValue": "",   "selectAttributes": [     "*"   ],   "tx": "" }

В итоге получено тело запроса с тремя параметрами: test, GovRegNumber и RegDocSeriesNumber.



5. Фильтры справочника. Атрибут не является обязательным. Данный атрибут можно использовать для того, чтобы получать от справочника только те данные, которые необходимы для работы шаблона.



Рисунок 7



• Наименование атрибута фильтрации. Атрибут, по которому осуществляется поиск в nsi справочнике.

Пример:
От справочника необходимо получить информацию только о регионе с кодом 59. В поле наименование атрибута фильтрации укажем значение «CODE».



Рисунок 8



• Тип фильтрации. Может принимать следующие значения:
• EQUALS (РАВНО);
• CONTAINS (СОДЕРЖИТ);
• NOT_EQUALS (НЕ РАВНО);
• IN (ОДНО ИЗ ПЕРЕЧИСЛЕННЫХ);
• GREATER_THAN (БОЛЬШЕ);
• GREATER_THAN_OR_EQUALS (БОЛЬШЕ ИЛИ РАВНО);
• LESS_THAN (МЕНЬШЕ);
• LESS_THAN_OR_EQUALS (МЕНЬШЕ ИЛИ РАВНО);
• STARTS_WITH (НАЧИНАЕТСЯ С);
• ENDS_WITH (ЗАКАНЧИВАЕТСЯ НА).

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

Пример:
Выше был определен атрибут фильтрации справочника. Для того чтобы получить информацию только о регионе с кодом 59, необходимо отобрать только те значения CODE, которые равны 59. В данном случае необходимо использовать тип фильтрации EQUALS (РАВНО), так как необходимо чтобы значение CODE = 59. Если необходимо получить информацию о всех регионах, кроме региона с CODE = 59, то необходимо использовать тип фильтрации NOT_EQUALS (НЕ РАВНО) и т.п.



• Тип получения значения для фильтра. В данном поле необходимо указать откуда берется значение, по которому осуществляется фильтрация (в примерах выше это значение 59). Оно может быть, как прописано вручную (статическое значение), так и формироваться динамически при прохождении услуги.
• Константное значение. Статическое значение, подставляется в запрос как есть.



Рисунок 9

Пример: константное значение для фильтра: «asString»:«Y»



• Значение из поддерживаемых. Данные берутся из value текущего компонента на уровне атрибутов.



Рисунок 10

Пример:
ссылка на поддерживаемое значение: «regCode»;
тип атрибута: «asDecimal».



• Любые данные из serviceDto. Данные берутся из черновика, который приходит от бэка getNextStep/getService согласно указанному path.



Рисунок 11

Пример: ссылка на поддерживаемое значение:
«display.components[0].arguments.code_value»



• Данные из заполненных компонентов с других экранов. Данные берутся из applicantAnswers — заполненных компонентов с предыдущих экранов.



Рисунок 12

Пример: ссылка на поддерживаемое значение:
«s6lookup.value.originalItem.attributeValues.CODE»



• Обращение к блоку serviceInfo. Фильтр нужен для обращения к блоку serviceInfo.



Рисунок 13

Пример: ссылка на поддерживаемое значение: «infSysCode»



• Данные из компонента формы текущего экрана. Позволяет использовать данные других компонентов текущего экрана, т.е. данных ещё нет в applicantAnswers т.к они не отправлены на backend.



Рисунок 14

Пример:
ссылка на значение для фильтра из компонентов текущего экрана: «act_rec_date»; формат даты: «yyyy-MM-dd». Если значение необходимо передавать в определённом формате, то здесь указывается формат.



• Выражение расчета значения. Позволяет описывать условияч, которые обработает backend и вернет в value компонента.



Рисунок 15

Пример:
параметры изменения value: «$dict2_SanCheRest_is_fell.value.attributeValues.ADDRESS != '' ? $dict2_SanCheRest_is_fell.value.attributeValues.ADDRESS : ''»



6. Таймаут. Атрибут не является обязательным. Его необходимо укзаывать, если необходимо ограничить время выполнения запроса BackRestCall.



Рисунок 16

Таймаут на время выполнения запроса в миллисекундах.


По истечении этого запроса бэк в ответе от getnextstep возвращает Status Code: 400 и в ответе:

{ "status": "Bad Request", "message": "BAD_REQUEST", "description": "Unexpected server error: I/O error on POST request for "http://pgu-uat-feddsnlb.test.gosuslugi.ru/internal/api/einfahrt": Read timed out; nested exception is java.net.SocketTimeoutException: Read timed out", "traceId": "d4d708041f33910e" }

Для пользователя отображается окно «Не сработало».