Новости 
База знаний 
Документация 
Форум 
ЛК УВ 
Назад
Содержание статьи
- Термины и сокращения
- Общая информация
- Создание и подготовка витрин к использованию
- Внедрение витрин на ЕПГУ. Разработка шаблона ВКУ по встраиванию витрин в услуги
- Разработка справочников NSI под РЗ
- Разработка экранов шаблона
- Вызов справочников с экранов шаблона
- Компонент BackRestCall
- Настройка атрибутов BackRestCall
Термины и сокращения
Витрина данных — комплекс программных и технических средств в составе информационно-телекоммуникационной инфраструктуры Участника взаимодействия, обеспечивающий хранение и предоставление данных другим Участникам взаимодействия с использованием ПОДД СМЭВ.
Регламентированный запрос (РЗ) — SQL-запрос, выраженный в терминах Модели данных, загруженной в ПОДД, и зарегистрированный в Ядре ПОДД СМЭВ под символической мнемоникой, используемой ИС Потребителя ПОДД СМЭВ для выполнения регламентированного запроса. Может иметь параметры, значения которых задаются Потребителем данных ПОДД СМЭВ при выполнении регламентированного запроса.
ПОДД СМЭВ — подсистема обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» – часть транспортной подсистемы СМЭВ, обеспечивающая доступ к данным, размещённым на витринах данных.
Агент ПОДД — типовое программное обеспечение, устанавливаемое в контуре ИС УВ и обеспечивающее сопряжение Витрин данных с ПОДД СМЭВ.
ЕИП НСУД (ФГИС ЕИП НСУД) — федеральная государственная информационная система «Единая информационная платформа Национальной системы управления данными».
Единая система контекстных справок (ЕСКС) — справочный интернет-ресурс, посвящённый СМЭВ, в том числе содержащий методические рекомендации, иную документацию по работе со СМЭВ, обеспечивающий информирование участников взаимодействия об изменении такой документации, изменениях в работе со СМЭВ, иных изменениях, функционирующий согласно Методическим рекомендациям по работе со СМЭВ. Доступен по адресу https://info.gosuslugi.ru
Шаблон ВКУ — набор настраиваемых экранов, который заключает в себе единую бизнес-функцию, а также позволяющий быстро разработать услугу, не вникая в детали реализации этой бизнес-функции.
Платформа обратной связи (ПОС) — информационный ресурс ЕПГУ, предназначенный для обеспечения возможности подачи обращений гражданами через единое окно подачи обращений — электронные формы, размещенные на официальных сайтах органов государственной власти (учреждений) в сети «Интернет» и на ЕПГУ.
Общая информация
Цель создания витрин данных:
- ускорение оказания государственных и муниципальных услуг путём сокращения времени на межведомственное взаимодействие посредством получения автоматических ответов из информационных систем органов и организаций государственного сектора;
- предоставление списка доступных данных из информационных систем органов и организаций государственного сектора, которые необходимы заявителю в ходе оказания государственных и муниципальных услуг;
- проверка корректности введенных данных заявителя при оказании государственных и муниципальных услуг;
- получение выписок (юридически значимых и информационного характера) из информационных систем органов и организаций государственного сектора по данным заявителя для дальнейшего использования их в оказании других государственных и муниципальных услуг, а также просто для информирования заявителя. Выписки в формате pdf всегда формирует на своей стороне поставщик данных (на стороне витрины).
Рисунок 1 — информационный обмен с использованием витрин данных
Подсистема обеспечения доступа к данным (ПОДД) — системы межведомственного электронного взаимодействия (СМЭВ 4) предназначена для передачи сведений между информационными системами (ИС) участников взаимодействия (УВ). Каждый УВ может быть, как потребителем, так и поставщиком данных.
Сведения, предоставляемые поставщиком, хранятся в витринах данных. Для получения сведений из витрин поставщиков ИС потребителя отправляет SQL-запрос через ПОДД, которая обеспечивает передачу запрошенной информации с учетом разграничения доступа к сведениям.
В качестве SQL-запроса может быть использован РЗ, который является зафиксированным SQL-запросом к витрине данных, заранее зарегистрированным в ПОДД. РЗ может содержать параметры, задаваемые при его вызове.
На стороне поставщика устанавливается ПО для поддержки витрины данных и ПО Агента ПОДД для связи с ядром ПОДД. Поставщик через ЕИП НСУД регистрирует модель данных витрины, содержащую структуру таблиц витрины, а также РЗ для данной витрины в ядре ПОДД. Агент ПОДД поставщика и витрины поставщика взаимодействуют через зарезервированные топики Kafka.
Загрузка данных в витрины осуществляется через JDBC-драйвер, REST API или CSV-файлы (через web-интерфейс или настроенную общую папку).
На стороне потребителя устанавливается ПО Агента ПОДД, который обеспечивает связь с ядром ПОДД для получения данных витрин поставщиков.
При информационном взаимодействии поставщика и потребителя выполняется следующий порядок действий:
- ИС потребителя формирует РЗ к витрине данных поставщика.
- РЗ передается агенту ПОДД через REST API.
- Агент ПОДД подписывает запрос электронной подписью (ЭП) органа власти (ОВ) и передает его в ядро ПОДД.
- Ядро ПОДД:
- проверяет корректность ЭП ОВ;
- проверяет полномочия на получение данных;
- выполняет преобразование РЗ в SQL-выражение, согласно метаданным, установленным при его регистрации РЗ в ПОДД. В результате формируется один или несколько SQL-запросов в витрину;
- проверяются технические ограничения на выполнение запросов (на объем данных, интенсивность запросов отправителя).
- Каждый SQL-запрос передается соответствующему агенту ПОДД поставщика данных.
- Агент ПОДД поставщика:
- проверяет корректность ЭП ОВ;
- проверяет условия доступа к запрошенным данным;
- помещает SQL-запрос в топик Kafka.
- Витрина данных поставщика получает SQL-запрос из Kafka, выполняет его и отправляет результат в Kafka.
- Агент ПОДД поставщика получает результат запроса из Kafka, подписывает его ЭП ОВ и отправляет в ядро ПОДД.
- Ядро ПОДД проверяет ЭП ОВ и ожидает завершения всех отправленных SQL-запросов.
- После получения результатов по всем SQL-запросам ядро ПОДД отправляет общий результат агенту ПОДД потребителю, отправившему запрос.
- Агент ПОДД потребителя проверяет ЭП ОВ и отправляет результат в ответе на соответствующий запрос REST API.
Подробное описание работы ПОДД содержится в «Методические рекомендации по работе с ПОДД СМЭВ».
Создание и подготовка витрин к использованию
Для использования витрин данных в оказании государственных и муниципальных услуг необходимо проделать ряд мероприятий:
- Описать информационные ресурсы и их атрибуты, а также пройти согласование (стр. 18-32 Инструкция ЕИП НСУД).
- Описать информационную систему, её атрибуты и группы атрибутов (стр. 36-52 Инструкция ЕИП НСУД).
- Описать модель витрины данных (стр. 69-91 Инструкция ЕИП НСУД).
- Подписать и отправить на согласование введенную информацию о витрине данных.
- Подключить витрину данных к ПОДД СМЭВ в тестовой и продуктивной среде (стр. 91-102 Инструкция ЕИП НСУД) с предварительным развертыванием витрины данных и агента подд на этих средах (Руководство администратора агента ПОДД СМЭВ).
- Обеспечить постоянное функционирование тестовой витрины данных, обеспечить ее наполнение тестовыми данными, а также их дальнейшую поддержку в процессе тестирования с потребителями витрины данных.
- Описать регламентные запросы в витрину и согласовать их (стр 132-139).
- Зарегистрировать регламентный запрос в тестовой и продуктивной среде (стр. 444-448 Руководство пользователя ЛК УВ). Обращаем внимание, что ведомство должно самостоятельно контролировать переход на новые версии РЗ своих потребителей, а также вывод из эксплуатации старых версий РЗ.
- Ведомство определяет плановые нагрузки на витрину и направляют в адрес ЕПГУ (в чат по координации разработки услуг ВКУ для ведомств) в соответствии с плановыми нагрузками отчет о прохождении нагрузочного тестирования.
- В частных случаях витрина может быть разработана только для нескольких услуг одного ведомства. В этом случае необходимо направить письмо в Минцифры России для получения согласования её разработки. Оператор ЕПГУ проводит экспертизу витрины согласно п. 3.3 настоящих Технических требований.
Внедрение витрин на ЕПГУ. Разработка шаблона ВКУ по встраиванию витрин в услуги
Разработка справочников NSI под РЗ
После получения доступа ИС ЕПГУ к РЗ витрины данных необходимо создать соответствующий справочник на ЕПГУ под каждый РЗ (либо те РЗ, которые планируется использовать в шаблоне ВКУ).
Для заведения справочника воспользуйтесь функциональностью ВКУ в разделе «Справочники витрин»
Разработка экранов шаблона
Рисунок 2
Экраны и компоненты шаблона витрины должны иметь уникальные идентификаторы. Это необходимо, чтобы при добавлении шаблона витрины в услугу разработчику услуги не приходилось изменять повторяющиеся идентификаторы
Экраны шаблона вызова витрины должны строиться по логике, которая предполагает после вызова РЗ отображение экранов с данными из витрины, либо экранов с ошибками витрины.
1. Переход к экрану «Недоступность витрины» происходит при выполнении одного из условий:
- response.error.code = 3 ИЛИ
- statusCode != 200
На экране требуется показать пользователю, что на текущий момент времени наблюдаются проблемы с доступностью витрины ПОДД.
2. Переход к экрану «Данные в витрине отсутствуют» происходит при условиях:
- response.total = 0
- response.error.code = 7
- statusCode = 200
На экране требуется показать пользователю, что по запрашиваемым данным отсутствуют сведения в витрине ПОДД.
3. Переход к экрану «Информация, найденная в витрине» происходит при условиях:
- response.total > 0
- statusCode = 200
На экране требуется показать пользователю данные, пришедшие из витрины ПОДД.
В случае, если при переходе на экран витрина возвращает следующие результаты:
- response.total = 0
- StatusCode = 200
то на таких экранах обязательно необходимо предусматривать ссылку на ПОС ведомства, которое является ответственным за витрину данных.
Шаблон витрины в ВКУ должен начинаться и заканчиваться экраном EMPTY, содержащий компонент типа Redirect. Так как все шаблоны витрин являются нередактируемыми, наличие такого экрана позволит разработчику услуги проще встроить шаблон в услугу
Вызов справочников с экранов шаблона
Компонент BackRestCall
Для вызова РЗ с формы услуги используется REST-запрос к справочнику, связанному с РЗ. Вызов осуществляется с помощью компонента BackRestCall.
BackRestCall — компонент, предназначенный для выполнения, сформированного на backend ЕПГУ REST-запроса во внешнюю систему в синхронном режиме с последующей обработкой полученного ответа.
В ВКУ компонент находится в разделе логические компоненты и называется «компонент предназначен для выполнения REST-запроса в синхронном режиме с последующей обработкой полученного ответа от внешней системы».
Рисунок 3
Настройка атрибутов BackRestCall
Рисунок 4
- URL вызываемого сервиса. Не нужно проставлять данный атрибут, т.к. URL определяется автоматически.
- HTTP-метод. Атрибут является обязательным. Для обращения к справочнику необходимо использовать метод POST.
- Путь до сервиса. Атрибут является обязательным. Необходимо прописать путь до необходимого справочника.
- Тело запроса. Атрибут является обязательным. Необходимо расписать все необходимые для получения желаемого ответа от справочника параметры (входные параметры). Входные параметры передаются в виде JSON.
- Определить, сколько параметров должно быть передано в запросе.
Пример: в запросе информации о ТС по VIN необходимо передавать всего один параметр - VIN-номер. - Определить, какой справочник используется для запроса. При использовании справочника, созданного в ВКУ, тело запроса будет отличаться.
- Сформировать JSON запроса с нужным кол-вом входных параметров, указав название параметра и его значение в поле value.
- Фильтрация по выбранному словарю. Атрибут не является обязательным. Данный атрибут можно использовать для того, чтобы получать от справочника nsi (не от витрины) только те данные, которые необходимы для работы.
- Наименование атрибута фильтрации. Атрибут, по которому осуществляется поиск в nsi справочнике.
- Тип фильтрации. Может принимать следующие значения:
- EQUALS (РАВНО);
- CONTAINS (СОДЕРЖИТ);
- NOT_EQUALS (НЕ РАВНО);
- IN (ОДНО ИЗ ПЕРЕЧИСЛЕННЫХ);
- GREATER_THAN (БОЛЬШЕ);
- GREATER_THAN_OR_EQUALS (БОЛЬШЕ ИЛИ РАВНО);
- LESS_THAN (МЕНЬШЕ);
- LESS_THAN_OR_EQUALS (МЕНЬШЕ ИЛИ РАВНО);
- STARTS_WITH (НАЧИНАЕТСЯ С);
- ENDS_WITH (ЗАКАНЧИВАЕТСЯ НА).
- Тип получения значения для фильтра. В данном поле необходимо указать откуда берется значение, по которому осуществляется фильтрация (в примерах выше это значение 59). Оно может быть, как прописано вручную (статическое значение), так и формироваться динамически при прохождении услуги.
- Константное значение. Статическое значение, подставляется в запрос как есть.
- Значение из поддерживаемых. Данные берутся из value текущего компонента на уровне атрибутов.
- Любые данные из serviceDto. Данные берутся из черновика, который приходит от бэка getNextStep/getService согласно указанному path.
- Данные из заполненных компонентов с других экранов. Данные берутся из applicantAnswers — заполненных компонентов с предыдущих экранов.
- Обращение к блоку serviceInfo. Фильтр нужен для обращения к блоку serviceInfo.
- Данные из компонента формы текущего экрана. Позволяет использовать данные других компонентов текущего экрана, т.е. данных ещё нет в applicantAnswers т.к они не отправлены на backend.
- Выражение расчета значения. Позволяет описывать условия, которые обработает backend и вернет в value компонента.
- Максимальное время выполнения запроса. Атрибут не является обязательным. Его следует указывать, если необходимо ограничить время выполнения запроса BackRestCall. Таймаут на время выполнения запроса указывается в миллисекундах
- Настройка параметров фильтрации ответа, полученного от сервиса. Атрибут не является обязательным. Его следует заполнять, если из всего ответа витрины сохранять в applicantAnswers в черновике нужно только некоторые атрибуты
- Настроить BackRestCall компонент без фильтрации, сохранить в текстовом редакторе ответ компонента из applicantAnswers
- Изучить структуру ответа, определить атрибуты, которые нужны в черновике
- Написать путь до этих атрибутов, используя JSONPath
- Добавить эти пути в массив параметров для фильтрации
- Протестировать, что все нужные атрибуты присутствуют в value компонента в applicantAnswers
Рисунок 5
Рисунок 6
- если справочник создан в ВКУ в разделе «Справочники витрин», то он имеет признак «internal» и путь до него должен быть следующий: /internal/api/nsi/v1/dictionary/название_справочника, где «название_справочника» генерируется в момент создания справочника и отображается на экране успешного сохранения
- в иных случаях: /api/nsi/v1/dictionary/название_справочника, где «название_справочника» давалось ранее специалистами ВКУ при регистрации справочника
Рисунок 7
Для корректной настройки необходимо:
|
{ "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.
Примеры запросов с использованием справочников, с признаком «internal», созданных в ВКУ. Обратите внимание, для таких справочников название параметров, передаваемых в запросе, можно увидеть в разделе «Справочники витрин» на вкладке «Проверка справочников» в блоке «Параметры запроса»:
Рисунок 8
Пример с одним параметром:
|
{ "parameters": [ { "name": "ogrn", "value": "${ogrn}" } ], "parentRefItemValue": "", "selectAttributes": ["*"], "tx": "" } |
Если для запроса требуется передать на вход более двух параметров, то можно воспользоваться примером выше и просто добавить в него нужное количество полей. Воспользуемся шаблоном выше для запроса по двум параметрам и скопируем фрагмент с блоком параметра:
|
{ "parameters": [ { "name": "ogrn", "value": "${ogrn}" }, { "name": "ogrn2", "value": "${ogrn2}" } ], "parentRefItemValue": "", "selectAttributes": ["*"], "tx": "" } |
Рисунок 9
Пример:
От справочника необходимо получить информацию только о регионе с кодом 59. В поле наименование атрибута фильтрации укажем значение «CODE».
Рисунок 10
Необходимо указать тип сравнения, который мы будем использовать для того чтобы отфильтровать значения справочника.
Пример:
Выше был определен атрибут фильтрации справочника. Для того чтобы получить информацию только о регионе с кодом 59, необходимо отобрать только те значения CODE, которые равны 59. В данном случае необходимо использовать тип фильтрации EQUALS (РАВНО), так как необходимо чтобы значение CODE = 59. Если необходимо получить информацию о всех регионах, кроме региона с CODE = 59, то необходимо использовать тип фильтрации NOT_EQUALS (НЕ РАВНО) и т.п.
Рисунок 11
Пример: константное значение для фильтра: «asString»:«Y»
Рисунок 12
Пример:
ссылка на поддерживаемое значение: «regCode»;
тип атрибута: «asDecimal».
Рисунок 13
Пример: ссылка на поддерживаемое значение:
«display.components[0].arguments.code_value»
Рисунок 14
Пример: ссылка на поддерживаемое значение:
«s6lookup.value.originalItem.attributeValues.CODE»
Рисунок 15
Пример: ссылка на поддерживаемое значение: «infSysCode»
Рисунок 16
Пример: ссылка на значение для фильтра из компонентов текущего экрана: «act_rec_date»; формат даты: «yyyy-MM-dd». Если значение необходимо передавать в определённом формате, то здесь указывается формат.
Рисунок 17
Пример: параметры изменения value: «$dict2_SanCheRest_is_fell.value.attributeValues.ADDRESS != '' ? $dict2_SanCheRest_is_fell.value.attributeValues.ADDRESS : ''»
Рисунок 18
По истечении этого запроса бэк в ответе от 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" } |
Для пользователя отображается окно «Не сработало»
Рисунок 19
Чтобы правильно настроить фильтрацию ответа из витрины, следует придерживаться следующего алгоритма:
Рассмотрим возможные варианты фильтрации на примере ответа витрины ФРДО для запроса сведений о среднем образовании
Пример возвращаемого ответа от витрины
|
{ "error": { "code": 0, "message": "operation completed" }, "fieldErrors": [], "total": 1, "items": [ { "value": "Диплом о среднем профессиональном образовании (повышенный уровень)", "title": "Диплом о среднем профессиональном образовании (повышенный уровень)", "isLeaf": false, "children": [], "attributes": [ { "name": "spo_document_type", "type": "STRING", "value": { "asString": "Диплом о среднем профессиональном образовании (повышенный уровень)", "value": "Диплом о среднем профессиональном образовании (повышенный уровень)", "typeOfValue": "STRING" }, "valueAsOfType": "Диплом о среднем профессиональном образовании (повышенный уровень)" }, { "name": "spo_document_name", "type": "STRING", "value": { "asString": "Диплом о среднем профессиональном образовании (повышенный уровень)", "value": "Диплом о среднем профессиональном образовании (повышенный уровень)", "typeOfValue": "STRING" }, "valueAsOfType": "Диплом о среднем профессиональном образовании (повышенный уровень)" }, { "name": "spo_org_fulltitle", "type": "STRING", "value": { "asString": "ОРГАНИЗАЦИЯ ТЕСТОВАЯ", "value": "ОРГАНИЗАЦИЯ ТЕСТОВАЯ", "typeOfValue": "STRING" }, "valueAsOfType": "ОРГАНИЗАЦИЯ ТЕСТОВАЯ" }, { "name": "spo_document_series", "type": "STRING", "value": { "asString": "1779", "value": "1779", "typeOfValue": "STRING" }, "valueAsOfType": "1779" }, { "name": "spo_document_number", "type": "STRING", "value": { "asString": "17782", "value": "17782", "typeOfValue": "STRING" }, "valueAsOfType": "17782" }, { "name": "spo_document_registernumber", "type": "STRING", "value": { "asString": "789", "value": "789", "typeOfValue": "STRING" }, "valueAsOfType": "789" }, { "name": "spo_document_status", "type": "STRING", "value": { "asString": "ОРИГИНАЛ", "value": "ОРИГИНАЛ", "typeOfValue": "STRING" }, "valueAsOfType": "ОРИГИНАЛ" }, { "name": "spo_recipient_snils", "type": "STRING", "value": { "asString": "506-861-153 84", "value": "506-861-153 84", "typeOfValue": "STRING" }, "valueAsOfType": "506-861-153 84" }, { "name": "spo_recipient_patronymic", "type": "STRING", "value": { "asString": "АНАТОЛЬЕВНА", "value": "АНАТОЛЬЕВНА", "typeOfValue": "STRING" }, "valueAsOfType": "АНАТОЛЬЕВНА" }, { "name": "spo_recipient_name", "type": "STRING", "value": { "asString": "ЕКАТЕРИНА", "value": "ЕКАТЕРИНА", "typeOfValue": "STRING" }, "valueAsOfType": "ЕКАТЕРИНА" }, { "name": "spo_recipient_surname", "type": "STRING", "value": { "asString": "ЗАХАРОВА", "value": "ЗАХАРОВА", "typeOfValue": "STRING" }, "valueAsOfType": "ЗАХАРОВА" }, { "name": "spo_recipient_gender", "type": "STRING", "value": { "asString": "ЖЕН", "value": "ЖЕН", "typeOfValue": "STRING" }, "valueAsOfType": "ЖЕН" }, { "name": "spo_levelofeducation", "type": "STRING", "value": { "asString": "СРЕДНЕЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАНИЕ", "value": "СРЕДНЕЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАНИЕ", "typeOfValue": "STRING" }, "valueAsOfType": "СРЕДНЕЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАНИЕ" }, { "name": "spo_admissionyear", "type": "STRING", "value": { "asString": "2000", "value": "2000", "typeOfValue": "STRING" }, "valueAsOfType": "2000" }, { "name": "spo_graduationyear", "type": "STRING", "value": { "asString": "2010", "value": "2010", "typeOfValue": "STRING" }, "valueAsOfType": "2010" }, { "name": "spo_trainingperiod", "type": "STRING", "value": { "asString": "10", "value": "10", "typeOfValue": "STRING" }, "valueAsOfType": "10" }, { "name": "spo_confirmationexchange", "type": "STRING", "value": { "asString": "false", "value": "false", "typeOfValue": "STRING" }, "valueAsOfType": "false" }, { "name": "spo_confirmationloss", "type": "STRING", "value": { "asString": "false", "value": "false", "typeOfValue": "STRING" }, "valueAsOfType": "false" }, { "name": "spo_qualification", "type": "STRING", "value": { "asString": "ИНЖЕНЕР", "value": "ИНЖЕНЕР", "typeOfValue": "STRING" }, "valueAsOfType": "ИНЖЕНЕР" }, { "name": "spo_educationprogramm", "type": "STRING", "value": { "asString": "ПРОГРАММА 1", "value": "ПРОГРАММА 1", "typeOfValue": "STRING" }, "valueAsOfType": "ПРОГРАММА 1" }, { "name": "spo_document_issuedate", "type": "STRING", "value": { "asString": "2010-06-30T00:00:00Z", "value": "2010-06-30T00:00:00Z", "typeOfValue": "STRING" }, "valueAsOfType": "2010-06-30T00:00:00Z" }, { "name": "spo_recipient_birthday", "type": "STRING", "value": { "asString": "1970-09-23T00:00:00Z", "value": "1970-09-23T00:00:00Z", "typeOfValue": "STRING" }, "valueAsOfType": "1970-09-23T00:00:00Z" }, { "name": "spo_specialty", "type": "STRING", "value": { "asString": "ИНЖЕНЕР", "value": "ИНЖЕНЕР", "typeOfValue": "STRING" }, "valueAsOfType": "ИНЖЕНЕР" } ], "attributeValues": { "spo_document_status": "ОРИГИНАЛ", "spo_recipient_patronymic": "АНАТОЛЬЕВНА", "spo_recipient_birthday": "1970-09-23T00:00:00Z", "spo_recipient_gender": "ЖЕН", "spo_document_type": "Диплом о среднем профессиональном образовании (повышенный уровень)", "spo_levelofeducation": "СРЕДНЕЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАНИЕ", "spo_admissionyear": "2000", "spo_trainingperiod": "10", "spo_recipient_surname": "ЗАХАРОВА", "spo_document_issuedate": "2010-06-30T00:00:00Z", "spo_recipient_snils": "506-861-153 84", "spo_specialty": "ИНЖЕНЕР", "spo_recipient_name": "ЕКАТЕРИНА", "spo_document_name": "Диплом о среднем профессиональном образовании (повышенный уровень)", "spo_qualification": "ИНЖЕНЕР", "spo_org_fulltitle": "ОРГАНИЗАЦИЯ ТЕСТОВАЯ", "spo_document_registernumber": "789", "spo_document_series": "1779", "spo_document_number": "17782", "spo_confirmationexchange": "false", "spo_confirmationloss": "false", "spo_graduationyear": "2010", "spo_educationprogramm": "ПРОГРАММА 1" } } ] } |
Чтобы оставить все возвращаемые атрибуты, задавать массив параметров фильтрации не нужно
Чтобы оставить в черновике только конкретные атрибуты из блока attributeValues, (например spo_qualification, spo_levelofeducation, spo_document_type), необходимо прописать их в массиве фильтрации и еще два обязательных параметра: total и error*, информация из которых используется для настройки правил перехода. Пример:
Рисунок 20
Результат ответа из витрины при такой фильтрации
| { "statusCode": 200, "response": { "error": { "code": 0, "message": "operation completed" }, "total": 1, "items": [ { "attributeValues": { "spo_document_type": "Диплом о среднем профессиональном образовании (повышенный уровень)", "spo_levelofeducation": "СРЕДНЕЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАНИЕ", "spo_qualification": "ИНЖЕНЕР" } } ] } } |
Если нужно оставить все значения из массива attributeValues, то можно прописать условие "items[*].attributeValues.*" Если нужно оставить все значения из массива attributes, то можно прописать условие "items[*].attributes[*].*" Вывести все дочерние элементы любого массива можно указав после его названия " .*"
Результат ответа из витрины при фильтрации по условию items[*].attributeValues.*
{ |
Если в массиве по каждому элементу нужно оставить только некоторые атрибуты, следует прописать условие например "items[*].attributes[*].name" - чтобы оставить только название элемента, или "items[*].attributes[*].value.value" - чтобы оставить значение элемента
Рисунок 21
Результат ответа из витрины при фильтрации по условию со скриншота
{ |
