2. Структура Витрины данных

2.1. Составные части Витрины данных

Программа имеет модульную архитектуру и построена на базе отдельных компонентов (включая разработки сторонних производителей).

Общую схему взаимосвязей компонентов можно просмотреть в разделе Архитектура Витрины данных.

Основные компоненты

  • Prostore - основной компонент программы с открытым исходным кодом, обеспечивает единый интерфейс к хранилищу разнородных данных. Определяет структуры данных, запись и чтение данных Витрины. Позволяет работать со входящими в состав хранилища СУБД одинаковым образом, используя единый синтаксис запросов SQL и единую логическую схему данных. Бэкапирование витрин выполняется средствами Prostore. Prostore включает следующие компоненты:

    • Сервис исполнения запросов — анализирует и исполняет SQL-запросы; предоставляет REST API для JDBC-драйвера и взаимодействует с сервисом мониторинга статусов Kafka по REST API. В свою очередь состоит из следующих компонентов:

      • Коннектор Kafka-Postgres reader - считывает данные из PostgreSQL и передает их в брокер сообщений Kafka;

      • Коннектор Kafka-Jet writer - записывает данные из брокера сообщений Kafka в PostgreSQL;

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

Компоненты, входящие в состав слоя адаптеров

  • СМЭВ3-адаптер - обеспечивает информационное взаимодействие через единый электронный сервис единой системы межведомственного электронного взаимодействия (далее – СМЭВ).

  • Сервис формирования документов - предназначен для обеспечения возможности формирования документов, в формате XML и PDF, на основе предварительно подготовленных pebble-шаблонов, с возможностью добавления к сформированным документам электронной подписи.

  • CSV-Uploader - программный модуль Витрины данных, предназначен для загрузки и выгрузки csv-файлов со структурой Витрины и csv-шаблонов с демо-шаблонами структуры Витрины, а также просмотра Журнала операций.

  • BLOB-адаптер - программный модуль Витрины данных, предназначен для получения доступа из Витрины данных к BLOB-объектам ведомства (BLOB-объект - это специальный тип двоичных данных, предназначенный для хранения бинарных файлов: изображений, скан-копий документов, текстовых файлов и т.д.).

  • DATA-Uploader - Модуль исполнения асинхронных заданий обеспечивает обработку очереди файлов, используя следующие функциональные особенности:

    • обработка очереди файлов производится циклами;

    • очередь файлов работает в режиме упорядочения процесса по принципу «первым пришел – первым обслужен»;

    • каждый элемент в очереди файлов содержит UUID задания, имя витрины и таблицы, содержимое CSV-файла;

    • файлы в очереди могут относится к разным витринам и/или разным таблицам одной витрины.

  • REST-Uploader - Модуль асинхронной загрузки данных из сторонних источников реализован для обеспечения параллельной загрузки данных с независимым масштабированием REST интерфейса.

  • Counter-provider - Сервис генерации уникального номера (Counter-Provider) позволяет создавать неповторяющиеся уникальные порядковые номера для сквозной нумерации файлов в сервисе формирования документов Типового ПО Витрины данных конфигурации установки Стандарт.

  • СМЭВ QL Сервер - СМЭВ QL Сервер — приложение для конфигурирования и запуска типового API извлечения данных из хранилищ под управлением типового ПО «Витрина данных» от Минцифры (Ядро Prostore 6.1+). СМЭВ QL Сервер обладает характеристиками:

    • поддержка множественных источников данных Prostore;

    • выбор источника по условиям запроса;

    • защита атрибутов модели данных по их предоставлению;

    • автоматический параллелизм запросов к Prostore.

Дополнительные компоненты

Рекомендуемое программное обеспечение для администрирования и мониторинга (не входит в поставку программы):

  • Агент СМЭВ4 - программное обеспечение, обеспечивающее сопряжение Типового ПО «Витрина данных» и ИС УВ с Ядром СМЭВ4. Связь компонентов реализована через HTTP.

  • Docker - программное обеспечение для автоматизации развёртывания и управления программы в виртуальных средах с поддержкой контейнеризации. Используется для установки Arenadata Cluster Manager (ADCM). Официальный сайт разработчика приложения: https://www.docker.com/.

  • Elasticsearch - система поиска и аналитики, позволяет быстро в режиме реального времени хранить, искать и анализировать большие объемы данных и сохраняет их для Graylog. Для передачи сообщений в Graylog использует Filebeat. Официальный сайт разработчика приложения: https://www.elastic.co/elasticsearch/.

  • Filebeat - агент на сервере для отправки различных типов оперативных данных в Elasticsearch. Официальный сайт разработчика приложения: https://www.elastic.co/elasticsearch/.

  • Grafana - инструмент реализован в виде панели управления и мониторинга и позволяет визуализировать системные события программы на базе собираемых метрик. Официальный сайт разработчика приложения: https://grafana.com/docs/.

  • Graylog - программное обеспечение для управления лог-файлами. Официальный сайт разработчика приложения: https://www.graylog.org/;

  • МongoDB - база данных Graylog. Официальный сайт разработчика приложения: https://www.mongodb.com/.

  • Node_exporter - процессы, обеспечивающие сбор и передачу системных метрик серверу Prometheus. Также, используется для сбора метрик модулей СМЭВ4-адаптера и CSV-uploader см. https://github.com/prometheus/node_exporter.

  • Prometheus - используется как система мониторинга системных ресурсов программы. Связь компонентов реализована через HTTP. Данные хранятся локально, в собственной TSBD базе, индексы хранятся в LevelDB. Метрики представляют собой time-series данные. Каждая метрика состоит из имени метрики, временной метки и пары «ключ – значение». Визуализация осуществляется через подключение к Grafana. Официальный сайт разработчика приложения: https://prometheus.io/.

Основные компоненты

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

    • Сервис исполнения запросов — анализирует и исполняет SQL-запросы; предоставляет REST API для JDBC-драйвера и взаимодействует с сервисом мониторинга статусов Kafka по REST API. В свою очередь состоит из следующих компонентов:

      • Коннектор Kafka-Postgres reader - считывает данные из PostgreSQL и передает их в брокер сообщений Kafka;

      • Коннектор Kafka-Jet writer - записывает данные из брокера сообщений Kafka в PostgreSQL;

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

Компоненты, входящие в состав слоя адаптеров

  • CSV-Uploader - программный модуль Витрины данных, предназначен для загрузки и выгрузки csv-файлов со структурой Витрины и csv-шаблонов с демо-шаблонами структуры Витрины, а также просмотра Журнала операций.

  • DATA-Uploader - Модуль исполнения асинхронных заданий обеспечивает обработку очереди файлов, используя следующие функциональные особенности:

    • обработка очереди файлов производится циклами;

    • очередь файлов работает в режиме упорядочения процесса по принципу «первым пришел – первым обслужен»;

    • каждый элемент в очереди файлов содержит UUID задания, имя витрины и таблицы, содержимое CSV-файла;

    • файлы в очереди могут относится к разным витринам и/или разным таблицам одной витрины.

  • REST-Uploader - Модуль асинхронной загрузки данных из сторонних источников реализован для обеспечения параллельной загрузки данных с независимым масштабированием REST интерфейса.

Дополнительные компоненты

  • Ansible — платформа удалённого управления конфигурациями программного обеспечения, предназначенная для упрощения развёртывания Компонент «Витрина данных Лайт» через создание специальных сценариев. Официальный сайт разработчика приложения: https://www.ansible.com/.

  • Docker — программное обеспечение для автоматизации развёртывания и управления программы в виртуальных средах с поддержкой контейнеризации. Контейнер позволяет производить изолированный запуск ОС с подключённой файловой системой из образа, изолированно разворачивать приложения и реализовывать микросервисы. Настройки среды хранятся в GitHub, обеспечивая единую точку управления конфигурациями. Может быть использован для для развёртывания тестового окружения Компонент «Витрина данных Лайт», без прерывания работы сервисов в продуктовой среде. Официальный сайт разработчика приложения: https://www.docker.com/.

  • Elasticsearch — утилита полнотекстового поиска и аналитики, которая позволяет быстро в режиме реального времени хранить, искать и анализировать большие объемы данных и сохраняет их для Graylog. Для передачи сообщений в Graylog использует Filebeat. Официальный сайт разработчика приложения: https://www.elastic.co/elasticsearch/.

  • Filebeat — агент на сервере для отправки различных типов оперативных данных в Elasticsearch. Официальный сайт разработчика приложения: https://www.elastic.co/elasticsearch/.

  • Grafana — инструмент реализован в виде панели управления и мониторинга и позволяет визуализировать системные события программы на базе собираемых метрик. Официальный сайт разработчика приложения: https://grafana.com/docs/.

  • Graylog — программное обеспечение для управления лог-файлами. Официальный сайт разработчика приложения: https://www.graylog.org/.

  • МongoDB — база данных Graylog. Официальный сайт разработчика приложения: https://www.mongodb.com/.

  • Node_exporter — процессы, обеспечивающие сбор и передачу системных метрик серверу Prometheus. Также, используется для сбора метрик СМЭВ4-адаптера и CSV-uploader см. https://github.com/prometheus/node_exporter.

  • Portainer — web-приложение для управления docker-контейнерами. Официальный сайт разработчика приложения: https://www.portainer.io/.

  • Prometheus — используется как система мониторинга системных ресурсов Компонент «Витрина данных Лайт». Связь компонентов реализована через HTTP. Данные хранятся локально, в собственной TSBD базе, индексы хранятся в LevelDB. Метрики представляют собой time-series данные. Каждая метрика состоит из имени метрики, временной метки и пары «ключ – значение». Визуализация осуществляется через подключение к Grafana. Официальный сайт разработчика приложения: https://prometheus.io/.

  • PostrgeSQL — база данных ProStore.

2.2. Состав компонентов в дистрибутиве

Состав компонентов в дистрибутиве конфигурации Стандарт версии 2.0.0 приведен в таблице ниже (см. Таблица 2.1)

Таблица 2.1 Состав компонентов в дистрибутиве программы

Наименование компонента

Версия

Техническое наименование

query-execution

7.0

query-execution:7.0

blob-adapter

2.0.0

blob-adapter:2.0.0

counter-provider

2.0.0

counter-provider:2.0.0

csv-uploader

2.0.0

csv-uploader:2.0.0

data-uploader

2.0.0

data-uploader:2.0.0

dtm-uploader

2.0.0

dtm-uploader:2.0.0

printable-form-service

2.0.0

printable-form-service:2.0.0

rest-uploader

2.0.0

rest-uploader:2.0.0

smevql-server

1.2.0

smevql-server:1.2.0

СМЭВ3-адаптер

2.0.0

smev3-adapter:2.0.0

dtm-tools

1.20.0

dtm-tools:1.20.0

kafka-greenplum-PXF-connector (writer)

1.2.0

kafka-greenplum-PXF-connector:1.2.0

kafka-jet-writer

1.5.0

kafka-jet-writer:1.5.0

Внимание

Для переноса системных данных (сервисной БД) из ZooKeeper в Postgres-совместимые СУБД при обновлении кластера Prostore до версии 7.2 используется команда ZK2PG утилиты DTM Tools.

Дистрибутив программы версии 2.0.0 тестировался с компонентами, приведенными в Таблица 2.2

Таблица 2.2 компоненты для тестирования программы

Наименование компонента

Версия

Техническое наименование

Агент СМЭВ4

3.17.0

Агент СМЭВ4:3.17.0

PostgreSQL

13.4

postgreSQL:13.4

Примечание

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

Конкретная конфигурация Витрины данных определяется Участником взаимодействия на этапе реализации Витрины данных в составе ИТ-инфраструктуры Участника взаимодействия.

Состав компонентов в дистрибутиве конфигурации Лайт версии 2.0.0 приведен в таблице ниже (см. Таблица 2.3)

Таблица 2.3 Состав компонентов в дистрибутиве программы

Наименование компонента

Версия

Техническое наименование

graylog

4.3.15

graylog:4.3.15

prometheus

2.34.0

prometheus:2.34.0

query-execution

7.0

query-execution:7.0

csv-uploader

2.0.0

csv-uploader:2.0.0

data-uploader

2.0.0

data-uploader:2.0.0

rest-uploader

2.0.0

rest-uploader:2.0.0

grafana

9.5.2

grafana:9.5.2

node_exporter

1.3.1

node_exporter:1.3.1

filebeat

7.10.2

filebeat:7.10.2

mongo

4.4

mongo:4.4

opensearch

1.3.14

opensearch:1.3.14

postgres

13.4

postgres:13.4

portainer

2.14.0

portainer:2.14.0

2.3. Cвязи между компонентами

Cвязи между компонентами конфигурации Стандарт приведены в Таблица 2.4.

Таблица 2.4 Взаимодействие между составными частями

Клиент

Сервер

Способ взаимодействия

Описание

Сервисная база данных Prostore (PostgreSQL)

Prostore

REST API

Хранение/получение метаданных

СУБД хранилища

Apache Kafka

СМЭВ4 Адаптер

ETL

Prostore

Хранилище СУБД

REST API

Перенаправление запросов в конкретную СУБД

ETL

ProStore

Kafka (Диспетчер сообщений)

JDBC

Исполнение запросов

Сервис формирования документов

ProStore

REST API

Запрашивает данные для формирования ПФ

СМЭВ3-адаптер

ProStore

REST API

Исполнение запросов

BLOB-адаптер

REST API

Запрашивает бинарное содержимое BLOB.

Cвязи между компонентами конфигурации Лайт приведены в Таблица 2.5.

Таблица 2.5 Взаимодействие между составными частями

Клиент

Сервер

Способ взаимодействия

Описание

CSV-Uploader

ProStore

REST API

Управление логической структурой таблиц.

Загрузка публикуемых данных в Витрину.

ProStore

СУБД PostgreSQL

REST API

Управление логической структурой таблиц.

Исполнение запросов.

Управление загрузкой публикуемых данных в Витрину.

2.4. Модули Витрины данных

Примечание

Описание настроек модулей, процессы запуска и остановки модуля см. в документах: «Руководстве администратора» и «Руководстве по установке».

2.4.1. CSV-Uploader

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.1.1. Общее описание

CSV-uploader - программный модуль Витрины данных, который предназначен для загрузки CSV-файлов в Витрину данных.

CSV-uploader предназначен для следующих задач:

  • формирование структуры витрины, заливка ddl, в том числе через GUI;

  • подготовка шаблонов csv, в том числе через GUI;

  • загрузка данных в витрину, через GUI с ручным/автоматическим выбором таблицы при помощи REST-Uploader;

  • загрузка CSV-файлов;

  • загрузка CSV-файлов со структурой Витрины;

  • выгрузка CSV-шаблонов с демо-шаблонами структуры Витрины;

  • автоматическая загрузка данных в витрину по расписанию.

Внимание

Загружаемые файлы обязательно должны быть в кодировке UTF-8

2.4.1.1.1. Общая схема взаимодействия через CSV-uploader
Общая схема взаимодействия через CSV-uploader

Рисунок - 2.1 Общая схема взаимодействия через CSV-uploader

2.4.2. DATA-Uploader - Модуль исполнения асинхронных заданий

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.2.1. Общее описание

Модуль исполнения асинхронных заданий обеспечивает обработку очереди файлов, используя следующие функциональные особенности:

  • обработка очереди файлов производится циклами;

  • очередь файлов работает в режиме упорядочения процесса по принципу «первым пришел – первым обслужен»;

  • каждый элемент в очереди файлов содержит UUID задания, имя витрины и таблицы, содержимое CSV-файла;

  • файлы в очереди могут относится к разным витринам и/или разным таблицам одной витрины

  • поддерживается удаление исторических данных.

Примечание

Заливка данных через через модуль DATA-Uploader не предусматривают параллельную заливку в датамарты вместе с другими инструментами. Параллельная заливка данных в те же датамарты вручную или средствами ETL приведет к конфликту в работе с дельтами и к ошибкам соответственно.

2.4.3. REST-Uploader - Модуль асинхронной загрузки данных из сторонних источников

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.3.1. Общее описание

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

Операции с данными:

  • загрузка: отправка запроса на .../upload;

  • логическое удаление: отправка запроса на .../delete (при этом для логических таблиц данные только помечаются как удаленные);

  • удаление исторических данных: отправка запроса на .../truncate.

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

Внимание

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

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

Обеспечены следующие функциональные особенности:

  • идентификатор генерируется по стандарту UUID;

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

  • загруженные данные размещаются вместе с UUID в очереди с именем «queue»;

  • формируется запись с ключом «status.[UUID запроса]» и статусом 0 в очереди;

  • клиенту, отправившему запрос, возвращается успешный статус запроса вместе с UUID;

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

Внимание

Загружаемые файлы обязательно должны быть в кодировке UTF-8

Примечание

Заливка данных через модуль REST-Uploader не предусматривают параллельную заливку в датамарты вместе с другими инструментами. Параллельная заливка данных в те же датамарты вручную или средствами ETL приведет к конфликту в работе с дельтами и к ошибкам соответственно.

Общие правила формата загружаемых CSV-файлов приведены в таблице Таблица 2.6.

Таблица 2.6 Общие правила формата загружаемых CSV-файлов

Параметр

Значение

Разделитель строк

Любой вариант из: CR/LF (0x0D0A), CR (0x0D), LF (0x0A)

Разделитель полей

по настройке csv-parser/separator (Параметры конфигурации)

Строка заголовка

да (обязательно)

Порядок полей в строке

определяется строкой заголовка

Ограничитель текстового поля

по настройке csv-parser/quote-char (Параметры конфигурации)

Символ маскировки в текстовом поле

по настройке csv-parser/escape-char (Параметры конфигурации)

Обнаружение значения null

До релиза 1.5.0 (включительно): по настройке csv-parser/field-as-null (Параметры конфигурации)

начиная с релиза 1.10.0: в текущей реализации парсера данная настройка не поддерживается

Кодирование символов

UTF-8

Десятичный разделитель

символ . (0x2E), может не указываться для целых значений

Формат даты

любой из: dd.MM.yyyy, yyyy-MM-dd

Формат времени

любой из: HH:mm:ss, H:mm:ss

Формат даты-времени

до релиза 1.5.0(включительно) любой из: yyyy-MM-dd HH:mm:ss, dd.MM.yyyy HH:mm:ss

начиная с релиза 1.10.0 любой из: yyyy-MM-dd HH:mm:ss.000000, dd.MM.yyyy HH:mm:ss.000000

2.4.3.2. Проверка форматно-логического контроля

Проверка форматно-логического контроля включает в себя:

  • обязательные проверки, выполняющиеся вне зависимости от настроек модуля в синхронном режиме;

  • необязательные проверки, индивидуальные для каждой таблицы, которыми управляет администратор Системы, выполняющиеся в асинхронном режиме.

Таблица 2.7 Список реализованных проверок

Наименование проверки

Код ошибки

Кирилическое описание

Проверка уникальности

dublicate

Дубликат файла/группы

Проверка парсинга файла

parsingErr

Ошибка парсинга: текст ошибки

Проверка кодирования

encodingErr

Кодировка файла не соответствует кодировке UTF-8

Проверка превышения предельного размера файла (больше 512 Мб)

tooLargeFile

Слишком большой файл

Проверка наличия данных в файле

emptyFile

Пустой файл

Проверка соответствия заголовков инфосхеме

wrongMetadata

Структура файла не соответствует схеме

Проверка соответствия числа столбцов в строке

wrongFieldsCount

Некорректное число столбцов в строке

Проверка соответствия типам полей

wrongFieldType

Значение не соответствует типу требуемый тип

Проверка уникальности полей

nonUniq

Значение не отвечает требованиям уникальности

Проверка регулярных выражений

nonMatchRegex

Значение не соответствует регулярному выражению регулярное выражение

Проверка соответствия условию

nonMatchConstant

Значение не соответствует условию условие

Таймаут валидации

validationTimeout

Истек таймаут валидации файла
2.4.3.2.1. Синхронная проверка ФЛК

Примечание

  • синхронные проверки выполняются вне зависимости от настроек модуля REST-Uploader;

  • синхронные проверки являются блокирующими;

  • ошибки синхронных проверок возвращаются в теле ответа по REST-API.

К синхронным проверкам относятся:

  • проверка соответствия инфосхеме:

    • проверка соответствия имен и количества полей в заголовках;

    • проверка типа данных;

    • проверка экранирования данных: проверка соответствия числа столбцов по каждой строке;

  • проверка соответствия файла кодировке UTF-8 , отсутствие BOM (при наличии BOM при загрузке удаляются начальные байты ef bb bf);

  • проверка размера файла и наличия данных:

    • проверка предельного размера загружаемого файла 512Мб;

    • проверка наличия данных в файле.

2.4.3.2.2. Асинхронная проверка

Примечание

  • асинхронные проверки выполняются в зависимости от настроек модуля;

  • проверки не являются блокирующими (поведение при их наличии определяется конфигурацией модуля);

  • список проверок уникален для каждой таблицы и хранится в Zookeeper в виде отдельного YAML файла.

К асинхронным проверкам относятся:

  • проверка уникальности полей:

    • по сочетанию атрибутов (для комплексных ключей);

    • по заданному атрибуту;

  • сравнение значения с константой;

  • соответствие регулярному выражению.

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

2.4.3.2.2.1. Проверка уникальности по одному или по сочетанию полей

Проверка уникальности проводится:

  • в рамках группы файлов, если заданы headers - для проверки в рамках группы обязательно заполнения всех полей:

    • group_id;

    • group_file_num;

    • group_file_count.

  • при проверке в рамках группы значения ключей для проверки уникальности в рамках группы хранится в Redis:

    • по всем файлам в рамках группы при наличии групповых атрибутов

    • по одному файлу, при отсутствии групповых атрибутов

Пример запроса для проверки уникальности по группе файлов:

--проверка по сочетанию полей
fields:
  id:
    uniq: true
    uniq-with: [type,region]
--проверка уникальности по одному полю
  snils:
    match: "/^[-\s\d]{11}$/"
    uniq: true
2.4.3.2.2.2. Проверка соответствия заданному значению

  • проверка соответствия заданному значению проводится для каждого файла вне зависимости от наличия group_id;

  • проверка осуществляется для значений каждого поля в соответствии с заданным правилом;

  • проверка соответствия заданному значению включает в себя:

2.4.3.2.2.3. Поведение в случае таймаута валидации

Период выполнения асинхронных проверок определяется конфигурационным параметром validation-timeout и по умолчанию составляет 60 минут.

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

В случае возникновения подобной ошибки рекомендуется:

  • проверить регулярные выражения, по которым происходит проверка, так как неверно заданное регулярное выражение кратно увеличивает скорость проверки;

  • увеличить значение validation-timeout и повторить загрузку данных.

2.4.3.3. Статусная модель

Статус запроса к модулю REST-Uploder можно получить, выполнив запрос с передачей идентификатора запроса GET '/v2/requests/:requestId/status'

В ответ возвращается три поля:

  • code - код статуса;

  • errorMessage - сообщение об ошибке, заполняется лишь в случае ошибочного статуса;

  • description - описание ошибки, заполняется лишь в случае ошибочного статуса.

Пример ответа на запрос статуса

{"code":2,"description":null,"errorMessage":null}

{"code":3,"description":"Успешно обработан","errorMessage":null}

{"code":4,"description":"Ошибка обработки запроса","errorMessage":"ru.itone.dtm.data.uploader.upload.UploadException: ru.itone.dtm.prostore.rest.api.ProstoreRestException: Error executing query [insert into univer.slots select resource_id,slot_id,tag_type,tag_age,available_date,duration,slot_create_ts,slot_update_ts,slot_status,sys_op from univer.slots_upload_ext]: All of the connectors are failed\n\tat"}

{"code":5,"description":"Идентификатор запроса не обнаружен","errorMessage":null}

{"code":7,"description":"Ошибки ФЛК","errorMessage":null}

В свою очередь, идентификатор запроса ранее был получен в ответ от REST-Uploader:

  • POST“/v2/datamarts/{datamart_name}/tables/{table_name}/upload;

  • POST“/v2/datamarts/{datamart_name}/tables/{table_name}/delete.

Таблица 2.8 Статусная модель

Код статуса

Описание статуса

Действия при получении данного статуса

-1

Загрузка данных в буффер

Данный статус клиентскому приложению не возвращается, ответ вернется после того как загружаемые данные будут сохранены приложением REST-Uploader для дальнейшей загрузки.

0

Запрос буфферизирован

Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30сек.

1

Ожидает открытия дельты

Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30сек.

2

В обработке (модулем DATA-Uploader)

Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30сек.

3

Успешно обработан

Дополнительных действий не требуется

4

Ошибка обработки запроса

Необходимо:

  • изучить содержимое вернувшегося поля description

  • если суть проблемы не ясна из предыдущего пункта, изучить содержимое логов приложений на предмет наличия ошибок:

    • REST-Uploader

    • DATA-Uploader

    • используемого коннектора (kafka-postgres-writer или kafka-jet-writer)

5

Идентификатор запроса не обнаружен

Использовать действующий идентификатор запроса

6

Форматно-логический контроль

Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30сек.

7

Ошибки ФЛК

В процессе ФЛК выявлены ошибки, необходимо запросить отчет ФЛК, обратившись к REST-Uploader c запросом GET '/v2/requests/{request_id}/report/'

Далее проанализировать и устранить выявленные недочеты в загружаемых данных или скорректировать проверки ФЛК.

2.4.4. BLOB-адаптер

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.4.1. Общее описание

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

BLOB-объект - это специальный тип двоичных данных, предназначенный для хранения бинарных файлов: изображений, скан-копий документов, текстовых файлов и т.д.

BLOB-адаптер предоставляет возможность настроить доступ к BLOB-объектам расположенным в Хранилище BLOB-объектов.

Примечание

Хранилище BLOB-объектов располагается на стороне ведомства и не является частью Витрины данных.

BLOB-адаптер предназначен для следующих задач:

  • настройка доступа в Хранилище BLOB-объектов;

  • предоставление регламентированного доступа к BLOB-объектам;

  • получение и отправка запросов на получение BLOB-объектов;

  • чтение BLOB-объектов;

  • сохранение BLOB-объектов на FTP-сервере (через СМЭВ3-адаптер).

Взаимодействие с BLOB-объектами возможно через запросы из СМЭВ3 (через СМЭВ3-адаптер) или Агента СМЭВ4. Доступ к считыванию BLOB-объектов производится методом GET по протоколу HTTP/HTTPS (указывается в конфигурации, параметр host) .

2.4.4.2. Общая схема взаимодействия через BLOB-адаптер

Общая схема взаимодействия через BLOB-адаптер

Рисунок - 2.2 Общая схема взаимодействия через BLOB-адаптер

2.4.4.3. Взаимодействие через СМЭВ-адаптер

2.4.4.3.1. Схема взаимодействия через СМЭВ-адаптер

Общая схема получения BLOB-объектов через СМЭВ-адаптер выглядит следующим образом:

Взаимодействие BLOB-адаптера через СМЭВ4-адаптер

Рисунок - 2.3 Взаимодействие BLOB-адаптера через СМЭВ4-адаптер

2.4.4.3.2. Процесс обработки запроса на получение BLOB-объекта (СМЭВ4-адаптер)

  1. В СМЭВ4 поступает запрос на получение данных из Витрины.

  2. СМЭВ4 отправляет запрос в Витрину.

  3. Витрина данных обрабатывает запрос и отправляет ответ.

  4. СМЭВ4 считывает данные полученные от Витрины. В случае, если в теле запроса содержится ссылка на BLOB-объект (например, изображение), отправляет запрос в BLOB-адаптер на получение этого BLOB-объекта. BLOB-адаптер, считывает ссылку на BLOB-объект и обращается в Хранилище BLOB-объектов на стороне ведомства. После получения BLOB-объекта, возвращает его в СМЭВ4.

2.4.4.4. Взаимодействие через СМЭВ3-адаптер

2.4.4.4.1. Схема взаимодействия через СМЭВ3-адаптер
Взаимодействие BLOB-адаптера через СМЭВ4

Рисунок - 2.4 Взаимодействие BLOB-адаптера через СМЭВ4

2.4.4.4.2. Процесс обработки запроса на получение BLOB-объекта (через СМЭВ3-адаптер)

  1. Из внешней ИС в СМЭВ4 поступает запрос на получение данных из Витрины.

  2. СМЭВ3-адаптер получает запрос и отправляет его в Витрину.

  3. Витрина обращается к БД, подготавливает ответ на запрос. Если в запросе есть ссылка на BLOB-объект, BLOB-адаптер обращается к Хранилищу BLOB-объектов, копирует BLOB-объект, выкладывает его на FTP-сервер СМЭВ4 и отправляет ссылку на BLOB-объект в Витрину.

  4. После того как BLOB-объект загружен на FTP-сервер СМЭВ4, Витрина отправляет ответ на запрос в СМЭВ4, в котором содержится ссылка на BLOB-объект (сохраненный на FTP-сервере).

  5. После получения ответа внешняя ИС может обратиться по ссылке и скачать BLOB-объект с FTP-сервера СМЭВ4.

2.4.4.5. Требования к серверу BLOB-адаптера

  1. Cледующие файлы не должны контролироваться системой управления конфигурации (при ее наличии), поскольку они должны быть доступны процессу установки для создания и модификации:

  • /etc/hosts

  • /etc/selinux/config

  • /etc/sysctl.conf

  • файлы директории /usr/lib/systemd/system/

  • /etc/sysconfig/iptables\*

  • /etc/firewalld/\*

  • /etc/docker/\*

  1. Снаружи сервер должен быть доступен по следующим портам:

  • 22 (SSH).

2.4.4.6. Требования к Хранилищу BLOB-объектов

Хранилище BLOB-объектов должно поддерживать регламентированный витриной интерфейс доступа к BLOB-объектам по запросу.

Для корректной работы с Хранилищем BLOB-объектов, необходимо выполнить следующие условия:

  • Предоставить доступ:

    • к таблицам с метаданными по документам, хранилища ведомства;

    • к ссылкам на BLOB-объекты (изображения, архивы, pdf-файлы и т.д.) в хранилище ведомства, соответствующие метаданным.

  • Предоставить связь между ссылками и метаданными, если они разнесены по разным хранилищам.

Примечание

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

2.4.4.7. Требования к предоставляемому интерфейсу Хранилища BLOB-объектов (API-интерфейс)

API-интерфейс реализованный соответственно данной спецификации должен предоставляться Хранилищем BLOB-объектов для возможности успешного взаимодействия с Витриной.

API-интерфейс Хранилища BLOB-объектов должен использовать метод GET, который поддерживается Витриной для получения тела BLOB-объекта из Хранилища BLOB-объектов.

С помощью API-интерфейса отправляется запрос на получение BLOB-объектов.

Считывание BLOB-объекта производится по протоколу HTTP (допустимо HTTPS, указывается в конфигурации файла application.yml, параметр host (см. раздел Конфигурация BLOB-адаптера (application.yml) в документе «Руководство администратора ПО «Витрина данных НСУД»)).

2.4.5. Сервис формирования документов

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.5.1. Общее описание

Сервис Формирования документов предназначен для обеспечения возможности формирования документов, в формате XML и PDF, на основе предварительно подготовленных pebble-шаблонов, с возможностью добавления к сформированным документам электронной подписи.

Внимание

Максимальный размер формируемого отчета не должен превышать 2Гб!

Сервис Формирования документов выполняет следующие основные функции:

  • Прием REST запроса на создание документа в соответствии со сцецификацией модуля;

  • Запрос необходимых данных для формирования документа в ядре Prostore;

  • Запрос номера документа в Сервисе генерации уникального номера;

  • Формирование документа, на основе поступившего в Витрину запроса, в формате:

    • XML;

    • PDF.

  • Отправка сформированных документов на подпись (опционально) в сервис Notarius;

  • Отправка сформированных и подписанных документов в виде ответа на пришедший запрос;

  • Публикация данных о модуле.

2.4.5.1.1. Процесс обработки запроса через модуль «Сервис Формирования документов»

Прием REST запроса на создание документа

Запрос на создание документа приходит на эндпоинт POST /report. Форматы запроса и ответа модуля описаны в спецификации OpenAPI модуля. После получения из ядра СМЭВ4 запрос на создание документа отправляется напрямую Агентом СМЭВ4.

Запрос данных

Запрос необходимых данных для формирования документа в ядре Prostore выполняется pebble-движком, на основе шаблона извлечения данных для запрашиваемого вида документа. В ответ на запрос данных ядро Prostore возвращает строки данных, в JSON. Если результат не может быть десериализован как JSON, то работа алгоритма прерывается и в ответ на запрос возвращается ошибка 500 Internal Server Error, тело ответа - пустое.

Запрос номера документа

Запрос номера документа осуществляется вызовом запроса GET /api/{service}/number/{counter} Сервиса генерации уникального номера. Вызов осуществляет pebble-движок, на основе шаблона формирования извлечения данных для запрашиваемого вида документа. В адресе запроса service задается полем counter-service.serviceName в настройках модуля, счетчик определяется pebble-шаблоном. В ответе на запрос возвращается следующий номер счетчика, который используется для нумерации отчета.

Формирование документа

Для формирование документа используются шаблоны формирования, в зависимости от запрашиваемого типа представления: XML или PDF. При этом при формировании PDF используется промежуточная трансформация в HTML, из которого формируется финальный PDF документ.

Внимание

Следует обратить внимание, что при формировании XML-документов используется - присоединенная подпись (подпись содержится в самом XML-документе).

Для PDF-документов - отсоединенная подпись (подпись документа формируется отдельным файлом), т.е. при формировании PDF-документа сгенерируется два файла: PDF-документ и файл электронной подписи для этого документа.

Отправка сформированных документов на подпись

При необходимости подписания документа (представления кроме xml и pdf) осуществляется вызов метода POST/api/v1/sign Агента СМЭВ4. При этом, в зависимости от представления результата:

  • xml_sig - присоединенная подпись

    • Возвращается подписанный фрагмент файла

    • Модуль пересобирает xml с учетом полученного подписанного фрагмента

  • pdf_sig - присоединенная подпись

    • Возвращается подписанный файл

  • xml_detached_sig, pdf_sig - отсоединенная подпись

    • Возвращается электронная подпись в формате p7s

Отправка сформированных и подписанных документов

Сформированный и подписанный документ возвращается в качестве ответа на вызов метода POST /report напрямую Агенту СМЭВ4 для отправки в ядро СМЭВ4.

2.4.5.1.2. Общая схема взаимодействия через Сервис формирования документов
Общая схема взаимодействия через «Сервис Формирования документов»

Рисунок - 2.5 Общая схема взаимодействия через «Сервис Формирования документов»

2.4.5.1.3. Примеры шаблонов
2.4.5.1.3.1. Шаблон extract_data.peb
{#формируем sql запрос в переменную passengersquery#}
{% var passengersquery %}
    {% if _0 is empty %}
        select * from auto_db.passenger limit 10
    {% else %}
        select * from auto_db.passenger limit {{ _0 }}
    {% endif %}
{% endvar %}
{# выполняем sql запрос и помещаем результат выполнения в переменную rows.searchpassenger #}
{{ sql("searchpassenger", passengersquery) }}

{% var json_data %}
{
    "passengers": [
    {% for p in rows.searchpassenger %}
    {#  формируем json динамически  #}
        {% if loop.first %}
        {% else %}
            ,
        {% endif %}
        {
            "id": "{{ p.id }}",
            "firstname": "{{ p.firstname }}",
            "middlename": "{{ p.middlename }}",
            "lastname": "{{ p.lastname }}",
            "birthday": "{{ p.birthday }}"
        }
    {% endfor %}
    ]
}
{% endvar %}

{#выведем полученный json в неэкранированной форме#}
{{ json_data | raw }}
2.4.5.1.3.2. Шаблон generate_xml.peb
{#соберем xml документ#}
<passengers>
{% for p in _0.passengers %}
    <passenger id="{{ p.id }}">
        <firstname>{{ p.firstname }}</firstname>
        <middlename>{{ p.middlename }}</middlename>
        <lastname>{{ p.lastname }}</lastname>
        <birthday>{{ p.birthday }}</birthday>
    </passenger>
{% endfor %}
</passengers>
2.4.5.1.3.3. Шаблон generate_pdf.peb
{#соберем html документ#}
<html>
    <head>
    <style>
        table, th, td {
            border: 1px solid black;
        }
    </style>
</head>
    <body>
        <h3>Passengers</h3>
        <table>
            <tr>
                <th>id</th>
                <th>firstname</th>
                <th>middlename</th>
                <th>lastname</th>
                <th>birthday</th>
            </tr>
{% for p in _0.passengers %}
            <tr>
                <td>{{ p.id }}</td>
                <td>{{ p.firstname }}</td>
                <td>{{ p.middlename }}</td>
                <td>{{ p.lastname }}</td>
                <td>{{ p.birthday }}</td>
            </tr>
{% endfor %}
        </table>
    <body>
</html>
2.4.5.1.4. REST запрос к сервису
openapi: "3.0.2"
info:
  title: Printable-form-service
  version: "1.0"
  description: API сервиса формирования документов
servers:
  - url: 'http://localhost:8081'
paths:
  /report:
    post:
      summary: Запрос на формирование документа
      tags:
        - PrintableForm
      operationId: postReport
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/ReportRequest'
      responses:
        '200':
          description: OK
          content:
            multipart/mixed:
              schema:
                $ref: '#/components/schemas/ReportResponse'
              examples:
                xml:
                  $ref: '#/components/examples/xml'
                xml_detached_sig:
                  $ref: '#/components/examples/xml_detached_sig'
                pdf:
                  $ref: '#/components/examples/pdf'
                pdf_sig:
                  $ref: '#/components/examples/pdf_sig'
        '400':
          description: Bad Request
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorMessage'
        '500':
          description: Internal Server Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorMessage'
components:
  schemas:
    ReportRequest:
      description: "Тело запроса на формирование документа"
      type: object
      required:
        - requestId
        - subRequestId
        - datamartMnemonic
        - certificate
        - reportName
        - result
        - params
      properties:
        requestId:
          description: "Идентификатор запроса"
          type: string
          format: uuid
        subRequestId:
          description: "Идентификатор подзапроса"
          type: string
          format: uuid
        datamartMnemonic:
          description: "Мнемоника Витрины данных"
          type: string
        certificate:
          description: "Алиас сертификата"
          type: string
        reportName:
          description: "Название документа, в виде v<версия РЗ>_<мнемоника РЗ>"
          type: string
        result:
          type: array
          description: "Массив необходимых представлений документа, подставляется из параметра doctype РЗ"
          items:
            type: string
            enum:
              - pdf
              - pdf_sig
              - xml
              - xml_detached_sig
        params:
          type: array
          description: "Массив параметров документа, подставляются из оставшихся параметров РЗ"
          items:
            type: string
      example:
        requestId: 9151f21f-43ae-43b4-92f3-f4af67cdf545
        subRequestId: 0151f21f-43ae-43b4-92f3-f4af67cdf546
        datamartMnemonic: demo_view
        certificate: MIIB/AYJKoZIhvcNAQcCoIIB7TCCAekCAQExADALBgkqhkiG9w0BBwGgggHRMIIBzTCCAXigAwIBAgIJANOtR7OLdZp6MAwGCCqFAwcBAQMCBQAwNTELMAkGA1UEBhMCUlUxCzAJBgNVBAoTAlJUMRkwFwYDVQQDDBBibGFzdG9mZl9jYV90ZXN0MB4XDTI0MDYxMzEwMzAxMVoXDTM0MDYxMTEwMzAxMVowLTERMA8GA1UEAwwIaXRvbmVkZXYxCzAJBgNVBAoMAlJUMQswCQYDVQQGEwJSVTBmMB8GCCqFAwcBAQEBMBMGByqFAwICJAAGCCqFAwcBAQICA0MABEBKaYnJXmFy5LaENHYklUpwlZCKtKfT0zrl3ZWWzl617fbfFkx50mZ/TNkMC1bPKw66peyBeiyxH3Ex9GhlhRGNo2owaDAdBgNVHQ4EFgQUkpelMTqUCxHujSJLQlbOI4JXJmwwDgYDVR0PAQH/BAQDAgTwMB8GA1UdIwQYMBaAFG+jo68J8q+Yv7whvdrDSaIFNWUlMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMCMAwGCCqFAwcBAQMCBQADQQCHGQxmwPCjRNYSNXSYqB40ap5BQBEjaZ8Ortx7iaqH+N1reoNnDG/Mb99Ecm9DjKqsfOiIBpDcTMSm1RSUDYUTMQA=
        reportName: v1_printable_form_address
        result:
          - pdf
        params:
          - 11
          - 0000bcce-fa66-4915-b805-c06e003bc7fb
          - Станислав
          - Тестович
          - Тестов
          - 2022-03-14
          - Picture_7.jpg
    ReportResponse:
      type: string
      description: "Ответ на запрос из n частей, соответствующих запрошенным представлениям документа"
    ErrorMessage:
      type: object
      required:
        - errorMessage
      properties:
        errorMessage:
          description: Сообщение об ошибке
          type: string
  examples:
    xml:
      value: |
        --9151f21f-43ae-43b4-92f3-f4af67cdf545
        Content-Disposition: form-data; name="xml_docType"
        Content-Type: text/plain

        xml
        --9151f21f-43ae-43b4-92f3-f4af67cdf545
        Content-Disposition: form-data; name="xml_content"; filename="document_1.xml"
        Content-Type: application/xml
        Content-Transfer-Encoding: binary

        <?xml version="1.0" encoding="UTF-8" standalone="no"?><root>...</root>

        --9151f21f-43ae-43b4-92f3-f4af67cdf545--
    xml_detached_sig:
      value: |
        --9151f21f-43ae-43b4-92f3-f4af67cdf545
        Content-Disposition: form-data; name="xml_detached_sig_docType"
        Content-Type: text/plain

        xml_detached_sig
        --9151f21f-43ae-43b4-92f3-f4af67cdf545
        Content-Disposition: form-data; name="xml_detached_sig_content"; filename="document_1.xml"
        Content-Type: application/xml
        Content-Transfer-Encoding: binary

        <?xml version="1.0" encoding="UTF-8" standalone="no"?><root>...</root>

        --9151f21f-43ae-43b4-92f3-f4af67cdf545
        Content-Disposition: form-data; name="xml_detached_sig_detached_sign"; filename="xmlSign.p7s"
        Content-Type: application/octet-stream
        Content-Transfer-Encoding: binary

        <file data>

        --9151f21f-43ae-43b4-92f3-f4af67cdf545--
    pdf:
      value: |
        --9151f21f-43ae-43b4-92f3-f4af67cdf545
        Content-Disposition: form-data; name="pdf_docType"
        Content-Type: text/plain

        pdf
        --9151f21f-43ae-43b4-92f3-f4af67cdf545
        Content-Disposition: form-data; name="pdf_content"; filename="pdfFileName.pdf"
        Content-Type: application/pdf
        Content-Transfer-Encoding: binary

        <file data>

        --9151f21f-43ae-43b4-92f3-f4af67cdf545--
    pdf_sig:
      value: |
        --9151f21f-43ae-43b4-92f3-f4af67cdf545
        Content-Disposition: form-data; name="pdf_sig_docType"
        Content-Type: text/plain

        pdf_sig
        --9151f21f-43ae-43b4-92f3-f4af67cdf545
        Content-Disposition: form-data; name="pdf_sig_content"; filename="pdfFileName.pdf"
        Content-Type: application/pdf
        Content-Transfer-Encoding: binary

        <file data>

        --9151f21f-43ae-43b4-92f3-f4af67cdf545
        Content-Disposition: form-data; name="pdf_sig_detached_sign"; filename="pdfSign.p7s"
        Content-Type: application/octet-stream
        Content-Transfer-Encoding: binary

        <file data>

        --9151f21f-43ae-43b4-92f3-f4af67cdf545--

2.4.6. СМЭВ QL Сервер

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.6.1. Назначение СМЭВ QL сервера

2.4.6.1.1. О системе

СМЭВ QL сервер - это компонент взаимодействия с витриной данных, который реализует её типовое API согласно внутренней спецификации СМЭВ QL.

Основным назначением СМЭВ QL сервера является обработка REST-запросов на получение данных от Потребителей и формирование оптимальных (простых) SQL-запросов к витрине для получения запрашиваемых данных.

Для Потребителя взаимодействие со СМЭВ QL сервера равнозначно виду информационного обмена - Обмен с использованием регламентированных запросов типа «Rest-сервис».

Основной принцип работы СМЭВ QL сервера заключается в следующем:

  1. СМЭВ QL принимает на вход REST-запрос, который содержит перечень запрашиваемых ресурсов, условий выбора данных, требуемые атрибуты ответа и пр. После чего определяет данные каких объектов и из каких источников необходимо извлечь. При этом определение источников происходит на основании заранее описанных моделей данных, которые хранятся на сервере в файлах вида model.yaml (что извлекать) и source.yaml (откуда извлекать).

  2. Далее формирует, в определенной последовательности (на основании плана выполнения запросов), столько SQL-запросов к источникам данных, сколько ресурсов было запрошено в исходном запросе от клиента. При этом запросы могут выполняться как последовательно, в случае если в запросе ресурсы имеют вложенность (иерархию) или параллельно, если ресурсы указаны на одном уровне. Это позволяет значительно упростить sql-выражения и уменьшить сложность запроса к БД.

  3. Обрабатывает результаты выполнения SQL-запросов по мере их поступления от источников.

  4. Затем формирует и передает комплексный ответ клиенту.

Схема СМЭВ QL Сервера

Рисунок - 2.6 Схема СМЭВ QL Сервера

2.4.6.1.2. Цели СМЭВ QL сервера

Целями создания СМЭВ QL сервера являются:

  1. Повышение скорости предоставления ответов от витрины данных Поставщика по сравнению с типовым видом взаимодействия Агент-Витрина.

  2. Защита витрины данных Поставщика от неоптимальных запросов.

  3. Сокращение объёма ответов.

  4. Сокращение количества передаваемых запросов от Потребителей.

  5. Повышение скорости развития услуг ЕПГУ.

2.4.6.1.3. Задачи СМЭВ QL сервера

Основные задачи СМЭВ QL сервера:

  1. Формирование API и модели данных витрины .

  2. Приём REST-запросов от Потребителей через Агент СМЭВ4.

  3. Формирование простых SQL-запросов к витрине.

  4. Формирование распределенных запросов к нескольким витринам.

  5. Формирование и передача ответа Потребителю.

  6. Проверка и формирование цифровых подписей ответов.

  7. Описание и исполнение при вызове модели машины состояний.

  8. Нотификация подписчиков при изменении данных витрины.

  9. Предоставление внешним клиентам OpenAPI для управления.

2.4.6.1.4. Место СМЭВ QL сервера в ИТ-ландшафте

СМЭВ QL сервер взаимодействует со следующими компонентами СМЭВ4:

  1. Агент СМЭВ4.

  2. Сервис исполнения запросов ядра витрины данных.

  3. Сервер криптографии (Notarius).

  4. Сервис формирования документов.

Схема взаимодействия СМЭВ QL Сервера с компонентами СМЭВ4

Рисунок - 2.7 Схема взаимодействия СМЭВ QL Сервера с компонентами СМЭВ4

2.4.6.1.5. Язык и синтаксис
2.4.6.1.5.1. Моделирование

Для моделирования документного слоя данных в спецификации выбран язык разметки YAML.

2.4.6.1.5.2. Запросы и ответы

Для написания запросов, а также в качестве сериализатора ответов, спецификация определяет использование JSON.

2.4.6.1.6. Типизация

Фактические типы данных наследуют типы данных JSON (включая NULL):

  • string;

  • number;

  • object;

  • array;

  • boolean;

  • null.

2.4.6.1.6.1. Типы данных в модели и приведение типов

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

Пример из описания модели:

fields:
  id:
    name: Идентификатор записи
    type:
      - number
      - SHORT
    length: 20
    nullable: not NULL
    key: PRIMARY

В качестве второго уточняющего типа следует применять типы НСУД:

  • STRING;

  • DOUBLE;

  • FLOAT;

  • BOOLEAN;

  • BYTE (не поддерживается на витрине);

  • BINARY;

  • BIG_DECIMAL (не поддерживается на витрине);

  • LONG;

  • INTEGER;

  • SHORT;

  • DATE;

  • TIME;

  • TIMESTAMP.

2.4.6.1.7. Моделирование данных

Модели данных описываются в формате YAML в папке проекта models согласно спецификации СМЭВ QL.

Структура базовой модели приведена в Базовая модель данных.

Структура базовой модели приведена в Модель данных.

Примечание

Заливка данных через через модуль RESt-Uploader и DATA-Uploader не предусматривают параллельную заливку в датамарты вместе с другими инструментами. Параллельная заливка данных в те же датамарты вручную или средствами ETL приведет к конфликту в работе с дельтами и к ошибкам соответственно.

2.4.6.1.8. Метрики

Для обеспечения возможности сбора информации о работе СМЭВ QL Сервера реализован набор метрик, обеспечивающий формирование показателей:

  • время исполнения входящих запросов;

  • количество успешных / не успешных выполнений входящих запросов;

  • время исполнения исходящих запросов или обращений к СПО;

  • количество успешных / не успешных выполнений исходящих запросов или обращений к СПО.

2.4.7. СМЭВ3-адаптер

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.7.1. Общее описание

Модуль CМЭВ3-адаптер обеспечивает информационное взаимодействие через единый электронный сервис единой системы межведомственного электронного взаимодействия (далее – СМЭВ).

С помощью CМЭВ3-адаптер Витрина данных выступает участником взаимодействия в роли Поставщика данных, а именно:

  • получает запросы из очереди СМЭВ;

  • отправляет ответы на запросы из очереди СМЭВ;

  • формирует и отправляет уведомления в СМЭВ об изменении данных в экземпляре Витрины данных.

Внимание

Отправляемые через СМЭВ3-адаптер файлы, не должны быть нулевыми (не содержать никаких данных)!

2.4.7.2. Схема взаимодействия

Подключение к СМЭВ

Рисунок - 2.8 Подключение к СМЭВ

  1. Внешняя ИС выполняет запрос к СМЭВ 3 на получение данных от Поставщика данных.

  2. Запрос через CМЭВ3-адаптер отправляется в СМЭВ.

  3. Адаптер СМЭВ 3 на стороне Поставщика данных принимает запрос из СМЭВ и отправляет его в Витрину данных поставщика.

  4. В Витрине Поставщика данных формируется ответ на поступивший запрос.

2.4.8. Сервис генерации уникального номера (Counter-Provider)

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.8.1. Общее описание

Сервис генерации уникального номера позволяет создавать неповторяющиеся уникальные порядковые номера для сквозной нумерации файлов в сервисе формирования документов Типового ПО Витрины данных конфигурации Стандарт.

В сервисе реализованы функции:

  • долговременного хранения неограниченного списка счетчиков;

  • атомарного изменения счетчика при параллельном использовании этой функции.

Основные функции модуля это:

  1. Создание и долговременное хранение неограниченного списка счетчиков;

  2. Обработка запросов на предоставление следующего номера счетчика;

  3. Создание резервной копии и восстановление из нее (бекапирование);

  4. Миграция счетчиков;

  5. Публикация данных о модуле.

Новый счетчик создается при первой попытке получения следующего номера счетчика (получен GET запрос /api/{service}/number/{counter}).

Параметрами счетчика являются:

  • Имя сервиса - переменная service в пути запроса;

  • Имя счетчика - переменная counter в пути запроса;

  • Стартовое значение - задается в настройке start-number модуля;

  • Инкремент счетчика - задается в настройке increment-gap модуля.

2.4.9. ETL - Модуль загрузки/ удаления данных

Примечание

Модуль входит в состав конфигурации Стандарт

Базовый сервис загрузки данных предоставляет возможность асинхронного приёма данных из сторонних источников с целью последующей загрузки их в Витрину данных. Загрузка/обновление данных осуществляется в соответствии с заранее подготовленными Avro-схемами.

Сервис загрузки данных реализуется компонентом ETL, предоставляющей REST API. Доступ к REST API должен осуществляться через Proxy API Datamart Studio. Перед загрузкой необходимо получить токен Proxy API, который в дальнейшем используется для авторизации при операциях, описанных в разделах ниже. При получении ошибки авторизации необходимо повторить авторизацию, получить новый токен и использовать его для дальнейшей загрузки.

Для взаимодействия с REST API (через Proxy API) в продуктивной среде на стороне источника данных требуется использовать сертифицированную версию ОС, а также механизмы, соответствующие требованиям безопасности, установленным для эксплуатации системы (например, через программный продукт Postman).

На стороне источника данных должны соблюдаться следующие требования к механизму взаимодействия:

  1. Запрещается хранение логина и пароля в открытом виде на диске. Логин и пароль должны выгружаться из безопасного хранилища в память ВМ (или контейнера) при старте взаимодействия с Proxy API для дальнейшего использования, сама ВМ должна находиться в закрытом контуре ИС или ведомства.

  2. Рекомендуется реализовать механизм стирания логина и пароля из памяти после успешной аутентификации через Proxy API.

В целях тестирования взаимодействия на тестовой среде может использоваться утилита curl.

2.5. Связи с другими программами

Взаимодействие с другими программами происходит путем вызова соответствующих модулей программы:

Связи программы с другими программами приведены в Таблица 2.9 .

Таблица 2.9 Связи с другими программами

Клиент

Сервер

Способ взаимодействия

Описание

Сервис формирования документов

Агент СМЭВ4

REST

Передает сформированные документы для формирования ЭП.

BLOB-адаптер

Агент СМЭВ4

REST

  • Получает запрос на предоставление содержимого BLOB-объекта;

  • Передает бинарное содержимое запрошенного BLOB-объекта.

Хранилище BLOB

REST

Запрашивает бинарное содержимое BLOB.

СМЭВ3-адаптер

СМЭВ3

SOAP

  • Получает запрос вида сведений от СМЭВ3;

  • Передает Результат запроса вида сведений;

  • Инициативно рассылает сведения об изменении публикуемых данных.

FTP-сервер СМЭВ3

FTP

Загружает на сервер бинарное содержимое запрошенных BLOB-объектов.

VipNet

REST

  • Проверяет ЭП получаемых от СМЭВ3 сообщений;

  • Формирует ЭП для отправляемых в СМЭВ сообщений.

ETL

Файловое хранилище ведомства

S3, FTP и т.п.

Считывание CSV файлов с данными, импортируемыми в витрину

БД ведомства

JDBC Driver

Считывание данных, импортируемых в витрину

Внутренняя ИС Ведомств

Сервер конечных точек

REST API

Имитация поведения, существующего REST API

Внутренняя ИС Ведомств

Ядро витрины

JDBC Driver

Доступ к БД ведомства

Взаимодействие с другими программами происходит путем вызова соответствующих модулей программы:

  • Внутренняя ИС Ведомства взаимодействует с ProStore через JDBC-driver.

  • СМЭВ4-адаптер - Модуль исполнения запросов для взаимодействия с ИС участников взаимодействия через Агента СМЭВ4.

  • CSV-uploader для взаимодействия с ИС участников взаимодействия для передачи файлов в формате XML и CSV.

Связи программы со сторонними программами приведены в см. Таблица 2.10.

Таблица 2.10 Связи с другими программами

Клиент

Сервер

Способ взаимодействия

Описание

Внутренняя ИС Ведомств

CSV-uploader

Файловый обмен (CSV)

REST

Загрузка публикуемых данных в Витрину

ProStore

JDBC

Управление логической структурой таблиц.

Исполнение запросов.

Загрузка публикуемых данных в Витрину.

2.6. Карта портов

Карта портов компонентов программы представлена в Таблица 2.11.

Таблица 2.11 Карта портов

Компонент

Описание

query-execution

Порт: 8080

Протокол: HTTP

Описание: номер порта сервиса метрик

Порт: 9090

Протокол: TCP

Описание: номер порта сервиса исполнения запросов

prometheus

Порт: 9090

Протокол: HTTP

Описание: Подключение к Prometheus WEB UI

grafana

Порт: 3000

Протокол: HTTP

Описание: WEB-интерфейс для работы c Grafana

node_exporter

Порт: 9100

Протокол: HTTP

Описание: Порт для загрузки метрик

filebeat

Порт: нет открытых портов

Протокол: -

Описание: -

mongodb

Порт: 27017

Протокол:TCP

Описание: Подключение к MongoDB. Порт по умолчанию для экземпляров mongod и mongos.

Вы можете изменить этот порт с помощью port или --port.

Порт: 27018

Протокол: TCP

Описание: Подключение к MongoDB. Порт по умолчанию для mongod при запуске с

параметром командной строки --shardsvr или значением shardsvr для параметра clusterRole в файле конфигурации

elasticsearch

Порт: 9200

Протокол: HTTP

Описание: Подключение к Elasticsearch.

kafka_postgres_writer

Порт: 8096

Протокол: HTTP

Описание: Порт используется для записи топиков Kafka в ProStore

kafka_postgres_reader

Порт: 8094

Протокол: HTTP

Описание: Порт используется для чтения топиков Kafka из ProStore

postgres

Порт: 5432

Протокол: TCP PostgresSQL Protocol

Описание: Источник данных SQL

portainer

Порт: 9000

Протокол: HTTP

Описание: Web-интерфейс для работы c Portainer