2. Настройка Компонента
2.1. Настройка технических средств
Серверы, на которых устанавливается Компонент «Витрина данных», должны соответствовать техническим характеристикам, указанным в документе «Техническое описание системы» в разделе Рекомендуемые технические и программные средства, в котором приводятся требования к серверному оборудованию (CPU, RAM, HDD и т.д.), программному обеспечению и каналам связи.
Необходимые настройки для серверов описаны в документе «Руководство по установке Компонента «Витрина данных»», в котором приводятся требования к серверам, доступности портов для каждого сервера, настройка протоколов, наличие библиотек и т.д.
2.2. Настройка программных средств
Предварительные действия необходимые перед установкой Компонента, процесс установки и проверка корректной установки Компонента описаны в документе «Руководство по установке компонента «Витрина данных»» в разделе «Подготовка к установке».
Внимание
Программные средства настраиваются в зависимости от используемой конфигурации. Состав компонентов приведен в разделе Состав модулей в дистрибутиве документа «Техническое описание компонента «Витрина данных»».
2.2.1. Настройка Prostore (dtm-query-execution-core)
2.2.1.1. Настройка Сервиса исполнения запросов )
Конфигурация инстанса сервиса исполнения запросов Prostore (dtm-query-execution-core) с описанием логики и порядка работы сервиса представляет собой текстовый YAML-файл, параметры которого организованы в древовидную структуру.
Для наглядности конфигурация сервиса исполнения запросов разделена на отдельные секции.
Пример файла конфигурации Prostore приведен в разделе Конфигурация ноды документации Prostore.
2.2.1.2. Настройка коннекторов
Следующие коннекторы требуют настройки конфигурации:
Kafka-Clickhouse writer connector;
Kafka-Postgres writer connector;
Kafka Jet writer connector.
Конфигурация коннектора представляет собой текстовый YAML-файл, параметры которого организованы в древовидную структуру.
Пример файла конфигурации коннекторов приведен в разделе Конфигурация коннекторов документации Prostore.
2.2.2. Настройка Агента проверок
2.2.2.1. Конфигурация Агента проверок (application.yml)
Файл application.yml – основной конфигурационный файл Агента проверок, в котором задана логика и порядок работы модуля:
2.2.2.1.1. Пример файла application.yml
В конфигурационном файле следует задавать только те настройки, которые необходимы для решения текущих бизнес-задач.
management:
endpoint:
health:
show-details: always
prometheus:
metrics:
export:
enabled: true
endpoints:
web:
exposure:
include: health, prometheus, configprops, env
metrics:
tags:
application: check-adapter-dqf
namespace: ${POD_NAMESPACE:local}
pod: ${POD_NAME:local}
node_name: ${NODE_NAME:local}
spring:
task:
scheduling:
pool:
size: 5
profiles:
active: ${PROFILES_ACTIVE:dqf}
server:
port: ${HTTP_PORT:3010}
adapter:
adapterNg:
http:
url: http://localhost:3010/
useAdapter: ${USE_NG_ADAPTER:true}
podd:
http:
url: http://localhost:8172/
prostore:
jdbc:
prostoreUrl: ${PROSTORE_JDBC_URL:jdbc:prostore://{prostore_host}:{prostore_port}/}
driverClassName: ${PROSTORE_JDBC_DRIVER_CLASS:ru.datamart.prostore.jdbc.Driver}
http:
prostoreUrl: ${PROSTORE_HTTP_URL:http://{prostore_host}:{prostore_port}/}
maxConnections: ${PROSTORE_MAX_CONNECTIONS:1000}
fetchSize: ${PROSTORE_FETCH_SIZE:10000}
maxInMemorySize: ${PROSTORE_MAX_IN_MEMORY_SIZE:16777216}
concurrency: ${PROSTORE_THREAD_COUNT:16}
webclient:
input:
connProvider:
maxConnections: ${ADAPTER_QUALITY_RECORD_INPUT_MAX_CONNECTIONS:1000}
retry:
initialDelayMs: ${ADAPTER_QUALITY_RECORD_INPUT_INITIAL_DELAY_MS:1000}
maxDelayMs: ${ADAPTER_QUALITY_RECORD_INPUT_MAX_DELAY_MS:5000}
output:
connProvider:
maxConnections: ${ADAPTER_QUALITY_RECORD_OUTPUT_MAX_CONNECTIONS:1000}
maxIdleTime: ${ADAPTER_QUALITY_RECORD_OUTPUT_MAX_IDLE_TIME:60}
maxLifeTime: ${ADAPTER_QUALITY_RECORD_OUTPUT_MAX_LIFE_TIME:120}
evictInBackground: ${ADAPTER_QUALITY_RECORD_OUTPUT_EVICT_IN_BACKGROUND:30}
retry:
initialDelayMs: ${ADAPTER_QUALITY_RECORD_OUTPUT_INITIAL_DELAY_MS:1000}
maxDelayMs: ${ADAPTER_QUALITY_RECORD_OUTPUT_MAX_DELAY_MS:5000}
execAlg:
connProvider:
maxConnections: ${ADAPTER_QUALITY_RECORD_EXEC_ALG_MAX_CONNECTIONS:1000}
maxIdleTime: ${ADAPTER_QUALITY_RECORD_EXEC_ALG_MAX_IDLE_TIME:60}
maxLifeTime: ${ADAPTER_QUALITY_RECORD_EXEC_ALG_MAX_LIFE_TIME:120}
evictInBackground: ${ADAPTER_QUALITY_RECORD_EXEC_ALG_EVICT_IN_BACKGROUND:30}
retry:
initialDelayMs: ${ADAPTER_QUALITY_RECORD_EXEC_ALG_INITIAL_DELAY_MS:1000}
maxDelayMs: ${ADAPTER_QUALITY_RECORD_EXEC_ALG_MAX_DELAY_MS:5000}
dqf:
quality:
bufferSize: 1000
capacity:
incomeQueue: ${DQF_QUALITY_CAPACITY_INCOME_QUEUE:1000}
outcomeQueue: ${DQF_QUALITY_CAPACITY_INCOME_QUEUE:1000}
threads:
recordThreads: ${DQF_QUALITY_RECORD_THREAD_COUNT:1}
checkThreads: ${DQF_QUALITY_CHECK_THREAD_COUNT:1}
consumerAsyncThreads: ${DQF_QUALITY_CONSUMER_ASYNC_THREADS:16}
schema: ${DQF_SCHEMA:reg_datamart_dqf}
nsud:
nsudCron: ${NSUD_CRON_TASK:0 */5 * * * *}
nsudUrlList: ${NSUD_URL_LIST:http://{agent_host}:{agent_port}/04PV02/pkch/api/v3/dqf_check_versions}
nsudUrlAck: ${NSUD_URL_ACK:http://{agent_host}:{agent_port}/04PV02/pkch/api/v3/dqf_check_versions/activations}
useHash: ${NSUD_USE_HASH:true}
pebble:
interval: ${NSUD_PEBBLE_INTERVAL:PT30s}
idleDelay: ${NSUD_PEBBLE_IDLE_DELAY:PT1m}
pebbleRefresh: ${NSUD_PEBBLE_REFRESH:PT5m}
datamarts:
- {имя основной схемы, подлежащей проверке}
agg:
aggCron: ${AGGREGATION_CRON_TASK: 0 0 1 * * *}
aggArmDsCron: ${AGGREGATION_ARM_DS_CRON_TASK: 0 0 1 * * *}
aggUrl: ${AGGREGATION_URL:http://{agent_host}:{agent_port}/04PV02/pkch/api/v3/dqf_check_reports}
aggArmDsStatUrl: ${AGGREGATION_DS_STAT_URL:http://{agent_host}:{agent_port}/04PV02/pmd/api/v3/data_mart_check_adapter_stats}
incident:
limitCount: ${INC_RATE_LIMITER_COUNT:100}
limitCron: ${INC_RATE_LIMITER_CRON:0 0 0 ? * 1}
batchSize: ${INC_BATCH_SIZE:100}
incUrl: ${INC_URL:http://{agent_host}:{agent_port}}/04PV02/pue/api/v3/incidents/dqf_quality_check}
2.2.2.2. Параметры конфигурации
Настройка конфигурации сервиса генерации уникального номера осуществляется путем редактирования параметров настроек в
файле application.yml, где настраиваются секции:
management– настройка внутренних эндпоинтов и метрик;spring– настройка Spring Boot и профиля работы приложения;server– настройка использования альтернативного значения серверного порта;adapter– настройка параметров вызова внешних сервисов;dqf– настройка параметров передачи данных аудита гостех;nsud– настройка взаимодействия с ЕИП НСУД;agg– настройка плана выполнения агрегаций;incident– настройка отправки единичных инцидентов качества.
2.2.2.2.1. Секция management
В секции management хранятся настройки внутренних эндпоинтов и метрик.
Например:
management:
endpoint:
health:
show-details: always
prometheus:
metrics:
export:
enabled: true
endpoints:
web:
exposure:
include: health, prometheus, configprops, env
metrics:
tags:
application: check-adapter-dqf
namespace: ${POD_NAMESPACE:local}
pod: ${POD_NAME:local}
node_name: ${NODE_NAME:local}
Параметры настроек
endpoint.health.show-details- детализация статуса health;prometheus.metrics.export.enabled- экспорт метрик Prometheus;endpoints.web.exposure.include- список доступных HTTP-эндпоинтов;metrics.tags.*- метки, добавляемые к метрикам.
2.2.2.2.2. Секция spring
В секции spring хранятся настройки Spring Boot и профиля работы приложения.
Например:
spring:
task:
scheduling:
pool:
size: 5
profiles:
active: ${PROFILES_ACTIVE:dqf}
Параметры настроек
task.scheduling.pool.size- размер пула планировщика задач Spring;profiles.active- активные профили приложения. Для задачи проверки качества данных используется профильdqf.
2.2.2.2.3. Секция server
В секции server хранятся настройки использования альтернативного значения серверного порта.
Существует два варианта изменения дефолтного значения номера порта:
Значение может быть передано через переменную окружения
SERVER_PORT. В случае запуска приложения с помощью systemd переменную необходимо передать через указаниеEnvironment="HTTP_PORT=3010"в.service-файле.
В случае прямого запуска, переменная должна быть задана на уровне ОС на момент запуска приложения.
Возможно указать в конфигурационном файле следующую настройку:
server:
port: ${HTTP_PORT:3010}
Параметры настроек
port- порт сервера, значение может быть изменено на нужное.
2.2.2.2.4. Секция adapter
В секции adapter хранятся настройки параметров вызова внешних сервисов.
Например:
adapter:
adapterNg:
http:
url: http://localhost:3010/
useAdapter: ${USE_NG_ADAPTER:true}
podd:
http:
url: http://localhost:8172/
prostore:
jdbc:
prostoreUrl: ${PROSTORE_JDBC_URL:jdbc:prostore://{prostore_host}:{prostore_port}/}
driverClassName: ${PROSTORE_JDBC_DRIVER_CLASS:ru.datamart.prostore.jdbc.Driver}
http:
prostoreUrl: ${PROSTORE_HTTP_URL:http://{prostore_host}:{prostore_port}/}
maxConnections: ${PROSTORE_MAX_CONNECTIONS:1000}
fetchSize: ${PROSTORE_FETCH_SIZE:10000}
maxInMemorySize: ${PROSTORE_MAX_IN_MEMORY_SIZE:16777216}
concurrency: ${PROSTORE_THREAD_COUNT:16}
webclient:
input:
connProvider:
maxConnections: ${DQF_QUALITY_RECORD_INPUT_MAX_CONNECTIONS:1000}
retry:
initialDelayMs: ${ADAPTER_QUALITY_RECORD_INPUT_INITIAL_DELAY_MS:1000}
maxDelayMs: ${ADAPTER_QUALITY_RECORD_INPUT_MAX_DELAY_MS:5000}
output:
connProvider:
maxConnections: ${DQF_QUALITY_RECORD_OUTPUT_MAX_CONNECTIONS:1000}
maxIdleTime: ${DQF_QUALITY_RECORD_OUTPUT_MAX_IDLE_TIME:60}
maxLifeTime: ${DQF_QUALITY_RECORD_OUTPUT_MAX_LIFE_TIME:120}
evictInBackground: ${DQF_QUALITY_RECORD_OUTPUT_EVICT_IN_BACKGROUND:30}
retry:
initialDelayMs: ${ADAPTER_QUALITY_RECORD_OUTPUT_INITIAL_DELAY_MS:1000}
maxDelayMs: ${ADAPTER_QUALITY_RECORD_OUTPUT_MAX_DELAY_MS:5000}
execAlg:
connProvider:
maxConnections: ${DQF_QUALITY_RECORD_EXEC_ALG_MAX_CONNECTIONS:1000}
maxIdleTime: ${DQF_QUALITY_RECORD_EXEC_ALG_MAX_IDLE_TIME:60}
maxLifeTime: ${DQF_QUALITY_RECORD_EXEC_ALG_MAX_LIFE_TIME:120}
evictInBackground: ${DQF_QUALITY_RECORD_EXEC_ALG_EVICT_IN_BACKGROUND:30}
retry:
initialDelayMs: ${ADAPTER_QUALITY_RECORD_EXEC_ALG_INITIAL_DELAY_MS:1000}
maxDelayMs: ${ADAPTER_QUALITY_RECORD_EXEC_ALG_MAX_DELAY_MS:5000}
Параметры настроек
adapterNg.http.url- URL сервиса ИУА;adapterNg.http. useAdapter- используется ли ИУА для взаимодействия со СМЭВ 3;podd.http.url- URL сервиса Агент СМЭВ 4, необходимо указывать порт для взаимодействия именно через Rest-api (по умолчанию в Агенте СМЭВ 4 8172);prostore.jdbc.*- JDBC-параметры подключения к Prostore;prostore.http.*- HTTP-параметры подключения к Prostore;fetchSize- количество записей, получаемых при поточной выборке из компонента Prostore;pormaxInMemorySizet- буферизация данных в памяти для кодеков webclient;concurrency- количество потоков трансфорирующих данные, после извлечения;webclient.input.connProvider.maxConnections- максимальное число одновременно открытых соединений в пуле;webclient.input.retry.initialDelayMs- начальное время паузы перед выполнением новой попытки вызова при получении ошибки;webclient.input.retry.maxDelayMs- конечное время паузы перед выполнением новой попытки вызова при получении ошибки;webclient.output.connProvider.maxIdleTime- максимальное время ожидания без активности для одного соединения;webclient.output.connProvider.maxLifeTime- общее время жизни соединения от момента его создания;webclient.output.connProvider.evictInBackground- интервал, с которым фоновой задачей будет выполняться проверка и удаления истекших (idle/expired) соединений;webclient.output.retry.initialDelayMs- начальное время паузы перед выполнением новой попытки вызова при получении ошибки;webclient.output.retry.maxDelayMs- конечное время паузы перед выполнением новой попытки вызова при получении ошибки;webclient.execAlg.connProvider.maxConnections- максимальное число одновременно открытых соединений в пуле;webclient.execAlg.connProvider. maxIdleTime- максимальное время ожидания без активности для одного соединения;webclient.execAlg.connProvider.maxLifeTime- общее время жизни соединения от момента его создания;webclient.execAlg.connProvider.evictInBackground- интервал, с которым фоновой задачей будет выполняться проверка и удаления истекших (idle/expired) соединений;powebclient. execAlg.retry.initialDelayMsrt- начальное время паузы перед выполнением новой попытки вызова при получении ошибки;webclient.execAlg.retry.maxDelayMs- конечное время паузы перед выполнением новой попытки вызова при получении ошибки.
2.2.2.2.5. Секция dqf
В секции dqf хранятся настройки параметров передачи данных аудита гостех.
Например:
dqf:
quality:
bufferSize: 1000
capacity:
incomeQueue: ${DQF_QUALITY_CAPACITY_INCOME_QUEUE:1000}
outcomeQueue: ${DQF_QUALITY_CAPACITY_INCOME_QUEUE:1000}
threads:
recordThreads: ${DQF_QUALITY_RECORD_THREAD_COUNT:1}
checkThreads: ${DQF_QUALITY_CHECK_THREAD_COUNT:1}
consumerAsyncThreads: ${DQF_QUALITY_CONSUMER_ASYNC_THREADS:16}
schema: ${DQF_SCHEMA:reg_datamart_dqf}
Параметры настроек
bufferSize- размер внутреннего пакета обработки;incomeQueue- размер внутренней очереди извлечения данных;outcomeQueue- размер очереди на отправку в ПО Prostore;recordThreads- количество тредов на получение списка идентификаторов;checkThreads- количество тредов на проверку полученых данных;consumerAsyncThreads- количество тредов на извлечение данных из внутренней очереди;schema- наименование служебной схемы (формируется по шаблону:{имя_основной_схемы}_dqf).
2.2.2.2.6. Секция nsud
В секции nsud хранятся настройки взаимодействия с ЕИП НСУД.
Например:
nsud:
nsudCron: ${NSUD_CRON_TASK:0 */5 * * * *}
nsudUrlList: ${NSUD_URL_LIST:http://{agent_host}:{agent_port}/04PV02/pkch/api/v3/dqf_check_versions}
nsudUrlAck: ${NSUD_URL_ACK:http://{agent_host}:{agent_port}/04PV02/pkch/api/v3/dqf_check_versions/activations}
useHash: ${NSUD_USE_HASH:true}
pebble:
interval: ${NSUD_PEBBLE_INTERVAL:PT30s}
idleDelay: ${NSUD_PEBBLE_IDLE_DELAY:PT1m}
pebbleRefresh: ${NSUD_PEBBLE_REFRESH:PT5m}
datamarts:
- {имя основной схемы, подлежащей проверке}
Параметры настроек
nsudCron- периодичность получения списка проверок;nsudUrlList- адрес для получения списка проверок качества данных (необходимо указывать порт для взаимодействия именно через REST API (по умолчанию в Агенте СМЭВ 4 8172));nsudUrlAck- адрес подтверждения применения проверок качества данных (необходимо указывать порт для взаимодействия именно через REST API (по умолчанию в Агенте СМЭВ 4 8172));useHash- порт веб-сервера, например:HTTP_PORT:9000.
2.2.2.2.7. Секция agg
В секции agg хранятся настройки плана выполнения агрегаций.
Например:
agg:
aggCron: ${AGGREGATION_CRON_TASK: 0 0 1 * * *}
aggArmDsCron: ${AGGREGATION_ARM_DS_CRON_TASK: 0 0 1 * * *}
aggUrl: ${AGGREGATION_URL:http://{agent_host}:{agent_port}/04PV02/pkch/api/v3/dqf_check_reports}
aggArmDsStatUrl: ${AGGREGATION_DS_STAT_URL:http://{agent_host}:{agent_port}/04PV02/pmd/api/v3/data_mart_check_adapter_stats}
Параметры настроек
aggCron- периодичность запуска подсчета агрегированной статистики для передачи в ЕИП НСУД (рекомендуется устанавливать 1 раз в день);aggArmDsCron- периодичность запуска подсчета агрегированной статистики для отображений виджета ТПО УД (рекомендуется устанавливать 1 раз в день);aggUrl- адрес отправки агрегированной статистики в ЕИП НСУД (необходимо указывать порт для взаимодействия именно через REST API (по умолчанию в Агенте СМЭВ 4 8172));aggArmDsStatUrl- адрес отправки агрегированной статистики в разрезе таблиц в ЕИП НСУД (необходимо указывать порт для взаимодействия именно через Rest-api (по умолчанию в Агенте СМЭВ 4 8172)).
2.2.2.2.8. Секция incident
В секции incident хранятся настройки отправки единичных инцидентов качества.
Например:
incident:
batchSize: ${INC_BATCH_SIZE:100}
incUrl: ${INC_URL:http://{agent_host}:{agent_port}}/04PV02/pue/api/v3/incidents/dqf_quality_check}
Параметры настроек
batchSiz- размер пакета, передаваемого за раз в ЕИП НСУД;incUrl- адрес для передачи единичных инцидентов в ЕИП НСУД;aggUrl- адрес отправки агрегированной статистики в ЕИП НСУД (необходимо указывать порт для взаимодействия именно через REST API (по умолчанию в Агенте СМЭВ 4 8172)).
2.2.2.3. Конфигурационный файл с описанием проверяемой схемы
Агенту проверок, для построения внутренней модели со связями таблиц, необходим файл с описанием проверяемой схемы и связей таблиц внутри этой схемы в формате приведенном ниже:
CREATE TABLE vehicle.owners (
id UUID NOT NULL,
name VARCHAR(255) NOT NULL,
birthdate DATE NULL,
PRIMARY KEY (id)
);
CREATE TABLE vehicle.cars (
id UUID NOT NULL,
owner_id UUID NOT NULL,
model VARCHAR(255) NOT NULL,
manufacture_year INTEGER NULL,
PRIMARY KEY (id)
);
CREATE TABLE vehicle.repairs (
id UUID NOT NULL,
car_id UUID NOT NULL,
owner_id UUID NOT NULL,
repair_date DATE NOT NULL,
description TEXT NULL,
PRIMARY KEY (id)
);
-- Foreign key constraints
ALTER TABLE vehicle.cars
ADD CONSTRAINT fk_cars_owner
FOREIGN KEY (owner_id)
REFERENCES vehicle.owners(id);
ALTER TABLE vehicle.repairs
ADD CONSTRAINT fk_repairs_car
FOREIGN KEY (car_id)
REFERENCES vehicle.cars(id);
ALTER TABLE vehicle.repairs
ADD CONSTRAINT fk_repairs_owner
FOREIGN KEY (owner_id)
REFERENCES vehicle.owners(id);
Имя файла необходимо формировать по формату {имя проверяемой схемы}.sql в данном случае vehicle.sql.
2.2.2.4. Описание спецификации для взаимодействия с Агентом проверок
2.2.2.4.1. Выполнение тестирования проверок качества данных, до их публикации и применения к витрине данных
URL сервиса: http://localhost/dqf/quality-checks
Описание сервиса
openapi: 3.0.1
info:
title: Quality Check API
version: 1.0.0
# Добавлен базовый путь /dqf
servers:
- url: /dqf
description: Base path for DQF Quality Check API
paths:
/quality-checks:
post:
summary: Тестирование проверки качества
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/SimpleQualityCheckRequest'
responses:
'200':
description: Успешный ответ (или ошибка логики запроса)
content:
application/json:
schema:
$ref: '#/components/schemas/QualityCheckResponse'
examples:
success:
summary: Проверка прошла успешно
value:
id: 1
status: success
code: "200"
description: Тестирование успешно пройдено
ProstoreError:
summary: Ошибка при выполнении SQL-запроса
value:
id: 1
status: error
code: "ProstoreError"
description: Датамарт не найден
yamlError:
summary: Ошибка при разборе yaml выражения
value:
id: 1
status: error
code: "yamlError"
description: Ошибка в строке 5
'400':
description: Ошибка в запросе
content:
application/json:
schema:
$ref: '#/components/schemas/QualityCheckResponse'
examples:
badRequestError:
summary: Ошибка при разборе входящего тела сообщения
value:
id: 1
status: error
code: "badRequestError"
description: Отсутствует обязательный элемент yaml_schema
'500':
description: Внутренняя ошибка сервера
content:
application/json:
schema:
$ref: '#/components/schemas/QualityCheckResponse'
examples:
internalServerError:
summary: Внутренняя ошибка сервера
value:
id: 1
status: error
code: "internalServerError"
description: Возникла внутренняя ошибка при тестировании проверки качества
components:
schemas:
SimpleQualityCheckRequest:
type: object
properties:
id:
type: integer
dqf_check_template_mnemonic:
type: string
enum:
- CheckValuePlenum
- CheckValueCorrect
- CheckValueConsistency
yaml_schema:
type: string
data_mart_version:
type: object
properties:
id:
type: integer
mnemonic:
type: string
code:
type: string
required:
- id
- mnemonic
- code
data_mart_table_tech_name:
type: string
data_mart_attributes:
type: array
items:
type: object
properties:
id:
type: integer
name:
type: string
tech_name:
type: string
required:
- id
- name
- tech_name
required:
- id
- dqf_check_template_mnemonic
- yaml_schema
- data_mart_version
- data_mart_table_tech_name
- data_mart_attributes
QualityCheckResponse:
type: object
properties:
id:
type: integer
status:
type: string
enum:
- success
- error
code:
type: string
description:
type: string
required:
- id
- status
- code
- description
2.2.2.4.2. Прием результатов сверок и сопоставлений данных подсистемой ЕСУМД ФГИС «Моя школа»
URL сервиса: http://localhost/api/v1/incidents/upload
Описание сервиса
openapi: 3.0.0
info:
title: Students API
version: 1.0.0
servers:
- url: /api/v1/incidents
description: Base path for incident operations
paths:
/upload:
post:
summary: Создание или обновление записей об инцидентах студентов
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/IncidentUploadRequest'
responses:
'200':
description: Успешное создание или обновление записей студентов
content:
application/json:
schema:
$ref: '#/components/schemas/UploadResponse'
examples:
success:
summary: Сообщение об успешной отправке
value:
message: "Messages sent successfully"
components:
schemas:
UploadResponse:
type: object
properties:
message:
type: string
description: Сообщение-подтверждение успешной операции (включает количество обработанных записей)
required:
- message
IncidentUploadRequest:
type: array
items:
$ref: '#/components/schemas/IncidentRecord'
description: Массив объектов с данными об инцидентах студентов
IncidentRecord:
type: object
required:
- checked_at
- identifier
- version
- table
- datamart
- algorithmId
- errors
properties:
checked_at:
type: integer
description: Метка времени UTC в миллисекундах
identifier:
$ref: '#/components/schemas/Identifier'
description: Объект с одним ключом, указывающим источник идентификатора (pk для СМЭВ-3 или cardId для ЕСУМД)
version:
type: integer
description: CN (номер изменения) исходной записи
table:
type: string
description: Имя исходной таблицы
datamart:
type: string
description: Имя исходного датамарта
algorithmId:
type: integer
description: Идентификатор алгоритма проверки качества
errors:
type: array
description: Список ошибок, выявленных алгоритмом
items:
$ref: '#/components/schemas/ErrorItem'
Identifier:
type: object
oneOf:
- $ref: '#/components/schemas/IdentifierPK'
- $ref: '#/components/schemas/IdentifierCardId'
description: Тип идентификатора, выбирается один из вариантов ниже
IdentifierPK:
type: object
required:
- pk
properties:
pk:
type: string
description: Значение идентификатора из СМЭВ-3
IdentifierCardId:
type: object
required:
- cardId
properties:
cardId:
type: string
description: Значение идентификатора из ЕСУМД
ErrorItem:
type: object
required:
- code
- description
properties:
code:
type: string
description: Код ошибки, возвращённый алгоритмом проверки
description:
type: object
description: Отображение имён полей на значения, которые не прошли валидацию
2.2.2.5. Описание служебной схемы, создаваемой Агентом проверок
При первом старте Агент проверок создает для корректной работы служебную схему с именем, указанном в конфигурационном файле
application.yaml:
dqf:
schema: ${DQF_SCHEMA:{имя_основной_схемы}_dqf}
2.2.2.5.1. Описание таблицы dqf_{table_name}_errors
Datamart name: Исходный datamart пользователя.
Datamart table: dqf_{table_name}_errors.
Тип таблицы: proxy.
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
dqf_id |
VARCHAR |
Уникальный идентификатор записи |
|
dqf_version |
BIGINT |
Идентификатор операции записи (cn), в рамках которой, в исходную таблицу поступила версия записи |
||
{field_name_1} |
{field_type_1} |
Первичный ключ строки из исходной таблицы |
Число строк в таблице результатов проверок зависит от числа строк, входящих в первичный ключ исходной таблицы, подлежащей проверке |
|
{field_name_2} |
{field_type_2} |
|||
{field_name_N} |
{field_type_N} |
|||
dqf_pk_hash |
VARCHAR |
Хешированные значения первичных ключей исходной таблицы |
||
dqf_checked_at |
TIMESTAMP |
Время, в которое выполнялась проверка |
||
dqf_algorithm_id |
BIGINT |
Алгоритм, по которому выполнялась проверка |
||
dqf_code |
VARCHAR |
Код ошибки |
||
dqf_description |
VARCHAR |
Исходное поле и его значение, не прошедшие проверку |
2.2.2.5.2. Описание таблицы dqf_checks
Datamart name: Исходный datamart пользователя.
Datamart table: dqf_checks.
Тип таблицы: proxy.
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
datamart_table |
VARCHAR |
Имя datamart |
|
algorithm_id |
BIGINT |
Алгоритм, по которому выполнялась проверка |
||
last_cn |
BIGINT |
Последний проверенный идентификатор операции записи (cn) из исходной таблицы |
2.2.2.5.3. Описание таблицы aggregation
Datamart name: {datamart_name}_dqf.
Datamart table: aggregation.
Тип таблицы: proxy.
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
id |
VARCHAR |
Уникальный идентификатор результата агрегации |
|
datamart |
VARCHAR |
Имя datamart |
||
datamart_table |
VARCHAR |
Имя таблицы |
||
created_at |
TIMESTAMP |
Время создания агрегата |
||
errors_count |
BIGINT |
Число ошибок в актуальном состоянии исходной таблицы на момент выполнения проверки |
||
field_count |
BIGINT |
Число записей в актуальном состоянии исходной таблицы на момент выполнения проверки |
||
algorithm_id |
BIGINT |
Алгоритм проверки |
||
code |
VARCHAR |
Код ошибки |
2.2.2.5.4. Описание таблицы aggregation_arm_ds
Datamart name: {datamart_name}_dqf.
Datamart table: aggregation_arm_ds.
Тип таблицы: proxy.
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
datamart |
VARCHAR |
Имя datamart |
|
true |
datamart_table |
VARCHAR |
Имя таблицы |
|
fields_count |
BIGINT |
Общее число строк в таблице |
||
error_fields_count |
BIGINT |
Количество строк с ошибками |
||
error_fields_notification_count |
BIGINT |
ЧЧисло с ошибками типа уведомительные |
||
error_fields_blocked_count |
BIGINT |
Число с ошибками типа блокирующие |
||
errors_count |
BIGINT |
Общее число ошибок |
||
errors_type_notification |
BIGINT |
Количество ошибок типа уведомительные |
||
errors_type_blocked |
BIGINT |
Количество ошибок типа блокирующие |
||
created_at |
TIMESTAMP |
Время формирования агрегации |
2.2.2.5.5. Описание таблицы child_checks
Datamart name: {datamart_name}_dqf.
Datamart table: child_checks.
Тип таблицы: proxy.
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
id |
VARCHAR |
Уникальный идентификатор записи |
|
parent_check_id |
VARCHAR |
Ссылка на запись в таблице
|
||
datamart_table |
VARCHAR |
Имя таблицы, для которой действует проверка |
||
expression |
VARCHAR |
Содержимое проверки |
2.2.2.5.6. Описание таблицы parent_checks
Datamart name: {datamart_name}_dqf.
Datamart table: parent_checks.
Тип таблицы: proxy.
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
id |
VARCHAR |
Уникальный идентификатор записи |
|
check_code |
BIGINT |
Алгоритм проверки |
||
datamart |
VARCHAR |
Имя датамарта |
||
datamart_table |
VARCHAR |
Имя исходной таблицы |
||
check_algorithm |
VARCHAR |
Тело проверки |
||
type |
VARCHAR |
Тип проверки |
2.2.2.5.7. Описание таблицы inc_settings
Datamart name: {datamart_name}_dqf.
Datamart table: inc_settings.
Тип таблицы: proxy
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
algorithm_id |
BIGINT |
Идентификатор алгоритма проверки |
|
code |
VARCHAR |
Код ошибки |
||
datamart |
VARCHAR |
Имя датамарта |
||
datamart_table |
VARCHAR |
Имя исходной таблицы |
||
quality_kind_code |
BIGINT |
Код вида проверки (блокирующая/неблокирующая и т.п.) |
||
is_internal |
BOOLEAN |
Признак внутренней проверки |
2.2.2.5.8. Описание таблицы last_processed_operation
Datamart name: {datamart_name}_dqf.
Datamart table: last_processed_operation.
Тип таблицы: proxy.
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
datamart |
VARCHAR |
Имя датамарта |
|
true |
datamart_table |
VARCHAR |
Имя исходной таблицы |
|
true |
algorithm_id |
BIGINT |
Идентификатор алгоритма проверки |
|
last_cn |
BIGINT |
Номер последней обработанной операции |
2.2.2.5.9. Описание таблицы schedule_checks
Datamart name: {datamart_name}_dqf.
Datamart table: schedule_checks.
Тип таблицы: proxy.
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
check_code |
BIGINT |
Код проверки |
|
cron |
VARCHAR |
Cron-выражение |
||
period_from |
VARCHAR |
Начало периода запуска |
||
period_to |
VARCHAR |
Конец периода запуска |
||
datamart |
VARCHAR |
Имя датамарта |
2.2.2.5.10. Описание таблицы smev3_adapter_pebble
Datamart name: {datamart_name}_dqf.
Datamart table: smev3_adapter_pebble.
Тип таблицы: proxy
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
id |
VARCHAR(100) |
Уникальный идентификатор шаблона |
|
content |
VARCHAR |
Содержимое шаблона |
||
exclusion |
BOOLEAN |
Флаг исключения применения шаблона |
||
period_to |
VARCHAR |
Конец периода запуска |
Если для шаблона указать true, то в случае удаления проверки в ЕИП НСУД, указаный шаблон не будет удаляться |
|
datamart |
VARCHAR |
Имя датамарта |
2.2.2.5.11. Описание таблицы smev3_adapter_receiver_scheduler
Datamart name: {datamart_name}_dqf.
Datamart table: smev3_adapter_receiver_scheduler.
Тип таблицы: proxy.
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
id |
INTEGER |
Уникальный идентификатор записи |
|
type |
VARCHAR (50) |
Тип Pebble шаблона, запросный или ответный |
||
content |
VARCHAR |
Параметры обновлений по шаблону |
||
template_file |
VARCHAR |
Идентификатор записи из таблицы
|
||
queue_id |
VARCHAR |
Имя выделенной очереди в адаптере ИУА |
Не заполняется в случае если для интеграции со СМЭВ 3 используется адаптер СМЭВ 3 |
2.2.2.5.12. Описание таблицы inc_rate_limiter
Datamart name: {datamart_name}_dqf.
Datamart table: inc_rate_limiter.
Тип таблицы: proxy.
PK |
Поле |
Тип |
Описание |
Примечание |
|---|---|---|---|---|
true |
algorithm_id |
BIGINT |
Уникальный идентификатор записи |
|
datamart |
VARCHAR |
Имя датамарта |
||
limit_count |
BIGINT |
Лимит на число единичных инцидентов за период |
||
limit_cron |
VARCHAR |
Периодичность обновления лимита |
||
current_count |
BIGINT |
Текущее число единичных инцидентов |
||
next_update_date |
VARCHAR |
Дата следующего сброса лимита |
2.2.3. Настройка Сервиса генерации уникального номера (Counter-provider)
2.2.3.1. Конфигурация модуля Counter-Provider (application.yml)
Файл application.yml – основной конфигурационный файл модуля, в котором задана его логика и порядок работы сервиса:
среда разработки;
настройка счетчика;
настройка подключения к Zookeeper, а также другие настройки необходимые для корректной работы сервиса.
2.2.3.2. Пример файла application.yml
В конфигурационном файле следует задавать только те настройки, которые необходимы для решения текущих бизнес-задач.
environment:
name: ${ENVIRONMENT_NAME:test}
http-server:
port: ${HTTP_PORT:9000}
counter:
start-number: ${COUNTER_START_NUMBER:1}
retry-after-failure: ${COUNTER_RETRY_AFTER_FAILURE:3}
update-timeout: ${COUNTER_UPDATE_TIMEOUT:}
reset-period: ${COUNTER_RESET_PERIOD:}
increment-gap: ${INCREMENT_GAP:1}
zookeeper:
connection-string: ${ZOOKEEPER_DS_ADDRESS:localhost}
connection-timeout-ms: ${ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000}
session-timeout-ms: ${ZOOKEEPER_DS_SESSION_TIMEOUT_MS:86400000}
chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}
persistence-mode: ${PERSISTENCE_MODE:prostore} # prostore | zookeeper
prostore-rest-client:
host: ${PS_HOST:localhost}
port: ${PS_PORT:9195}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:5}
persistence-datamart: ${PERSISTENCE_DATAMART:persistence}
datasource: ${PERSISTENCE_DATASOURCE:} # по умолчанию пусто, тогда берется единственный датасорс из настроек Простора
counter-prefix: ${COUNTER_PREFIX:counter_}
migration:
enabled: ${MIGRATION_ENABLE:false}
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# Массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается неактивным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- keys
metrics:
port: ${METRICS_PORT:9837}
2.2.3.3. Параметры конфигурации
Настройка конфигурации сервиса генерации уникального номера осуществляется путем редактирования параметров настроек в
файле application.yml, где настраиваются секции:
environment- указывается среда разработки;http-server- указывается порт веб-сервера;counter- указываются настройки счетчика;zookeeper- определяет настройки подключения к Zookeeper;persistence-mode- настройки хранения данных;prostore-rest-client- блок параметров конфигурирования взаимодействия с Prostore;migration- настройки миграции;component-info- настройки модуля сбора информации о компонентах витрины;metrics- настройка порта для получения метрик.
2.2.3.3.1. Секция environment
В секции environment указывается среда разработки (dev, test, stable, prod).
Например:
environment:
name: ${ENVIRONMENT_NAME:test}
Параметры настроек
name- среда разработки, напримерENVIRONMENT_NAME:test.
2.2.3.3.2. Секция http-server
В секции http-server указывается порт веб-сервера.
Например:
http-server:
port: ${HTTP_PORT:9000}
Параметры настроек
port- порт веб-сервера, например:HTTP_PORT:9000.
2.2.3.3.3. Секция counter
В секции counter можно настраивать начальный номер счетчика, а также количество попыток записи счетчика после ошибки
обновления.
Например:
counter:
start-number: ${COUNTER_START_NUMBER:1}
retry-after-failure: ${COUNTER_RETRY_AFTER_FAILURE:3}
update-timeout: ${COUNTER_UPDATE_TIMEOUT:}
reset-period: ${COUNTER_RESET_PERIOD:}
increment-gap: ${INCREMENT_GAP:1}
Параметры настроек
start-number- начальный номер счетчика, напримерCOUNTER_START_NUMBER:1;retry-after-failure- количество попыток записи счетчика после ошибки обновления, напримерCOUNTER_RETRY_AFTER_FAILURE:3;update-timeout- таймаут обновления счетчика, напримерCOUNTER_UPDATE_TIMEOUT:;reset-period- период сброса счетчика, напримерCOUNTER_RESET_PERIOD:;increment-gap- шаг инкремента, напримерINCREMENT_GAP:1.
2.2.3.3.4. Секция zookeeper
В секции zookeeper настраиваются параметры подключения к Zookeeper.
Например:
zookeeper:
connection-string: ${ZOOKEEPER_DS_ADDRESS:t5-adsp-01.ru-central1.internal}
connection-timeout-ms: ${ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000}
session-timeout-ms: ${ZOOKEEPER_DS_SESSION_TIMEOUT_MS:86400000}
chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}
Параметры настроек
connection-string- Подключение к Zookeeper DS, напримерZOOKEEPER_DS_ADDRESS:t5-adsp-01.ru-central1.internal;connection-timeout-ms- Zookeeper DS таймаут подключения, напримерZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000;session-timeout-ms- Zookeeper DS таймаут сессии, напримерZOOKEEPER_DS_SESSION_TIMEOUT_MS:86400000;chroot- Zookeeper DS chroot path, напримерZOOKEEPER_DS_CHROOT:/adapter.
2.2.3.3.5. Секция persistence-mode
В секции persistence-mode указывается настройка хранения данных: или в Prostore, или в Zookeeper. В случае
выбора Prostore автоматически создаются необходимые таблицы.
Например:
persistence-mode: ${PERSISTENCE_MODE:prostore} # prostore | zookeeper
Параметры настроек
persistence-mode- настройка хранения данных, напримерPERSISTENCE_MODE:prostore.
2.2.3.3.6. Секция prostore-rest-client
В секции prostore-rest-client реализован блок параметров конфигурирования взаимодействия с Prostore.
Например:
prostore-rest-client:
host: ${PS_HOST:localhost}
port: ${PS_PORT:9195}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:5}
persistence-datamart: ${PERSISTENCE_DATAMART:persistence}
datasource: ${PERSISTENCE_DATASOURCE:}
counter-prefix: ${COUNTER_PREFIX:counter_}
Параметры настроек
host- адрес Prostore, напримерPS_HOST:localhost;port- порт Prostore, напримерPS_PORT:9195;max-pool-size- максимальное число подключений к Prostore, напримерPS_MAX_POOL_SIZE:8;persistence-datamart- настройка хранения данных, например{PERSISTENCE_DATAMART:persistence};datasource- источник данных, напримерPERSISTENCE_DATASOURCE:, по умолчанию пусто, в этом случае берется единственный датасорс из настроек Простора.
2.2.3.3.7. Секция migration
В секции migration настраиваются миграции из Zookeeper в Prostore для задачи бекапирования.
Например:
migration:
enabled: ${MIGRATION_ENABLE:false}
Параметры настроек
enabled- подключение миграции, например{MIGRATION_ENABLE:false}.
2.2.3.3.8. Секция component-info
В секции component-info хранятся настройки компонента сбора информации о компонентах витрины.
Например:
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# Массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается неактивным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- keys
Параметры настроек
enabled- статус подключения компонента, указывается булево значение;datasource- массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте;datamart- схема Prostore;table-name- имя таблицы для записи информации о компоненте;create-table-period- период попыток создания схемы, при неуспехе, указывается в секундах;publish-period- период публикации health-check, указывается в секундах;timeout-active- период после которого компонент считается неактивным при отсутствии health-check, указывается в секундах;secrets- список элементов конфига маскируемых при отправке, если указан узловой элемент, то маскируются все вложенные в него элементы.
2.2.3.3.9. Секция metrics
В секции metrics настраивается порт получения метрик.
Например:
metrics:
port: ${METRICS_PORT:9837}
Параметры настроек
port- порт для получения метрик, например{METRICS_PORT:9837}.
2.2.4. Настройка Сервиса формирования документов
2.2.4.1. Конфигурация модуля «Сервиса Формирования документов» (application.yml)
Файл application.yml – основной конфигурационный файл сервиса формирования документов, в котором задана логика и порядок работы сервиса:
настройка и обработка документов;
путь к pebble-шаблонам документов (секция
printable-forms);настройка сервиса формирования подписи (
sign-service);настройка подключения к базе данных (секция:
datasource);настройка проверки состояния БД (секция
health) и другие настройки необходимые для корректной работы сервиса.
2.2.4.1.1. Пример файла application.yml
В конфигурационном файле следует задавать только те настройки, которые необходимы для решения текущих бизнес-задач.
http-server:
port: ${HTTP_PORT:8080}
executor:
reader-pool-size: ${EXECUTOR_READER_POOL_SIZE:20}
prostore-rest-client:
host: ${PS_HOST:localhost}
port: ${PS_PORT:9195}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:20}
metrics:
port: ${METRICS_PORT:9837}
vertx:
web-client:
max-pool-size: 20
counter-service:
host: ${COUNTER_SERVICE_HOST:localhost}
port: ${COUNTER_SERVICE_PORT:9000}
serviceName: ${COUNTER_SERVICE_NAME:printableform}
timeout: ${COUNTER_SERVICE_TIMEOUT:30}
sign-service:
url: ${SIGN_SERVICE_URL:http://localhost:8192}
timeout: ${SIGN_SERVICE_TIMEOUT:30}
pool-size: ${SIGN_SERVICE_POOL_SIZE:5}
printable-forms:
# Таймаут по умолчанию для генерации отчётов, применяется если не задан конкретный таймаут на отчёт
default-request-timeout: 60s
# Список отчетов
reports:
# имя документа
- report: document_1
# Таймаут для генерации отчёта
request-timeout: 30s
# настройки по извлечению данных
extract:
# путь pebble шаблона, который будет извлекать данные
template: extract_static.peb
# настройки по формированию xml документа
xml:
# путь pebble шаблона, который будет формировать xml документ
template: generate_xml_1.peb
# Id подписываемого элемента, если не указано, то подписывается весь xml
elementId: elementToSign
# имя элемента, куда добавлять ЭП, если не указано, то в корень
elementName: signature
# имя файла, если не указано, то <Id_ПФ + ".xml">
fileName: document_1.xml
# настройки по формированию xml документа с открепленной подписью
xml_detached_sig:
# имя файла, если не указано, то <Id_ПФ + ".xml">
fileName: document_1.xml
# имя файла p7s, если не указано, то <Id_ПФ + ".p7s">
fileSign: xmlSign.p7s
# настройки по формированию pdf документа
pdf:
# путь pebble шаблона, который будет формировать pdf документ
template: generate_pdf_1.peb
# имя файла, если не указано, то <Id_ПФ + ".pdf">
fileName: pdfFileName.pdf
# настройки по формированию pdf документа с открепленной подписью
pdf_sig:
# путь pebble шаблона, который будет формировать подписываемый pdf документ, задается в .pdf.template
# (для генерации "pdf без ЭП" и "pdf с ЭП" используется единый pebble-шаблон)
# имя файла, если не указано, то <Id_ПФ + ".pdf">
fileName: pdfFileName.pdf
# имя файла p7s, если не указано, то <Id_ПФ + ".p7s">
fileSign: pdfSign.p7s
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# Массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается неактивным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- keys
2.2.4.2. Параметры конфигурации
Настройка конфигурации сервиса формирования документов осуществляется путем редактирования параметров настроек в файле application.yml,
где настраиваются секции:
http-server- указывается порт веб-сервера;executor- предназначена для указания размера пула для запросов;prostore-rest-client- настраивается блок параметров взаимодействия с Prostore;metrics- указывается порт для получения метрик;counter-service- указываются настройки подключения к сервису генерации номера;sign-service- указываются настройки подключения к сервису подписания документа;printable-forms- указываются настройки сервиса формирования документов;component-info- настройки модуля сбора информации о компонентах витрины.
2.2.4.2.1. Секция http-server
В секции http-server указывается порт веб-сервера.
Например:
http-server:
port: ${HTTP_PORT:8080}
Параметры настроек
port- порт веб-сервера, например:HTTP_PORT:8080.
2.2.4.2.2. Секция executor
В секции executor указывается размер пула для запросов.
Например:
executor:
reader-pool-size: ${EXECUTOR_READER_POOL_SIZE:20}
Параметры настроек
reader-pool-size- размер пула для чтения запросов, напримерEXECUTOR_READER_POOL_SIZE:20
2.2.4.2.3. Секция prostore-rest-client
В секции prostore-rest-client настраивается блок параметров взаимодействия с Prostore.
Например:
prostore-rest-client:
host: ${PS_HOST:localhost}
port: ${PS_PORT:9195}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:20}
Параметры настроек
host- адрес Prostore, напримерPS_HOST:localhost;port- порт Prostore, напримерPS_PORT:9195;max-pool-size- максимальное число подключений к Prostore, напримерPS_MAX_POOL_SIZE:20.
2.2.4.2.4. Секция metrics
В секции metrics указывается порт для получения метрик.
Например:
metrics:
port: ${METRICS_PORT:9837}
Параметры настроек
port- порт для получения метрик, напримерMETRICS_PORT:9837.
2.2.4.2.5. Секция counter-service
В секции counter-service настраивается подключение к сервису генерации номера.
Например:
counter-service:
host: ${COUNTER_SERVICE_HOST:localhost}
port: ${COUNTER_SERVICE_PORT:9000}
serviceName: ${COUNTER_SERVICE_NAME:printableform}
timeout: ${COUNTER_SERVICE_TIMEOUT:30}
Параметры настроек
host- адрес сервиса генерации номера, напримерCOUNTER_SERVICE_HOST:t5-printable-form-01.ru-central1.internal;port- порт сервиса генерации номера, напримерCOUNTER_SERVICE_PORT:9000;serviceName- значение имени сервиса, напримерCOUNTER_SERVICE_NAME:printableform;timeout- таймаут на генерации номера, напримерCOUNTER_SERVICE_TIMEOUT:30.
2.2.4.2.6. Секция sign-service
В секции sign-service настраивается подключение к сервису подписания документа.
Например:
sign-service:
url: ${SIGN_SERVICE_URL:http://dev-dtm-poddagent01.ru-central1.internal:8192}
timeout: ${SIGN_SERVICE_TIMEOUT:30}
pool-size: ${SIGN_SERVICE_POOL_SIZE:5}
Параметры настроек
url- URL сервиса подписания документа, напримерSIGN_SERVICE_URL:http://dev-dtm-poddagent01.ru-central1.internal:8192;timeout- таймаут на подписание документа (сек), напримерSIGN_SERVICE_TIMEOUT:30;pool-size- размер пула для сервиса подписания, напримерSIGN_SERVICE_POOL_SIZE:5.
2.2.4.2.7. Секция printable-forms
В секции printable-forms настраивается сервис формирования документов.
Например:
printable-forms:
# Таймаут по умолчанию для генерации отчётов, применяется если не задан конкретный таймаут на отчёт
default-request-timeout: 60s
# Список отчетов
reports:
# имя документа
- report: document_1
# Таймаут для генерации отчёта
request-timeout: 30s
# настройки по извлечению данных
extract:
# путь pebble шаблона, который будет извлекать данные
template: extract_static.peb
# настройки по формированию xml документа
xml:
# путь pebble шаблона, который будет формировать xml документ
template: generate_xml_1.peb
# Id подписываемого элемента, если не указано, то подписывается весь xml
elementId: elementToSign
# имя элемента, куда добавлять ЭП, если не указано, то в корень
elementName: signature
# имя файла, если не указано, то <Id_ПФ + ".xml">
fileName: document_1.xml
# настройки по формированию xml документа с открепленной подписью
xml_detached_sig:
# имя файла, если не указано, то <Id_ПФ + ".xml">
fileName: document_1.xml
# имя файла p7s, если не указано, то <Id_ПФ + ".p7s">
fileSign: xmlSign.p7s
# настройки по формированию pdf документа
pdf:
# путь pebble шаблона, который будет формировать pdf документ
template: generate_pdf_1.peb
# имя файла, если не указано, то <Id_ПФ + ".pdf">
fileName: pdfFileName.pdf
# настройки по формированию pdf документа с открепленной подписью
pdf_sig:
# путь pebble шаблона, который будет формировать подписываемый pdf документ, задается в .pdf.template
# (для генерации "pdf без ЭП" и "pdf с ЭП" используется единый pebble-шаблон)
# имя файла, если не указано, то <Id_ПФ + ".pdf">
fileName: pdfFileName.pdf
# имя файла p7s, если не указано, то <Id_ПФ + ".p7s">
fileSign: pdfSign.p7s
Внимание
В конфигурационном файле application.yml пути к файлам pebble-шаблонов должны быть либо относительно директории запуска, либо абсолютные пути.
2.2.4.2.8. Секция component-info
В секции component-info хранятся настройки компонента сбора информации о компонентах витрины.
Например:
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# Массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается неактивным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- keys
Параметры настроек
enabled- статус подключения компонента, указывается булево значение;datasource- массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте;datamart- схема Prostore;table-name- имя таблицы для записи информации о компоненте;create-table-period- период попыток создания схемы, при неуспехе, указывается в секундах;publish-period- период публикации health-check, указывается в секундах;timeout-active- период после которого компонент считается неактивным при отсутствии health-check, указывается в секундах;secrets- список элементов конфига маскируемых при отправке, если указан узловой элемент, то маскируются все вложенные в него элементы.
2.2.4.3. Примеры pebble-шаблонов для Сервиса Формирования документов
2.2.4.3.1. Возможность вызова REST-сервисов из шаблона Сервиса Формирования документов
Для вызова REST-сервисов из шаблона Сервиса Формирования документов используется функция callRest.
Пример вызова функции из pebble-шаблона:
{% set host = "smevql-dtm-smevqlserver01.ru-central1.internal" %}
{% set port = "8080" %}
{% set route = "data" %}
{% set rq = "${jsonRequest.replace("\"", "\\\"")}" %}
{% set varName = callRest(
method = "POST",
url = "http://#\{host}:#{port}/#{route}",
headers = "Content-Type=application/json",
body = rq,
responseType = "JSON"
)
%}
{{ varName["response"]["ticket"][0]["id"]}}
Для асинхронного вызова (без ожидания ответа), необходимо выставить параметр async=true.
2.2.4.3.2. Pebble-шаблон для обработки поступившего запроса и формирования json-файла
{# формируем sql запрос в переменную passengersquery#}
{% var passengersquery %}
{% if params[0] is empty %}
select * from smart.all_types limit 10
{% else %}
select * from smart.all_types limit {{ params[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.2.4.3.3. Pebble-шаблон для формирования xml-документа
<root>
<passengers Id="elementToSign">
{% for p in data.passengers %}
<passenger id="{{ p.id }}">
<firstname>{{ p.firstname }}</firstname>
<middlename>{{ p.middlename }}</middlename>
<lastname>{{ p.lastname }}</lastname>
<birthday>{{ p.birthday }}</birthday>
</passenger>
<cert>
<organization>{{ certification_info.subjectDN.commonName }}</organization>
<serial>{{ dec_to_hex(certification_info.serialNumber) }}</serial>
<issuer>{{ certification_info.issuerDN.commonName }}</issuer>
<valid-from>{{ certification_info.notBefore | date("dd.MM.yyyy") }}</valid-from>
<valid-until>{{ certification_info.notAfter | date("dd.MM.yyyy") }}</valid-until>
</cert>
{% endfor %}
</passengers>
<signature/>
</root>
2.2.4.3.4. Pebble-шаблон для формирования pdf-документа
<html>
<head>
<style>
table, th, td {
border: 1px solid black;
}
</style>
</head>
<body>
<h3>Certificate</h3>
<table>
<tr>
<th>Организация</th>
<th>Сертификат</th>
<th>Издатель</th>
<th>Действителен с</th>
<th>Действителен по</th>
</tr>
<tr>
<td>{{ certification_info.subjectDN.commonName }}</td>
<td>{{ certification_info.serialNumber }}</td>
<td>{{ certification_info.issuerDN.commonName }}</td>
<td>{{ certification_info.notBefore }}</td>
<td>{{ certification_info.notAfter }}</td>
</tr>
</table>
<h3>Passengers</h3>
<table>
<tr>
<th>id</th>
<th>firstname</th>
<th>middlename</th>
<th>lastname</th>
<th>birthday</th>
</tr>
{% for p in data.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.2.5. Настройка СМЭВ3-адаптера
2.2.5.1. Конфигурация СМЭВ3-адаптер (application.yml)
Файл application.yml – основной конфигурационный файл CМЭВ3-адаптера,
в котором задана логика и порядок работы адаптера:
получение входящих запросов, их обработка;
настройка подключения к СМЭВ и FTP-серверу СМЭВ3, к Prostore через REST-запросы;
настройка алгоритма формирования и проверки электронной подписи(ЭП) и т.д.
2.2.5.1.1. Пример файла application.yml
vertx:
# Настройки вертекса
props: # тут можно указать все настройки из документации для vertx
metricsOptions: # метрики
enabled: true
prometheusOptions: # тип метрик, например prometheusOptions | jmxMetricsOptions
enabled: true
startEmbeddedServer: true
embeddedServerOptions:
port: 9033 # порт для сервера с метриками
web-client:
max-pool-size: 20
spring:
main:
allow-bean-definition-overriding: true
liquibase:
enabled: ${LIQUIBASE_ENABLED:true}
analytics-enabled: false
change-log: classpath:/liquibase-changes/changelog.xml
driver-class-name: ru.datamart.prostore.jdbc.Driver
url: jdbc:prostore://${prostore-rest-client.host}:${prostore-rest-client.port}/${prostore-persistence.persistence-datamart}
database-change-log-table: smev3_adapter_changelog
database-change-log-lock-table: smev3_adapter_changeloglock
liquibase-schema: ${prostore-persistence.persistence-datamart}
default-schema: ${prostore-persistence.persistence-datamart}
user: ""
password: ""
iua: # Блок настроек взаимодействия с сервисом ИУА
it-system: "" # мнемоника информационной системы
wsdl-url: http://localhost:7575/ws/?wsdl # адрес к wsdl веб сервиса ИУА
endpoint-address: "" # Endpoint для запросов к сервису ИУА. По умолчанию указывать не требуется
retry-count: 2
retry-delay: 500ms
smev:
# self | iua
# self- собственная реализация подписи и взаимодействия с транспортом
# iua- подписание и работа с транспортом через адаптер ИУА
implementation: self
#url смэва
endpointUrl: http://localhost:7979/api/v1/soap/
keystoreType: "DUMMY"
keystoreFile: x
keystorePass: x
privateKeyAlias: x
privateKeyPass: x
certificateAlias: x
signatureURI: "http://www.w3.org/2001/04/xmldsig-more#dummy"
# алгоритм подписи
signatureAlgorithm: "DUMMY"
#метод подписи
digestMethod: "http://www.w3.org/2001/04/xmldsig-more#dummy"
#версия схемы смев
#availiabe 1.2 and 1.3
version: 1.3
#верификация входящих сообщений
incomingVerificationEnabled: false
#подпись исходящих сообщений
outgoingSigningEnabled: false
#таймаут отправки сообщения в смев
timeout: 30000
#время между попытками перепосылки в смев
retry-timeout: 30000
#максимальный размер очереди, ожидающей отправки сообщений
webMaxWaitQueueSize: -1
#пул коннектов
webMaxPoolSize: 20
receiver:
receiver-property:
- selector: # селектор сообщений из смэв
# используется при smev3->implementation: self, должно быть пусто или может отсутствовать при использовании smev3->implementation: iua
namespace: a
# используется при smev3->implementation: self, должно быть пусто или может отсутствовать при использовании smev3->implementation: iua
root-element-name: b
# используется при smev3->implementation: iua, должно быть пусто или может отсутствовать при использовании smev3->implementation: self
router-extra-queue: some_request
# пебл шаблон, который будет обрабатываться для определенного selector
template: smev3-adapter/templates/smev.xml.peb
# задержка между запросами, в случае если очередь пуста
idle-delay: PT1m
# файл, который будет отправлен в случае ошибки
fallback-response: smev3-adapter/templates/fallback.xml
pebble-refresh: PT5m
- selector:
namespace: urn://x-artefacts-testperson/1.0
root-element-name: TestPersonRequest
router-extra-queue: some_request
template: smev3-adapter/templates/smev.xml.peb
idle-delay: PT1m
response-receiver-property:
- selector: # селектор из смэв
# используется при smev3->implementation: self, должно быть пусто или может отсутствовать при использовании smev3->implementation: iua
namespace: a
# используется при smev3->implementation: self, должно быть пусто или может отсутствовать при использовании smev3->implementation: iua
root-element-name: b
# используется при smev3->implementation: iua, должно быть пусто или может отсутствовать при использовании smev3->implementation: self
router-extra-queue: some_request
# пебл шаблон, который будет обрабатываться для определенного selector
template: smev3-adapter/templates/smev.xml.peb
# задержка между запросами, в случае если очередь пуста
idle-delay: PT1m
persistence-mode: prostore # prostore -default, zookeeper
prostore-rest-client:
host: ${PS_HOST:localhost}
port: ${PS_PORT:9195}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
default-schema: demo_view
# Параметры витрины персистентности в Prostore, используемой для технического функционала
prostore-persistence:
persistence-datamart: persistence
datasource: []
environment:
name: ${ENVIRONMENT_NAME:test}
zookeeper:
connection-string: ${ZOOKEEPER_DS_ADDRESS:t5-adsp-01.ru-central1.internal}
retryPolicy:
baseSleepTime: 1000
maxRetries: 3
maxSleepTime: 3000
chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}
migration:
zk-enabled: ${MIGRATION_ZK_ENABLE:false}
# Конфигурация хранилища параметров (для SDB)
paramstorage:
base-path: '/smev/paramstorage'
table-variables: smev3_adapter_variables
sign:
digest-algorithm: 1.2.643.7.1.1.2.2 #алгоритм подписи файла
blob:
s3-smev3:
protocol: http
host: localhost
port: 8084
bucket: attachment
user: "" # Используется по умолчанию
password: "" # Используется по умолчанию
blob-source: # настройки подключения к BLOB адаптеру
host: 'localhost'
port: 8080
path:
ftp-destination:
host: localhost # хост фтп смева
port: 21 # порт фтп смева
# path: aaa/bbb/ccc # корневой каталог
user: user # пользователь
password: 123 # пароль
rest:
enabled: false # вкл/выкл
get: /le # путь get запроса
post: /le # путь post запроса
template: smev3-adapter/templates/smev.xml.peb # обрабатываемый шаблон
# рассылка смев
scheduler:
templates:
- enabled: false # вкл/выкл
cron: "*/30 * * * * *" # Cron выражение для запуска задачи. В данном случае запуск каждые 30 сек
# Режим запуска задач на исполнение при наличии текущей активной задачи. Допустимые значения skip, wait, run.
# skip - если имеется текущая не завершенная задача, новый задача не запускается
# wait - если имеется текущая не завершенная задача - новая задача становится в очередь и автоматически запускается
# после завершения. Если задача в очереди уже есть - новая задача игнорируется.
# run - всегда запускает задачу, даже если предыдущая задача еще выполняется
overlap-mode: skip
template: smev3-adapter/templates/pfr-delta.peb # обрабатываемый шаблон
pool:
reader-executor: 20 # корутин пул для обработки смев шаблонов
schedule-executor: 1 # корутин пул для обработки шедулера
logExecutor: 20
logging:
request-response:
smev-request: true
smev-response: true
http-server:
port: ${SERVER_PORT:8080}
# Параметры подключения к сервису печатных форм. Указывается при использовании функции toSpf
spf:
host: ${SPF_HOST:localhost}
port: ${SPF_PORT:8080}
# Дополнительные параметры. Указываются ключ-значения сертификатов, необходимых для сервиса ПФ
params: { }
# Параметры подключения динамических конфигураций
dynamic-config:
# Включение процедуры сканирования источника на предмет наличия конфигураций
enabled: false
# Интервал проверки источника
refresh: PT3m
# Источник подключаемых конфигураций
table-receiver-scheduler: smev3_adapter_receiver_scheduler
# Источник pebble-шаблонов
table-pebble: smev3_adapter_pebble
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается неактивным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- keys
# Допускаются лишь скалярные строковые значения,
# так например переменная pebble-variables→host станет доступна в pebble как {{host}}
pebble-variables: { }
2.2.5.2. Параметры конфигурации
Настройка конфигурации CМЭВ3-адаптера осуществляется путем редактирования параметров настроек в файле application.yml.
Обязательными параметрами для настройки CМЭВ3-адаптера являются секции: smev, receiver, datasource. Остальные параметры следует
оставить без изменения и настраивать только для решения определенных бизнес-задач.
Pebble-шаблоны для настройки задаются в секциях: receiver-property, rest и scheduler.
Для каждого вида сведений, предоставляемых Витриной, следует создавать отдельное сопоставление receiver и устанавливать значения
receiver-property. Остальные параметры следует оставить без изменения.
В файле конфигурации могут быть настроены следующие секции:
vertx– настройка параметров фреймворка Vert.x (подробнее на сайте разработчиков: https://vertx.io/docs/);spring– параметры подключения к фреймворку spring boot (используется для разработки) и параметры для определения наименований служебных таблиц liquibase;iua- блок настроек взаимодействия с сервисом ИУА;smev– настройки подключения к CМЭВ3-адаптеру;receiver- настройка взаимодействия СМЭВ-запросов с Peblle-шаблонами (для каждогоreceiverможно настроить количествоinstance);persistence-mode- настройки хранения данных;prostore-rest-client- блок параметров конфигурирования взаимодействия с ProStore;prostore-persistence– Параметры витрины персистентности в Prostore, используемой для технической функциональности;environment- настройки окружения;zookeeper– параметры подключения к Zookeeper;migration– настройка параметров миграции сервисной базы данных CМЭВ3-адаптера в базу данных Zookeeper;paramstorage– указывается корневой путь хранилища параметров;sign- настройка формирования и проверки электронной подписи(ЭП) в SOAP-пакетах СМЭВ3;blob- интеграция с BLOB-адаптер;rest- настройки подключения для возможности выполнения rest-запросов к СМЭВ3-адаптеру и получения ответов на них;scheduler- настройка планировщика заданий (запуск дельт по расписанию);pool- размер прерываемого кода;logging– настраивается логирование работы модуля;http-server- указывается порт веб-сервера;spf- параметры подключения к сервису печатных форм (Указывается при использовании функции toSpf);dynamic-config- параметры подключения динамических конфигураций;component-info- настройки модуля сбора информации о компонентах витрины.
2.2.5.2.1. Секция vertx
Секция vertx предназначена для настройки параметров фреймворка Vert.x (подробнее на сайте разработчиков: https://vertx.io/docs/).
Для включения сбора метрик используйте следующий код:
vertx:
# Настройки вертекса
props: # тут можно указать все настройки из документации для vertx
metricsOptions: # метрики
enabled: true
prometheusOptions: # тип метрик, например prometheusOptions | jmxMetricsOptions
enabled: true
startEmbeddedServer: true
embeddedServerOptions:
port: 9033 # порт для сервера с метриками
web-client:
max-pool-size: 20
2.2.5.2.2. Секция spring
В секции spring указываются параметры подключения к фреймворку spring boot (используется для разработки) и
параметры для определения наименований служебных таблиц liquibase.
Например:
spring:
main:
allow-bean-definition-overriding: true
liquibase:
enabled: ${LIQUIBASE_ENABLED:true}
analytics-enabled: false
change-log: classpath:/liquibase-changes/changelog.xml
driver-class-name: ru.datamart.prostore.jdbc.Driver
url: jdbc:prostore://${prostore-rest-client.host}:${prostore-rest-client.port}/${prostore-persistence.persistence-datamart}
database-change-log-table: smev3_adapter_changelog
database-change-log-lock-table: smev3_adapter_changeloglock
liquibase-schema: ${prostore-persistence.persistence-datamart}
default-schema: ${prostore-persistence.persistence-datamart}
user: ""
password: ""
Параметры настроек
enabled- признак включения/отключения миграций (значениеfalseзадается, если в секции persistence-mode включено хранение данных в Zookeeper:PERSISTENCE_MODE:zookeeper);analytics-enabled- флаг подключения статистики;change-log- путь к файлам миграций, которые находятся внутри jar;driver-class-name- имя JDBC-драйвера Prostore. Константа, без переопределения.url- адрес подключения к простору в формате JDBC. Переопределять не потребуется, конструируется из параметров подключения к Prostore.database-change-log-table- имя таблицы хранения истории выполненных миграций;database-change-log-lock-table- имя таблицы для блокировок, константа;liquibase-schema- имя датамарта, в которой распалагаются 2 таблицы (database-change-log-table, database-change-log-lock-table)default-schema- имя датамарта для системных таблиц. Так же заполняется из блока конфигурации Prostore.user- имя пользователя Prostore;password- пароль пользователя Prostore.
2.2.5.2.3. Секция iua
Секция iua хранит блок настроек взаимодействия с сервисом ИУА.
Например:
iua:
it-system: ""
wsdl-url: http://localhost:7575/ws/?wsdl
endpoint-address: "" # Endpoint для запросов к сервису ИУА. По умолчанию указывать не требуется
retry-count: 2
retry-delay: 500ms
Параметры настроек
it-system- мнемоника информационной системы;wsdl-url- адрес к wsdl веб-сервиса ИУА;endpoint-address- Endpoint для запросов к сервису ИУА. По умолчанию указывать не требуется;idle-delay- периодичность опроса очереди СМЭВ3 для получения новых запросов (в формате ISO 8601);retry-count- количество попыток осуществления запросов к сервису;retry-delay- период задержки в секундах.
2.2.5.2.4. Секция smev
Секция smev отвечает за настройки подключения к СМЭВ3.
Например:
smev:
endpointUrl: http://127.0.0.1:7979/api/v1/soap/
keystoreType: "DUMMY"
keystoreFile: x
keystorePass: x
privateKeyAlias: x
privateKeyPass: x
certificateAlias: x
signatureURI: "http://www.w3.org/2001/04/xmldsig-more#dummy"
signatureAlgorithm: "DUMMY"
digestMethod: "http://www.w3.org/2001/04/xmldsig-more#dummy"
incomingVerificationEnabled: false
outgoingSigningEnabled: true
#таймаут отправки сообщения в смев
timeout: 30000
#время между попытками перепосылки в смев
retry-timeout: 30000
#максимальный размер очереди, ожидающей отправки сообщений
webMaxWaitQueueSize: -1
#пул коннектов
webMaxPoolSize: 20
В случае когда сервер не отвечает на запрос, в новой версии СМЭВ3-адаптера (секция smev), добавлена возможность, которая позволяет задать
время ожидания ответа (timeout) перед повторной отправкой запроса к СМЭВ3:
timeout- таймаут отправки сообщения в СМЭВ3;retry-timeout- время между повторной попыткой отправки запроса в СМЭВ3;webMaxWaitQueueSize- максимальный размер очереди, ожидающей отправки сообщений;webMaxPoolSize- пул коннектов.
Примечание
Для удобного отслеживания в лог-файлах всех запросов/ответов к СМЭВ3 в рамках одной бизнес-операции, в файл logback-json.xml добавлен параметр ReqMessageID.
При обработке ошибки от СМЭВ3, в лог-файл добавляется описание ошибки и код ошибки СМЭВ3 (в том случае, если СМЭВ3 вернул данный код в блоке description).
2.2.5.2.5. Секция receiver
Секция receiver предназначена для настройки параметров взаимодействия СМЭВ-запросов с peblle-шаблонами.
Например:
receiver:
receiver-property:
- selector: # селектор сообщений из смэв
# используется при smev3->implementation: self, должно быть пусто или может отсутствовать при использовании smev3->implementation: iua
namespace: a
# используется при smev3->implementation: self, должно быть пусто или может отсутствовать при использовании smev3->implementation: iua
root-element-name: b
# используется при smev3->implementation: iua, должно быть пусто или может отсутствовать при использовании smev3->implementation: self
router-extra-queue: some_request
# пебл шаблон, который будет обрабатываться для определенного selector
template: smev3-adapter/templates/smev.xml.peb
# задержка между запросами, в случае если очередь пуста
idle-delay: PT1m
# файл, который будет отправлен в случае ошибки
fallback-response: smev3-adapter/templates/fallback.xml
pebble-refresh: PT5m
- selector:
namespace: urn://x-artefacts-testperson/1.0
root-element-name: TestPersonRequest
router-extra-queue: some_request
template: smev3-adapter/templates/smev.xml.peb
idle-delay: PT1m
response-receiver-property:
- selector: # селектор из смэв
# используется при smev3->implementation: self, должно быть пусто или может отсутствовать при использовании smev3->implementation: iua
namespace: a
# используется при smev3->implementation: self, должно быть пусто или может отсутствовать при использовании smev3->implementation: iua
root-element-name: b
# используется при smev3->implementation: iua, должно быть пусто или может отсутствовать при использовании smev3->implementation: self
router-extra-queue: some_request
# пебл шаблон, который будет обрабатываться для определенного selector
template: smev3-adapter/templates/smev.xml.peb
# задержка между запросами, в случае если очередь пуста
idle-delay: PT1m
Параметры настроек
selector- селектор сообщений из СМЭВ;namespace- пространство имен в XML;root-element-name- имя корневого элемента запроса обрабатываемого ВС (как указано в заявке на регистрацию ВС);router-extra-queue- очередь роутера, используется при smev3->implementation: iua, должно быть пусто или может отсутствовать при использовании smev3->implementation: self;template- имя файла, содержащего pebble-шаблон обработки запросов для данного ВС;idle-delay- периодичность опроса очереди СМЭВ3 для получения новых запросов (в формате ISO 8601)$max-concurrency- настройка обработчика, для исключения блокировки таблицы необходимо обрабатывать запросы, направленные на заполнение одной таблицы, по одному, без конкурентности.
Пример файла smev.xml.peb
<TestPersonResponse xmlns="urn://x-artefacts-testperson/1.0">
{% set my_blob = fromblob ("/Picture_13.jpg", "my_fname", "my_mime") %}
<photo>{{ toftp ("some test 1", "file.txt", "text/plain") }}</photo>
<photo>{{ toftp ("some test 2", "file.txt", "text/plain") }}</photo>
<photo>{{ toftp ("some test 3", "file2.txt", "text/plain") }}</photo>
<photo>{{ tomtom (my_blob, my_mime) }}</photo>
</TestPersonResponse>
Пример файла fallback.xml (Ответ при ошибке обработки запроса)
<TestPersonResponse xmlns="urn://x-artefacts-testperson/1.0">
<text>Произошла ошибка при обработке запроса: %error_message%</text>
</TestPersonResponse>
2.2.5.2.6. Секция persistence-mode
В секции persistence-mode указывается настройка хранения данных: или в Prostore, или в Zookeeper.
В случае выбора Prostore автоматически создаются необходимые таблицы.
В случае выбора Zookeeper необходимо отключить выполнение миграций liquibase в секции spring: LIQUIBASE_ENABLED:false.
Например:
persistence-mode: ${PERSISTENCE_MODE:prostore} # prostore -default, zookeeper
Параметры настроек
persistence-mode- настройка хранения данных, напримерPERSISTENCE_MODE:prostore.
2.2.5.2.7. Секция prostore-rest-client
В секции prostore-rest-client реализован блок параметров конфигурирования взаимодействия с ProStore.
Например:
prostore-rest-client:
persistence-datamart: persistence
datasource: # по умолчанию пусто, тогда берется единственный датасорс из настроек Простора
table-variables: smev3_adapter_variables
host: ${PS_HOST:localhost}
port: ${PS_PORT:9195}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
default-schema: demo_view
Параметры настроек
persistence-datamart- датамарт, где будут располагаться таблицы хранения данных, используется приpersistence-mode = prostore;datasource- источник данных, напримерpersistence;table-variables- таблица переменных СМЭВ3-адаптера, напримерsmev3_adapter_variables;host- адрес Prostore, напримерPS_HOST:t5-prostore-01.ru-central1.internal;port- порт Prostore, напримерPS_PORT:9195;max-pool-size- максимальное число подключений к Prostore, напримерPS_MAX_POOL_SIZE:8.
2.2.5.2.8. Секция prostore-persistence
В секции prostore-persistence реализован блок параметров витрины персистентности в Prostore, используемой для технической функциональности.
Например:
prostore-persistence:
persistence-datamart: persistence
datasource: []
Параметры настроек
persistence-datamart- датамарт, где будут располагаться таблицы хранения данных, используется приpersistence-mode = prostore;datasource- массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте.
2.2.5.2.9. Секция environment
В секции environment указывается среда разработки (dev, test, stable, prod).
Например:
environment:
name: ${ENVIRONMENT_NAME:test}
Параметры настроек
name- Название окружения, напримерENVIRONMENT_NAME:test.
2.2.5.2.10. Секция zookeeper
Секция zookeeper предназначена для настройки параметров подключения к Zookeeper.
Например:
zookeeper:
connection-string: ${ZOOKEEPER_DS_ADDRESS:t5-adsp-01.ru-central1.internal}
retryPolicy:
baseSleepTime: 1000
maxRetries: 3
maxSleepTime: 3000
chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}
Параметры настроек
connect-string- адреса серверов для подключения к Zookeeper (разделитель -,);baseSleepTime- начальное значение таймаута ожидания при повторных запросах;maxRetries- максимальное количество повторных запросов;maxSleepTime- максимальное значение таймаута ожидания при повторных запросах.
2.2.5.2.11. Секция migration
Секция migration реализована настройка миграции из Zookeeper в Prostore.
Например:
migration:
zk-enabled: ${MIGRATION_ZK_ENABLE:false}
Параметры настроек
zk-enabled- включение миграции, например{MIGRATION_ENABLE:false}.
Примечание
При включении миграции из Zookeeper должны быть заполнены настройки подключения к Zookeeper.
2.2.5.2.12. Секция paramstorage
В секции paramstorage указывается конфигурация хранилища параметров (для SDB).
Например:
paramstorage:
base-path: '/smev/paramstorage'
table-variables: smev3_adapter_variables
2.2.5.2.13. Секция sign
Секция sign предназначена для формирования и проверки электронной подписи (ЭП) в SOAP-пакетах СМЭВ3.
Например:
sign:
digest-algorithm: 1.2.643.7.1.1.2.2
Параметры настроек
digest-algorithm- алгоритм ключа проверки электронной подписи.
2.2.5.2.14. Секция blob
Секция blob предназначена для настройки взаимодействия модуля СМЭВ3-адаптер с:
файловым хранилищем СМЭВ3 по протоколу S3 или S3 адаптера ИУА для считывания и записи BLOB-полей;
BLOB-адаптером для считывания и записи BLOB-полей (см. Взаимодействие через СМЭВ3-адаптер);
FTP-сервером СМЭВ3, на который модуль СМЭВ3-адаптер выгружает содержимое BLOB-полей и/или большие табличные данные.
Например:
blob:
s3-smev3:
protocol: http
host: localhost
port: 8084
bucket: attachment
user: "" # используется по умолчанию если не задано на уровне pebble расширения, значение из pebble расширения имеет приоритет
password: "" # используется по умолчанию если не задано на уровне pebble расширения, значение из pebble расширения имеет приоритет
blob-source:
host: 'localhost'
port: 8080
path:
ftp-destination:
host: localhost # хост фтп смева
port: 21 # порт фтп смева
# path: aaa/bbb/ccc # корневой каталог
user: user # пользователь
password: 123 # пароль
Параметры настроек
s3-smev3- настройка подключения к файловому хранилищу S3 СМЭВ3;blob-source- настройка подключения к BLOB-адаптеру;ftp-destination- настройка подключения к FTP-серверу СМЭВ3.
2.2.5.2.15. Секция rest
Секция rest предназначена для настройки возможности выполнения REST-запросов к СМЭВ3-адаптеру и получения ответов на них.
Например:
rest:
enabled: false # вкл/выкл
get: /le # путь get запроса
post: /le # путь post запроса
template: smev3-adapter/templates/smev.xml.peb # обрабатываемый шаблон
Параметры настроек
enabled- включение настроек;get- путь GET запроса;post- путь POST запроса;template- путь к Pebble-шаблону.
2.2.5.2.16. Секция scheduler
Секция scheduler предназначена для настройки планировщика заданий в случае, если планируется использовать механизм отправки дельт
по расписанию.
Например:
scheduler:
templates:
- enabled: false # вкл/выкл
cron: "*/30 * * * * *" # Cron выражение для запуска задачи. В данном случае запуск каждые 30 сек
# Режим запуска задач на исполнение при наличии текущей активной задачи. Допустимые значения skip, wait, run.
# skip - если имеется текущая не завершенная задача, новый задача не запускается
# wait - если имеется текущая не завершенная задача - новая задача становится в очередь и автоматически запускается
# после завершения. Если задача в очереди уже есть - новая задача игнорируется.
# run - всегда запускает задачу, даже если предыдущая задача еще выполняется
overlap-mode: skip
template: smev3-adapter/templates/pfr-delta.peb # обрабатываемый шаблон
Параметры настроек
enabled- включение планировщика заданий;cron- Cron выражение для запуска задачи;overlap-mode- режим запуска задач на исполнение при наличии текущей активной задачи. Допустимые значения skip, wait, run.skip- если имеется текущая не завершенная задача, новый задача не запускается;wait- если имеется текущая не завершенная задача - новая задача становится в очередь и автоматически запускается после завершения, если задача в очереди уже есть - новая задача игнорируется;run- всегда запускает задачу, даже если предыдущая задача еще выполняется;
template- обрабатываемый шаблон.
2.2.5.2.17. Секция pool
В секции pool указывается размер прерываемого кода.
Например:
pool:
reader-executor: 20
schedule-executor: 1
logExecutor: 20
Параметры настроек
reader-executor- корутин пул для обработки СМЭВ-шаблонов;schedule-executor- корутин пул для обработки шедулера.
2.2.5.2.18. Секция logging
В секции logging настраивается логирование работы модуля.
Например:
logging:
request-response:
smev-request: true
smev-response: true
Параметры настроек
smev-request- логирование запросов;smev-response- логирование ответов.
2.2.5.2.19. Секция http-server
В секции http-server указывается порт веб-сервера.
Например:
server:
port: ${SERVER_PORT:8080}
Параметры настроек
port- порт веб-сервера, например:SERVER_PORT:8080.
2.2.5.2.20. Секция spf
В секции spf указываются параметры подключения к сервису печатных форм. Указывается при использовании функции toSpf.
Например:
spf:
host: ${SPF_HOST:localhost}
port: ${SPF_PORT:8080}
# Дополнительные параметры. Указываются ключ-значения сертификатов, необходимых для сервиса ПФ
params: {}
Параметры настроек
host- адрес подключения, например{SPF_HOST:localhost};port- порт подключения, например:{SPF_PORT:8080};params- дополнительные параметры. Указываются ключ-значения сертификатов, необходимых для сервиса ПФ.
2.2.5.2.21. Секция dynamic-config
В секции dynamic-config хранятся параметры подключения динамических конфигураций.
Используется Агентом проверок для применения дополнительных конфигураций и pebble-скриптов без перезапуска приложения.
Например:
dynamic-config:
# Включение процедуры сканирования источника на предмет наличия конфигураций
enabled: false
# Интервал проверки источника
refresh: PT3m
# Источник подключаемых конфигураций
table-receiver-scheduler: smev3_adapter_receiver_scheduler
# Источник pebble-шаблонов
table-pebble: smev3_adapter_pebble
Параметры настроек
enabled- включение процедуры сканирования источника на предмет наличия конфигураций;refresh- интервал проверки источника;table-receiver-scheduler- источник подключаемых конфигураций, напримерsmev3_adapter_receiver_scheduler;table-pebble- источник pebble-шаблонов, напримерsmev3_adapter_pebble;
2.2.5.2.22. Секция component-info
В секции component-info хранятся настройки компонента сбора информации о компонентах витрины.
Например:
component-info:
enabled: true
datasource: []
datamart: component_info
table-name: component_info
create-table-period: 60s
publish-period: 60s
timeout-active: 300s
secrets:
- keys
Параметры настроек
enabled- статус подключения компонента, указывается булево значение;datasource- датасорс Prostore;datamart- массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте;table-name- имя таблицы для записи информации о компоненте;create-table-period- период попыток создания схемы, при неуспехе, указывается в секундах;publish-period- период публикации health-check, указывается в секундах;timeout-active- период, после которого компонент считается неактивным при отсутствии health-check, указывается в секундах;secrets- список элементов конфигурации, маскируемых при отправке, если указан узловой элемент, то маскируются все вложенные в него элементы.
2.2.6. Настройка СМЭВ QL Сервера
2.2.6.1. Конфигурирование сервера
Конфигурирование СМЭВ QL сервера выполняется путем изменения параметров настроек, определенных в файлах credentials.yaml и application.yaml.
application.yaml - конфигурирует поведение сервера;
credentials.yaml - конфигурирует представление сервера.
2.2.6.1.1. Конфигурация файла application.yml
ktor:
deployment:
port: "$PORT:8080"
application:
modules:
- ru.gov.digital.smevql.ApplicationKt.mainModule
sources:
directory: "$SOURCES_DIR:sources"
models:
directory: "$MODELS_DIR:models"
states:
directory: "$STATES_DIR:states"
regulated-query:
directory: "$QUERIES_DIR:queries"
swagger:
file: smevql-openapi.yaml # путь к файлу openapi спецификации
servers:
- "http://127.0.0.1:8080/smevql/api/v1"
storage: # Блок параметров хранения информации
adapter: prostore # postgres|prostore (по умолчанию)
pool: # Настройка подключений
- host: 127.0.0.1
port: 6379
database: "smevql" # Имя БД для адаптера postgres. Для адаптера prostore - имя датамарта
schema: "public" # схема БД, используется для адаптера postgres
data-sources: [] # используется для адаптера prostore
migration:
enabled: true
host: 127.0.0.1
port: 5432
database: "smevql"
schema: "public"
user: "postgres" # Пользователь для подключения к postgres
password: "postgres" # Пароль
max-pool-size: 20 # Максимальный размер пула соединений
user: "" # Пользователь для подключения к postgres|prostore
password: "" # Пароль
idle-timeout: 5m # Таймаут неиспользуемого соединения в пуле, после которого соединение закрывается
access: # Блок настроек доступа к выполнению операций чтения данных и операций стейтмашины. Допускается задание черного или белого списка
black-list: [ ] # Указывает список потребителей, для которых доступ запрещен
white-list: [ ] # Указывает список потребителей, для которых доступ разрешен
request:
strategy: delegate # Стратегия исполнения запросов delegate|atomic
timeout: 20s # Таймаут исполнения запросов
base-path: smevql/api/v1 # Префикс для всех роутов
max-nested-level: 5 # Предельная вложенность запрашиваемых ресурсов
omit-empty-array: false # Настройка, позволяющая исключить пустые строки массовов из ответа
pagination:
default: 100 # Количество элементов на странице по умолчанию
max: 1000 # Максимальное количество элементов на странице
logging:
long:
duration: 20s # Продолжительность исполнения запросов к источникам, выше которой необходимо производить логирование
percentage: 100 # Процент логирования длительных запросов к источникам. Допустимо использовать вещественные числа, например, 0.1 - только каждый тысячный долгий запрос
limits: # Блок параметров конфигурации лимитов
enabled: true # флаг влюкчения проверок лимитов
total: # Параметры по всем запросам
value: 500000 # Общее число запросов в период времени
period: 1D # Период лимитирования
mnemonic: # Блок настроек лимитирования по потребителям
value: 5000 # Число запросов в период времени
period: 1D # Период лимитирования
purpose: # Блок настроек лимитирования по целям
value: 5000 # Число запросов в период времени
period: 1D # Период лимитирования
user: # Блок настроек лимитирования по пользователям
value: 1000 # Число запросов в период времени
period: 1D # Период лимитирования
records-ttl:
day: 1M # Период хранения дневной статистики
week: 1M # Период хранения статистики за неделю
month: 1Y # Период хранения статистики за месяц
year: 2Y # Период хранения статистики за год
async: # Блок настроек асинхронного выполнения запросов
request-in: 10s # Значение интервала опроса получения данных асинхронного результата. Выдается в качестве значения атрибута request_in на запрос получения данных
read-timeout: 5m # Таймаут вычитывания асинхронных данных из источников. Используется для источников с типом smevql, если была возвращена информация по асинхронным результатам
delta:
commit-interval: 60s # Интервал фиксации дельты источника при изменении данных
force-commit-interval: 30m # Интервал принудительной фиксации дельт всех источников
state:
max-nested-event: 5 # Максимально допустимая вложенность связанных переходов стейт машины
max-updated-rows: 1 # Максимальное количество обновляемых строк при событии стейт машины
index-recommendations: # Рекомендации по аналитике
enabled: true # Флаг включения формирования рекомендаций
period: 7D # Период формирования. 7 дней
concurrency: 10 # Количество параллельных корутин сохранения статистики
# Массив описания standalone таблиц
standalone-tables: [ ]
# Пример описания
# standalone-tables:
# - readable-table: "misdm05.readable_book"
# writable-table: "misdm05.writable_book"
# anchor: "update_at"
# soft-delete: "delete_at"
# Массив описания proxy таблиц
proxy-tables: [ ]
# Пример описания
# proxy-tables:
# - table: "misdm05.notebook"
# anchor: "update_at"
# soft-delete: "delete_at"
push: # Настройки отправки push уведомлений
notification-path: "/{target}/push/notify" # Шаблон пути агента, на который необходимо отправлять нотификации
request-timeout: 1m # Таймаут на исполнение http запроса на доставку push уведомления потребителю
state-machine-enabled: false # Признак публикации нотификаций на основе событий стейт машины
status-prostore-enabled: true # Признак публикации нотификаций на основе событий статусов Простора
prostore:
type: KAFKA # KAFKA | HTTP
status-event-topic:
topic: "$PS_STATUS_EVENT_TOPIC:status.event"
property:
bootstrap.servers: "$PS_KAFKA:localhost:9092"
group.id: smevql-server-status-event
auto.offset.reset: earliest
queue:
lock-check-interval: 30s
lock-timeout: 5m
retry:
max-attempts: 3 # Количество попыток отправки нотификации
min-period: 5s # Минимальный период ожидания перед повторной попыткой
max-period: 10s # Максимальный период ожидания перед повторной попыткой
queue:
max-attempts: 30 # Количество попыток отправки уведомлений из персистентной очереди
min-period: 1m # Минимальный период ожидания перед повторной попыткой отправки уведомления из персистентной очереди
max-period: 3m # Максимальный период ожидания перед повторной попыткой отправки уведомления из персистентной очереди
scan-waiting-period: 1m # Период сканирования отложенных уведомлений
process:
check-expired-period: 5m # Период проверки уведомлений взятых в работу и просроченных
timeout: 5m # Предельное время обработки уведомления из очереди
poisoned:
check-expired-period: 1h # Период проверки времени жизни "отравленных" уведомлений
timeout: 7d # Время хранения уведомлений в poisoned-очереди
agent: # Параметры конфигурирования агента ПОДД
host: 127.0.0.1 # Хост агента
port: 8171 # Порт приема api-gateway запросов
mnemonic: "" # Мнемоника агента
signature: # Блок настроек механизма подписания
enabled: true # Признак включения подписания и проверки подписи
validate-enabled: false # Признак предоставления дополнительного URL проверки подписи
algorithm: "GOST3410_2012_256" # Алгоритм формирования подписи
serial-number: "" # Серийный номер ключа подписи
alias: "" # Алиас ключа. Заполняется либо серийный номер, либо алиас
notarius: # Блок настроек сервиса Notaris, используемый для подписания
host: localhost # Хост, на котором доступен Notaris
port: 8080 # Порт, на котором доступен Notaris
cls: # Конфигурация отправки событий в СЦЛ
enabled: false # Признак включения отправки событий в СЦЛ
url: "http://127.0.0.1:8192/api/v1/cls/event" # Адрес для отправки событий СЦЛ
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# Источник в папке задаваемой настройкой ${sources.directory}
source: prostore
# Массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается неактивным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- storage.user
- storage.password
- storage-queue.user
s3:
enabled: "$S3_ENABLED:false"
endpoint: "$S3_ENDPOINT:http://127.0.0.1:9000/"
bucket: "$S3_BUCKET:smevql" # Имя бакета
region: "$S3_REGION:us-west-2"
access-key: "$S3_USER:minioadmin" # Пользователь, под которым происходит взаимодействие с s3
secret-key: "$S3_PASSWORD:minioadmin" # Пароль пользователя для взаимодействия с s3
Настройка конфигурации СМЭВ QL Сервера осуществляется путем редактирования параметров настроек в файле application.yml,
в котором могут быть настроены следующие секции:
ktor- настройки подключения фреймворка Ktor;sources- определение директории хранения источников;models- определение директории хранения моделей;states- определение директории хранения состояний;regulated-query- определение директории хранения регламентированных запросов;swagger- настройка файла openapi спецификации;storage- управление подключением к внутреннему хранилищу данных СМЭВ-QL;access- блок настроек доступа к выполнению операций чтения данных и операций стейт-машины;request- блок настроек исполнения запросов;delta- управление принудительными коммитами дельт витрин данных;state- установка ограничений в машинах-состояний;index_recommendations- рекомендации по аналитике;standalone-tables- массив описания standalone таблиц;proxy-tables- массив описания proxy таблиц;push- настройки отправки push уведомлений;storage-queue- настройки хранилища очередей;agent- Параметры конфигурирования агента СМЭВ4;signature- блок настроек механизма подписания;cls- конфигурация отправки событий в СЦЛ;component-info- настройки модуля сбора информации о компонентах витрины;s3- настройки взаимодействия с s3.
2.2.6.1.1.1. Секция ktor
В секции ktor настраивается параметры подключения фреймворка Ktor, например:
ktor:
deployment:
port: "$PORT:8080"
application:
modules:
- ru.gov.digital.smevql.ApplicationKt.mainModule
Параметры конфигурации
port- порт хоста развертывания фреймворка;modules- модули приложения.
2.2.6.1.1.2. Секция sources
В секции sources определяется директория хранения источников, например:
sources:
directory: "$SOURCES_DIR:sources"
models:
directory: "$MODELS_DIR:models"
states:
directory: "$STATES_DIR:states"
regulated-query:
directory: "$QUERIES_DIR:queries"
Параметры конфигурации
sources.directory- директория хранения источников;models.directory- директория хранения моделей;states.directory- директория хранения состояний;regulated-query.directory- директория хранения регламентированных запросов;
2.2.6.1.1.3. Секция swagger
В секции swagger хранится настройка файла openapi спецификации, например:
swagger:
file: smevql-openapi.yaml
servers:
- "http://127.0.0.1:8080/smevql/api/v1"
Параметры конфигурации
file- путь к файлу openapi спецификации;servers- адрес сервера.
2.2.6.1.1.4. Секция storage
В секции storage настраиваются параметры хранения информации, например:
storage: # Блок параметров хранения информации
adapter: prostore # postgres|prostore
pool: # Настройка подключений
- host: 127.0.0.1
port: 6379
database: "smevql" # Имя БД для адаптера postgres. Для адаптера prostore - имя датамарта
schema: "public" # схема БД, используется для адаптера postgres
data-sources: [] # используется для адаптера prostore
migration:
enabled: true
host: 127.0.0.1
port: 5432
database: "smevql"
schema: "public"
user: "postgres" # Пользователь для подключения к postgres
password: "postgres" # Пароль
max-pool-size: 20 # Максимальный размер пула соединений
user: "" # Пользователь для подключения к postgres|prostore
password: "" # Пароль
idle-timeout: 5m # Тайм-аут неиспользуемого соединения в пуле, после которого соединение закрывается
Параметры конфигурации
adapter- система хранения данных;pool- настройка подключений;host- адрес хоста;port- порт хоста;database- имя БД для адаптера Postgres, для адаптера Prostore - имя датамарта;schema- схема БД, используется для адаптера Postgres;data-sources- массив датасорсов, используется для адаптера Prostore;migration- настройки миграции;enabled- признак включения/отключения миграций;database- имя БД для адаптера Postgres, для адаптера Prostore - имя датамарта;schema- схема БД, используется для адаптера Postgres;user- имя пользователя для подключения к Postgres;password- пароль пользователяmax_pool_size- максимальный размер пула соединений;user- имя пользователя для авторизации в системе хранения данных;password- пароль для авторизации в системе хранения данных;idle-timeout- тайм-аут неиспользуемого соединения в пуле, после которого соединение закрывается.
2.2.6.1.1.5. Секция access
В секции access настраивается доступ к выполнению операций чтения данных и операций стейт-машины.
Допускается задание черного или белого списка.
Например:
access: # Блок настроек доступа к выполнению операций чтения данных и операций стейтмашины. Допускается задание черного или белого списка
black_list: [ ] # Указывает список потребителей, для которых доступ запрещен
white_list: [ ] # Указывает список потребителей, для которых доступ разрешен
Параметры конфигурации
black_list- перечень мнемоник ИС Потребителей, которым запрещен доступ к СМЭВ QL. Не заполняется, если заполнен white_list!white_list- перечень мнемоник ИС Потребителей, которым разрешен доступ к СМЭВ QL. Не заполняется, если заполнен black_list!
2.2.6.1.1.6. Секция request
В секции request хранятся настройки исполнения запросов, например:
request:
strategy: delegate # Стратегия исполнения запросов delegate|atomic
timeout: 20s # Таймаут исполнения запросов
base-path: smevql/api/v1 # Префикс для всех роутов
max-nested-level: 5 # Предельная вложенность запрашиваемых ресурсов
omit-empty-array: false # Настройка, позволяющая исключить пустые строки массовов из ответа
pagination:
default: 100 # Количество элементов на странице по умолчанию
max: 1000 # Максимальное количество элементов на странице
logging:
long:
duration: 20s # Продолжительность исполнения запросов к источникам, выше которой необходимо производить логирование
percentage: 100 # Процент логирования длительных запросов к источникам. Допустимо использовать вещественные числа, например, 0.1 - только каждый тысячный долгий запрос
limits: # Блок параметров конфигурации лимитов
enabled: true # флаг влюкчения проверок лимитов
total: # Параметры по всем запросам
value: 500000 # Общее число запросов в период времени
period: 1D # Период лимитирования
mnemonic: # Блок настроек лимитирования по потребителям
value: 5000 # Число запросов в период времени
period: 1D # Период лимитирования
purpose: # Блок настроек лимитирования по целям
value: 5000 # Число запросов в период времени
period: 1D # Период лимитирования
user: # Блок настроек лимитирования по пользователям
value: 1000 # Число запросов в период времени
period: 1D # Период лимитирования
records-ttl:
day: 1M # Период хранения дневной статистики
week: 1M # Период хранения статистики за неделю
month: 1Y # Период хранения статистики за месяц
year: 2Y # Период хранения статистики за год
async: # Блок настроек асинхронного выполнения запросов
request-in: 10s # Значение интервала опроса получения данных асинхронного результата. Выдается в качестве значения атрибута request_in на запрос получения данных
read-timeout: 5m # Таймаут вычитывания асинхронных данных из источников. Используется для источников с типом smevql, если была возвращена информация по асинхронным результатам
Параметры конфигурации
strategy- стратегия исполнения запросовdelegate|atomic;timeout- таймаут исполнения запросов;base_path- префикс для роута запросов. Например,smevql/api/v1;max_nested_level- предельная вложенность запрашиваемых ресурсов;omit-empty-array- настройка, позволяющая исключить пустые строки массивов из ответа;pagination- управление количеством элементов при ответе. Содержит следующие атрибуты:default- количество элементов на странице по умолчанию;max- максимальное количество элементов на странице;
logging- управление логированием «долгих» запросов. Содержит следующие атрибуты:duration- продолжительность исполнения запросов к источникам, выше которой необходимо производить логирование. Например:20s;percentage- процент логирования длительных запросов к источникам. Допустимо использовать вещественные числа, например,0.1- только каждый тысячный долгий запрос;
limits- установка ограничений на количество запросов. Содержит следующие атрибуты:total- общее допустимое количество запросов к серверу:value- целочисленное значение количества запросов, например:1000;period- на какой период устанавливается ограничение, например: 1D (на сутки)
mnemonic- допустимое для одного потребителя данных количество запросов к серверу:value- целочисленное значение количества запросов, например:100;period- на какой период устанавливается ограничение, например:1D(на сутки);
purpose- допустимое количество запросов к одному ресурсу (таблице, объекту);value- целочисленное значение количества запросов, например:100;period- на какой период устанавливается ограничение, например:1D(на сутки);
user- допустимое количество запросов для пользователя:value- целочисленное значение количества запросов, например:100;period- на какой период устанавливается ограничение, например:1D(на сутки);
records_ttl- настройка хранения статистики по лимитам:day: 1M- период хранения дневной статистики;week: 1M- период хранения статистики за неделю;month: 1Y- период хранения статистики за месяц;year: 2Y- период хранения статистики за год;
async- блок настроек асинхронного выполнения запросов. Содержит следующие атрибуты:request_in- значение интервала опроса получения данных асинхронного результата. Выдается в качестве значения атрибута request_in на запрос получения данных;read_timeout- таймаут вычитывания асинхронных данных из источников. Используется для источников с типом smevql, если была возвращена информация по асинхронным результатам
2.2.6.1.1.7. Секция delta
В секции delta настраивается управление принудительными коммитами дельт витрин данных.
Например:
delta:
commit_interval: 60s # Интервал фиксации дельты источника при изменении данных
force_commit_interval: 30m # Интервал принудительной фиксации дельт всех источников
Параметры конфигурации
commit_interval- интервал фиксации дельты источника при изменении данных, например 60s;force_commit_interval- интервал принудительной фиксации дельт всех источников, например 30s.
Если commit_interval: 0 и force_commit_interval: 0, то для добавления/изменения/удаления данных в Prostore не используется
механизм открытия и закрытия дельт, а данные меняются прямым запросом.
При этом возникают следующие ограничения:
в бекап текущей реализации данные, софрмированные вне дельт, не попадают;
в результаты запросов к материализованным представлениям данные, софрмированные вне дельт, не попадают;
в рамках подписок данные, софрмированные вне дельт, не передаются.
2.2.6.1.1.8. Секция state
В секции state устанавливаются ограничения в стейт-машинах.
Например:
state:
max_nested_event: 5 # Максимально допустимая вложенность связанных переходов стейт машины
max_updated_rows: 1 # Максимальное количество обновляемых строк при событии стейт машины
Параметры конфигурации
max_nested_event- максимально допустимая вложенность связанных переходов стейт-машины, например 5;max_updated_rows- максимальное количество обновляемых строк при событии стейт-машины, например 1.
2.2.6.1.1.9. Секция index_recommendations
В секции index_recommendations настраиваются рекомендации по аналитике, например:
index-recommendations: # Рекомендации по аналитике
enabled: true # Флаг включения формирования рекомендаций
period: 7D # Период формирования. 7 дней
concurrency: 10 # Количество параллельных корутин сохранения статистики
Параметры конфигурации
enabled- флаг включения формирования рекомендаций;period- устанавливается период формирования аналитики, например 7 дней;concurrency- количество параллельных корутин сохранения статистики
2.2.6.1.1.10. Секция standalone-tables
В секции standalone-tables настраиваются данные standalone таблиц.
Например:
# Массив описания standalone таблиц
standalone-tables: [ ]
# Пример описания
# standalone-tables:
# - readable-table: "misdm05.readable_book"
# writable-table: "misdm05.writable_book"
# anchor: "update_at"
# soft-delete: "delete_at"
Параметры конфигурации
readable-table- название readable таблицы;writable-table- название writable таблицы;anchor- название атрибута, характеризующего дату и время последнего изменения данных в нетемпоральной таблице;soft-delete- название атрибута, характеризующего дату и время удаления данных в нетемпоральной таблице.
2.2.6.1.1.11. Секция proxy-tables
В секции proxy-tables настраиваются данные прокси-таблиц.
Например:
# Массив описания proxy таблиц
proxy-tables: [ ]
# Пример описания
# proxy-tables:
# - table: "misdm05.notebook"
# anchor: "update_at"
# soft-delete: "delete_at"
Параметры конфигурации
table- название прокси таблицы;anchor- название атрибута характеризующего дату и время последнего изменения данных в нетемпоральной прокси таблице;soft-delete- название атрибута характеризующего дату и время удаления данных в нетемпоральной прокси таблице.
2.2.6.1.1.12. Секция push
В секции push содержатся настройки сервиса формирования push-уведомлений.
Например:
push: # Настройки отправки push уведомлений
notification-path: "/{target}/push/notify" # Шаблон пути агента, на который необходимо отправлять нотификации
request-timeout: 1m # Таймаут на исполнение http запроса на доставку push уведомления потребителю
state-machine-enabled: false # Признак публикации нотификаций на основе событий стейт машины
status-prostore-enabled: true # Признак публикации нотификаций на основе событий статусов Простора
prostore:
type: KAFKA # KAFKA | HTTP
status-event-topic:
topic: "$PS_STATUS_EVENT_TOPIC:status.event"
property:
bootstrap.servers: "$PS_KAFKA:localhost:9092"
group.id: smevql-server-status-event
auto.offset.reset: earliest
queue:
lock-check-interval: 30s
lock-timeout: 5m
retry:
max-attempts: 30 # Количество попыток отправки нотификации
min-period: 5s # Минимальный период ожидания перед повторной попыткой
max-period: 10s # Максимальный период ожидания перед повторной попыткой
queue:
max-attempts: 30 # Количество попыток отправки уведомлений из персистентной очереди
min-period: 1m # Минимальный период ожидания перед повторной попыткой отправки уведомления из персистентной очереди
max-period: 3m # Максимальный период ожидания перед повторной попыткой отправки уведомления из персистентной очереди
scan-waiting-period: 1m # Период сканирования отложенных уведомлений
process:
check-expired-period: 5m # Период проверки уведомлений взятых в работу и просроченных
timeout: 5m # Предельное время обработки уведомления из очереди
poisoned:
check-expired-period: 1h # Период проверки времени жизни "отравленных" уведомлений
timeout: 7d # Время хранения уведомлений в poisoned-очереди
Параметры конфигурации
notification_path- шаблон пути агента, на который необходимо отправлять нотификации;request-timeout- таймаут на исполнение HTTP запроса на доставку push уведомления потребителю;state_machine_enabled- признак публикации нотификаций на основе событий стейт-машины;status-prostore-enabled- признак публикации нотификаций на основе событий статусов Prostore;prostore- настройки Prostore;retry- настройки попыток отправок нотификаций.
2.2.6.1.1.13. Секция agent
В секции agent указываются параметры подключения к Агенту СМЭВ4 поставщика, например:
agent: # Параметры конфигурирования агента СМЭВ4
host: 127.0.0.1 # Хост агента
port: 8171 # Порт приема api-gateway запросов
mnemonic: "" # Мнемоника агента
Параметры конфигурации
host- хост агента;port- порт приема api-gateway запросов;mnemonic- мнемоника агента СМЭВ4.
2.2.6.1.1.14. Секция signature
В секции signature настраивается управление механизмом цифровой подписи.
Например:
signature: # Блок настроек механизма подписания
enabled: true # Признак включения подписания и проверки подписи
validate_enabled: false # Признак предоставления дополнительного URL проверки подписи
algorithm: "GOST3410_2012_256" # Алгоритм формирования подписи
serial_number: "" # Серийный номер ключа подписи
alias: "" # Алиас ключа. Заполняется либо серийный номер, либо алиас
notarius: # Блок настроек сервиса Notaris, используемый для подписания
host: localhost # Хост, на котором доступен Notaris
port: 8080 # Порт, на котором доступен Notaris
Параметры конфигурации
enable- включение (true), отключение (false) подписи ответов и проверки подписей других источников;validate_enabled- признак предоставления дополнительного URL проверки подписи (доступность вызова REST-метода проверки подписи);algorithm- алгоритм формирования подписи. На текущий момент доступен только GOST3410_2012_256;serial_number- серийный номер ключа подписи;alias- алиас ключа, заполняется либо серийный номер, либо алиас;notarius- настройки подключения (host и port) к модулю криптографии notarius.
2.2.6.1.1.15. Секция cls
В секции signature настраивается конфигурация отправки событий в СЦЛ, например:
cls:
enabled: false
url: "http://127.0.0.1:8192/api/v1/cls/event"
Параметры конфигурации
enable- включение (true), отключение (false) отправки событий в СЦЛ;url- эндпоинт отправки событий;
2.2.6.1.1.16. Секция component-info
В секции component-info указываются настройки модуля сбора информации о компонентах витрины.
Например:
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# Источник в папке задаваемой настройкой ${sources.directory}
source: prostore
# DataSource Prostore
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается неактивным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- storage.user
- storage.password
Параметры настроек
enabled- статус подключения компонента, указывается булево значение;datasource- массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте;datamart- схема Prostore;table-name- имя таблицы для записи информации о компоненте;create-table-period- период попыток создания схемы, при неуспехе, указывается в секундах;publish-period- период публикации health-check, указывается в секундах;timeout-active- период после которого компонент считается неактивным при отсутствии health-check, указывается в секундах;secrets- список элементов конфига маскируемых при отправке, если указан узловой элемент, то маскируются все вложенные в него элементы.
2.2.6.1.2. Конфигурация файла credentials.yml
version: 1.0.0
system:
mnemonic: smev_ql_mnemonic
instance: smev_ql_instance
Параметры конфигурации
version- номер версии СМЭВ QL;mnemonic- мнемоника СМЭВ QL, по этому параметру осуществляется идентификация СМЭВ QL сервер во внешних системах и СМЭВ4;instance- наименование инстанса СМЭВ QL.
2.2.6.1.3. Общий сценарий выполнения
Администратор системы открывает на редактирование нужный файл (
credentials.yamlи/илиapplication.yaml) настроек СМЭВ QL сервер и меняет требуемые параметры.Перезапускает приложение для применения новых настроек. Для этого открывает консоль утилиты работы со СМЭВ QL и выполняет команду:
./smevql restart
2.2.6.2. Стейт-машина СМЭВ QL
СМЭВ QL содержит встроенную машину состояний для изменения объектов модели внутри витрин данных. Одновременно с этим Стейт машина может, в качестве подтверждения перехода состояния, использовать внешний источник (например ИС Электронной очереди).
2.2.6.2.1. Конфигурирование Стейт-машины
Карта состояний и переходов описывается в формате YAML-файла state.yaml располагаемого в папке states/<имя-модели>/<х.х версия модели>
инстанса СМЭВ QL Сервера.
Описание формата и правил карты состояний:
model: slot # имя модели
states: # массив состояний объекта
- state: available # название состояния available
attributes: # массив атрибутов, описывающих состояние
- name: status # состояние определятся значением атрибута status
value: AVAILABLE # значение атрибута для описываемого состояния
initial: true
- state: booked
attributes:
- name: status
value: RECORDED
- state: reserved
attributes:
- name: status
value: RESERVED
- state: cancelled
attributes:
- name: status
value: CANCELED
- state: blocked
attributes:
- name: status
value: BLOCKED
events: # список событий изменения состояний, из них создаются методы API
- event: book # создает метод POST /states/slot/book
from: # массив состояний из которых возможен вызов события
- available
- reserved
to: booked # в какое состояние переводится объект после события
hooks: # массив связанных событий
- model: book # после перевода надо вызвать событие init для модели book
event: init
confirm:
source: rmis_rest # названия источника
endpoint: /booking/book
method: post
body: payload # что включать в тело запроса (full|state|conditions|payload|credentials)
accept: # условие принятия
jsonpath: $.status.statusCode
eq: 0 # ожидаем, что statusCode будет равен 0
- event: reserve
from: available
to: reserved
- event: block
from: available
to: blocked
- event: cancel
from:
- available
- reserved
- booked
- blocked
to: cancelled
hooks:
- model: book
event: cancel
2.2.6.2.2. Удаление записи через Стейт-машину
Статус удаления отмечается флагом delete: true, соответствует удалению записи по conditions. Значения атрибутов для такого
статуса не применимы, при наличи атрибутов необходимо выдать предупреждение в лог и проигнорировать их.
Статус с признаком delete конечный по смыслу в графе состояний, он не может использоваться в разделе from любых событий.
Проверок на эту тему не делаем, даже если кто то и пропишет из него переход, то условие никогда не выполнится.
2.2.6.2.3. Передача данных без изменения статуса (статичный ивент)
Можно передавать данные к связанному источнику из блока confirm с использованием флага статичного запроса при создании
стейта: static: true.
Созданный с указанием стейта с флагом static: true ивент не меняет статус модели, а только передает указанную в описании
ивента часть запроса в блоке confirm к связанному источнику.
Пример state ивента:
model: slot # имя модели
states: # массив состояний объекта
- state: static
static: true
events: # список событий изменения состояний, из них создаются методы API
- event: state
from:
- available
- reserved
- booked
- blocked
- cancelled
- deleted
to: static # в какое состояние переводится объект после события
confirm:
source: rmis_rest # названия источника
endpoint: /booking/book
method: post
body: payload # что включать в тело запроса (full|state|conditions|payload|credentials)
accept: # условие принятия
jsonpath: $.status.statusCode
eq: 0 # ожидаем, что statusCode будет равен 0
2.2.6.2.4. Обновление объектов через Стейт-машину
Через Стейт-машину можно обновлять записи в витрине. Для этого при конфигурировании карты состояний необходимо задать значение у
event updatable: true. При этом если требуется дать возможность обновлять только часть атрибутов, то ограничить этот список можно
перечислив атрибуты в массиве ``updatable_attribute``s.
- event: reserve
from: available
to: reserved
updatable: true // по умолчанию false для всех, кроме init, возможность изменять запись при переводе статуса
updatable_attributes: [] // массив атрибутов, которые можно обновлять, пустой — можно все
Данные для обновления будут браться из блока payload запроса на смену состояния. Для события init такое конфигурирование не
требуется — по умолчанию обновления разрешены для всех атрибутов из payload.
2.2.6.2.5. Обогащение payload запроса дополнительными атрибутами
Можно обогащать payload запроса к Витрине. Для этого необходимо выставить в блоке enrich раздела confim значение
allow: true, с указанием jsonpath для получения атрибутов для обогащения.
Пример ивента с блоком enrich:
events: # список событий изменения состояний, из них создаются методы API
- event: book # создает метод POST /states/slot/book
from: # массив состояний из которых возможен вызов события
- available
- reserved
to: booked # в какое состояние переводится объект после события
hooks: # массив связанных событий
- model: book # после перевода надо вызвать событие init для модели book
event: init
confirm:
source: rmis_rest # названия источника
endpoint: /booking/book
method: post
body: payload # что включать в тело запроса (full|state|conditions|payload|credentials)
accept: # условие принятия
jsonpath: $.status.statusCode
eq: 0 # ожидаем, что statusCode будет равен 0
enrich:
allow: true // по умолчанию false
attributes: [] // пустой массив — все, а если перечислены, то только эти
jsonpath: $.update.payload // ожидается что по этому адресу объект с атрибутами и значениями
При выставлении атрибута allow: true в блоке enrich, при выполнении запроса блока confirm происходит обращение к объекту,
указанному в переменной jsonpath с возвратом атрибутов, перечисленных в массиве atttributes (пустой массив означает отсутствие
ограничений). Извлеченные атрибуты возвращаются в payload ответа confirm запроса. Пример возможного confirm ответа от ИС
приведен ниже:
{
"status": "OK",
"update": {
"payload": {
"position": "Тест1",
"rvr_cv_id": "8888888-AEA2-4EF7-95C4-B29A4A5E990",
"rvr_candidate_id": "99999999-AEA2-4EF7-95C4-B29A4A5E990"
}
}
}
Атрибуты payload ответа confirm запроса обогащают payload основного запроса. Обновление данных в витрине в случае
обогащения payload дополнительными атрибутами происходит независимо от значения updatable.
При отсутствии объекта по пути jsonpath в confirm запросе возвращается ошибка 501 "Отсутствует объект при обращении по jsonpath",
выполнение запроса прерывается.
При несоответствии атрибутов в блоке attributes и в jsonpath - в payload вернутся только те атрибуты, по которым есть
соответствия с фиксацией в логах событий уровня WARN о несоответствующих атрибутах:
"Отсутствует атрибут *attribute_name" в $.update.payload".
В случае, если в payload присутствуют атрибуты, аналогичные тем, что возвращаются при выполнении блока enrich, обновляются
данные в соответствии со значениями вернувшимися при выполнении блока enrich. В этом случае в логах фиксируется запись "Изменение
значений атрибутов: *attribute_name" payload в соответствии со значениями блока enrich".
2.2.6.2.6. Методы API Стейт-машины
При наличии заполненных состояний машины СМЭВ QL Сервер генерирует API c набором HTTP-методов, отвечающих за изменение и просмотр состояний объектов:
GET /states— получить карту переходов;GET /states/<model-name>— получить карту переходов конкретной модели;POST /states/<model-name>/<event-name>— выполнить переход состояний для модели.
Запрос выполнения перехода:
POST /states/slot/book
{
"state": {
"conditions": {
"id": "d9e70331-b4c0-4e96-96b6-322ac75e5188" # slot_id
},
"payload": {
"bookId":"82dcac12-0a29-4fff-b9a7-8dfc84f7853d",
"patient_Id":"23453456",
"booking_type":"APPOINTMENT",
"caseNumber":"73367196",
"preliminaryReservation": false,
"email":"email@gmail.com",
"mobilePhone":"89150000102",
"referral_id":"102111",
"cards_id":"102"
}
},
"credentials": {
"system": {
"mnemonic": "117bed7f-1c07-4079-a446-1161588db4e5",
"instance_id": "ccb4a88f-f44b-43e7-8a97-3e45c8345e90",
"user_id": "5ed38461-0907-486a-930a-7b443482932c"
},
"request": {
"id": "df5a0073-c6be-4d8c-8eb2-9b2f4188a429",
"sub_id": "0cdb59ce-224b-4118-8da1-c5ea08a5d955",
"name": "request_name",
"purpose_id": "ed1170f1-3caa-4985-aa38-c9c5a190b770",
"audit": false,
"audit_id": "fc1048fe-323d-4eeb-92df-5710b3d1d100",
"audit_token": false
}
}
}
2.2.6.2.7. Спецификация интерфейса Стейт-машины
openapi: 3.0.0
x-stoplight:
id: 5i2oag6m5eq3v
info:
title: SmevQLStateMachine
version: '1.0'
description: ''
servers:
- url: 'http://localhost:3000'
paths:
/states:
parameters: []
get:
summary: Get models
tags: []
responses:
'200':
description: ''
content:
application/x-yaml:
schema:
$ref: '#/components/schemas/Models'
examples: {}
application/xml:
schema:
type: object
properties: {}
multipart/form-data:
schema:
type: object
properties: {}
text/html:
schema:
type: object
properties: {}
operationId: get-models
description: Retrieve the information of models
'/states/{model}':
parameters:
- schema:
type: string
name: model
in: path
required: true
get:
summary: Get model
tags: []
responses:
'200':
description: Model Found
content:
application/x-yaml:
schema:
$ref: '#/components/schemas/Model'
examples: {}
'400':
description: Bad Request
'404':
description: Model Not Found
operationId: get-model
description: Retrieve the information of model
parameters: []
'/states/{model}/{event}':
post:
summary: State change
operationId: post-state
responses:
'200':
description: State Updated
content:
plain/text:
schema:
type: string
examples: {}
'400':
description: Bad request
'404':
description: Not Found
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/StateUpdate'
examples: {}
description: Post the necessary fields for the API to create a new user.
description: Update state
parameters: []
parameters:
- schema:
type: string
name: model
in: path
required: true
- schema:
type: string
name: event
in: path
required: true
components:
schemas:
State:
type: object
x-stoplight:
id: 89f55561cae04
properties:
state:
type: string
attributes:
type: array
minItems: 1
items:
$ref: '#/components/schemas/Attribute'
initial:
type: boolean
Model:
type: object
x-stoplight:
id: b96a73db1e1b2
properties:
model:
type: string
states:
type: array
minItems: 1
items:
$ref: '#/components/schemas/State'
events:
type: array
items:
$ref: '#/components/schemas/Event'
Events:
title: Events
x-stoplight:
id: qdvbkmgs9xkli
type: array
items:
$ref: '#/components/schemas/Event'
States:
$ref: '#/components/schemas/State'
x-stoplight:
id: wab1w6ro30nrl
Event:
title: Event
x-stoplight:
id: sr024y2v7khum
type: object
properties:
event:
type: string
from:
type: string
to:
type: string
Models:
title: ModelSet
x-stoplight:
id: e7de590d788a7
type: array
items:
$ref: '#/components/schemas/ModelInstance'
ModelInstance:
type: object
properties:
model:
type: string
states:
$ref: '#/components/schemas/States'
events:
$ref: '#/components/schemas/Events'
ModelSet:
type: array
items:
$ref: '#/components/schemas/Model'
Attribute:
title: Attribute
x-stoplight:
id: 3kiqu047734tc
type: object
properties:
name:
type: string
value:
type: string
description: ''
StateUpdate:
title: StateUpdate
x-stoplight:
id: 2iyfifo0q1dt2
type: object
properties:
state:
type: object
properties:
conditions:
type: object
payload:
type: object
credentials:
type: object
properties:
system:
type: object
properties:
mnemonic:
type: string
instance_id:
type: string
user_id:
type: string
request:
type: object
properties:
id:
type: string
format: uuid
sub_id:
type: string
format: uuid
name:
type: string
purpose_id:
type: string
format: uuid
audit:
type: boolean
audit_id:
type: string
format: uuid
audit_token:
type: string
Пример реализации: Спецификация интерфейса Стейт-машины РМИС (OpenAPI)
openapi: 3.0.0
x-stoplight:
id: 5i2oag6m5eq3v
info:
title: SmevQLStateMachine
version: '1.0'
description: ''
servers:
- url: 'http://localhost:3000'
paths:
/states:
parameters: []
get:
summary: Get models
tags: []
responses:
'200':
description: ''
content:
application/x-yaml:
schema:
$ref: '#/components/schemas/Models'
examples: {}
application/xml:
schema:
type: object
properties: {}
multipart/form-data:
schema:
type: object
properties: {}
text/html:
schema:
type: object
properties: {}
operationId: get-models
description: Retrieve the information of models
'/states/{model}':
parameters:
- schema:
type: string
name: model
in: path
required: true
get:
summary: Get model
tags: []
responses:
'200':
description: Model Found
content:
application/x-yaml:
schema:
$ref: '#/components/schemas/Model'
examples: {}
'400':
description: Bad Request
'404':
description: Model Not Found
operationId: get-model
description: Retrieve the information of model
parameters: []
'/states/{model}/{event}':
post:
summary: State change
operationId: post-state
responses:
'200':
description: State Updated
content:
plain/text:
schema:
type: string
examples: {}
'400':
description: Bad request
'404':
description: Not Found
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/StateUpdate'
examples: {}
description: Post the necessary fields for the API to create a new user.
description: Update state
parameters: []
parameters:
- schema:
type: string
name: model
in: path
required: true
- schema:
type: string
name: event
in: path
required: true
components:
schemas:
State:
type: object
x-stoplight:
id: 89f55561cae04
properties:
state:
type: string
attributes:
type: array
minItems: 1
items:
$ref: '#/components/schemas/Attribute'
initial:
type: boolean
Model:
type: object
x-stoplight:
id: b96a73db1e1b2
properties:
model:
type: string
states:
type: array
minItems: 1
items:
$ref: '#/components/schemas/State'
events:
type: array
items:
$ref: '#/components/schemas/Event'
Events:
title: Events
x-stoplight:
id: qdvbkmgs9xkli
type: array
items:
$ref: '#/components/schemas/Event'
States:
$ref: '#/components/schemas/State'
x-stoplight:
id: wab1w6ro30nrl
Event:
title: Event
x-stoplight:
id: sr024y2v7khum
type: object
properties:
event:
type: string
from:
type: string
to:
type: string
Models:
title: ModelSet
x-stoplight:
id: e7de590d788a7
type: array
items:
$ref: '#/components/schemas/ModelInstance'
ModelInstance:
type: object
properties:
model:
type: string
states:
$ref: '#/components/schemas/States'
events:
$ref: '#/components/schemas/Events'
ModelSet:
type: array
items:
$ref: '#/components/schemas/Model'
Attribute:
title: Attribute
x-stoplight:
id: 3kiqu047734tc
type: object
properties:
name:
type: string
value:
type: string
description: ''
StateUpdate:
title: StateUpdate
x-stoplight:
id: 2iyfifo0q1dt2
type: object
properties:
state:
type: object
properties:
conditions:
type: object
properties:
id:
type: string
format: uuid
payload:
type: object
properties:
book_id:
type: string
format: uuid
patient_id:
type: string
booking_type:
type: string
case_number:
type: string
preliminary_reservation:
type: boolean
email:
type: string
mobile_phone:
type: string
referral_id:
type: string
cards_id:
type: string
credentials:
type: object
properties:
system:
type: object
properties:
mnemonic:
type: string
instance_id:
type: string
user_id:
type: string
request:
type: object
properties:
id:
type: string
format: uuid
sub_id:
type: string
format: uuid
name:
type: string
purpose_id:
type: string
format: uuid
audit:
type: boolean
audit_id:
type: string
format: uuid
audit_token:
type: string
2.2.6.2.7.1. Выполнение операций обновления данных в витрине
Инсерты в витрину выполняются в порядке поступления запросов.
Каждый экземпляр СМЭВ QL сервера ведет нарастающий счетчик инсертов.
Каждый экземпляр СМЭВ QL сервера создает один поток управления дельтами, который выполняет:
Периодически (период конфигурируемая величина, по умолчанию 60 сек) проверяет значение счетчика числа инсертов, если значение счетчика более 0
Выполняет открытие и закрытие дельты с флагом immediate, ошибки открытия и закрытия дельты игнорируются. Попытка закрытия дельты выполняется независимо от успешности открытия дельты.
Обнуляет значение счетчика.
Периодически (период конфигурируемая величина, по умолчанию 30 мин)
Выполняет открытие и закрытие дельты с флагом immediate, ошибки открытия и закрытия дельты игнорируются. Попытка закрытия дельты выполняется независимо от успешности открытия дельты.
Чтение данных сервером СМЭВQL выполняется с применением AS OF <maxLong>.
2.2.6.2.7.2. Обновление объектов через Стейт-машину
Через Стейт-машину можно обновлять записи в витрине. Для этого при конфигурировании карты состояний необходимо
задать значение у event updatable: true.
При этом если требуется дать возможность обновлять только часть
атрибутов, то ограничить этот список можно перечислив атрибуты в массиве updatable_attributes.
- event: reserve
from: available
to: reserved
updatable: true // по умолчанию false для всех, кроме init, возможность изменять запись при переводе статуса
updatable_attributes: [] // массив атрибутов, которые можно обновлять, пустой — можно все
Данные для обновления будут браться из блока payload запроса на смену состояния.
Для события init такое конфигурирование не требуется - по умолчанию обновления разрешены для всех атрибутов из payload.
2.2.6.3. Запросы
Запросы к серверу выполняют методом POST и содержат в теле JSON-объект, состоящий из обязательных блоков:
Блок Credentials;
Блок Query;
Также пространстве методов server находятся методы, помогающие эксплуатации корректно конфигурировать хранилища данных относительно модели СМЭВ QL.
2.2.6.3.1. Блок Credentials
"credentials":{
"system":{
"mnemonic":"117bed7f-1c07-4079-a446-1161588db4e5",
"instance_id":"ccb4a88f-f44b-43e7-8a97-3e45c8345e90",
"user_id":"5ed38461-0907-486a-930a-7b443482932c"
},
"request":{
"id":"df5a0073-c6be-4d8c-8eb2-9b2f4188a429",
"sub_id":"0cdb59ce-224b-4118-8da1-c5ea08a5d955",
"name":"driver_data",
"purpose_id":"ed1170f1-3caa-4985-aa38-c9c5a190b770",
"audit":"false",
"audit_id":"fc1048fe-323d-4eeb-92df-5710b3d1d100",
"audit_token":"39e47aac-45d2-44c1-8c26-2d9b28b1703b"
},
"signature":{
"digest": null,
"signature": null
}
}
2.2.6.3.2. Блок Query
{
"query": {
"office": {
"conditions": {
"phone": "(347) 246-53-00"
},
"attributes": [
"id",
"phone",
"name"
],
"cabinet": {
"conditions": {
"available": true
},
"attributes": [
"number",
"name",
"seats"
],
"online_room": {
"conditions": {
"public": true,
"software": "zoom"
},
"attributes": [
"url"
]
},
"parking": {
"conditions": {
"free": true,
"available": true
},
"attributes": [
"number",
"floor"
]
}
}
}
}
}
2.2.6.3.2.1. Условия фильтрации Conditions
Объединение условий только по and (MVP)
Операции сравнения (op):
= (по умолчанию)
>
>=
<
<=
in
like (на перспективу)
Условия сравнения применимы к численным типам, датам, временам и таймштампам.
Варианты определения условий фильрации:
По равенству
{
"query": {
"office": {
"conditions": {
"phone": "(347) 246-53-00"
}
}
}
}
На основе сравнения, краткая запись
{
"query": {
"office": {
"conditions": {
"area": [">","130"]
}
}
}
}
На основе сравнения, полная запись
{
"query": {
"office": {
"conditions": {
"area": {
"op": ">",
"value": "130"
}
}
}
}
}
Комплексное условие
{
"query": {
"office": {
"conditions": {
"area": [">","130"],
"floor": ["in", [1, 2]]
}
}
}
}
OR (ИЛИ) в условиях
В conditions СМЭВ QL запроса поддерживается возможность указывать логический ИЛИ через зарезервированное слово or.
В блок or необходимо передать массив объектов, содержащих условия в свою очередь объединённые логическим И (AND).
Все условия, находящиеся на одном уровне с or группируются через логическое И (AND), как при обычном СМЭВ QL Запросе.
Пример:
"conditions": {
"lastname": "П",
"middlename": "И",
"birthdate": "2021-11-29 00:00:00",
"or": [
{
"vin": "в1"
},
{
"vin2": "в2",
"model": "bmw"
}
],
"fetch": {
"order": [["id", "ASC"], ["number", "DESC"]], // ASC default
"page": [2, 10] // limit 10 offset 10
}
}
Условия описанного выше запроса (без учета fetch) соберутся в следующую конструкцию:
...
WHERE
(lastname = 'П' AND middlename = 'И' AND birthdate = '2021-11-29 00:00:00')
OR
(vin ='в1')
OR
(vin2='в2' AND model = 'bmw')
...
2.2.6.3.2.2. Сортировка и пагинация
В блоке conditions опционально можно добавить блок fetch, в котором указывать условия сортировки и выбора страниц.
Пример блока:
"conditions": {
"lastname": "П",
"middlename": "И",
"birthdate": "2021-11-29 00:00:00",
"fetch": {
"order": [["id", "ASC"], ["number", "DESC"]], // ASC default
"page": [2, 10] // limit 10 offset 10
}
}
Если порядок сортировки не указан, то применяется ASC.
Если не указаны страницы, то по умолчанию всегда устанавливается первая страница с лимитом, равными параметру default блока pagination в файле конфигураций application.yaml.
Если запрашивается элементов на страницу больше, чем значение max, то должно использоваться дефолтное значение.
pagination:
default: 100 //количество элементов на странице по умолчанию
max: 1000 //максимальное количество элементов на странице
2.2.6.3.3. Эксплуатационные запросы
В пространстве методов server находятся методы, помогающие эксплуатации корректно конфигурировать хранилища данных относительно модели СМЭВ QL.
Метод возврата списка обязательных для создания индексов: GET server/indexes/required
В ответе должен возвращаться JSON с полями, используемыми в связях моделей (connections) и блоке conditions.allowed моделей, если они определены (conditions)
{
"server": {
"mnemonic": "#mnemonic",
"instance": "#instance"
},
"indexes": {
"connections": [{
"source": "#source_name2",
"table": "#table_name2",
"fields": ["#field_name1", "#field_name2"]
},
{
"source": "#source_name2",
"table": "#table_name2",
"fields": ["#field_name1", "#field_name2"]
}
],
"conditions": [{
"source": "#source_name2",
"table": "#table_name2",
"fields": ["#field_name1", "#field_name2"]
},
{
"source": "#source_name2",
"table": "#table_name2",
"fields": ["#field_name1", "#field_name2"]
}
]
}
}
2.2.6.3.4. Обработка запросов
2.2.6.3.4.1. Логирование мета-данных
У каждого запроса логируются данные из блока credentials в info и выше.
Формат строки лога:
{
"level": "info",
"time": "2000-01-01T01:01:01.111Z",
"name": "#{smevql_server_name}.request",
"system": {
"mnemonic": "117bed7f-1c07-4079-a446-1161588db4e5",
"instance_id": "ccb4a88f-f44b-43e7-8a97-3e45c8345e90",
"user_id": "5ed38461-0907-486a-930a-7b443482932c"
},
"request": {
"id": "df5a0073-c6be-4d8c-8eb2-9b2f4188a429",
"sub_id": "0cdb59ce-224b-4118-8da1-c5ea08a5d955",
"name": "driver_data",
"purpose_id": "ed1170f1-3caa-4985-aa38-c9c5a190b770",
"audit": "false",
"audit_id": "fc1048fe-323d-4eeb-92df-5710b3d1d100",
"audit_token": "39e47aac-45d2-44c1-8c26-2d9b28b1703b"
}
}
Для каждого входящего запроса логируется каждый отправленный запрос к источнику:
{
"level": "info",
"time": "2000-01-01T01:01:01.111Z",
"name": "#{smevql_server_name}.request",
"system": {
"mnemonic": "117bed7f-1c07-4079-a446-1161588db4e5",
"instance_id": "ccb4a88f-f44b-43e7-8a97-3e45c8345e90",
"user_id": "5ed38461-0907-486a-930a-7b443482932c"
},
"request": {
"id": "df5a0073-c6be-4d8c-8eb2-9b2f4188a429",
"sub_id": "0cdb59ce-224b-4118-8da1-c5ea08a5d955",
"name": "driver_data",
"purpose_id": "ed1170f1-3caa-4985-aa38-c9c5a190b770",
"audit": "false",
"audit_id": "fc1048fe-323d-4eeb-92df-5710b3d1d100",
"audit_token": "39e47aac-45d2-44c1-8c26-2d9b28b1703b"
},
"source_request": {
"id": "1cdb59ce-224b-4118-8da1-c5ea08a5d955",
"source": "#{source_name}"
}
}
Передача идентификаторов:
source_request.idпередается вqueryIdтела запроса в Простор.В
x-request-idпередается склейка{request.id};{request.sub_id};{source_request.id}
Логирование ответа
{
"level": "info",
"time": "2000-01-01T01:01:01.111Z",
"name": "#{smevql_server_name}.response",
"system": {
"mnemonic": "117bed7f-1c07-4079-a446-1161588db4e5",
"instance_id": "ccb4a88f-f44b-43e7-8a97-3e45c8345e90",
"user_id": "5ed38461-0907-486a-930a-7b443482932c"
},
"request": {
"id": "df5a0073-c6be-4d8c-8eb2-9b2f4188a429",
"sub_id": "0cdb59ce-224b-4118-8da1-c5ea08a5d955",
"name": "driver_data",
"purpose_id": "ed1170f1-3caa-4985-aa38-c9c5a190b770",
"audit": "false",
"audit_id": "fc1048fe-323d-4eeb-92df-5710b3d1d100",
"audit_token": "39e47aac-45d2-44c1-8c26-2d9b28b1703b"
},
"source_request": {
"id": "1cdb59ce-224b-4118-8da1-c5ea08a5d955",
"source": "#{source_name}"
},
"response": {
"duration": "1ms",
"code": 200,
"result": "ok"
}
}
2.2.6.3.4.2. Исполнение плана запроса
Запускающее событие
Подготовлен план выполнения запроса.
Ход выполнения
Указанная последовательность выполняется для каждого подзапроса из плана. При этом сначала параллельно выполняются подзапросы первого уровня, затем подзапросы второго уровня на основе данных полученных на первом уровне и т.д. по всем уровням иерархии плана запроса.
В качестве ответа от Источника могут быть сами запрашиваемые данные (если обращение к источнику шло в синхронном режиме) или токен (если обращение к источнику шло в асинхронном режиме).
Система отправляет подзапрос к источнику с указанным в плане sql-выражением. Так же на этом шаге Система обновляет счетчики лимитов в Redis, при этом количество увеличивается на величину подзапросов к источникам данных.
Система ожидает ответ и определяет режим обработки подзапроса к источнику ресурса. Для этого определяет значение параметра fetch->policy в модели данных ресурса:
a) если установлено значение sync или async_on_timeout и ответ пришёл в течение заданного таймаута, то режим обработки подзапроса синхронный, переход к выполнению шага 2. b) иначе, установлено значение async или async_on_timeout и исчтоник не отвечает в в течение заданного таймаута, то режим обработки подзапроса асинхронный, переход к выполнению шага 6.
Система обрабатывает полученный ответ от источника или обрабатывает ситуацию, когда ответ не получен:
a) если ответ получен и он некорректного формата или ответ не получен в заданный таймаут, то Система формрует блок с описанием ошибки (пример приведен ниже) и переходит к следующему источнику. b) если, ответ корректен и получен в заданный таймаут, а источником данных является prostore, то данный процесс завершается и вызывается выполнение передачи ответа потребителю. c) иначе, ответ корректен и получен в заданный таймаут, а источником данных является smevql, переход к выполнению следующего шага.
Система проверяет, что ответ от источника подписан цифровой подписью (далее ЦП). Для этого извлекает данные из полученного ответа (блок signature) и отправляет данные ЦП на проверку в модуль Notarius. После чего дожидается результатов проверки ЦП от Notarius:
a) если ЦП не прошла успешную проверку в Notarius или блок signature не заполнен источником, то ответ считается невалидным, Система передаёт соответствующее сообщение об ошибке, процесс завершается. b) иначе, ЦП прошла успешную проверку в Notarius, ответ валиден, переход к выполнению следующего шага.
Система накладывает свою ЦП на ответ источника. Для этого отправляет запрос в модуль Notarius и ожидает получение ответа. После чего ответ подписан ЦП (заполнен блок partials в ответе для потребителя). Процесс завершается после получения всех ответов от всех источников и вызывается выполнение передачи ответа потребителю.
Система генерирует токен (по которому в дальнейшем Потребитель сможет отдельно запросить данные) и записывает его в блоке персистентности Redis.
Система в качестве временного ответа от источника подставляет токен (получение данных по токену см. раздел 3.5.4 Асинхронное получение данных клиентом). Процесс завершается после получения всех ответов от всех источников и вызывается выполнение передачи ответа потребителю.
Пример блока с описанием ошибки:
"errors": [ - блок ошибок, единый для всех ресурсов и источников
{
"resource": <название ресурса>, - новое поле
"source": <название источника>, - новое поле (опциональное)
"error": "Ошибка обращения к источнику prostore: connection timed out after 30000 ms: prostore.dtm-test1.svc.cluster.local/10.111.97.115:9010",
"code": "901"
}
]
2.2.6.4. Ответы
Ответы СМЭВ QL сервера представляют из себя объект JSON, схема которого определяется составом запроса.
Например, для запроса:
{
"query":{
"people":{
"conditions":{
"age":"<35"
},
"attributes":[
"name",
"phone",
"vsu_code"
],
"military_office":{
"attributes":[
"address"
]
}
}
},
"credentials":{
}
}
Ответ будет следующим:
{
"response":{
"people":[
{
"name":"Иван",
"phone":"+79011001010",
"vsu_code":"1025",
"military_office":[
{
"address":"г.Москва, ул.Угрешко"
}
]
},
{
"name":"Пётр",
"phone":"+79022002020",
"vsu_code":"1026",
"military_office":[
{
"address":"г.Москва, Хилков переулок"
}
]
}
]
},
"credentials":{
}
}
2.2.6.5. Описание эндпоинтов
2.2.6.5.1. GET /ping
Метод проверяет доступность сервера
GET /ping
URL
http://localhost:8080/smevql/api/v1/ping
Запрос отправляется без параметров
Пример запроса:
curl -X 'GET' \
'http://localhost:8080/smevql/api/v1/ping' \
-H 'accept: plain/text'
Пример ответа:
pong
Параметр |
Тип данных |
Описание |
|---|---|---|
pong |
string |
Текстовый ответ при успешном отклике сервера |
2.2.6.5.2. GET /states
Метод выводит состояния стейт-машины на данный момент
GET /states
URL
http://localhost:8080/smevql/api/v1/states
Запрос отправляется без параметров
Пример запроса:
curl -X 'GET' \
'http://localhost:8080/smevql/api/v1/states' \
-H 'accept: application/json'
Пример ответа:
[
{
"model": "book",
"states": [
{
"state": "appointment",
"attributes": [
{
"name": "type",
"value": "APPOINTMENT"
}
],
"initial": true,
"delete": false,
"static": false
},
{
"state": "cancel",
"attributes": [
{
"name": "type",
"value": "CANCEL"
}
],
"initial": false,
"delete": false,
"static": false
},
{
"state": "observation",
"attributes": [
{
"name": "type",
"value": "D_OBSERVATION"
}
],
"initial": false,
"delete": false,
"static": false
},
{
"state": "cancelled",
"attributes": [
{
"name": "type",
"value": "Cancel"
}
],
"initial": false,
"delete": false,
"static": false
},
{
"state": "deleted",
"attributes": [],
"initial": false,
"delete": true,
"static": false
}
],
"events": [
{
"event": "book",
"from": [
"appointment"
],
"to": "observation",
"hooks": [],
"confirm": null,
"updatable": false,
"updatable_attributes": []
},
{
"event": "observation",
"from": [
"appointment"
],
"to": "observation",
"hooks": [],
"confirm": null,
"updatable": false,
"updatable_attributes": []
},
{
"event": "cancel",
"from": [
"appointment",
"observation"
],
"to": "cancel",
"hooks": [],
"confirm": null,
"updatable": false,
"updatable_attributes": []
},
{
"event": "delete",
"from": [
"appointment",
"observation",
"cancel"
],
"to": "deleted",
"hooks": [],
"confirm": null,
"updatable": false,
"updatable_attributes": []
}
]
,
]
Параметр |
Тип данных |
Описание |
|---|---|---|
model |
string |
имя модели |
state |
string |
название состояния |
attributes |
array |
набор атрибутов, описывающих состояние |
name |
string |
имя атрибута |
value |
string |
значение атрибута для описываемого состояния |
initial |
boolean |
возможность создания записи |
events |
array |
список событий изменения состояний |
event |
string |
событие |
from |
string |
массив состояний из которых возможен вызов события |
to |
string |
в какое состояние переводится объект после события |
2.2.6.5.3. GET /states/{model}
Возвращает информацию о модели
GET /states/{model}
URL
http://localhost:8080/smevql/api/v1/states/{model}
Параметр |
Тип данных |
Описание |
|---|---|---|
model |
string |
имя модели |
Пример запроса:
curl -X 'GET' \
'http://localhost:8080/smevql/api/v1/states/{model}' \
-H 'accept: application/json'
Пример ответа:
[
{
"model": "book",
"states": [
{
"state": "appointment",
"attributes": [
{
"name": "type",
"value": "APPOINTMENT"
}
],
"initial": true,
"delete": false,
"static": false
},
{
"state": "cancel",
"attributes": [
{
"name": "type",
"value": "CANCEL"
}
],
"initial": false,
"delete": false,
"static": false
},
{
"state": "observation",
"attributes": [
{
"name": "type",
"value": "D_OBSERVATION"
}
],
"initial": false,
"delete": false,
"static": false
},
{
"state": "cancelled",
"attributes": [
{
"name": "type",
"value": "Cancel"
}
],
"initial": false,
"delete": false,
"static": false
},
{
"state": "deleted",
"attributes": [],
"initial": false,
"delete": true,
"static": false
}
],
"events": [
{
"event": "book",
"from": [
"appointment"
],
"to": "observation",
"hooks": [],
"confirm": null,
"updatable": false,
"updatable_attributes": []
},
{
"event": "observation",
"from": [
"appointment"
],
"to": "observation",
"hooks": [],
"confirm": null,
"updatable": false,
"updatable_attributes": []
},
{
"event": "cancel",
"from": [
"appointment",
"observation"
],
"to": "cancel",
"hooks": [],
"confirm": null,
"updatable": false,
"updatable_attributes": []
},
{
"event": "delete",
"from": [
"appointment",
"observation",
"cancel"
],
"to": "deleted",
"hooks": [],
"confirm": null,
"updatable": false,
"updatable_attributes": []
}
]
,
]
Параметр |
Тип данных |
Описание |
|---|---|---|
model |
string |
имя модели |
state |
string |
название состояния |
attributes |
array |
набор атрибутов, описывающих состояние |
name |
string |
имя атрибута |
value |
string |
значение атрибута для описываемого состояния |
initial |
boolean |
возможность создания записи |
events |
array |
список событий изменения состояний |
event |
string |
событие |
from |
string |
список состояний из которых возможен вызов события |
to |
string |
в какое состояние переводится объект после события |
2.2.6.5.4. POST /states/{model}/{event}
Метод обновляет данные состояния модели по указанному событию
Метод
POST /states/{model}/{event}
URL
http://localhost:8080/smevql/api/v1/states/{model}/{event}
Параметр |
Тип данных |
Описание |
|---|---|---|
model |
string |
имя модели |
event |
string |
событие |
В теле запроса нужно заполнить поля:
{
"state": {
"conditions": {
"id": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
},
},
"credentials": {
"system": {
"mnemonic": "string",
"instance_id": "string",
"user_id": "string"
},
"request": {
"id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"sub_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"name": "string",
"purpose_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"audit": true,
"audit_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"audit_token": "string"
}
}
}
Параметр |
Тип данных |
Описание |
|---|---|---|
state |
string |
название состояния |
conditions |
string |
указывается условие фильтрации записей (опционально) |
credentials |
array |
системные реквизиты |
mnemonic |
string |
мнемоника |
instance_id |
string |
идентификатор экземпляра |
user_id |
string |
идентификатор пользователя |
request |
array |
параметры запроса |
id |
string |
идентификатор запроса |
sub_id |
string |
идентификатор подзапроса |
name |
string |
имя запроса |
purpose_id |
string |
идентификатор события, породившего запрос |
audit |
boolean |
признак необходимости запроса аудита |
audit_id |
string |
идентификатор аудита |
audit_token |
string |
токен аудита |
Пример запроса:
curl -X 'POST' \
'http://localhost:8080/smevql/api/v1/states/{model}/{event}' \
-H 'accept: plain/text' \
-H 'Content-Type: application/json' \
-d '{
"state": {
"conditions": {
"id": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
},
"payload": {
"book_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"patient_id": "string",
"booking_type": "string",
"case_number": "string",
"preliminary_reservation": true,
"email": "string",
"mobile_phone": "string",
"referral_id": "string",
"cards_id": "string"
}
},
"credentials": {
"system": {
"mnemonic": "string",
"instance_id": "string",
"user_id": "string"
},
"request": {
"id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"sub_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"name": "string",
"purpose_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"audit": true,
"audit_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"audit_token": "string"
}
}
}'
Пример ответа:
{
"response": {
"state": "booked"
},
Параметр |
Тип данных |
Описание |
|---|---|---|
state |
string |
обновленный статус события |
2.2.6.5.5. GET /model
Метод выводит массив моделей сервера
GET /model
URL
http://localhost:8080/smevql/api/v1/model
Запрос отправляется без параметров
Пример запроса:
curl -X 'GET' \
'http://localhost:8080/smevql/api/v1/model' \
-H 'accept: application/json'
Пример ответа:
"resources": {
"ticket1": {
"name": "ticket",
"description": "ticket",
"version": "1.0",
"available_versions": [
"1.0"
],
"fields": {
"id": {
"name": "id",
"type": [
"string",
"STRING"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"passengerid": {
"name": "passengerid",
"type": [
"string",
"STRING"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"tripid": {
"name": "tripid",
"type": [
"string",
"STRING"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"number": {
"name": "number",
"type": [
"number",
"LONG"
],
"length": 0,
"nullable": "NULL",
"key": "PRIMARY"
},
"bycard": {
"name": "bycard",
"type": [
"boolean",
"BOOLEAN"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"price": {
"name": "price",
"type": [
"number",
"DOUBLE"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"sold": {
"name": "sold",
"type": [
"string",
"TIMESTAMP"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
}
},
"connections": {
"has_many": [],
"belongs_to": [
{
"passenger1": {
"primary_key": [
"id"
],
"foreign_key": [
"passengerid"
]
}
},
{
"trip1": {
"primary_key": [
"id"
],
"foreign_key": [
"tripid"
]
}
}
]
},
"restrictions": {
"personal_data": []
},
"conditions": {
"allowed": [],
"denied": [],
"always": []
},
"extract": {
"source": [
{
"name": "prostore",
"table": "smevql_test.ticket1",
"conditions": [
{
"eq": {
"field": "sold",
"extract": {
"source": "prostore",
"table": "smevql_test.ticket1",
"key": "sold",
"is": true
},
"isFallback": false
}
}
]
}
]
}
},
Параметр |
Тип данных |
Описание |
|---|---|---|
name |
string |
название модели |
version |
string |
текущая версия модели |
available_versions |
string |
доступные версии модели |
fields |
string |
список полей модели |
2.2.6.5.6. GET /model/{model}
Метод выводит данные выбранной модели
GET /model/{model}
URL
http://localhost:8080/smevql/api/v1/model/{model}
Запрос отправляется без параметров
Пример запроса:
curl -X 'GET' \
'http://localhost:8080/smevql/api/v1/model/{model}' \
-H 'accept: application/json'
Пример ответа:
[
"ticket1": {
"name": "ticket",
"description": "ticket",
"version": "1.0",
"available_versions": [
"1.0"
],
"fields": {
"id": {
"name": "id",
"type": [
"string",
"STRING"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"passengerid": {
"name": "passengerid",
"type": [
"string",
"STRING"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"tripid": {
"name": "tripid",
"type": [
"string",
"STRING"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"number": {
"name": "number",
"type": [
"number",
"LONG"
],
"length": 0,
"nullable": "NULL",
"key": "PRIMARY"
},
"bycard": {
"name": "bycard",
"type": [
"boolean",
"BOOLEAN"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"price": {
"name": "price",
"type": [
"number",
"DOUBLE"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"sold": {
"name": "sold",
"type": [
"string",
"TIMESTAMP"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
}
}
}
]
Параметр |
Тип данных |
Описание |
|---|---|---|
name |
string |
название модели |
version |
string |
текущая версия модели |
available_versions |
string |
доступные версии модели |
fields |
string |
список полей модели |
2.2.6.5.7. GET /model/{model}/{version}
Метод выводит версию выбранной модели
GET /model/{model}/{version}
URL
http://localhost:8080/smevql/api/v1/model/{model}/{version}
Запрос отправляется без параметров
Пример запроса:
curl -X 'GET' \
'http://localhost:8080/smevql/api/v1/model/{model}/{version}' \
-H 'accept: application/json'
Пример ответа:
[
"ticket1": {
"name": "ticket",
"description": "ticket",
"version": "1.0",
"available_versions": [
"1.0"
],
"fields": {
"id": {
"name": "id",
"type": [
"string",
"STRING"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"passengerid": {
"name": "passengerid",
"type": [
"string",
"STRING"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"tripid": {
"name": "tripid",
"type": [
"string",
"STRING"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"number": {
"name": "number",
"type": [
"number",
"LONG"
],
"length": 0,
"nullable": "NULL",
"key": "PRIMARY"
},
"bycard": {
"name": "bycard",
"type": [
"boolean",
"BOOLEAN"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"price": {
"name": "price",
"type": [
"number",
"DOUBLE"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
},
"sold": {
"name": "sold",
"type": [
"string",
"TIMESTAMP"
],
"length": 0,
"nullable": "NULL",
"key": "NONE"
}
}
}
]
Параметр |
Тип данных |
Описание |
|---|---|---|
name |
string |
название модели |
version |
string |
текущая версия модели |
available_versions |
string |
доступные версии модели |
fields |
string |
список полей модели |
2.2.6.5.8. GET /sources
Метод выводит массив источников сервера
GET /sources
URL
http://localhost:8080/smevql/api/v1/sources
Запрос отправляется без параметров
Пример запроса:
curl -X 'GET' \
'http://localhost:8080/smevql/api/v1/sources' \
-H 'accept: application/json'
Пример ответа:
{
"prostore": [
{
"version": "1.0",
"adapter": "prostore",
"protocol": "http",
"host": "prostore",
"port": 9090,
"path": "api/v1/datamarts/query?format=json",
"headers": [
{
"content-type": "application/json"
}
],
"threads-count": 4,
"connection-timeout": 30,
"type": "rest"
}
],
"smevql": [
{
"version": "1.0",
"adapter": "smevql",
"protocol": "http",
"host": "smevql-server",
"port": 8080,
"path": "data?format=json",
"headers": [
{
"content-type": "application/json"
}
],
"threads-count": 4,
"connection-timeout": 30,
"type": "rest"
}
],
"csv-uploader": [
{
"version": "1.0",
"adapter": "confirm",
"protocol": "http",
"host": "csv-uploader",
"port": 8080,
"path": "version?format=json",
"headers": [
{
"content-type": "application/json"
}
],
"threads-count": 4,
"connection-timeout": 30,
"type": "rest"
}
]
}
Параметр |
Тип данных |
Описание |
|---|---|---|
version |
string |
версия |
adapter |
string |
имя адаптера |
protocol |
string |
протокол передачи данных |
host |
string |
хост сервера |
port |
int |
порт сервера |
path |
string |
путь к источнику |
headers |
array |
заголовки |
threads-count |
int |
кол-во потоков |
connection-timeout |
int |
время соединения |
type |
string |
тип взаимодействия с источником |
2.2.6.5.9. POST /data
Запрашивает данные ресурсов в синхронном режиме
POST /data
URL
http://localhost:8080/smevql/api/v1/data
При запросе необходимо указать Headers:
Key: content-type
Value: application/json
Тело запроса должно содержать два обязательных блока:
Блок query - описание требуемых ресурсов и условий фильтрации данных;
Блок credentials - общие данные запроса и информация о потребителе.
Пример блока query:
{
"query": {
"office": {
"conditions": {
"phone": "(347) 246-53-00"
},
"attributes": [
"id",
"phone",
"name"
],
"cabinet": {
"conditions": {
"available": true
},
"attributes": [
"number",
"name",
"seats"
],
"online_room": {
"conditions": {
"public": true,
"software": "zoom"
},
"attributes": [
"url"
]
},
"parking": {
"conditions": {
"free": true,
"available": true
},
"attributes": [
"number",
"floor"
]
}
}
}
}
}
Пример блока credentials:
"credentials":{
"system":{
"mnemonic":"117bed7f-1c07-4079-a446-1161588db4e5",
"instance_id":"ccb4a88f-f44b-43e7-8a97-3e45c8345e90",
"user_id":"5ed38461-0907-486a-930a-7b443482932c"
},
"request":{
"id":"df5a0073-c6be-4d8c-8eb2-9b2f4188a429",
"sub_id":"0cdb59ce-224b-4118-8da1-c5ea08a5d955",
"name":"driver_data",
"purpose_id":"ed1170f1-3caa-4985-aa38-c9c5a190b770",
"audit":"false",
"audit_id":"fc1048fe-323d-4eeb-92df-5710b3d1d100",
"audit_token":"39e47aac-45d2-44c1-8c26-2d9b28b1703b"
},
"signature":[
{
"digest": null,
"signature": null,
"jsonpath": "/response"
}
]
}
Параметр |
Тип данных |
Описание |
Примечание |
|---|---|---|---|
query |
array |
атрибут запроса данных внутри указывается название сущности, данные которой нужно получить |
|
conditions |
string |
указывается условие фильтрации записей (опционально) |
|
fetch |
array |
опциональный блок условий |
|
attributes |
array |
Атрибуты, значения которых необходимо получить при выполнении запроса |
|
credentials |
object |
Объект, содержащий общие данные запроса и информация о потребителе |
|
mnemonic |
string |
мнемоника системы |
|
instance_id |
string |
идентификатор экземпляра системы |
|
user_id |
string |
идентификатор пользователя |
|
request |
object |
Объект описывает общие параметры запроса |
|
id |
string |
идентификатор запроса |
|
sub_id |
string |
идентификатор подзапроса |
|
name |
string |
имя запроса |
|
purpose_id |
string |
идентификатор события, инициировавшего запрос |
|
audit |
boolean |
возможность аудита |
|
audit_id |
string |
идентификатор аудита. Заполняется только, если audit = true |
|
audit_token |
string |
токен аудита. Заполняется только, если audit = true |
|
signature |
object |
Объект, описывает параметры ЭЦП |
|
digest |
string |
дайджест подписи (не заполняется) |
|
signature |
string |
подпись (не заполняется) |
Пример запроса:
curl -X 'POST' \
'http://localhost:8080/smevql/api/v1/data' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
"query": {
"ticket": {
"conditions": {},
"attributes": [
"id",
"price"
]
}
},
"credentials": {
"system": {
"mnemonic": "3fa45f64-5717-4562-b3fc-2c963f66afa6",
"instance_id": "3fa45f64-5717-4562-b3fc-2c963f66afa6",
"user_id": "3fa45f64-5717-4562-b3fc-2c963f66afa6"
},
"request": {
"id": "6fa45f64-5717-4562-b3fc-2c963f66afa6",
"sub_id": "7fa45f64-5717-4562-b3fc-2c963f66afa6",
"name": "query",
"purpose_id": "8fa45f64-5717-4562-b3fc-2c963f66afa6",
"audit": true,
"audit_id": "9fa45f64-5717-4562-b3fc-2c963f66afa6",
"audit_token": "b3fc"
},
"signature": {
"digest": "digest",
"signature": "signature"
}
}
}'
Пример ответа:
{
"response": {
"ticket": [
{
"price": 298.8082301905419,
"id": "3424f5b3-e337-4d0d-a046-a1c491ab3300"
},
{
"price": 67.79323025646744,
"id": "ad14fce2-04f5-45b8-b430-3ff9efb5d4ca"
}
]
},
"credentials": {
"system": {
"mnemonic": "3fa45f64-5717-4562-b3fc-2c963f66afa6",
"instance_id": "4fa45f64-5717-4562-b3fc-2c963f66afa6",
"user_id": "5fa45f64-5717-4562-b3fc-2c963f66afa6"
},
"request": {
"id": "6fa45f64-5717-4562-b3fc-2c963f66afa6",
"sub_id": "7fa45f64-5717-4562-b3fc-2c963f66afa6",
"name": "query",
"purpose_id": "8fa45f64-5717-4562-b3fc-2c963f66afa6",
"audit": true,
"audit_id": "9fa45f64-5717-4562-b3fc-2c963f66afa6",
"audit_token": "b3fc"
},
"signature": {
"digest": "digest",
"signature": "signature"
},
"response": {
"id": "ec26f676-5931-11ee-9044-eb1795d841ef",
"sub_id": "ec26f677-5931-11ee-9044-eb1795d841ef",
"started_at": "2023-09-22 13:22:24.456 +0300",
"finished_at": "2023-09-22 13:22:24.530 +0300"
}
}
}
Параметр |
Тип данных |
Описание |
|---|---|---|
response |
object |
объект с описанием ресурсов, содержащих массивы данных запросов |
resourse_data |
array |
массивы данных, запрашиваемых ресурсов (имя объекта) |
2.2.6.5.9.1. Правила задания условий
Объединение условий только по and
Операции сравнения:
=(по умолчанию);>;>=;<;<=;in.
Условия сравнения применимы к численным типам, датам, временам и таймштампам.
2.2.6.5.9.2. Варианты определения условий фильтрации
Простое равенство
{
"query": {
"office": {
"conditions": {
"phone": "(347) 246-53-00"
}
}
}
}
Сравнение краткое
{
"query": {
"office": {
"conditions": {
"area": [">","130"]
}
}
}
}
Сравнение полное
{
"query": {
"office": {
"conditions": {
"area": {
"op": ">",
"value": "130"
}
}
}
}
}
Комплексное условие
{
"query": {
"office": {
"conditions": {
"area": [">","130"],
"floor": ["in", [1, 2]]
}
}
}
}
В conditions СМЭВ QL запроса поддерживается возможность указывать логический ИЛИ через зарезервированное слово or.
В блок or необходимо передать массив объектов, содержащих условия в свою очередь объединённые логическим И (AND).
Все условия, находящиеся на одном уровне с or группируются через логическое И (AND), как при обычном СМЭВ QL Запросе.
Пример:
"conditions": {
"lastname": "П",
"middlename": "И",
"birthdate": "2021-11-29 00:00:00",
"or": [
{
"vin": "в1"
},
{
"vin2": "в2",
"model": "bmw"
}
],
"fetch": {
"order": [["id", "ASC"], ["number", "DESC"]], // ASC default
"page": [2, 10] // limit 10 offset 10
}
}
Условия описанного выше запроса (без учета fetch) соберутся в следующую конструкцию:
WHERE
(lastname = 'П' AND middlename = 'И' AND birthdate = '2021-11-29 00:00:00')
OR
(vin ='в1')
OR
(vin2='в2' AND model = 'bmw')
2.2.6.5.9.3. Подробное описание блока fetch
В блоке conditions опционально можно добавить блок fetch, в котором указывать:
условия сортировки (order);
условия выбора страниц (page);
условия выборки доступных для каждого ресурса событий машины состояния (show_events);
применение локализованных переменных (localize);
условия выбора версии данных на указанную дату, диапазон дат, дельту, диапазон дельт (for_system_time, for_system_time_started, for_system_time_finished).
"conditions": {
"lastname": "П",
"middlename": "И",
"birthdate": "2021-11-29 00:00:00",
"fetch": {
"order": [["id", "ASC"], ["number", "DESC"]], // ASC default
"page": [2, 10] // limit 10 offset 10
}
}
Если порядок сортировки не указан, то применяется ASC.
Если не указаны страницы, то по умолчанию всегда устанавливается первая страница с лимитом, равными параметру default блока pagination в файле конфигураций
application.yaml.
Если запрашивается элементов на страницу больше, чем значение max, то должно использоваться дефолтное значение.
В блок fetch можно добавить атрибут выборки доступных евентов (events стэйт-машины (Создание карты машины-состояний) show_events):
"conditions": {
"lastname": "П",
"middlename": "И",
"birthdate": "2021-11-29 00:00:00",
"fetch": {
"order": [["id", "ASC"], ["number", "DESC"]], // ASC default
"page": [2, 10] // limit 10 offset 10,
"show_events": true // false default
}
}
Если данный атрибут указан и возвращаемый объект управляется стейт-машиной, то его атрибуты дополняются доступными евентами в
атрибуте available_state_events:
"response": {
"office": [
{
"id": "10459",
"phone": "(347) 246-53-00",
"name": "ГБУЗ РБ Поликлиника № 50 г.Уфа, Кабинет вакцинации COVID-19",
"available_state_events": [ "book", "cancel" ]
},
{
"id": "10461",
"phone": "(347) 246-53-00",
"name": "ГБУЗ РБ Поликлиника № 50 г.Уфа, Кабинет вакцинации COVID-19",
"available_state_events": [ "book" ]
},
{
"id": "6344",
"phone": "(347) 246-53-00",
"name": "ГБУЗ РБ Поликлиника № 50 г.Уфа, отделение 26",
"available_state_events": [ "reserve", "cancel" ]
}
]
}
Если евентов нет, то выводится пустой массив. Если объект не управляется стейт-машиной, то директива просто игнорируется.
В блоке локализованных переменных localize можно задать массив произвольных именованных переменных.
Данные переменные можно указывать в качестве критерия отбора данных для других ресурсов.
При этом получение данных ресурса с критерием включающим локализованную переменную выполняется после получения данных ресурса, где эта переменная была определена.
Пример определения локализованных переменных:
"query": {
"mdm": {
"conditions": {
"eduejd": "00650abd-dde7-4a3b-a44e-475285ff276f",
"fetch": {
"localize": [
"eduejd01",
"eduejd02"
]
}
Пример указания локализованной переменной в качестве критерия отбора данных другого ресурса:
"students_eduejd01": {
"conditions": {
"id": "@mdm.eduejd01",
},
Примечание
Использование локализованных переменных допускается только для ресурсов, находящихся на одном уровне в запросе.
Если необходимо получить данные конкретной версии (версия может характеризоваться временной отметкой или номером дельты),
то в блоке fetch указывается соответствующий системный параметр:
for_system_time- получение текущих данных витрины на заданную отметку версии. Возможны следующие варианты определения отметки версии:Номер дельты (целое число), например:
"for_system_time": 231Время (timestamp), например:
"for_system_time": "2024-02-09 12:05:03"
for_system_time_started- получение новых/измененных данных витрины с заданным диапазоном версий. Возможны следующие варианты определения отметки диапазона версий:Диапазон номеров дельт, например:
"for_system_time_started": [210,215]Диапазон времени, например:
"for_system_time_started": ["2024-02-09 12:00:00","2024-02-09 15:59:59"]
for_system_time_finished- получение удалённых данных витрины с заданным диапазоном версий. Возможны следующие варианты определения отметки диапазона версий:Диапазон номеров дельт, например:
"for_system_time_finished": [210,215]Диапазон времени, например:
"for_system_time_finished": ["2024-02-09 12:00:00","2024-02-09 15:59:59"]
for_system_time_cn- получение текущих данных витрины на заданный номер операции (CN, целое число), например:"for_system_time_cn": 114;for_system_time_started_cn- получение новых/ измененных данных витрины с заданным диапазоном номеров операций, например:"for_system_time_started_cn": [110,115];for_system_time_finished_cn- получение удалённых данных витрины с заданным диапазоном номеров операций, например:"for_system_time_finished_cn": [110,115].
Общие правила работы с системными параметрами:
СМЭВ QL фиксирует время получения запроса для подстановки в запросы к ресурсам у которых не указана отметка.
Указание отметок времени может быть на уровне родительского ресурса, так и на уровне вложенного ресурса.
При наличии отметок и на уровне родительского и на уровне вложенного ресурса, приоритет имеет более близкая к ресурсу отметка.
При чтении данных ресурса из нескольких источников, фильтрация на основе отметки ресурса распространяется на все таблицы.
Для таблиц типа стенделон и прокси Простор игнорирует конструкцию
for system_time.Для не версионированных таблиц запросы с
for system_time as offвозвращают актуальное значение без учета отметки
b. Для не версионированных таблиц запросы с
for system_time started/finishedвозвращают пустое множество без учета отметок диапазонаПри наличии отметок на уровне запроса, она распространяется на все ресурсы, для которых метка не определена.
Совмещение в одном запросе различных режимов получения данных (добавленных и удаленных), например 1 ресурс добавленные записи, а 2 ресурс удаленные записи недопустимо, должен вернуться код 409 «Недопустимое сочетание условий выборки данных». Остальные сочетания режимов получения данных допустимы.
Метки времени на ресурсы сиблинги не распространяются.
Примеры запросов с указанием временных меток:
получение данных офисов и кабинетов на таймштамп
{
"query": {
"office": {
"conditions": {
"phone": "(347) 246-53-00",
"fetch": {
"for_system_time": "2024-02-09 12:05:03"
}
},
"attributes": [
"id",
"phone",
"name"
],
"cabinet": {
"conditions": {
"available": true
},
"attributes": [
"number",
"name",
"seats"
]
}
}
}
}
получение данных офисов на 120 дельту и кабинетов на 45 дельту
{
"query": {
"office": {
"conditions": {
"phone": "(347) 246-53-00",
"fetch": {
"for_system_time": 120
}
},
"attributes": [
"id",
"phone",
"name"
],
"cabinet": {
"conditions": {
"available": true,
"fetch": {
"for_system_time": 45
}
},
"attributes": [
"number",
"name",
"seats"
]
}
}
}
}
получение данных офисов и кабинетов добавленных с 210 по 215 дельту
{
"query": {
"office": {
"conditions": {
"phone": "(347) 246-53-00",
"fetch": {
"for_system_time_started": [210,215]
}
},
"attributes": [
"id",
"phone",
"name"
],
"cabinet": {
"conditions": {
"available": true
},
"attributes": [
"number",
"name",
"seats"
]
}
}
}
}
получение данных офисов и кабинетов удаленных за диапазон времени
{
"query": {
"office": {
"conditions": {
"phone": "(347) 246-53-00",
"fetch": {
"for_system_time_finished": ["2024-02-09 12:00:00","2024-02-09 15:59:59"]
}
},
"attributes": [
"id",
"phone",
"name"
],
"cabinet": {
"conditions": {
"available": true
},
"attributes": [
"number",
"name",
"seats"
]
}
}
}
}
получение данных офисов на 231 дельту и всех актуальных кабинетов (сиблинг)
{
"query": {
"office": {
"conditions": {
"phone": "(347) 246-53-00",
"fetch": {
"for_system_time": 231
}
},
"attributes": [
"id",
"phone",
"name"
]
},
"cabinet": {
"conditions": {
"available": true
},
"attributes": [
"number",
"name",
"seats"
]
}
}
}
2.2.6.5.10. GET /server/indexes/required
Формирует рекомендации по индексам на основании описания моделей
GET /server/indexes/required
URL
http://localhost:8080/smevql/api/v1/server/indexes/required
Запрос отправляется без параметров
Пример запроса:
curl -X 'GET' \
'http://localhost:8080/smevql/api/v1/server/indexes/required' \
-H 'accept: application/json'
Пример ответа:
{
"server": {
"mnemonic": "00000000-d759-11ed-84c6-47c59cf9ecf6",
"instance": "00000001-d759-11ed-84c6-47c59cf9ecf6"
},
"indexes": {
"connections": [
{
"source": "prostore",
"table": "smevql_test.ticket1",
"fields": [
"passengerid",
"tripid"
]
}
],
"conditions": [
{
"source": "prostore",
"table": "smevql_test.passenger1",
"fields": [
"lastname",
"firstname",
"code"
]
},
{
"source": "prostore",
"table": "mvd.vehicleregdata",
"fields": [
"vehiclevin",
"vehiclevin2"
]
}
]
}
}
}
Параметр |
Тип данных |
Описание |
|---|---|---|
server |
string |
данные сервера |
mnemonic |
string |
мнемоника |
instance |
string |
экземпляр сервера |
indexes |
string |
данные индекса |
connections |
array |
массив связей |
source |
string |
название источника |
table |
string |
название таблицы |
fields |
string |
список полей модели |
conditions |
array |
массив условий фильтрации записей |
2.2.6.5.11. GET /regulated-query
Получение данных из Витрины с использованием регламентированного запроса СМЭВ QL
GET /regulated-query
URL
http://localhost:8080/smevql/api/v1/regulated-query
Параметр |
Тип данных |
Описание |
Примечание |
|---|---|---|---|
mnemonic |
string |
мнемоника системы |
|
credentials |
object |
Объект, содержащий общие данные запроса и информация о потребителе |
|
request |
object |
Объект описывает общие параметры запроса |
|
signature |
object |
Объект, описывает параметры ЭЦП |
Пример запроса:
curl --location 'http://localhost:8080/smevql/api/v1/regulated-query' \
--header 'Request-Timeout: 5' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
"mnemonic": "test_query",
"majorVersion": 1,
"minorVersion": 1,
"params": {
"month": 1,
"name": "test_name"
},
"credentials": {
"system": {
"mnemonic": "string",
"instance_id": "string",
"user_id": "string"
},
"request": {
"id": "string",
"sub_id": "string",
"name": "string",
"purpose_id": "string",
"audit": true,
"audit_id": "string",
"audit_token": "string"
},
"signature": {
"digest": "string",
"signature": "string"
}
}
}'
Пример ответа:
{
"response": {
"referral": [
{
"to_post_name": "врач-терапевт участковый",
"end_date": null,
"speciality_id": "119",
"to_mo_id": "325",
"mo": [
{
"id": "325",
"name": "ГКБ 222; Кардиология"
}
]
}
]
}
}
2.2.6.6. Ошибки
Ошибки выводятся в блоке response:
{
"response": {
"errors": [
{
"error": "Запрещен вывод атрибутов без переданного guard",
"code": "401"
}
]
},
"credentials": {
}
}
2.2.6.6.1. Базовые ошибки СМЭВ Ql
1ХХ Ошибки разбора запроса
101 Запрос не должен называться „errors“ — Неправильное название запроса „errors“
2ХХ Ошибки модели
201 Неизвестный атрибут — У ресурса не найден атрибут с соотв. именем
202 Неизвестный ресурс — Ресурс с соотв. именем не зарегистрирован в модели данных
203 Неизвестная связь — Не найдена связь между двумя ресурсами
204 Неправильная связь — Размеры ключей не соответствуют для соединения одного ресурса с другим
3ХХ Ошибки источников
301 Неизвестный источник — Не найдено описание источника данных с соотв. именем
302 Неизвестный адаптер — Не найден адаптер с соотв. именем
4ХХ Ошибки доступов и ограничений
401 Запрещен вывод атрибутов без переданного guard — Среди запрашиваемых атрибутов есть атрибут с невыполненными ограничениями в блоке guard (не переданы в запросе атрибуты из guard)
402 Недостаточно атрибутов для выбора источника — Среди атрибутов фильтрации нет атрибутов, необходимых для выбора источника
403 Запрещенные атрибуты для поиска — Среди атрибутов фильтрации есть атрибуты, указанные в блоке denied модели
404 Атрибуты для поиска не разрешены — Среди атрибутов фильтрации есть атрибуты, которые не указаны в разрешающем блоке allowed модели
405 Попытка переопределения фиксированных условий поиска — Среди атрибутов фильтрации есть атрибуты, которые пытаются переопределить фиксированные ограничения поиска в блоке always модели
9ХХ Прочие ошибки
901 Непредвиденная ошибка — Непредвиденная ошибка
2.2.7. Настройка стандартного загрузчика
2.2.7.1. Конфигурация стандартного загрузчика
Все компоненты приложения конфигурируются при помощи файла application.yaml.
Если какой-то компонент не нужен в рамках данного приложения (например необходимость запустить часть компонентов на другой машине), то в настройках указывается enabled: false.
Reader на отдельных JVM (в том числе удаленных) загрузчика могут быть сконфигурированы и связаны с Информационной системой удаленно, через служебную БД.
Такая возможность предусмотрена для случаев отсутствия доступа напрямую поменять конфигурационный файлы приложения на удаленной машине.
Для этого необходимо:
В метаданных загрузчика, с использованием соответствующего REST API (Раздел 2.3.6.5):
создать Deployer, которые будут разворачивать данные Reader;
добавить настройки для Reader (соответствуют секции
readers.[].configобщего файла настройки, без элемента config);создать Reader нужных типов.
Развернуть Deployer с мнемониками из пункта 1 и указанием адреса подключения к основной части загрузчика.
2.2.7.1.1. Пример файла application.yml
В конфигурационном файле следует задавать только те настройки, которые необходимы для решения текущих бизнес-задач.
http-server:
port: ${SERVER_PORT:8081}
metrics:
port: ${METRICS_PORT:9837}
prostore-rest-client:
# В случае если запускается удалённый загрузчик (отсутствует менеджер и/или подключение к локальной БД, из компонент только ридеры)
# то раздел service-database, как и весь prostore-rest-client, не читается, поэтому может быть удалён.
service-database: # простор служебной БД
persistence-datamart: ${PERSISTENCE_DATAMART:persistence}
datasource: ${PERSISTENCE_DATASOURCE:} # по умолчанию пусто, тогда берется единственный датасорс из настроек Простора
host: ${PS_HOST:localhost}
port: ${PS_PORT:9090}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
application-database: # простор прикладной БД
enabled: true
host: ${PS_HOST:localhost}
port: ${PS_PORT:9090}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
spring:
liquibase:
enabled: true
analytics-enabled: false
change-log: classpath:/liquibase-changes/changelog.xml
driver-class-name: ru.datamart.prostore.jdbc.Driver
url: jdbc:prostore://${prostore-rest-client.service-database.host}:${prostore-rest-client.service-database.port}/${prostore-rest-client.service-database.persistence-datamart}
database-change-log-table: loader_changelog
database-change-log-lock-table: loader_changeloglock
liquibase-schema: ${prostore-rest-client.service-database.persistence-datamart}
default-schema: ${prostore-rest-client.service-database.persistence-datamart}
user: ""
password: ""
auth:
mode: DISABLED # STUDIO/DISABLED
studio: # oauth through datamart studio
url: http://localhost/api/v1/auth_system
username: user
password: passwd
organization_ogrn: ogrn
datamart: datamart
manager:
enabled: true
port: ${MANAGER_PORT:8087}
active:
capture-period: ${ACTIVE_CAPTURE_PERIOD:30s} # период захвата и подтверждения активности
time-to-live: ${ACTIVE_TTL:60s} # время жизни флага активности
scheduler:
sync-interval: 15s # Интервал синхронизации информации по расписаниям
active-task-check-interval: 5s # Задержка для опроса активных заданий на предмет их завершения
queue:
max-poll-attempts: 50 # Максимальное количество попыток захвата записи компонентом. Используется только в случае большой конкуренции
check-interval: 1m # Интервал периодической проверки очереди. В случае недоступности компонента задание возвращается в очередь на обработку.
file-merge:
max-file-count: 1 # Максимальное количество файлов, объединяемых в один запрос загрузки
max-data-size: 100MB
components:
period-send: 60s # Интервал периодической отправки сведений о компонентах deployer
health-check:
publish-period: 1m # Период публикации health check
timeout-active: 5m # Период после которого компонент считается неактивным при отсутствии health-check
cleanup-period: 10m # Период выполнения очистки
retention:
session: 5d # Период хранения сведений о сеансах загрузки
event: 5d # Период хранения событий загрузки
cleanup-period: 1h # Период выполнения очистки
flk:
# Режим ФЛК проверок по умолчанию. Используется, если не переопределен для конкретной таблицы
# Допустимые значения off / warning / skip_string / skip_on_first_error / skip_file / skip_string_except_last
mode: warning
# datamarts: # определяет flk для конкретных датамартов и таблиц
# region777:
# tickets: skip_string
fifo:
enabled: false # Признак включения упорядоченной загрузки. Используется, если не переопределен для конкретной таблицы
# datamarts:
# region777: # определяет fifo для конкретных датамартов и таблиц
# tickets: false
# region36:
# passengers: false
# cars: false
buffer:
enabled: true
port: 9090
retention:
retention-period: 0s # Интервал хранения данных. 0 или отрицательное значение - без ограничений
cleanup-period: 10m # Интервал проведения очистки данных (проверка по retention-period, а так же отложенное удаление файлов)
delayed-deletion: { } # Настройки отложенного удаления. В качестве ключа - код завершения сеанса, значение - интервал, в течении которого выполняется хранение файла
# delayed-deletion:
# 300: 0s
# 301: 1d
data-storage: # файловое хранилище
type: ${DATA_STORAGE_TYPE:dir} # redis|dir|s3|prostore
dir: ${DATA_STORAGE_DIR:/upload/data} # Директория хранения файлов для типа dir
s3:
endpoint: ${S3_ENDPOINT:http://127.0.0.1:9000/}
bucket: ${S3_BUCKET:data} # Имя бакета
region: ${S3_REGION:us-west-2}
access-key: ${S3_USER:minioadmin} # Пользователь, под которым происходит взаимодействие с s3
secret-key: ${S3_PASSWORD:minioadmin} # Пароль пользователя для взаимодействия с s3
chunk-size: 5MB
redis: #клиент к Редису
type: ${REDIS_TYPE:STANDALONE}
connection-string: ${REDIS_CONNECTION_STRING:redis://localhost:6379}
password: ${REDIS_PASSWORD:eYVX7EwVmmxKPCDmwMtyKVge8oLd2t81}
max-pool-size: ${REDIS_MAX_POOL_SIZE:6}
max-pool-waiting: ${REDIS_MAX_POOL_WAITING:24}
max-waiting-handlers: ${REDIS_MAX_WAITING_HANDLERS:32}
net-client-options:
tcp-user-timeout-duration: 30s
idle-timeout-duration: 30s
flk: # для rest endpoint используется общий http порт
enabled: true
cleanup-period: 1h
stream:
avro-codec: zstd # zstd/none
# Предельный размер отчета ФЛК, ограничение нужно чтобы не выйти за ограничение heap при формировании отчета в памяти.
# При срабатывании предела в лог приложения выдается предупреждение. Получив отчет лимитированной длины, клиент должен
# понимать что получил не весь отчет об ошибках. При увеличении этого параметра необходимо внимательно следить за утилизацией
# памяти приложения. Размер отчета считается в числе записей, значение <=0 означает неограниченный отчет, такая настройка
# опасна падением приложения по OutOfMemory.
report-max-length: 10_000
conditions:
validation:
validation-timeout: 1h # Тайм-аут выполнения асинхронной проверки
concurrency: 1 # Количество корутин асинхронной валидации
uploader:
enabled: true
check-uniqueness: true # выполнять ли проверку уникальности первичных ключей для операций upload, modify
preferred-mode: ${UPLOAD_MODE:stream} # stream|llw Режим загрузки в prostore
concurrency: ${UPLOAD_CONCURRENCY:100} # Общее количество параллельных задач загрузки
limit:
row-max-count: 500_000
llw:
batch: ${UPLOAD_LLW_BATCH:1000} # Число записей в одной команде upsert/delete в случае llw загрузки.
stream:
batch: ${UPLOAD_STREAM_BATCH:10000} # Число записей в одной команде upsert/delete в случае потоковой загрузки частями.
comparator: # для rest endpoint используется общий http порт
enabled: true
leader:
capture-period: ${ACTIVE_CAPTURE_PERIOD:30s} # период захвата и подтверждения активности
time-to-live: ${ACTIVE_TTL:60s} # время жизни флага активности
queue:
poll-delay: 5s # Интервал тайм-аута (long-polling) получения сообщения из очереди
component-health-check-timeout: 5m # Период после которого компонент считается неактивным при отсутствии health-check
check-period: 1m # Интервал периодической проверки очереди. В случае недоступности компонента задание возвращается в очередь на обработку.
scheduler:
sync-interval: 15s # Интервал синхронизации информации по расписаниям
upload:
poll-delay: 5s # Периодичность опроса активных сеансов загрузки hash данных на предмет завершения
timeout: 1d # Тайм-аут завершения сеансов загрузки hash данных таблиц
correction:
poll-delay: 5s # Периодичность опроса активных сеансов корректирующих загрузок на предмет завершения
timeout: 1d # Тайм-аут завершения сеансов корректирующих загрузок
batch-size: 100 # Размер порции нарезаемых данных для корректирующих загрузок
concurrency: # Ограничения на количество одновременно выполняемых сеансов сверок. Значение <= 0 - без ограничений
upload: 0
awaiting-upload: 0
comparison: 0
stable-differences: 0
correction-exception: 0
correction: 0
retention:
session: 5d # Период хранения сведений о сеансах сверок
event: 5d # Период хранения сведений о событиях сверок
correction-attempt: 5d # Период хранения сведений о попытках корректировок
cleanup-period: 10m # Период выполнения очистки
deployer:
enabled: true
mnemonic: deployer # Уникальный идентификатор деплойера в рамках manager
config-priority: database # database/config
readers: [ ]
# - mnemonic: push-reader # Уникальный идентификатор в рамках manager
# enabled: true
# data-flow-type: push
# source-type: rest # jdbc | rest | folder
# is-mnemonic: local
# config:
# file-size:
# restriction: ${SEND_FILE_SIZE_RESTRICTION:512MB}
# rest-timeout: ${REST_TIMEOUT:60s} # Таймаут обработки запроса. 0 - таймаут отключен
# stream:
# avro-codec: zstd # zstd/none
# validation:
# charset-check-enabled: true # признак выполнения проверки кодировки
# valid-charsets: [ UTF-8, US-ASCII, TIS-620 ] # допустимые кодировки для механизма автоопределения
# # Предельный размер отчета синхронной проверки, ограничение нужно чтобы не выйти за ограничение heap
# # при формировании отчета в памяти. При срабатывании предела в лог приложения выдается предупреждение.
# # Получив отчет лимитированной длины, клиент должен понимать что получил не весь отчет об ошибках. При увеличении
# # этого параметра необходимо внимательно следить за утилизацией памяти приложения. Размер отчета считается в числе
# # записей, значение <=0 означает неограниченный отчет, такая настройка опасна падением приложения по OutOfMemory.
# report-max-length: 10_000
# csv-parser:
# # Символ разделителя значений
# separator: ${CSV_PARSER_SEPARATOR:;}
# # Символ кавычки
# quote-char: ${CSV_PARSER_QUOTE_CHAR:"}
# # Символ экранирования значений
# escape-char: ${CSV_PARSER_ESCAPE_CHAR:'}
# # Настройка интерпретации значений как null. Допустимые значения:
# # - EMPTY_SEPARATORS - пустое значение между двумя разделителями, например ;;
# # - EMPTY_QUOTES - пустые кавычки, например ;"";
# # - BOTH - оба варианта
# # - NEITHER - никогда. Пустая строка всегда определяется как пустая строка
# field-as-null: ${CSV_PARSER_FIELD_AS_NULL:EMPTY_SEPARATORS}
dtm-facade: # Компонент поддержки интерфейса dtm-uploader
enabled: true
upload:
host: localhost # Хост доступа к компоненту reader-rest-push
port: 8081 # Порт доступа к компоненту reader-rest-push
datamart: dtm # Датамарт загрузки данных
timeout: 5m # Тайм-аут сеансов загрузки, после которого операция считается невалидной
poll-delay: 1s # Периодичность опроса статусов сеансов загрузки
batch-size: 100MB # Размер пачки данных, загружаемых через метод /data
cleanup-period: 10m # Периодичность выполнения очистки сведений по запросам
retention-period: 3d # Период хранения сведений о загрузках
blob-adapter:
host: blob-adapter # Хост сервиса работы с вложениями - blob-adapter
port: 8081 # Порт сервиса работы с вложениями - blob-adapter
# клиенты
manager-client:
host: 127.0.0.1
port: 8087
buffer-client:
host: 127.0.0.1
port: 9090
chunk-size: 5MB
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# Массив датасорсов Prostore, которые нужно использовать для хранения данных персистености
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается неактивным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- buffer.data-storage.redis.password
- buffer.data-storage.s3.secret-key
- auth.studio.password
retry: # блок настроек повторения операций в случае ошибок
default:
attempts: 3
delay: 5s
manager-client:
attempts: -1 # Отрицательное значение означает без ограничений
delay: 5s
service-db:
attempts: -1
delay: 5s
grpc:
client:
max-inbound-message-size: 10MB
server:
max-inbound-message-size: 10MB
2.2.7.2. Параметры конфигурации
Настройка конфигурации стандартного загрузчика осуществляется путем редактирования параметров настроек в файле application.yml,
где настраиваются секции:
http-server- указывается порт сервера;metrics- настройка получения метрик;prostore-rest-client- блок параметров конфигурирования взаимодействия с Prostore;spring- параметры для определения наименований служебных таблиц liquibase;auth- настройки авторизации через сервис «Студия»;manager- управление процессом загрузки;buffer- настройки сервиса Buffer;flk- настройки сервиса ФЛК;uploader- настройки сервиса Uploader;comparator- настройки сервиса Comparator;deployerнастройки развертывания экземпляров компонентов стандартного загрузчика (кроме manager);dtm-facade- сервис поддержки интерфейса dtm-uploader;manager-client- настройки подключения к сервису Manager;buffer-client- настройки подключения к сервису Buffer;component-info- настройки модуля сбора информации о компонентах витрины;retry- блок настроек повторения операций в случае ошибок;grpc- настройки передачи сообщений по протоколу gRPC.
2.2.7.2.1. Секция http-server
В секции http-server указывается порт веб-сервера.
Например:
http-server:
port: ${SERVER_PORT:8081}
Параметры настроек
port- порт веб-сервера, например:SERVER_PORT:8081.
2.2.7.2.2. Секция metrics
Секция metrics предназначена для настройки параметров метрик.
Например:
metrics:
port: ${METRICS_PORT:9837}
Параметры настроек
port- порт для метрик, напримерMETRICS_PORT:9837.
2.2.7.2.3. Секция prostore-rest-client
В секции prostore-rest-client реализован блок параметров конфигурирования взаимодействия с Prostore.
Например:
prostore-rest-client:
service-database:
persistence-datamart: ${PERSISTENCE_DATAMART:persistence}
datasource: ${PERSISTENCE_DATASOURCE:}
host: ${PS_HOST:localhost}
port: ${PS_PORT:9090}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
application-database: # простор прикладной БД
enabled: true
host: ${PS_HOST:localhost}
port: ${PS_PORT:9090}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
Параметры настроек
service-database- Prostore служебной БД;persistence-datamart- датамарт, где будут располагаться таблицы хранения данных, напримерPERSISTENCE_DATAMART:persistence;datasource- массив датасорсов типа ADP;application-database- Prostore прикладной БД;host- адрес Prostore, напримерPS_HOST:localhost;port- порт Prostore, напримерPS_PORT:9090;max-pool-size- максимальное число подключений к Prostore, напримерPS_MAX_POOL_SIZE:8.
2.2.7.2.4. Секция spring
В секции spring указываются параметры для определения наименований служебных таблиц liquibase.
Например:
spring:
liquibase:
enabled: true
analytics-enabled: false
change-log: classpath:/liquibase-changes/changelog.xml
driver-class-name: ru.datamart.prostore.jdbc.Driver
url: jdbc:prostore://${prostore-rest-client.service-database.host}:${prostore-rest-client.service-database.port}/${prostore-rest-client.service-database.persistence-datamart}
database-change-log-table: loader_changelog
database-change-log-lock-table: loader_changeloglock
liquibase-schema: ${prostore-rest-client.service-database.persistence-datamart}
default-schema: ${prostore-rest-client.service-database.persistence-datamart}
user: ""
password: ""
Параметры настроек
enabled- признак включения/отключения миграций;analytics-enabled- флаг подключения статистики;change-log- путь к файлам миграций, которые находятся внутри jar;driver-class-name- имя JDBC-драйвера Prostore. Константа, без переопределения.url- адрес подключения к простору в формате JDBC. Переопределять не потребуется, конструируется из параметров подключения к Prostore.database-change-log-table- имя таблицы хранения истории выполненных миграций;database-change-log-lock-table- имя таблицы для блокировок, константа;liquibase-schema- имя датамарта, в которой распалагаются 2 таблицы (database-change-log-table, database-change-log-lock-table)default-schema- имя датамарта для системных таблиц. Так же заполняется из блока конфигурации Prostore.user- имя пользователя Prostore;password- пароль пользователя Prostore.
2.2.7.2.5. Секция auth
В секции auth указываются настройки авторизации через сервис «Студия».
Например:
auth:
mode: DISABLED
studio: # oauth through datamart studio
url: http://localhost/api/v1/auth_system
username: user
password: passwd
organization_ogrn: ogrn
datamart: datamart
Параметры настроек
mode- подключение авторизации через сервис, например:DISABLED;url- метод авторизации;username- имя пользователя, напримерuser;password- пароль пользователя, напримерpasswd;organization_ogrn- ОГРН организации пользователя;datamart- имя таблицы.
2.2.7.2.6. Секция manager
В секции manager указываются настройки управления процессом згрузки.
Например:
manager:
enabled: true
port: ${MANAGER_PORT:8087}
active:
capture-period: ${ACTIVE_CAPTURE_PERIOD:30s} # период захвата и подтверждения активности
time-to-live: ${ACTIVE_TTL:60s} # время жизни флага активности
scheduler:
sync-interval: 15s # Интервал синхронизации информации по расписаниям
active-task-check-interval: 5s # Задержка для опроса активных заданий на предмет их завершения
queue:
max-poll-attempts: 50 # Максимальное количество попыток захвата записи компонентом. Используется только в случае большой конкуренции
check-interval: 1m # Интервал периодической проверки очереди. В случае недоступности компонента задание возвращается в очередь на обработку.
file-merge:
max-file-count: 1 # Максимальное количество файлов, объединяемых в один запрос загрузки
max-data-size: 100MB
components:
period-send: 60s # Интервал периодической отправки сведений о компонентах deployer
health-check:
publish-period: 1m # Период публикации health check
timeout-active: 5m # Период после которого компонент считается неактивным при отсутствии health-check
cleanup-period: 10m # Период выполнения очистки
retention:
session: 5d # Период хранения сведений о сеансах загрузки
event: 5d # Период хранения событий загрузки
cleanup-period: 1h # Период выполнения очистки
flk:
# Режим ФЛК проверок по умолчанию. Используется, если не переопределен для конкретной таблицы
# Допустимые значения off / warning / skip_string / skip_on_first_error / skip_file / skip_string_except_last
mode: warning
# datamarts: # определяет flk для конкретных датамартов и таблиц
# region777:
# tickets: skip_string
fifo:
enabled: false # Признак включения упорядоченной загрузки. Используется, если не переопределен для конкретной таблицы
# datamarts:
# region777: # определяет fifo для конкретных датамартов и таблиц
# tickets: false
# region36:
# passengers: false
# cars: false
Параметры настроек
enabled- состояние менеджера (вкл/выкл);port- порт подключения, например:SERVER_PORT:8081;active- настройки активности менеджера;capture-period- период захвата и подтверждения активности, напримерACTIVE_CAPTURE_PERIOD:30s;time-to-live- время жизни флага активности, напримерAACTIVE_TTL:60s;scheduler- настройки планировщика;sync-interval- интервал синхронизации информации по расписаниям, например15s;active-task-check-interval- Задержка для опроса активных заданий на предмет их завершения, например5s;queue- настройки очереди;max-poll-attempts- максимальное число попыток, например50;check-interval- временной интервал проверки, например1m;file-merge- настройки файлов, объединяемых в один запрос загрузки;max-file-count- максимальное количество файлов, объединяемых в один запрос загрузки, например1;max-data-size- максимальный размер файла с данными, например100MB;components- настройки рассылки состава компонента Deployer;period-send- период отправки, например60s;health-check- настройки health-check, например;publish-period- период публикации health-check, например1m;timeout-active- период после которого компонент считается неактивным при отсутствии health-check, например5m;cleanup-period- период выполнения очистки, например10m;retention- настройки хранения;session- период хранения сведений о сеансах загрузки, например5d;event- период хранения событий загрузки, например5d;cleanup-period- период выполнения очистки, например1h;flk- настройки форматно-логического контроля$mode- режим настройки ФЛК, например:warning. Описание режимов приведено в Раздел 2.3.6.3.1.3.1;fifo- указывается принцип организации данных, при котором первый элемент, поступивший в очередь, обрабатывается или извлекается первым;enabled- состояние FIFO (вкл/выкл).
Примечание
Параллельная загрузка данных в снапшот-таблицы выполняется, если для таблицы отключена упорядоченная загрузка (если fifo.enabled: false в конфигурации или fifo.enabled: true, но значение переопределено для конкретной таблицы)
2.2.7.2.7. Секция buffer
В секции buffer - содержатся настройки сервиса Buffer.
buffer:
enabled: true
port: 9090
retention:
retention-period: 0s # Интервал хранения данных. 0 или отрицательное значение - без ограничений
cleanup-period: 10m # Интервал проведения очистки данных (проверка по retention-period, а так же отложенное удаление файлов)
delayed-deletion: { } # Настройки отложенного удаления. В качестве ключа - код завершения сеанса, значение - интервал, в течении которого выполняется хранение файла
# delayed-deletion:
# 300: 0s
# 301: 1d
data-storage: # файловое хранилище
type: ${DATA_STORAGE_TYPE:dir} # redis|dir|s3|prostore
dir: ${DATA_STORAGE_DIR:/upload/data} # Директория хранения файлов для типа dir
s3:
endpoint: ${S3_ENDPOINT:http://127.0.0.1:9000/}
bucket: ${S3_BUCKET:data} # Имя бакета
region: ${S3_REGION:us-west-2}
access-key: ${S3_USER:minioadmin} # Пользователь, под которым происходит взаимодействие с s3
secret-key: ${S3_PASSWORD:minioadmin} # Пароль пользователя для взаимодействия с s3
chunk-size: 5MB
redis: #клиент к Редису
type: ${REDIS_TYPE:STANDALONE}
connection-string: ${REDIS_CONNECTION_STRING:redis://localhost:6379}
password: ${REDIS_PASSWORD:eYVX7EwVmmxKPCDmwMtyKVge8oLd2t81}
max-pool-size: ${REDIS_MAX_POOL_SIZE:6}
max-pool-waiting: ${REDIS_MAX_POOL_WAITING:24}
max-waiting-handlers: ${REDIS_MAX_WAITING_HANDLERS:32}
net-client-options:
tcp-user-timeout-duration: 30s
idle-timeout-duration: 30s
Параметры настроек
enabled- флаг подключения сервиса, напримерtrue;port- порт подключения сервиса, например9090;retention- настройки хранения;retention-period- интервал хранения данных. 0 или отрицательное значение - без ограничений;cleanup-period- период выполнения очистки, например10m;delayed-deletion- Настройки отложенного удаления. В качестве ключа - код завершения сеанса, значение - интервал, в течении которого выполняется хранение файла;data-storage- файловое хранилище;type- тип хранилища, напримерDATA_STORAGE_TYPE:dir(возможные значения: redis / dir / s3);dir- директория хранения файлов для типа dir, напримерDATA_STORAGE_DIR:/upload/data;endpoint- адрес конечной точки, напримерS3_ENDPOINT:http://127.0.0.1:9000/;bucket- имя бакета, напримерS3_BUCKET:dataregion- регион хранилища;access-key- пользователь, под которым происходит взаимодействие с s3, напримерS3_USER:minioadmin;secret-key- пароль пользователя для взаимодействия с s3, напримерS3_PASSWORD:minioadmin;chunk-size- размер чанка, например5MB;type- тип подключения к Redis (STANDALONE/CLUSTER), напримерREDIS_TYPE:STANDALONE;connection-string- указывается список серверов для подключения (перечисление через запятую), напримерREDIS_CONNECTION_STRING:redis://localhost:6379;password- пароль для подключения, напримерREDIS_PASSWORD:eYVX7EwVmmxKPCDmwMtyKVge8oLd2t81;max-pool-size- устанавливается максимальный размер пула, напримерREDIS_MAX_POOL_SIZE:6;max-pool-waiting- устанавливается максимальный размер пула ожидающих команд, напримерREDIS_MAX_POOL_WAITING:24;max-waiting-handlers- устанавливается максимальный размер ожидающих обработчиков, напримерREDIS_MAX_WAITING_HANDLERS:32;net-client-options- параметры Redis клиента:tcp-user-timeout-duration- таймаут на соединение;idle-timeout-duration- таймаут ожидания ответа от Redis.
2.2.7.2.8. Секция flk
В секции flk - содержатся настройки ФЛК.
flk: # для rest endpoint используется общий http порт
enabled: true
cleanup-period: 1h
stream:
avro-codec: zstd # zstd/none
# Предельный размер отчета ФЛК, ограничение нужно чтобы не выйти за ограничение heap при формировании отчета в памяти.
# При срабатывании предела в лог приложения выдается предупреждение. Получив отчет лимитированной длины, клиент должен
# понимать что получил не весь отчет об ошибках. При увеличении этого параметра необходимо внимательно следить за утилизацией
# памяти приложения. Размер отчета считается в числе записей, значение <=0 означает неограниченный отчет, такая настройка
# опасна падением приложения по OutOfMemory.
report-max-length: 10_000
conditions:
validation:
validation-timeout: 1h # Тайм-аут выполнения асинхронной проверки
concurrency: 1 # Количество корутин асинхронной валидации
Параметры настроек
enabled- флаг подключения сервиса, напримерtrue;cleanup-period- период очистки, например1h;avro-codec- выбор авро-кодека, напримерzstd;report-max-length- максимальная длина отчета, например10_000;validation-timeout- тайм-аут выполнения асинхронной проверки, например1h;concurrency- количество корутин асинхронной валидации, например1.
2.2.7.2.9. Секция uploader
В секции uploader - содержатся настройки сервиса Uploader.
uploader:
enabled: true
check-uniqueness: true # выполнять ли проверку уникальности первичных ключей для операций upload, modify
preferred-mode: ${UPLOAD_MODE:stream} # stream|llw Режим загрузки в prostore
concurrency: ${UPLOAD_CONCURRENCY:100} # Общее количество параллельных задач загрузки
limit:
row-max-count: 500_000
llw:
batch: ${UPLOAD_LLW_BATCH:1000} # Число записей в одной команде upsert/delete в случае llw загрузки.
stream:
batch: ${UPLOAD_STREAM_BATCH:10000} # Число записей в одной команде upsert/delete в случае потоковой загрузки частями.
Параметры настроек
enabled- флаг подключения сервиса, напримерtrue;check-uniqueness- выполнять ли проверку уникальности первичных ключей для операций upload,modify;preferred-mode- режим загрузки в Prostore (stream или llw);concurrency- общее количество параллельных задач загрузки;row-max-count- лимит на максимальное число, например500_000;batch- число записей в одной команде upsert/delete в случае llw загрузки или потоковой загрузки частями.batch- число записей в одной команде upsert/delete в случае ;
2.2.7.2.10. Секция comparator
В секции comparator - содержатся настройки сервиса Comparator.
comparator: # для rest endpoint используется общий http порт
enabled: true
leader:
capture-period: ${ACTIVE_CAPTURE_PERIOD:30s} # период захвата и подтверждения активности
time-to-live: ${ACTIVE_TTL:60s} # время жизни флага активности
queue:
poll-delay: 5s # Интервал тайм-аута (long-polling) получения сообщения из очереди
component-health-check-timeout: 5m # Период после которого компонент считается неактивным при отсутствии health-check
check-period: 1m # Интервал периодической проверки очереди. В случае недоступности компонента задание возвращается в очередь на обработку.
scheduler:
sync-interval: 15s # Интервал синхронизации информации по расписаниям
upload:
poll-delay: 5s # Периодичность опроса активных сеансов загрузки hash данных на предмет завершения
timeout: 1d # Тайм-аут завершения сеансов загрузки hash данных таблиц
correction:
poll-delay: 5s # Периодичность опроса активных сеансов корректирующих загрузок на предмет завершения
timeout: 1d # Тайм-аут завершения сеансов корректирующих загрузок
batch-size: 100 # Размер порции нарезаемых данных для корректирующих загрузок
concurrency: # Ограничения на количество одновременно выполняемых сеансов сверок. Значение <= 0 - без ограничений
upload: 0
awaiting-upload: 0
comparison: 0
stable-differences: 0
correction-exception: 0
correction: 0
retention:
session: 5d # Период хранения сведений о сеансах сверок
event: 5d # Период хранения сведений о событиях сверок
correction-attempt: 5d # Период хранения сведений о попытках корректировок
cleanup-period: 10m # Период выполнения очистки
Параметры настроек
enabled- флаг подключения сервиса, напримерtrue;capture-period- период захвата и подтверждения активности, напримерACTIVE_CAPTURE_PERIOD:30s;time-to-live- время жизни флага активности, напримерACTIVE_TTL:60s;poll-delay- интервал тайм-аута (long-polling) получения сообщения из очереди, например5s;component-health-check-timeout- период после которого компонент считается неактивным при отсутствии health-check, например5m;check-period- интервал периодической проверки очереди. В случае недоступности компонента задание возвращается в очередь на обработку, например1m;sync-interval- интервал синхронизации информации по расписаниям, например1s;poll-delay- дляuploadпериодичность опроса активных сеансов загрузки hash данных на предмет завершения, например5s;timeout- дляuploadтайм-аут завершения сеансов загрузки hash данных таблиц, например1d;poll-delay- дляcorrectionопроса активных сеансов корректирующих загрузок на предмет завершения, например5s;timeout- дляcorrectionзавершения сеансов корректирующих загрузок, например1d;batch-size- размер порции нарезаемых данных для корректирующих загрузок, например100;concurrency- ограничения на количество одновременно выполняемых сеансов сверок. Значение <= 0 - без ограничений;poll-delay- периодичность опроса активных сеансов загрузки hash данных на предмет завершения, например5s;retention- настройки хранения;session- период хранения сведений о сеансах загрузки, например5d;event- период хранения событий загрузки, например5d;correction-attempt- период хранения сведений о попытках корректировок, например5d;cleanup-period- период выполнения очистки, например1h.
2.2.7.2.11. Секция deployer
В секции deployer расположены настройки развертывания экземпляров компонентов стандартного загрузчика (кроме manager).
Например:
deployer:
enabled: true
mnemonic: deployer # Уникальный идентификатор деплойера в рамках manager
config-priority: database # database/config
Параметры настроек
enabled- состояние (вкл/выкл);mnemonic- уникальный идентификатор деплойера в рамках manager, например135;config-priority- , напримерdatabase.
2.2.7.2.12. Секция dtm-facade
В секции dtm-facade расположены настройки сервиса поддержки интерфейса dtm-uploader.
Например:
dtm-facade: # Компонент поддержки интерфейса dtm-uploader
enabled: true
upload:
host: localhost # Хост доступа к компоненту reader-rest-push
port: 8081 # Порт доступа к компоненту reader-rest-push
datamart: dtm # Датамарт загрузки данных
timeout: 5m # Тайм-аут сеансов загрузки, после которого операция считается невалидной
poll-delay: 1s # Периодичность опроса статусов сеансов загрузки
batch-size: 100MB # Размер пачки данных, загружаемых через метод /data
cleanup-period: 10m # Периодичность выполнения очистки сведений по запросам
retention-period: 3d # Период хранения сведений о загрузках
blob-adapter:
host: blob-adapter # Хост сервиса работы с вложениями - blob-adapter
port: 8081 # Порт сервиса работы с вложениями - blob-adapter
Параметры настроек
enabled- состояние (вкл/выкл);host- дляuploadхост доступа к компоненту reader-rest-push, напримерlocalhost;port- дляuploadпорт доступа к компоненту reader-rest-push, например8081;datamart- дляuploadдатамарт загрузки данных, напримерdtm;timeout- дляuploadтайм-аут сеансов загрузки, после которого операция считается невалидной, например5m;poll-delay- дляuploadпериодичность опроса статусов сеансов загрузки, например1s;batch-size- дляuploadразмер пачки данных, загружаемых через метод /data, например100MB;cleanup-period- дляuploadпериодичность выполнения очистки сведений по запросам, например10m;retention-period- дляuploadпериод хранения сведений о загрузках, например3d;host- дляblob-adapterхост сервиса работы с вложениями - blob-adapter, напримерblob-adapter;port- дляuploadпорт сервиса работы с вложениями - blob-adapter, например8081;
2.2.7.2.13. Секция manager-client
В секции manager-client содержит настройки подключения к сервису Manager.
Например:
manager-client:
host: 127.0.0.1
port: 8087
Параметры настроек
host- хост к сервису Manager, например127.0.0.1;port- порт к сервису Manager, например8087.
2.2.7.2.14. Секция buffer-client
В секции buffer-client содержит настройки подключения к сервису Buffer.
Например:
buffer-client:
host: 127.0.0.1
port: 9090
chunk-size: 5MB
Параметры настроек
host- хост к сервису Manager, например127.0.0.1;port- порт к сервису Manager, например8087;chunk-size- размер чанков, например5MB.
2.2.7.2.15. Секция component-info
В секции component-info хранятся настройки компонента сбора информации о компонентах витрины.
Например:
component-info:
enabled: true
# Массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается неактивным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- buffer.data-storage.redis.password
- buffer.data-storage.s3.secret-key
- auth.studio.password
Параметры настроек
enabled- статус подключения компонента, указывается булево значение;datasource- массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте;datamart- схема Prostore;table-name- имя таблицы для записи информации о компоненте;create-table-period- период попыток создания схемы, при неуспехе, указывается в секундах;publish-period- период публикации health-check, указывается в секундах;timeout-active- период после которого компонент считается неактивным при отсутствии health-check, указывается в секундах;secrets- список элементов конфига маскируемых при отправке, если указан узловой элемент, то маскируются все вложенные в него элементы.
2.2.7.2.16. Секция retry
В секции retry располгается блок настроек повторения операций в случае ошибок.
Например:
retry: # блок настроек повторения операций в случае ошибок
default:
attempts: 3
delay: 5s
manager-client:
attempts: -1
delay: 5s
service-db:
attempts: -1
delay: 5s
Параметры настроек
default- настройки для подключения по умолчанию;manager-client- настройки для подключения к Manager;service-db- настройки для подключения к служебной БД;attempts- количество попыток подключения, отрицательное значение означает без ограничений;delay- время между попытками подключения.
2.2.7.2.17. Секция grpc
В секции grpc содержатся настройки передачи сообщений по протоколу gRPC.
Например:
grpc:
client:
max-inbound-message-size: 10MB
server:
max-inbound-message-size: 10MB
Параметры настроек
max-inbound-message-sizeдляclient- максимальный размер сообщения по протоколу gRPC на стороне клиента;max-inbound-message-sizeдляserver- максимальный размер сообщения по протоколу gRPC на стороне сервера.
2.2.8. Настройка BLOB-адаптера
2.2.8.1. Конфигурация BLOB-адаптера (application.yml)
Файл application.yml – основной конфигурационный файл BLOB-адаптера, в котором задана логика и порядок работы модуля:
получение и обработка входящих запросов;
настройка подключения к СМЭВ3-адаптеру, СМЭВ4-адаптеру и Хранилищу BLOB-объектов, и другие настройки необходимые для корректной работы модуля.
2.2.8.1.1. Пример файла application.yml
В конфигурационном файле следует задавать только те настройки, которые необходимы для решения текущих бизнес-задач.
http-server:
enabled: ${SERVER_ENABLED:true}
port: ${SERVER_PORT:8081}
metrics:
port: ${METRICS_PORT:9837}
executor:
reader-pool-size: ${EXECUTOR_READER_POOL_SIZE:20}
blob-storage:
protocol: ${BLOB_STORAGE_PROTOCOL:http}
host: ${BLOB_STORAGE_HOST:t5-blob-adapter-01.ru-central1.internal}
port: ${BLOB_STORAGE_PORT:9000}
path-prefix: ${BLOB_STORAGE_PATH_PREFIX:test/image}
path-postfix: ${BLOB_STORAGE_PATH_POSTFIX:}
auth:
type: ${BLOB_STORAGE_AUTH_TYPE:AUTH}
user: ${BLOB_STORAGE_AUTH_USER:}
password: ${BLOB_STORAGE_AUTH_PASSWORD:}
token: ${BLOB_STORAGE_AUTH_TOKEN:}
authorization-server:
protocol: ${AUTH_SERVER_PROTOCOL:http}
host: ${AUTH_SERVER_HOST:t5-avanpost-01.ru-central1.internal}
port: ${AUTH_SERVER_PORT:80}
path: ${AUTH_SERVER_PATH:oauth2/token}
client-id: ${AUTH_SERVER_CLIENT_ID:b0fd0f28-4b99-40d7-8dd3-e663a6cc77d1}
client-secret: ${AUTH_SERVER_CLIENT_SECRET:Zaq1sd!sa2}
logging:
request-response:
blob-request: ${BLOB_REQUEST_LOG_ENABLED:false}
blob-response: ${BLOB_RESPONSE_LOG_ENABLED:false}
2.2.8.2. Параметры конфигурации
Настройка конфигурации BLOB-адаптера осуществляется путем редактирования параметров настроек в файле application.yml,
где настраиваются секции:
http-server- указывается порт сервера;metrics- настраивается получение метрикexecutor- настраивается размер пула для запросов;blob-storage- настраивается подключение к Хранилищу BLOB-объектов;logging- настраивается логирование работы модуля.
2.2.8.2.1. Секция http-server
Секция http-server позволяет настраивать взаимодействие с BLOB-объектами через модуль СМЭВ3-адаптер по
протоколу HTTP/HTTPS и задавать порт, на котором будет открыт доступ к серверу.
Например:
http-server:
enabled: ${SERVER_ENABLED:true}
port: ${SERVER_PORT:8081}
enabled- флаг активации работы с сервером;port- порт, на котором будет открыт доступ к серверу.
2.2.8.2.2. Секция metrics
Секция metrics предназначена для настройки параметров метрик.
Например:
metrics:
port: ${METRICS_PORT:9837}
Параметры конфигурации
port- порт для метрик, напримерMETRICS_PORT:9837.
2.2.8.2.3. Секция executor
Секция executor предназначена для масштабирования нагрузки (увеличения / уменьшения) на модуль.
Например:
executor:
reader-pool-size: ${EXECUTOR_READER_POOL_SIZE:20}
Параметры настроек
reader-pool-size- размер пула для чтения Kafka, напримерEXECUTOR_READER_POOL_SIZE:20.
2.2.8.2.4. Секция blob-storage
Секция blob-storage предназначена для настройки:
размера выгружаемого чанка BLOB;
пути к Хранилищу BLOB-объектов (GET-запрос);
метода аутентификации для модуля BLOB-адаптера;
получения токена;
повторной аутентификаций при истечении времени жизни токена.
Например:
blob-storage:
protocol: ${BLOB_STORAGE_PROTOCOL:http}
host: ${BLOB_STORAGE_HOST:t5-blob-adapter-01.ru-central1.internal}
port: ${BLOB_STORAGE_PORT:9000}
path-prefix: ${BLOB_STORAGE_PATH_PREFIX:test/image}
path-postfix: ${BLOB_STORAGE_PATH_POSTFIX:}
auth:
type: ${BLOB_STORAGE_AUTH_TYPE:AUTH}
user: ${BLOB_STORAGE_AUTH_USER:}
password: ${BLOB_STORAGE_AUTH_PASSWORD:}
token: ${BLOB_STORAGE_AUTH_TOKEN:}
authorization-server:
protocol: ${AUTH_SERVER_PROTOCOL:http}
host: ${AUTH_SERVER_HOST:t5-avanpost-01.ru-central1.internal}
port: ${AUTH_SERVER_PORT:80}
path: ${AUTH_SERVER_PATH:oauth2/token}
client-id: ${AUTH_SERVER_CLIENT_ID:b0fd0f28-4b99-40d7-8dd3-e663a6cc77d1}
client-secret: ${AUTH_SERVER_CLIENT_SECRET:Zaq1sd!sa2}
Параметры конфигурации
protocol- протокол обмена с сервером хранилища BLOB-объектов (одно из значений HTTP или HTTPS), напримерBLOB_STORAGE_PROTOCOL:http;host- имя сервера хранилища BLOB-объектов, напримерBLOB_STORAGE_HOST:localhost;port- порт сервера хранилища BLOB-объектов, если отсутствует, то следует использовать следующие порты80для HTTP,443для HTTPS, напримерBLOB_STORAGE_PORT:9000;path-prefix- путь до места хранилища BLOB-объектов, путь до места хранения BLOB-объекта на сервере хранилища BLOB-объектов, напримерBLOB_STORAGE_PATH_POSTFIX:;path-postfix- окончание пути, начало списка параметров, напримерBLOB_STORAGE_PATH_PREFIX:test/image;auth- параметры аутентификации BLOB-адаптера;type- тип аутентификации (NONE- нет,BASIC- по имени/паролю,TOKEN- по токену,AUTH- через сервер аутентификации), напримерBLOB_STORAGE_AUTH_TYPE:AUTH;user- имя пользователя (для аутентификацииBASIC), напримерBLOB_STORAGE_AUTH_USER:;password- пароль (для аутентификацииBASIC), напримерBLOB_STORAGE_AUTH_PASSWORD:;token- токен (для аутентификацииTOKEN), напримерBLOB_STORAGE_AUTH_TOKEN:;protocol- имя протокола HTTP или HTTPS (для аутентификацииAUTH), напримерAUTH_SERVER_PROTOCOL:http;host- строка с IP или FQDN сервера авторизации (для аутентификацииAUTH), напримерAUTH_SERVER_HOST:t5-avanpost-01.ru-central1.internal;port- TCP-порт (для аутентификацииAUTH), напримерAUTH_SERVER_PORT:80;path- путь на сервере (для аутентификацииAUTH), напримерAUTH_SERVER_PATH:oauth2/token;client-id- идентификатор клиента, присвоенный BLOB-адаптеру в сервере авторизации (для аутентификацииAUTH), напримерAUTH_SERVER_CLIENT_ID:AUTH_SERVER_CLIENT_ID:b0fd0f28-4b99-40d7-8dd3-e663a6cc77d1;client-secret- секретный код клиента, присвоенный BLOB-адаптеру в сервере авторизации (для аутентификацииAUTH), напримерAUTH_SERVER_CLIENT_SECRET:Zaq1sd!sa2.
Пример cURL-запроса к серверу аутентификации
cURL (windows)
curl -X POST http://t5-avanpost-01.ru-central1.internal/oauth2/token ^
-H "Accept: application/json"^
-H "Content-type: application/x-www-form-urlencoded"^
--data "grant_type=client_credentials&client_id=b0fd0f28-4b99-40d7-8dd3-e663a6cc77d1&client_secret=Zaq1sd!sa2" ^
-o result.txt ^
--trace-ascii result.log
cURL (linux)
curl --request POST \
--url http://t5-avanpost-01.ru-central1.internal/oauth2/token \
--header 'Accept: application/json' \
--header 'Content-type: application/x-www-form-urlencoded' \
--data 'grant_type=client_credentials&client_id=b0fd0f28-4b99-40d7-8dd3-e663a6cc77d1&client_secret=Zaq1sd!sa2' \
-o result.txt
Пример cURL-запроса к Хранилищу BLOB-объектов
cURL (windows)
curl -X GET http://vmserv1.internal.example.com:8080/datamart/data/v1/blobs/1234567 ^
-H "Authorization: bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJqdGkiOiI5YmQ3MzdjZi05MDNmLTQxZTktYjI5Mi1mZmUwM2QzNDhkNWIiLCJleHAiOjE2NTQxMDI5NDgsImlhdCI6MTY1NDEwMTE0OCwiaXNzIjoiY2VydC5pc3N1ZXIuaG9zdCIsImF1ZCI6IiIsImV4cGlyZXNfaW4iOjE4MDAsImNsaWVudF9pZCI6ImIwZmQwZjI4LTRiOTktNDBkNy04ZGQzLWU2NjNhNmNjNzdkMSJ9.qi8JKlQAdMsK3fTq4H88Z5-FppaUP95OH-rmPtCxEMmlPnyhNCRJe34aKMR5mXVldEzY1clV87-qjWCyPLH_Zkqji1C7aQz7fMbgZixhY2wrQnXAXRfslkRe5Ph3GYYd26GvWOG1xl99AHvfDWIfI1SGcJyd0z_iOl1GbghLvSV38MquZ8ugBdKaDjV-Ww3U_sWlJVO-oF8xjUMYuhOSsCNxhxMng1oVwUdAUbbgoB5ldyoGTbqmbQMYvBmKBT0eZqOR6RnJEAjmfOC9YeWwADKwovFybvGOaQZsjlaoJ2XxpmS79U7UO_6KXK1cnHfshVuB5_yUwubrRh6tRxt0CA"^
-o result.bin ^
--trace-ascii result.log
Пример настройки динамической ссылки на файлы с содержимым BLOB-полей
Пример 1
Если на Витрине данных поле с типом LINK содержит текст 12345678 и для получения содержимого BLOB надо использовать строку вызова:
http://aa.bb.cc:8080/api/v1/blobs/12345678
Настройки файла application.yml должны иметь следующий вид:
blob-storage:
protocol: http
host: aa.bb.cc
port: 8080
path-prefix: api/v1/blobs/
Пример 2
Если на Витрине данных поле с типом LINK содержит текст 12345678 и для получения содержимого BLOB надо использовать строку вызова:
https://aa.bb.cc/api/v1/blobs/12345678/data?format=jpg&size=low&backgraund=#000000,
Настройки файла application.yml должны иметь следующий вид:
blob-storage:
protocol: https
host: aa.bb.cc
path-prefix: api/v1/blobs/
path-postfix: /data
params:
format: jpg
size: low
backgraund: "#000000"
Пример 3
Если на Витрине данных поле с типом LINK содержит текст 12345678 и для получения содержимого BLOB надо использовать строку вызова:
http://aa.bb.cc:8080/api/v1/blobs/12345678
Настройки файла application.yml должны иметь следующий вид:
blob-storage:
protocol: ${PROT:http}
host: ${HOST:aa.bb.cc}
port: ${PORT:80}
path-prefix: ${PREFIX:api/v1/blobs/}
Пример 4
Если требуется получить строку вида:
https://aa.bb.cc:8080/app/{link}/download?requester_id={value}&user=fdsfs&zip=true
Необходимо настроить:
На Витрине данных поле с типом
LINKдолжно содержать текст:
12345678/download?requester_id=ABCDEFGH
В файл
application.ymlдобавить следующие настройки:
blob-storage:
protocol: https
host: aa.bb.cc
port: 8080
path-prefix: api/
params:
user: fdsfs
zip: true
Указание дополнительных параметров к Хранилищу BLOB-объектов
Например:
blob-storage:
params:
name1: value1
name2: value2
Пример запроса:
/files/test?name1=value1&name2=value2
2.2.8.2.5. Секция logging
В секции logging настраивается логирование работы модуля.
Например:
logging:
request-response:
blob-request: ${BLOB_REQUEST_LOG_ENABLED:false}
blob-response: ${BLOB_RESPONSE_LOG_ENABLED:false}
Параметры настроек
blob-request- журналировать запросы, напримерBLOB_REQUEST_LOG_ENABLED:false;blob-request- журналировать ответы, напримерBLOB_RESPONSE_LOG_ENABLED:false.
2.2.8.3. Спецификация модуля «BLOB-адаптер»
Данная спецификация описывает эндпоинты API модуля «BLOB-адаптер».
2.2.9. Настройка CSV-Uploader
2.2.9.1. Конфигурация CSV-uploader (application.yml)
Файл application.yml – основной конфигурационный файл модуля CSV-uploader, в котором задана логика и порядок
работы загрузчика, а также другие настройки необходимые для корректной работы адаптера.
2.2.9.1.1. Пример файла application.yml
# Настройки авторизации
auth:
# Режим аутентификации
# DISABLED - аутентификация отключена
# JWT - (ранее upload.jwt-auth) включает окно запроса JWT на странице "Загрузка" для аутентификации в rest-uploader
# STUDIO - включает аутентификацию по логину и паролю в Datamart Platform Studio
mode: ${AUTH_MODE:DISABLED}
# Настройки аутентификации в режиме STUDIO
studio:
# Запрос логина и пароля на странице "Загрузка", (отдельно для каждого datamart).
# При false используются реквизиты в блоке datamarts:
ui-prompt: true
datamarts:
# Реквизиты для авторизации используемые на странице "Загрузка" если ui-prompt: false, а также при загрузке по расписанию.
- datamart_mnemonic: datamart25
username: user
password: passwd
organization_ogrn: ogrn
http-server:
# Порт для старта веб сервера
port: ${HTTP_PORT:8080}
# Включить веб-сервер
enabled: ${HTTP_ENABLED:true}
file-size:
# Ограничение на размер отправляемого файла (в мегабайтах)
restriction: ${SEND_FILE_SIZE_RESTRICTION:1024}
environment:
# Папка для ошибочных файлов
error-folder: ${ENVIRONMENT_ERROR_FOLDER:error}
prostore-rest-client:
enabled: true # true / false # выключение доступа к Простору
persistence-datamart: ${PERSISTENCE_DATAMART:persistence} # датамарт, в котором будут располагаться таблицы с данными сервиса
datasource: ${PERSISTENCE_DATASOURCE:} # по умолчанию пусто, тогда берется единственный датасорс из настроек Простора
storage-duration: 14d # продолжительность хранения данных в журналах
cleanup-interval: 10m # периодичность очистки данных из таблиц журналов
max-retry: 3 # количество попыток выполнить запрос, в случае переключения datasource
host: ${PS_HOST:localhost}
port: ${PS_PORT:9195}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
spring:
liquibase:
enabled: ${prostore-rest-client.enabled}
analytics-enabled: false
change-log: classpath:/liquibase-changes/changelog.xml
driver-class-name: ru.datamart.prostore.jdbc.Driver
url: jdbc:prostore://${prostore-rest-client.host}:${prostore-rest-client.port}/${prostore-rest-client.persistence-datamart}
database-change-log-table: csv_uploader_changelog
database-change-log-lock-table: csv_uploader_changeloglock
liquibase-schema: ${prostore-rest-client.persistence-datamart}
default-schema: ${prostore-rest-client.persistence-datamart}
user: ""
password: ""
metadata: # задействовано только если prostore-rest-client.enabled:false
free-input: false # true / false разрешить свобоный ввод строки датамарта и таблицы
# datamarts: # определяет варианты к выбору датамартов и таблиц, список доступных таблиц определяется для каждого датамарта отдельно
# marketing:
# tables: [sales]
# region36:
# tables: [tickets,passengers,cars]
# способ хранения пользовательской конфигурации
persistence-mode: ${PERSISTENCE_MODE:prostore} # prostore, preferences
validation:
enabled: ${VALIDATION_ENABLE:true}
upload:
mandatoryFlk: ${UPLOAD_MANDATORY_FLK:false}
uploader:
url: ${REST_UPLOADER_URL:http://localhost:8081} # бывший rest-uploader-url
upload-uri: /v2/datamarts/{datamart}/tables/{table}/upload
delete-uri: /v2/datamarts/{datamart}/tables/{table}/delete
status-uri: /v2/requests/{requestId}/status
flk-report-uri: /v2/requests/{requestId}/report/
use-multipart: false
# Настройки парсера csv файлов
csv-parser:
# Символ разделителя значений
separator: ${CSV_PARSER_SEPARATOR:;}
# Символ кавычки
quote-char: ${CSV_PARSER_QUOTE_CHAR:"}
# Символ экранирования значений
escape-char: ${CSV_PARSER_ESCAPE_CHAR:'}
# Настройка интерпретации значений как null. Допустимые значения:
# - EMPTY_SEPARATORS - пустое значение между двумя разделителями, например ;;
# - EMPTY_QUOTES - пустые кавычки, например ;"";
# - BOTH - оба варианта
# - NEITHER - никогда. Пустая строка всегда определяется как пустая строка
field-as-null: ${CSV_PARSER_FIELD_AS_NULL:EMPTY_SEPARATORS}
metrics:
port: ${METRICS_PORT:9837}
2.2.9.2. Параметры конфигурации
Настройка конфигурации CSV-uploader осуществляется путем редактирования параметров настроек в файле application.yml.
В файле конфигурации CSV-uploader могут быть настроены следующие секции:
auth- настройки авторизации;http-server- настройки порта подключения;file-size- ограничение на размер отправляемого файла (мегабайты);environment- определяет папку для ошибочных файлов;prostore-rest-client- блок параметров конфигурирования взаимодействия с Prostore;spring- параметры для определения наименований служебных таблиц liquibase;metadata- добавление поля ввода наименования датамарта и таблицы;persistence-mode- настройка хранения пользовательской конфигурации;validation- адрес подключения модуля REST-Uploader;upload- требование токена для аутентификации в модуле REST-Uploader;csv-parser- настройка парсинга CSV;metrics- настройка получения метрик.
2.2.9.2.1. Секция auth
Секция auth содержит настройки авторизации.
Например:
auth:
mode: ${AUTH_MODE:DISABLED}
studio:
ui-prompt: true
datamarts:
- datamart_mnemonic: datamart25
username: user
password: passwd
organization_ogrn: ogrn
Параметры конфигурации
mode- режим аутентификации, напримерAUTH_MODE:DISABLED, доступные следующие варианты:DISABLED- аутентификация отключена;JWT- включает окно запроса JWT на странице «Загрузка» для аутентификации в REST-Uploader (ранее upload.jwt-auth);STUDIO- включает аутентификацию по логину и паролю в Datamart Platform Studio;
studio- настройки аутентификации в режиме STUDIO;ui-prompt- если выбранtrueзапрос логина и пароля на странице «Загрузка», (отдельно для каждого datamart), если выбранfalse, то используются реквизиты из блока «datamarts»;datamarts- Реквизиты для авторизации используемые на странице «Загрузка» если выбранui-prompt: false, а также при загрузке по расписанию;datamart_mnemonic- мнемоника датамарта, например:datamart_mnemonic: datamart25;username- имя пользователя, напримерusername: user;password- пароль авторизации, напримерpassword: passwd;organization_ogrn- ОГРН организации, напримерorganization_ogrn: ogrn.
2.2.9.2.2. Секция http-server
Секция http-server предназначена для настройки порта и протокола передачи данных (одно из значений HTTP или HTTPS).
Например:
http:
port: ${HTTP_PORT:8080}
enabled: ${HTTP_ENABLED:true}
Параметры конфигурации
port- порт для старта веб-сервера, напримерHTTP_PORT:8080;enabled- статус включения/отключения веб-сервера, напримерHTTP_ENABLED:true.
2.2.9.2.3. Секция file-size
Секция file-size отвечает за ограничение на размер отправляемого файла (указывется в мегабайтах).
file-size:
restriction: ${SEND_FILE_SIZE_RESTRICTION:1024}
Параметры конфигурации
restriction- ограничение на размер отправляемого файла, напримерSEND_FILE_SIZE_RESTRICTION:1024.
2.2.9.2.4. Секция environment
В секции environment указывается папка для ошибочных файлов.
Например:
environment:
error-folder: ${ENVIRONMENT_ERROR_FOLDER:error}
Параметры конфигурации
error-folder- папка для ошибочных файлов, напримерENVIRONMENT_ERROR_FOLDER:error.
2.2.9.2.5. Секция prostore-rest-client
В секции prostore-rest-client реализован блок параметров конфигурирования взаимодействия с Prostore.
Например:
prostore-rest-client:
enabled: true
persistence-datamart: ${PERSISTENCE_DATAMART:persistence}
datasource: ${PERSISTENCE_DATASOURCE:}
storage-duration: 14d
cleanup-interval: 10m
max-retry: 3
host: ${PS_HOST:localhost}
port: ${PS_PORT:9090}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
Параметры настроек
enabled- включение/ выключение доступа к Prostorepersistence-datamart- датамарт, в котором будут располагаться таблицы с данными сервиса, напримерPERSISTENCE_DATAMART:persistence;datasource- массив датасорсов типа ADP;storage-duration- продолжительность хранения данных в журналах, например14d, указывается в днях;cleanup-interval- периодичность очистки данных из таблиц журналов, например10m, указывается в минутах;max-retry- количество попыток выполнить запрос, в случае переключения datasource, например3;host- адрес Prostore, напримерPS_HOST:localhost;port- порт Prostore, напримерPS_PORT:9195;max-pool-size- максимальное число подключений к Prostore, напримерPS_MAX_POOL_SIZE:8.
2.2.9.2.6. Секция spring
В секции spring указываются параметры для определения наименований служебных таблиц liquibase.
Например:
spring:
liquibase:
enabled: true
analytics-enabled: false
change-log: classpath:/liquibase-changes/changelog.xml
driver-class-name: ru.datamart.prostore.jdbc.Driver
url: jdbc:prostore://${prostore-rest-client.service-database.host}:${prostore-rest-client.service-database.port}/${prostore-rest-client.service-database.persistence-datamart}
database-change-log-table: loader_changelog
database-change-log-lock-table: loader_changeloglock
liquibase-schema: ${prostore-rest-client.service-database.persistence-datamart}
default-schema: ${prostore-rest-client.service-database.persistence-datamart}
user: ""
password: ""
Параметры настроек
enabled- признак включения/отключения миграций;analytics-enabled- флаг подключения статистики;change-log- путь к файлам миграций, которые находятся внутри jar;driver-class-name- имя JDBC-драйвера Prostore. Константа, без переопределения.url- адрес подключения к простору в формате JDBC. Переопределять не потребуется, конструируется из параметров подключения к Prostore.database-change-log-table- имя таблицы хранения истории выполненных миграций;database-change-log-lock-table- имя таблицы для блокировок, константа;liquibase-schema- имя датамарта, в которой распалагаются 2 таблицы (database-change-log-table, database-change-log-lock-table)default-schema- имя датамарта для системных таблиц. Так же заполняется из блока конфигурации Prostore.user- имя пользователя Prostore;password- пароль пользователя Prostore.
2.2.9.2.7. Секция metadata
Настройки секции metadata позволяют отображать поле ручного ввода названия датамарта и таблиц.
Задействовано, только если в секции prostore-rest-client указано enabled: false.
Например:
metadata:
free-input: false
# datamarts:
# marketing:
# tables: [sales]
# region36:
# tables: [tickets,passengers,cars]
Параметры конфигурации
free-input- разрешить свободный ввод строки датамарта и таблицы, напримерfree-input: false;datamarts- определяет варианты к выбору датамартов и таблиц, список доступных таблиц определяется для каждого датамарта отдельно.
2.2.9.2.8. Секция persistence-mode
В секции persistence-mode указывается способ хранения пользовательской конфигурации.
Например:
persistence-mode: ${PERSISTENCE_MODE:prostore} # prostore, preferences
2.2.9.2.9. Секция validation
В секции validation реализован механизм настройки валидации ФЛК.
Например:
validation:
enabled: ${VALIDATION_ENABLE:true}
Параметры конфигурации
enabled- подключение к сервису REST-Uploader для выполнения валидации, напримерVALIDATION_ENABLE:true.
2.2.9.2.10. Секция upload
В секции upload реализовано включение/ отключение обязательности проверки ФЛК.
Например:
upload:
mandatoryFlk: ${UPLOAD_MANDATORY_FLK:false}
Параметры конфигурации
jmandatoryFlk- включение/ выключение обязательности ФЛК:true- проверка ФЛК выполняется всегда, изменение переключателя ФЛК веб-интерфейсе заблокировано;false- необходимость проверки ФЛК задается пользователем в веб-интерфейсе.
2.2.9.2.11. Секция uploader
В секции uploader настройки подключения к стандартному загрузчику/ REST-Upoloader.
Например:
uploader:
url: ${REST_UPLOADER_URL:http://localhost:8081} #
upload-uri: /v2/datamarts/{datamart}/tables/{table}/upload
delete-uri: /v2/datamarts/{datamart}/tables/{table}/delete
status-uri: /v2/requests/{requestId}/status
flk-report-uri: /v2/requests/{requestId}/report/
use-multipart: false
Параметры конфигурации
url- предыдущий rest-uploader-url;upload-uri- метод загрузки;delete-uri- метод удаления;status-uri- метод получения статуса;flk-report-uri- метод получения отчета ФЛК.
2.2.9.2.12. Секция csv-parser
Примечание
При загрузке файлов с форматно-логическим контролем, важно, чтобы настройки секции csv-parser должны быть синхронизированы с соответствующими настройками csvparser Prostore. Так же настройки секции csv-parser должны быть одинаковыми в модулях CSV-Uploader (если используется его UI), REST-Uploader и DATA-Uploader.
Секция csv-parser - настройка парсинга CSV.
Например:
# Настройки парсера csv файлов
csv-parser:
# Символ разделителя значений
separator: ${CSV_PARSER_SEPARATOR:;}
# Символ кавычки
quote-char: ${CSV_PARSER_QUOTE_CHAR:"}
# Символ экранирования значений
escape-char: ${CSV_PARSER_ESCAPE_CHAR:'}
# Настройка интерпретации значений как null. Допустимые значения:
# - EMPTY_SEPARATORS - пустое значение между двумя разделителями, например ;;
# - EMPTY_QUOTES - пустые кавычки, например ;"";
# - BOTH - оба варианта
# - NEITHER - никогда. Пустая строка всегда определяется как пустая строка
field-as-null: ${CSV_PARSER_FIELD_AS_NULL:EMPTY_SEPARATORS}
Параметры конфигурации
separator- Символ разделителя значений, напримерCSV_PARSER_SEPARATOR:;;quote-char- символ кавычки, напримерCSV_PARSER_QUOTE_CHAR:";escape-char- Символ экранирования значений, напримерCSV_PARSER_ESCAPE_CHAR:';Настройка интерпретации значений как null. Допустимые значения:
EMPTY_SEPARATORS- пустое значение между двумя разделителями, например ;;EMPTY_QUOTES- пустые кавычки, например ;»»;BOTH- оба варианта;NEITHER- никогда. Пустая строка всегда определяется как пустая строка.
field-as-null- способ определения null поля, напримерCSV_PARSER_FIELD_AS_NULL:EMPTY_SEPARATORS.
Дополнительное описание параметров
Параметр
CSV_PARSER_ESCAPE_CHARработает следующим образом: если символ экранирования и символ кавычки равны", то будет использован RFC4180Parser, который считывает все символы между двумя двойными кавычками, при этом двойная кавычка в тексте поля должна быть экранирована двойной кавычкой (Например"поле, ""содержащее двойную кавычку"""будет считано какполе, "содержащее двойную кавычку"). В противном случае будет использован CSVParser, использующий символ экранирования для обозначения «непечатаемых символов».Параметр
CSV_PARSER_FIELD_AS_NULLможет принимать следующие значения:EMPTY_SEPARATORS- два разделителя полей (см. csv-parser/separator) подряд считаются null. Например: строка [aaa,,ccc] содержит значения [«aaa», null, «bbb»], а строка [aaa,»»,ccc] содержит значения [«aaa», «», «bbb»].EMPTY_QUOTES- два «ограничителя строки» (см. csv-parser/escape-char) подряд считаются null. Например: строка [aaa,»»,ccc] содержит значения [«aaa», null, «bbb»], а строка [aaa,,ccc] содержит значения [«aaa», «», «bbb»].BOTH- оба варианта (см.EMPTY_SEPARATORSиEMPTY_QUOTES) считаются null. Например: обе строки [aaa,»»,ccc] и [aaa,,bbb] содержат одинаковое значение [«aaa», null, «bbb»].NEITHER- ни один из вариантов (см.EMPTY_SEPARATORSиEMPTY_QUOTES) не считается null. Например: обе строки [aaa,»»,ccc] и [aaa,,bbb] содержат одинаковое значение [«aaa», «», «bbb»].
2.2.9.2.13. Секция metrics
Секция metrics предназначена для настройки параметров метрик.
Например:
metrics:
port: ${METRICS_PORT:9837}
Параметры конфигурации
port- Порт для метрик, напримерMETRICS_PORT:9837.
2.2.10. Настройка DATA-Uploader – Модуль исполнения асинхронных заданий
2.2.10.1. Конфигурация модуля DATA-Uploader (application.yml)
Файл application.yml – основной конфигурационный файл модуля, в котором задана его логика и порядок работы модуля:
обеспечение обработки очереди файлов, настройка подключения к ядру витрины (секция: prostore), а также другие
настройки необходимые для корректной работы модуля.
2.2.10.1.1. Пример файла application.yml
В конфигурационном файле следует задавать только те настройки, которые необходимы для решения текущих бизнес-задач.
http-server:
port: ${SERVER_PORT:8082}
persistence-mode: ${PERSISTENCE_MODE:prostore} # prostore, zookeeper&redis
prostore-rest-client:
persistence-datamart: ${PERSISTENCE_DATAMART:persistence}
datasource: ${PERSISTENCE_DATASOURCE:} # по умолчанию пусто, тогда берется единственный датасорс из настроек Простора
table-completed-inserts-datamarts: ${PERSISTENCE_COMPLETED_INSERTS_TABLE:data_uploader_completed_inserts_datamarts}
table-deltas-open: ${PERSISTENCE_OPEN_DELTAS_TABLE:data_uploader_deltas_open}
# Таблица активных экземляров сервиса data-uploader (используется при persistence-mode: prostore)
table-data-uploader-health-check: ${PERSISTENCE_HEALTH_CHECK_TABLE:data_uploader_health_check}
# Имя таблицы с задачами загрузки данных (используется при persistence-mode: prostore)
table-validation-complete: ${PERSISTENCE_VALIDATION_COMPLETE_TABLE:validation_complete}
# Имя таблицы хранения статусов запросов (используется при persistence-mode: prostore)
table-requests-status: ${PERSISTENCE_STATUS_TABLE:status}
# Имя таблицы хранения данных файлов (используется при persistence-mode: prostore)
table-files: ${PERSISTENCE_FILES_TABLE:files}
# Имя таблицы хранения активных экземпляров сервисов
table-data-uploader-active: ${PERSISTENCE_ACTIVE_TABLE:data_uploader_active}
health-check-refresh-period-sec: ${HEALTH_CHECK_REFRESH_PERIOD:120}
health-check-wait-period-sec: ${HEALTH_CHECK_WAIT_PERIOD:300}
max-retry: 3 # количество попыток выполнить запрос, в случае переключения datasource
recovery-await-timeout: 10s # таймаут ожидания восстановления datasource
recovery-retry-delay: 1s # задержка между попытками восстановить datasource
host: ${PS_HOST:localhost}
port: ${PS_PORT:9090}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
redis:
type: ${REDIS_TYPE:STANDALONE}
connection-string: ${REDIS_CONNECTION_STRING:redis://localhost:6379}
password: ${REDIS_PASSWORD:eYVX7EwVmmxKPCDmwMtyKVge8oLd2t81}
max-pool-size: ${REDIS_MAX_POOL_SIZE:6}
max-pool-waiting: ${REDIS_MAX_POOL_WAITING:24}
max-waiting-handlers: ${REDIS_MAX_WAITING_HANDLERS:32}
net-client-options:
tcp-user-timeout-duration: 30
idle-timeout-duration: 30
upload:
concurrency: ${UPLOAD_CONCURRENCY:100} # Общее количество параллельных задач загрузки
send-concurrency: ${UPLOAD_SEND_CONCURRENCY:10} # Количество параллельных отправок данных в кафку для каждого файла
poll-interval: ${UPLOAD_POLL_INTERVAL:500ms} # Интервал опроса очереди сообщений на загрузку
llw-batch: ${UPLOAD_LLW_BATCH:1000} # Число записей в одной команде upsert/delete в случае llw загрузки.
stream-batch: ${UPLOAD_STREAM_BATCH:10000} # Число записей в одной команде upsert/delete в случае потоковой загрузки частями.
creating-delta-on-upload-request: ${DELTA_CREATING_MODE:enable} # enable|disable|period
period: ${CREATING_DELTA_ON_UPLOAD_REQUEST_PERIOD:300}s # Используется при creating-delta-on-upload-request=period
check-uniqueness: true # выполнять ли проверку уникальности первичных ключей
pool:
size: ${UPLOAD_POOL_SIZE:16}
retry:
attempts: 5
delay: 1m
preffered_mode: ${UPLOAD_MODE:stream} # stream|llw // Режим загрузки в prostore
data-storage:
compress: ${DATA_STORAGE_COMPRESS:zstd} # zstd/none редактируется синхронно для модулей rest-uploader/data-uploader!!!
type: ${DATA_STORAGE_TYPE:dir} # redis|dir|s3|prostore
# Директория хранения файлов для типа dir
dir: ${DATA_STORAGE_DIR:/upload/data}
s3:
endpoint: ${S3_ENDPOINT:http://127.0.0.1:9000/}
bucket: ${S3_BUCKET:data} # Имя бакета
region: ${S3_REGION:}
access-key: ${S3_USER:minioadmin} # Пользователь, под которым происходит взаимодействие с s3
secret-key: ${S3_PASSWORD:minioadmin} # Пароль пользователя для взаимодействия с s3
environment:
name: ${ENVIRONMENT_NAME:test}
zookeeper:
connection-string: ${ZOOKEEPER_DS_ADDRESS:localhost}
connection-timeout-ms: ${ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000}
session-timeout-ms: ${ZOOKEEPER_DS_SESSION_TIMEOUT_MS:8640000}
chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}
csv-parser:
separator: ${CSV_PARSER_SEPARATOR:;}
quote-char: ${CSV_PARSER_QUOTE_CHAR:"}
escape-char: ${CSV_PARSER_ESCAPE_CHAR:'}
# Настройка интерпретации значений как null. Допустимые значения:
# - EMPTY_SEPARATORS - пустое значение между двумя разделителями, например ;;
# - EMPTY_QUOTES - пустые кавычки, например ;"";
# - BOTH - оба варианта
# - NEITHER - никогда. Пустая строка всегда определяется как пустая строка
field-as-null: ${CSV_PARSER_FIELD_AS_NULL:EMPTY_SEPARATORS}
active:
timeout: ${ACTIVE_TIMEOUT:60}
time-to-live: ${ACTIVE_TTL:180}
delta:
timeout: ${DELTA_TIMEOUT:300}
row-max-count: ${DELTA_MAX_ROWS:500000}
chunk-row-max-count: ${DELTA_CHUNK_ROWS:10000}
chunk-data-max-size: ${DELTA_CHUNK_DATA_SIZE:1048576}
# параметр ожидания перед повторной попыткой открытия дельты в случае ошибки
open-delay: ${DELTA_OPEN_DELAY:60}s
# количество попыток открытия дельты в случае ошибки
open-attempts: ${DELTA_OPEN_ATTEMPTS:5}
# период проверки открытых дельт
open-check: ${DELTA_OPEN_CHECK:60}s
# количество попыток фиксации дельты в случае ошибки
commit-attempts: ${DELTA_COMMIT_ATTEMPTS:5}
# период ожидания перед повторной попыткой фиксации дельты
commit-error-delay: ${DELTA_COMMIT_DELAY:1}s
# количество попыток отката дельты в случае ошибки
rollback-attempts: ${DELTA_COMMIT_ATTEMPTS:3}
# период ожидания перед повторной попыткой отката дельты
rollback-error-delay: ${DELTA_COMMIT_DELAY:5}s
stream:
timeout: ${DELTA_TIMEOUT:300}
row-max-count: ${DELTA_MAX_ROWS:500000}
avro-codec: zstd
response:
time-to-live: ${RESPONSE_TTL:36000}
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# Массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается не активным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- redis.password
metrics:
port: ${METRICS_PORT:9837}
2.2.10.2. Параметры конфигурации
Настройка конфигурации DATA-Uploader осуществляется путем редактирования параметров настроек в файле application.yml,
где настраиваются секции:
http-server- указывается порт сервера;persistence-mode- настройки хранения данных;prostore-rest-client- блок параметров конфигурирования взаимодействия с Prostore;redis- настройка подключения к Redis;upload- указываются настройки параллельной загрузки данных;data-storage- директория хранения файлов для типаdir;environment- определяет значение среды разработки;zookeeper- определяет настройки подключения к Zookeeper;csv-parser- настройка парсера CSV-файлов;active- настройки интервалов между попытками перехода в активное состояние и времени жизни ключа флага активности;delta- настройка обработок загрузок и отправок заданий на загрузку дельт;stream- настройка потоковой загрузки, в случае если поток разбивается на части;response- настройка времени хранения ответов по заданию в Redis;component-info- настройки модуля сбора информации о компонентах витрины;metrics- настройка получения метрик.
2.2.10.2.1. Секция http-server
В секции http-server указывается порт веб-сервера.
Например:
server:
port: ${SERVER_PORT:8082}
Параметры настроек
port- порт веб-сервера, например:SERVER_PORT:8082.
2.2.10.2.2. Секция persistence-mode
В секции persistence-mode указывается настройка хранения данных: или в Prostore, или в Zookeeper. В случае
выбора Prostore автоматически создаются необходимые таблицы.
Например:
persistence-mode: ${PERSISTENCE_MODE:prostore} # prostore | zookeeper
Параметры настроек
persistence-mode- настройка хранения данных, напримерPERSISTENCE_MODE:prostore.
2.2.10.2.3. Секция prostore-rest-client
В секции prostore-rest-client реализован блок параметров конфигурирования взаимодействия с Prostore.
Например:
prostore-rest-client:
persistence-datamart: ${PERSISTENCE_DATAMART:persistence}
datasource: ${PERSISTENCE_DATASOURCE:} # по умолчанию пусто, тогда берется единственный датасорс из настроек Простора
table-completed-inserts-datamarts: ${PERSISTENCE_COMPLETED_INSERTS_TABLE:data_uploader_completed_inserts_datamarts}
table-deltas-open: ${PERSISTENCE_OPEN_DELTAS_TABLE:data_uploader_deltas_open}
# Таблица активных экземляров сервиса data-uploader (используется при persistence-mode: prostore)
table-data-uploader-health-check: ${PERSISTENCE_HEALTH_CHECK_TABLE:data_uploader_health_check}
# Имя таблицы с задачами загрузки данных (используется при persistence-mode: prostore)
table-validation-complete: ${PERSISTENCE_VALIDATION_COMPLETE_TABLE:validation_complete}
# Имя таблицы хранения статусов запросов (используется при persistence-mode: prostore)
table-requests-status: ${PERSISTENCE_STATUS_TABLE:status}
# Имя таблицы хранения данных файлов (используется при persistence-mode: prostore)
table-files: ${PERSISTENCE_FILES_TABLE:files}
# Имя таблицы хранения активных экземпляров сервисов
table-data-uploader-active: ${PERSISTENCE_ACTIVE_TABLE:data_uploader_active}
health-check-refresh-period-sec: ${HEALTH_CHECK_REFRESH_PERIOD:120}
health-check-wait-period-sec: ${HEALTH_CHECK_WAIT_PERIOD:300}
max-retry: 3 # количество попыток выполнить запрос, в случае переключения datasource
recovery-await-timeout: 10s # таймаут ожидания восстановления datasource
recovery-retry-delay: 1s # задержка между попытками восстановить datasource
host: ${PS_HOST:localhost}
port: ${PS_PORT:9090}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
Параметры настроек
persistence-datamart- датамарт, где будут располагаться таблицы хранения данных, используется приpersistence-mode = prostore;datasource- массив датасорсов типа ADP;table-completed-inserts-datamarts- таблица с данными по завершенным запросам добавления данных, напримерPERSISTENCE_COMPLETED_INSERTS_TABLE:data_uploader_completed_inserts_datamarts;table-deltas-open- таблица с данными по открытым дельтам, напримерPERSISTENCE_OPEN_DELTAS_TABLE:data_uploader_deltas_open;table-data-uploader-health-check- таблица с health-check, напримерPERSISTENCE_HEALTH_CHECK_TABLE:data_uploader_health_check;table-validation-complete- таблица с задачами загрузки данных, напрммерPERSISTENCE_VALIDATION_COMPLETE_TABLE:validation_complete;table-requests-status- таблица хранения статусов запросов. напримерPERSISTENCE_STATUS_TABLE:status;table-files- таблица хранения данных файлов, напримерPERSISTENCE_FILES_TABLE:files;table-data-uploader-active- таблица хранения активных экземпляров сервисов, напримерPERSISTENCE_ACTIVE_TABLE:data_uploader_active;health-check-refresh-period-sec: ${HEALTH_CHECK_REFRESH_PERIOD:120}- период обновления health-check в секундах, напримерHEALTH_CHECK_REFRESH_PERIOD:120;health-check-wait-period-sec- период ожидания health-check в секундах, напримерHEALTH_CHECK_WAIT_PERIOD:300;max-retry- количество попыток выполнить запрос, в случае переключения datasource, например3;recovery-await-timeout- таймаут ожидания восстановления datasource, например10s;recovery-retry-delay- задержка между попытками восстановить datasource, например1s;host- адрес Prostore, напримерPS_HOST:t5-prostore-01.ru-central1.internal;port- порт Prostore, напримерPS_PORT:9195;max-pool-size- максимальное число подключений к Prostore, напримерPS_MAX_POOL_SIZE:8.
2.2.10.2.4. Секция redis
Секция redis определяет настройки подключения к Redis.
Например:
redis:
type: ${REDIS_TYPE:STANDALONE}
connection-string: ${REDIS_CONNECTION_STRING:redis://localhost:6379}
password: ${REDIS_PASSWORD:eYVX7EwVmmxKPCDmwMtyKVge8oLd2t81}
max-pool-size: ${REDIS_MAX_POOL_SIZE:6}
max-pool-waiting: ${REDIS_MAX_POOL_WAITING:24}
max-waiting-handlers: ${REDIS_MAX_WAITING_HANDLERS:32}
net-client-options:
tcp-user-timeout-duration: 30
idle-timeout-duration: 30
Параметры настроек
type- тип подключения к Redis (STANDALONE/CLUSTER), напримерREDIS_TYPE:STANDALONE;connection-string- указывается список серверов для подключения (перечисление через запятую), напримерREDIS_CONNECTION_STRING:redis://localhost:6379;password- пароль для подключения, напримерREDIS_PASSWORD:eYVX7EwVmmxKPCDmwMtyKVge8oLd2t81;max-pool-size- устанавливается максимальный размер пула, напримерREDIS_MAX_POOL_SIZE:6;max-pool-waiting- устанавливается максимальный размер пула ожидающих команд, напримерREDIS_MAX_POOL_WAITING:24;max-waiting-handlers- устанавливается максимальный размер ожидающих обработчиков, напримерREDIS_MAX_WAITING_HANDLERS:32;net-client-options- параметры Redis клиента:tcp-user-timeout-duration- таймаут на соединение;idle-timeout-duration- таймаут ожидания ответа от Redis.
2.2.10.2.5. Секция upload
Секция upload определяет настройки параллельной загрузки данных.
Например:
upload:
concurrency: ${UPLOAD_CONCURRENCY:100} # Общее количество параллельных задач загрузки
send-concurrency: ${UPLOAD_SEND_CONCURRENCY:10} # Количество параллельных отправок данных в кафку для каждого файла
poll-interval: ${UPLOAD_POLL_INTERVAL:500ms} # Интервал опроса очереди сообщений на загрузку
llw-batch: ${UPLOAD_LLW_BATCH:1000} # Число записей в одной команде upsert/delete в случае llw загрузки.
stream-batch: ${UPLOAD_STREAM_BATCH:10000} # Число записей в одной команде upsert/delete в случае потоковой загрузки частями.
creating-delta-on-upload-request: ${DELTA_CREATING_MODE:enable} # enable|disable|period
period: ${CREATING_DELTA_ON_UPLOAD_REQUEST_PERIOD:300}s # Используется при creating-delta-on-upload-request=period
check-uniqueness: true # выполнять ли проверку уникальности первичных ключей
pool:
size: ${UPLOAD_POOL_SIZE:16}
retry:
attempts: 5
delay: 1m
preffered_mode: ${UPLOAD_MODE:stream} # stream|llw // Режим загрузки в prostore
Параметры настроек
concurrency- общее количество параллельных задач загрузки, например100;send-concurrency- количество параллельных отправок данных в kafka для каждого файла, например10;poll-interval- интервал опроса очереди сообщений на загрузку, например500ms;llw-batch- число записей в одной команде UPSERT/DELETE в случае llw загрузки, напримерUPLOAD_LLW_BATCH:1000;creating-delta-on-upload-request- создание дельты при запросе загрузки, напримерDELTA_CREATING_MODE:enable;возможные значения:
enable/disable/period;period- период создания дельты при запросе загрузки (в секундах), напримерCREATING_DELTA_ON_UPLOAD_REQUEST_PERIOD:300, используется при creating-delta-on-upload-request=period;check-uniqueness- флаг выполнения проверки уникальности первичных ключей;pool/size- размер пула загрузки, напримерUPLOAD_POOL_SIZE:16;retry- повтор попытки загрузки;attempts- количество попыток;delay- период задержки (в минутах);preffered_mode- режим загрузки, напримерUPLOAD_MODE:stream.
2.2.10.2.6. Секция data-storage
В секции data-storage указывается директория хранения файлов для типа dir.
Например:
data-storage:
compress: ${DATA_STORAGE_COMPRESS:zstd} # zstd/none редактируется синхронно для модулей rest-uploader/data-uploader!!!
type: ${DATA_STORAGE_TYPE:dir} # redis|dir|s3|prostore
# Директория хранения файлов для типа dir
dir: ${DATA_STORAGE_DIR:/upload/data}
s3:
endpoint: ${S3_ENDPOINT:http://127.0.0.1:9000/}
bucket: ${S3_BUCKET:data} # Имя бакета
region: ${S3_REGION:}
access-key: ${S3_USER:minioadmin} # Пользователь, под которым происходит взаимодействие с s3
secret-key: ${S3_PASSWORD:minioadmin} # Пароль пользователя для взаимодействия с s3
Параметры настроек
compress- настройки сжатия директории хранения файлов, напримерDATA_STORAGE_COMPRESS:zstd;
Примечание
блок compress редактируется синхронно для модулей REST-Uploader/ DATA-Uploader
type- тип файлов, напримерDATA_STORAGE_TYPE:dir(возможные значения: redis / dir / s3);dir- директория хранения файлов для типа dir, напримерDATA_STORAGE_DIR:/upload/data;s3- настройки облачного хранилища S3;endpoint- адрес конечной точки, напримерS3_ENDPOINT:http://127.0.0.1:9000/;bucket- имя бакета, напримерS3_BUCKET:dataregion- регион хранилища;access-key- пользователь, под которым происходит взаимодействие с s3, напримерS3_USER:minioadmin;secret-key- пароль пользователя для взаимодействия с s3, напримерS3_PASSWORD:minioadmin.
2.2.10.2.7. Секция environment
В секции environment выбирается среда разработки (например, значение test, prod и т.д).
Например:
environment:
name: ${ENVIRONMENT_NAME:test}
Параметры конфигурации
name- название окружения, напримерENVIRONMENT_NAME:test.
2.2.10.2.8. Секция zookeeper
В секции zookeeper настраиваются параметры подключения к Zookeeper.
Например:
zookeeper:
connection-string: ${ZOOKEEPER_DS_ADDRESS:localhost}
connection-timeout-ms: ${ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000}
session-timeout-ms: ${ZOOKEEPER_DS_SESSION_TIMEOUT_MS:8640000}
chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}
Параметры настроек
connection-string- Подключение к Zookeeper DS, напримерZZOOKEEPER_DS_ADDRESS:localhost;connection-timeout-ms- Zookeeper DS таймаут подключения, напримерZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000;session-timeout-ms- Zookeeper DS таймаут сессии, напримерZOOKEEPER_DS_SESSION_TIMEOUT_MS:40000;chroot- Zookeeper DS chroot path, напримерZOOKEEPER_DS_CHROOT:/adapter.
2.2.10.2.9. Секция csv-parser
Примечание
При загрузке файлов с форматно-логическим контролем, важно, чтобы настройки секции csv-parser должны быть синхронизированы с соответствующими настройками csvparser Prostore. Так же настройки секции csv-parser должны быть одинаковыми в модулях CSV-Uploader (если используется его UI), REST-Uploader и DATA-Uploader.
Секция csv-parser - настройка парсинга CSV.
Например:
csv-parser:
separator: ${CSV_PARSER_SEPARATOR:;}
quote-char: ${CSV_PARSER_QUOTE_CHAR:"}
escape-char: ${CSV_PARSER_ESCAPE_CHAR:'}
field-as-null: ${CSV_PARSER_FIELD_AS_NULL:EMPTY_SEPARATORS}
multiline-limit: 0
Параметры конфигурации
separator- символ разделителя значений, напримерCSV_PARSER_SEPARATOR:;;quote-char- символ кавычки, напримерCSV_PARSER_QUOTE_CHAR:";escape-char- символ экранирования значений, напримерCSV_PARSER_ESCAPE_CHAR:';Настройка интерпретации значений как null. Допустимые значения:
EMPTY_SEPARATORS- пустое значение между двумя разделителями, например ;;EMPTY_QUOTES- пустые кавычки, например ;»»;BOTH- оба варианта;NEITHER- никогда. Пустая строка всегда определяется как пустая строка.
field-as-null- способ определения null поля, напримерCSV_PARSER_FIELD_AS_NULL:EMPTY_SEPARATORS.multiline-limit- параметры парсинга мультистроковых значений.
Примечание
Парсер может зависать, если в данных встречаются вложенные неэкранированные кавычки..
Параметр
CSV_PARSER_ESCAPE_CHARработает следующим образом: если символ экранирования и символ кавычки равны", то будет использован RFC4180Parser, который считывает все символы между двумя двойными кавычками, при этом двойная кавычка в тексте поля должна быть экранирована двойной кавычкой (Например"поле, ""содержащее двойную кавычку"""будет считано какполе, "содержащее двойную кавычку"). В противном случае будет использован CSVParser, использующий символ экранирования для обозначения «непечатаемых символов».Параметр
CSV_PARSER_FIELD_AS_NULLможет принимать следующие значения:EMPTY_SEPARATORS- два разделителя полей (см. csv-parser/separator) подряд считаются null. Например: строка [aaa,,ccc] содержит значения [«aaa», null, «bbb»], а строка [aaa,»»,ccc] содержит значения [«aaa», «», «bbb»].EMPTY_QUOTES- два «ограничителя строки» (см. csv-parser/escape-char) подряд считаются null. Например: строка [aaa,»»,ccc] содержит значения [«aaa», null, «bbb»], а строка [aaa,,ccc] содержит значения [«aaa», «», «bbb»].BOTH- оба варианта (см.EMPTY_SEPARATORSиEMPTY_QUOTES) считаются null. Например: обе строки [aaa,»»,ccc] и [aaa,,bbb] содержат одинаковое значение [«aaa», null, «bbb»].NEITHER- ни один из вариантов (см.EMPTY_SEPARATORSиEMPTY_QUOTES) не считается null. Например: обе строки [aaa,»»,ccc] и [aaa,,bbb] содержат одинаковое значение [«aaa», «», «bbb»].
2.2.10.2.10. Секция active
В секции active настраиваются интервалы между попытками перехода в активное состояние и времени жизни ключа флага
активности.
Например:
active:
timeout: ${ACTIVE_TIMEOUT:60}
time-to-live: ${ACTIVE_TTL:180}
Параметры настроек
timeout- интервал между попытками перехода в активное состояние;time-to-live- время жизни ключа флага активности.
2.2.10.2.11. Секция delta
Секция delta предназначена для указания настройки обработок загрузок и отправок заданий на загрузку дельт.
Например:
delta:
timeout: ${DELTA_TIMEOUT:300}
row-max-count: ${DELTA_MAX_ROWS:500000}
chunk-row-max-count: ${DELTA_CHUNK_ROWS:10000}
chunk-data-max-size: ${DELTA_CHUNK_DATA_SIZE:1048576}
# параметр ожидания перед повторной попыткой открытия дельты в случае ошибки
open-delay: ${DELTA_OPEN_DELAY:60}s
# количество попыток открытия дельты в случае ошибки
open-attempts: ${DELTA_OPEN_ATTEMPTS:5}
# период проверки открытых дельт
open-check: ${DELTA_OPEN_CHECK:60}s
# количество попыток фиксации дельты в случае ошибки
commit-attempts: ${DELTA_COMMIT_ATTEMPTS:5}
# период ожидания перед повторной попыткой фиксации дельты
commit-error-delay: ${DELTA_COMMIT_DELAY:1}s
# количество попыток отката дельты в случае ошибки
rollback-attempts: ${DELTA_COMMIT_ATTEMPTS:3}
# период ожидания перед повторной попыткой отката дельты
rollback-error-delay: ${DELTA_COMMIT_DELAY:5}s
Параметры настроек
timeout- максимальный интервал времени между первой считанной записью цикла загрузки и отправкой заданий на загрузку дельт, напримерDELTA_TIMEOUT:300;row-max-count- максимальное количество обработанных записей для старта отправки заданий на загрузку дельт, напримерDELTA_CHUNK_ROWS:10000;chunk-row-max-count- количество сообщений в одном чанке, напримерDELTA_CHUNK_ROWS:10000;chunk-data-max-size- максимальный размер чанка, напримерDELTA_CHUNK_DATA_SIZE:1048576;open-delay- параметр ожидания (в секундах) перед повторной попыткой открытия дельты в случае ошибки, напримерDELTA_OPEN_DELAY:60;open-attempts- количество попыток открытия дельты в случае ошибки, напримерDELTA_OPEN_ATTEMPTS:5;open-check- период проверки открытых дельт (в секундах), напримерDELTA_OPEN_CHECK:60;commit-attempts- количество попыток фиксации дельты в случае ошибки, напримерDELTA_COMMIT_ATTEMPTS:5;commit-error-delay- период ожидания перед повторной попыткой фиксации дельты (в секундах), напримерDELTA_COMMIT_DELAY:1;rollback-attempts- количество попыток отката дельты в случае ошибки, напримерDELTA_COMMIT_ATTEMPTS:3;rollback-error-delay- период ожидания перед повторной попыткой отката дельты (в секундах), напримерDELTA_COMMIT_DELAY:5.
2.2.10.2.12. Секция stream
Секция stream содержит настройки потоковой загрузки, в случае если поток разбивается на части.
Например:
stream:
timeout: ${DELTA_TIMEOUT:300}
row-max-count: ${DELTA_MAX_ROWS:500000}
avro-codec: zstd
Параметры настроек
timeout- максимальный интервал времени между первой считанной записью цикла загрузки и отправкой заданий на загрузку потока, напримерDELTA_TIMEOUT:300;row-max-count- максимальное количество обработанных записей для старта отправки заданий на загрузку потока, напримерDELTA_MAX_ROWS:500000;avro-codec- AVRO кодек, напримерzstd.
2.2.10.2.13. Секция response
Секция response определяет настройку времени хранения ответов по заданию в Redis.
Например:
response:
time-to-live: ${RESPONSE_TTL:36000}
Параметры настроек
time-to-live- период времени Redis, который будет хранить ответ по заданию (ключ status.<uuid>).
2.2.10.2.14. Секция component-info
В секции component-info хранятся настройки компонента сбора информации о компонентах витрины.
Например:
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# Массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается не активным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- redis.password
Параметры настроек
enabled- статус подключения компонента, указывается булево значение;datasource- массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте;datamart- схема Prostore;table-name- имя таблицы для записи информации о компоненте;create-table-period- период попыток создания схемы, при неуспехе, указывается в секундах;publish-period- период публикации health-check, указывается в секундах;timeout-active- период после которого компонент считается неактивным при отсутствии health-check, указывается в секундах;secrets- список элементов конфига маскируемых при отправке, если указан узловой элемент, то маскируются все вложенные в него элементы.
2.2.10.2.15. Секция metrics
Секция metrics предназначена для настройки параметров метрик.
Например:
metrics:
port: ${METRICS_PORT:9837}
Параметры настроек
port- порт для метрик, напримерMETRICS_PORT:9837.
2.2.11. Настройка DTM-Uploader
Загрузка данных в систему производится в виде файлов по HTTP, каждый из которых имеет структуру, представленную на Структура загружаемых сообщений.
Рисунок - 2.38 Структура загружаемых сообщений
Для успешной загрузки данные должны соответствовать следующим условиям:
Тело сообщения представляет собой файл Avro (Object Container File), который состоит из заголовка и блоков данных.
Заголовок файла содержит схему данных Avro.
Схема данных содержит следующие элементы:
имя;
тип “record”;
перечень полей.
Последним полем схемы должно быть указано служебное поле
sys_opс типом данныхavro.int.Каждый блок данных содержит запись, представленную в бинарной кодировке.
Каждая запись содержит перечень полей и их значений.
Состав и порядок полей должны совпадать во всех следующих объектах:
в схеме данных заголовка файла Avro;
в наборе загружаемых записей;
во внешней таблице загрузки (поле
sys_opдолжно отсутствовать);в таблице-приемнике данных (поле
sys_opдолжно отсутствовать).
Более подробно про формат данных Avro описано в источнике: https://avro.apache.org/docs/1.10.2/spec.html#Object+Container+Files
Примечание
В загружаемой схеме данных Avro и записях Avro важны порядок и тип полей. Имена полей не сравниваются с именами полей внешней таблицы и таблицы-приемника.
Пример ниже содержит схему данных Avro, используемую для загрузки данных о сотрудниках в таблицу staff.
Для поля date_of_birth указан логический тип Avro, для поля middle_name — элемент union (поле является не обязательным
для заполнения, поэтому маркер null выведен в отдельный параметр).
Пример схемы данных Avro:
{
"name": "staff",
"type": "record",
"fields": [
{
"name": "id",
"type": "long"
},
{
"name": "firstname",
"type": "string"
},
{
"name": "lastname",
"type": "string"
},
{
"name": "middle_name",
"type": [
"null",
"string"
]
},
{
"name": "date_of_birth",
"type": {
"logicalType": "timestamp-micros",
"type": "long"
}
},
{
"name": "employee_position",
"type": "string"
},
{
"name": "department_category",
"type": "long"
},
{
"name": "sys_op",
"type": "int"
}
]
}
Пример ниже содержит набор записей о сотрудниках, загружаемых в таблицу staff.
Для наглядности примера бинарные данные представлены в JSON-формате.
[
{
"id": 1000111,
"firstname": "Елена",
"lastname": "Фролова",
"middle_name": "Андреевна",
"date_of_birth": 4641084000000000,
"employee_position": "Менеджер по подбору персонала",
"department_category": 1,
"description": "Сотрудники отдела кадров",
"sys_op": 0
},
{
"id": 1000005,
"firstname": "Пётр",
"lastname": "Платонов",
"middle_name": "",
"date_of_birth": 5639904000000000,
"employee_position": "Руководитель отдела кадров",
"department_category": 1,
"description": "Сотрудники отдела кадров",
"sys_op": 0
}
]
Функциональные особенности реализованного ETL включают в себя следующие пункты:
Генерация первичных ключей записей, передаваемых для загрузки, производится на стороне источника.
Каждая Avro-структура должна содержать данные только для одной таблицы Витрины.
В Avro-структурах данных источник заполняет тип операции
sys_op:0 – для добавления новой или обновления существующей записи;
1 – для удаления существующей записи (см. пример записей Avro в Основные требования к исходным файлам).
ETL не выполняет преобразования данных, предназначенных для загрузки на Витрину данных.
При выполнении операций, требующих консистентности данных, в рамках одной дельты могут быть только операции одного типа: либо добавления/обновления, либо удаления. При этом в рамках одной дельты первичные ключи всех записей должны быть уникальны.
Не должно быть двух версий одной записи в рамках одной дельты.
Нельзя менять порядок атрибутов в avro-схеме, поскольку данные при загрузке в БД распределяются в соответствии с тем перечнем, который был указан в avro-схеме.
Этапы настройки Proxy API включают в себя следующие шаги:
Для начала необходимо пройти авторизацию в Datamart Studio. Сделать это можно, направив запрос ниже:
curl -X POST \
'http://<ip-studio>:8088/api/v1/auth_system' \
-d "username=<username>" \
-d "password=<password>" \
-d "organization_ogrn=<organization_ogrn>" \
-d "datamart_mnemonic=<datamart_mnemonic>"
где:
ip-studio— ip-адрес Datamart Studio;username— имя пользователя IAM;password— пароль пользователя IAM;organization_ogrn— ОГРН организации, в рамках которой развернута Витрина данных;datamart_mnemonic— мнемоника Витрины (пример: eduejd##, где ## – номер региона).
Примечание
Безопасность передачи данных по протоколу HTTP обеспечивается защищенной сетью. Требуется обращать внимание на протокол запроса. Если он будет некорректным (например, HTTPS вместо HTTP), то ответ сервера будет содержать ошибку с кодом 500 - InternalServerError.
Пример успешного ответа Datamart Studio на запрос токена представлен ниже:
{
"access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICI5NGRuNzhOeVF2TjBhRG3NMcUdkc0tTOTNlTWxjNkRwRjZ5V1NXSUo4In0.eyJleHAiOjE2OTMzMTg0NzIsImlhdCI6MTY5MzMxNDg3MiwianRpIjoiYTJkNTQ5NDktZWYwZC00MzA1LWI5OTAtMDIxMTAyZDkzODU2IiwiaXNzIjoiaHR0cHM6Ly9rYy5kYXRhbWFydC5ydS9yZWFsbXMvc3R1ZGlvLWRldiIsInN1YiI6IjE1NjdkYWI3LTc1OTAtNGM0Zi1iNWNhLWYzMmFkOTU1NThjYyIsInR5cCI6IkJlYXJlciIsImF6cCI6InN0dWRpbyIsInNlc3Npb25fc3RhdGUiOiJlMGE0MjJlZC1hNDQxLTQzY2MtYTAxMS01MzNiY2RiNTc5OGQiLCJhY3IiOiIxIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInN1cGVyYWRtaW4iLCJhZG1pbiJdfSwic2NvcGUiOiJvcGVuaWQgZW1haWwiLCJzaWQiOiJlMGE0MjJlZC1hNDQxLTQzY2MtYTAxMS01MzNiY2RiNTc5OGQiLCJ1cG4iOiJhZG1pbiIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJhZGRyZXNzIjp7fSwibmFtZSI6ImFkbWluIGFkbWluIiwiZ3JvdXBzIjpbInN1cGVyYWRtaW4iLCJhZG1pbiJdLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhZG1pbiIsImdpdmVuX25hbWUiOiJhZG1pbiIsIm9yZ2FuaXphdGlvbl9vZ3JuIjpbIjExMTIyMjMzMzQ0NCIsIjExMTEiXSwiZmFtaWx5X25hbWUiOiJhZG1pbiIsImVtYWlsIjoiYWRtaW5AYWRtaW4uYWRtaW4ifQ.BC3sREXC3nf2LNvBX8SiHKouVGqJVfUBokVJa-B-9YW0zLhnNTs7mGZVOnC-kM-5mWE6bz8du0lvxQqiGpi3HRlAv1eedcGMTf_2TmjhohAaz--zSCdLC5NSmI79r54XYTLORiWKXj5T_AY8efFwWnWgUJ1LEkd5BTQyGSTvaoJkMv7xextA_isx_WoReHC5_-3GznNtcf_hOd2J1CfMHUFjhqMRSxMkIQDPHnspgU6WUz9IeVA1VWKh1GcggqYDtrruigQcl4_f7XeJQKJ49NNVdhjHtywUVbTpEDKYh4FsgAbf3vIPYUVwGWFW0Qm7LgUCpB8UvMQfb4UYZMF4UA",
"expires_in": 3600,
"refresh_expires_in": 3600,
"refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJmYmMzOWNmNi1kZTRkLTQ2YWEtYTAwZi1iZGU3ZmFkNTJmNTgifQ.eyJleHAiOjE2OTMzMTg0NzIsImlhdCI6MTY5MzMxNDg3MiwianRpIjoiYWIxN2M0MzQtZGI4Yi00N2QwLTkyM2YtMTFiYmM3NzBiNmE4IiwiaXNzIjoiaHR0cHM6Ly9rYy5kYXRhbWFydC5ydS9yZWFsbXMvc3R1ZGlvLWRldiIsImF1ZCI6Imh0dHBzOi8va2MuZGF0YW1hcnQucnUvcmVhbG1zL3N0dWRpby1kZXYiLCJzdWIiOiIxNTY3ZGFiNy03NTkwLTRjNGYtYjVjYS1mMzJhZDk1NTU4Y2MiLCJ0eXAiOiJSZWZyZXNoIiwiYXpwIjoic3R1ZGlvIiwic2Vzc2lvbl9zdGF0ZSI6ImUwYTQyMmVkLWE0NDEtNDNjYy1hMDExLTUzM2JjZGI1Nzk4ZCIsInNjb3BlIjoib3BlbmlkIGVtYWlsIiwic2lkIjoiZTBhNDIyZWQtYTQ0MS00M2NjLWEwMTEtNTMzYmNkYjU3OThkIn0.SI6Tb6CJ5HIHwzETOyJZ-2nTLibGNq7JEQwW07fY-2M",
"token_type": "Bearer",
"id_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICI5NGRuNzhOeVF2TjBhRGtvX3NMcUdkc0tTOTNlTWxjNkRwRjZ5V1NXSUo4In0.eyJleHAiOjE2OTMzMTg0NzIsImlhdCI6MTY5MzMxNDg3MiwiYXV0aF90aW1lIjowLCJqdGkiOiI5NDM1ZDE3NS00MzE2LTQyN2QtODlkYi1lYTJkOWJlZjJmNWIiLCJpc3MiOiJodHRwczovL2tjLmRhdGFtYXJ0LnJ1L3JlYWxtcy9zdHVkaW8tZGV2IiwiYXVkIjoic3R1ZGlvIiwic3ViIjoiMTU2N2RhYjctNzU5MC00YzRmLWI1Y2EtZjMyYWQ5NTU1OGNjIiwidHlwIjoiSUQiLCJhenAiOiJzdHVkaW8iLCJzZXNzaW9uX3N0YXRlIjoiZTBhNDIyZWQtYTQ0MS00M2NjLWEwMTEtNTMzYmNkYjU3OThkIiwiYXRfaGFzaCI6Ik9UZzZoUFQtWjhhWHR1Yjl1VV91LWciLCJhY3IiOiIxIiwic2lkIjoiZTBhNDIyZWQtYTQ0MS00M2NjLWEwMTEtNTMzYmNkYjU3OThkIiwidXBuIjoiYWRtaW4iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiYWRkcmVzcyI6e30sIm5hbWUiOiJhZG1pbiBhZG1pbiIsImdyb3VwcyI6WyJzdXBlcmFkbWluIiwiYWRtaW4iXSwicHJlZmVycmVkX3VzZXJuYW1lIjoiYWRtaW4iLCJnaXZlbl9uYW1lIjoiYWRtaW4iLCJvcmdhbml6YXRpb25fb2dybiI6WyIxMTEyMjIzMzM0NDQiLCIxMTExIl0sImZhbWlseV9uYW1lIjoiYWRtaW4iLCJlbWFpbCI6ImFkbWluQGFkbWluLmFkbWluIn0.K372NBffA3xtsxyM3hixr5GF1ouHNdr8DFMBYnGQ-t-REbYcwOymvs-D-HYEsmaUhkCWjKSeLM9taLmAPloSt2hb8xN_VG4s-gc_yvGs_aHkUehTqddjGMislPyAlydzCaDVxQ5Px-TplsDzIAwm5P0V23LDU3qwnVxVR7P3Dbxi5YB84_38zjClNrDWt9YOxnPMCzDT4fnBjGXkDcQZoHo5jsbFP_K5ymugsYEumKIZyekbY_l_A-XkRcTM6SMTRhKLAvQ3lq2YguLm2LFF3e-PrGsaEymeS-Peuff5qJw5Vf9r3_nD3APCivVc0Kunl8miRpr3lsZgSAp-xi3Jow",
"not-before-policy": 0,
"session_state": "e0a422ed-a441-43cc-a011-533bcdb5798d",
"scope": "openidemail"
}
С полученным токеном послать запрос для подключения к API инсталляции Компонента «Витрина данных» для выбранной организации:
curl -X <method>
'http://<ip-studio>:8088/api/v1/secure/<organization_ogrn>/<datamart_mnemonic>/<installation_name>/<installation_id>/<request_path>' \
-H "Authorization: Bearer <access_token>" \
-H "<headers>" \
-d "<data>"
где:
ip-studio— ip-адрес Datamart Studio;organization_ogrn— ОГРН организации, в рамках которой развернута Витрина данных;datamart_mnemonic— мнемоника Витрины (пример: eduejd##, где ## – номер региона);installation_name— имя инсталляции в целевой Витрине;installation_id— идентификатор инсталляции (присутствует в ее названии);request_path— URI оригинального API инсталляции;access_token— токен Proxy API;headers— заголовки запроса;data— данные запроса.
Сначала источник данных формирует и передает файлы по REST API, которые накапливаются Компонентом ETL.
Далее данные загружаются и вставляются на Витрину данных через внешние таблицы, или удаляются. Статусы обработки каждой операции
необходимо отслеживать через Endpoint /status.
Информация о каждом шаге процесса содержится в подразделах ниже.
Под Endpoint’ом /newDelta регистрируется новая порция данных. Для того чтобы начать работу с данными, источнику данных
необходимо сгенерировать UUID (идентификатор для новой порции данных) и вставить его в запрос c Endpoint’ом /newDelta.
Согласованные данные – это данные для нескольких таблиц, которые должны попасть на Витрину данных за одну операцию вставки (то есть в одной дельте), а значит будут доступны для потребителя одномоментно (такой способ загрузки актуален, когда необходимо обновить данные).
Пример набора данных, который будет загружен или удален в рамках одной дельты представлен ниже:
{
"requestId": "6B29FC40-CA47-1067-B31D-00DD010662DA",
"dataSetName": ["product", "stock"]
}
где:
requestId— идентификатор порции изменений (дельты);dataSetName— массив имен набора данных (product и stock - имена таблиц).
Запрос с Endpoint’ом /newDelta будет иметь вид:
curl -X POST "http://<ip-studio>:8088/api/v1/secure/<organization_ogrn>/<datamart_mnemonic>/<installation_name>/<installation_id>/newDelta" -H "Authorization: Bearer <access_token>" -H 'Content-Type: application/json' -d '{"requestId": "6B29FC40-CA47-1067-B31D-00DD010662DA", "dataSetName": ["product", "stock"]}'
где:
requestId— идентификатор порции изменений (дельты), который был ранее сгенерирован;dataSetName— имя набора данных (имена таблиц).
Примечание
Данные для обновления/вставки и для удаления должны быть отдельно зарегистрированы в newDelta с разными requestId. Если требуется обновить/вставить данные, то сначала нужно зарегистрировать порцию данных через newDelta с requestId, затем прислать данные с зарегистрированным requestId через endpoint /partOfDelta (описан в Загрузка / удаление согласованных данных (Endpoint – partOfDelta)). Допускается передача как в одном файле одним запросом, так и в двух файлах двумя запросами - это не имеет значения. Главное условие - нужно отправлять только данные на обновление и вставку, и они должны быть уникальны по первичному ключу. Также в них не должно быть одинаковых записей с одним первичным ключом. Пример: отправлены два обновления одной записи (с одинаковым первичным ключом). В этом случае в хранилище Prostore попадет только одна запись, и неизвестно какая, поэтому дублей по первичному ключу отправленных с одним requestId быть не должно!
Чтобы проверить статус выполнения запроса, необходимо направить запрос с Endpoint’ом /status
(пример запроса описан в Проверка статусной информации по загрузке / удалению данных (Endpoint – status))
Если обработка запроса завершится успешно, то Витрина данных вернет JSON-ответ, содержащий статус-сообщение об успешной операции:
{
"requestId": "6B29FC40-CA47-1067-B31D-00DD010662DA",
"dataSets": [
"product",
"stock"
],
"inDeltaFlag": true,
"statusCode": "SUCCESS",
"statusMessage": "Загрузка порции данных успешно завершена"
"errors": []
}
где:
requestId— идентификатор порции изменений (дельты);statusCode— код возвращаемого статуса (SUCCESS – запрос выполнен успешно).
Пример JSON-ответа на проверку статуса, завершившегося ошибкой, приведен ниже:
{
"requestId": "6B29FC40-CA47-1067-B31D-00DD010662DA",
"statusCode": "REQUESTID_ALREADY_EXIST",
"statusMessage": "Дельта с requestId = 6B29FC40-CA47-1067-B31D-00DD010662DA уже существует. Статус загрузки дельты: SUCCESS"
}
где:
requestId— идентификатор порции изменений (дельты) который необходимо проверить;statusCode— код возвращаемого статуса (REQUESTID_ALREADY_EXIST – идентификатор уже существует в БД);statusMessage— сообщение с описанием кода ошибки.
Примечание
Для удаления записей необходимо зарегистрировать новую дельту во Endpoint’е /newDelta с новым requestId, и по зарегистрированному requestId должны быть присланы только данные на удаление.
На данном шаге выполняется накапливание порции данных, создается вставка на Витрину данных по Endpoint’у isLastChunk.
Примечание
Если в процессе загрузки вызван метод newDelta, то текущая загрузка будет прервана и порция не попадет на Витрину данных.
Чтобы отправить последнюю порцию данных для таблицы product, необходимо направить запрос с Endpoint’ом /partOfDelta с указанием
dataSetName=product и isLastChunk=true (что означает что данная порция данных - последняя). Обработка и загрузка данных
не начнется, пока не будет направлен такой же запрос, но уже по таблице stock: dataSetName=stock, isLastChunk=true.
Пример запроса на загрузку данных под ранее созданный набор данных:
curl -X POST "http://<ip-studio>:8088/api/v1/secure/<organization_ogrn>/<datamart_mnemonic>/<installation_name>/<installation_id>/partOfDelta" -H "Authorization: Bearer <access_token>" -F upload=@"./product.avro" -F dataSetName=product -F chunkNumber=0 -F isLastChunk=false -F requestId=a6212a7d-4526-4e2d-89a7-9828f380c91d
где:
upload— загружаемый avro-файл (пример avro-файла с данными представлен в разделе 2);dataSetName— имя набора данных (имя таблицы);chunkNumber— номер порции dataSet в рамках дельты;isLastChunk— флаг последней порции dataSet;requestId— идентификатор порции изменений (дельты).
В результате успешной загрузки при проверке статуса requestId (пример запроса по Endpoint’у /status представлен в Проверка статусной информации по загрузке / удалению данных (Endpoint – status))
на запрос Витрина данных вернет JSON-ответ, содержащий статус-сообщение об успешной операции.
Пример успешной загрузки:
{
"requestId": "f3947645-88c8-4044-bd8b-de273f8a8461",
"statusCode": "SUCCESS",
"statusMessage": "Порция получена."
}
где:
requestId— идентификатор порции изменений (дельты);statusCode— статус код результата запроса (SUCCESS - запрос выполнен успешно);statusMessage— описание статусного сообщения.
Если загрузка прервалась ошибкой, то при проверке статуса requestId (пример запроса по Endpoint’у /status
представлен в Проверка статусной информации по загрузке / удалению данных (Endpoint – status)) на запрос Витрина данных вернет JSON-ответ с описанием ошибки.
Пример загрузки, прерванной ошибкой:
{
"requestId": "aef2f195-b037-4aaa-b171-f2746511e7e2",
"dataSets": [
"stock"
],
"inDeltaFlag": true,
"statusCode": "ERROR",
"statusMessage": "Произошла ошибка"
"errors": [
{
"dataSet": "stock",
"errorType": "INSERT",
"message": "Ошибка вставки в таблицы: stock"
}
]
}
где:
requestId— идентификатор порции изменений (дельты);dataSets— массив имен набора данных (имен таблиц где была допущена ошибка);inDeltaFlag= true — загрузка согласованных данных производилась через endpoint /partOfDetla;status— статус код результата запроса (ERROR – внутренняя ошибка);statusMessage— описание статусного сообщения;errors— массив, ошибки загрузки или парсинга входящих данных;dataSet— название таблицы где допущена ошибка;errorType— тип ошибки;message— описание ошибки.
Примечание
Возможна ситуация, когда после падения ETL приходит запрос с requestId, который был до падения, в данном случае
Витрина данных возвращает ошибку со статусом NOT_FOUND. Необходимо снова направить запрос по Endpoint’у /newDelta с
новым requestId и начать процесс загрузки заново.
Для загрузки несогласованных данных поддерживается возможность накапливания данных, аналогично загрузке согласованных данных, описанной в Загрузка / удаление согласованных данных (Endpoint – partOfDelta).
Несогласованные данные – могут быть вставлены в разных дельтах и будут доступны потребителю постепенно по мере загрузки. Этот способ подходит для первоначальной загрузки, когда еще нет потребителей.
Вставка на Витрину данных выполнится после накопления порции или по флагу isLast, который используется для последней порции
данных. Флаг isLast подает сигнал для завершения формирования дельты, для того чтобы выполнить вставку накопленных данных и
закрыть транзакцию.
Пример запроса:
curl -X POST "http://<ip-studio>:8088/api/v1/secure/<organization_ogrn>/<datamart_mnemonic>/<installation_name>/<installation_id>/data" -H "Authorization: Bearer <access_token>" -F upload=@"./product.avro" -F dataSetName=product -F isLast=false -F requestId=a6212a7d-4526-4e2d-89a7-9828f380c91d
где:
upload— загружаемый avro-файл (пример avro-файла с данными представлен в Основные требования к исходным файлам);dataSetName— имя набора данных (имя таблицы);isLast— флаг последней порции данных (сигнал для завершения формирования дельты, для того чтобы выполнить вставку накопленных данных и закрыть транзакцию.);requestId— идентификатор порции изменений (дельты).
В результате успешной операции при проверке статуса запроса по Endpoint’у /status (пример запроса описан в Проверка статусной информации по загрузке / удалению данных (Endpoint – status))
Витрина данных вернет JSON-ответ, содержащий статус-сообщение:
{
"requestId": "6B29FC40-CA47-1067-B31D-00DD010662DA",
"statusCode": "SUCCESS",
"statusMessage": "Порция получена."
}
где:
requestId— идентификатор порции изменений (дельты);statusCode— статус код результата запроса (SUCCESS - запрос выполнен успешно);statusMessage— описание статусного сообщения.
Если загрузка прервалась ошибкой, то при проверке requestId (пример запроса по Endpoint’у /status представлен
в Проверка статусной информации по загрузке / удалению данных (Endpoint – status)) Витрина данных вернет JSON-ответ с описанием ошибки.
Пример JSON-ответа:
{
"requestId": "6B29FC40-CA47-1067-B31D-00DD010662DA",
"statusCode": "NOT_FOUND",
"statusMessage": "Не найдена дельта с requestId = 6B29FC40-CA47-1067-B31D-00DD010662DA"
}
где:
requestId— идентификатор порции изменений (дельты);statusCode— статус код результата запроса (NOT_FOUND - данные по requestId были утеряны в результате остановки сервиса, необходимо зарегистрировать новую дельту и снова загрузить данные);statusMessage— описание статусного сообщения.
Наименование |
Код |
Описание |
|---|---|---|
EMPTY_ATTACHMENT |
400 |
Нет файла вложения |
ERROR |
500 |
Внутренняя ошибка |
NOT_FOUND |
400 |
Данные не найдены, либо были утеряны в результате остановки сервиса |
PROCESSING |
400 |
Идет обработка данных |
REQUESTID_ALREADY_EXIST |
400 |
|
SUCCESS |
200 |
Успешное выполнение |
UNREGISTERED_DATASETNAME |
400 |
Незарегистрированный набор данных |
WRONG_ENDPOINT |
400 |
|
В данном разделе производится проверка статусной информации из сервисных таблиц по requestId.
Пример запроса:
Curl -X GET "http://<ip-studio>:8088/api/v1/secure/<organization_ogrn>/<datamart_mnemonic>/<installation_name>/<installation_id>/status/<requestId>" -H "Authorization: Bearer <access_token>"
где:
requestId— UUID идентификатор порции изменений (дельты).
Пример ответа на такой запрос представлен ниже.
{
"requestId": "13f2475e-f3dc-4c9e-b2f6-3a98320261f1",
"inDeltaFlag": false,
"dataSets": [
"stock"
],
"status": "ERROR",
"statusMessage": "Произошла ошибка",
"errors": [
{
"dataSet": "stock",
"errorType": "PARCING",
"message": "Неверно указан тип поля count_pieces: LONG. Ожидается: INTEGER"
},
{
"dataSet": "stock",
"errorType": "PARCING",
"message": "Неверно указан тип поля product_id: LONG. Ожидается: INTEGER"
}
]
}
где:
requestId— UUID идентификатор порции изменений (дельты);inDeltaFlag = false— загрузка несогласованных данных производилась через endpoint /data;dataSets— массив имен набора данных (имен таблиц где была допущена ошибка);status— статус код результата запроса (NOT_FOUND, PROCESSING, ERROR, SUCCESS);statusMessage— описание статусного сообщения;errors— массив, ошибки загрузки или парсинга входящих данных;dataSet— название таблицы где допущена ошибка;errorType— тип ошибки;message— описание ошибки.
Перед загрузкой источнику данных необходимо сгенерировать UUID (идентификатор для новой порции данных) и вставить его в запрос с
Endpoint’ом /uploadAttachment. При совпадении имен вложений в хранилище, вложение перезаписывается. Пример запроса на загрузку
вложения в хранилище представлен ниже:
curl -X POST "http://<ip-studio>:8088/api/v1/secure/<organization_ogrn>/<datamart_mnemonic>/<installation_name>/<installation_id>/uploadAttachment" -H "Authorization: Bearer <access_token>" -F upload=@"document.pdf" -F requestId=13f2475e-f3dc-4c9e-b2f6-3a98320261f1 -F name=Doc_1
где:
upload— путь до загружаемого файла-вложения;requestId— UUID идентификатор запроса;name— уникальное имя вложения.
После успешной загрузки при проверке по Endpoint’у /status (пример запроса описан в Проверка статусной информации по загрузке / удалению данных (Endpoint – status)) Витрина данных
вернет JSON-ответ, содержащий статус-сообщение:
{
"requestId": "13f2475e-f3dc-4c9e-b2f6-3a98320261f1",
"statusCode": "UPDATED",
"statusMessage": "Файл Doc_1 успешно обновлен."
}
где:
requestId— UUID идентификатор запроса;statusCode— статус код результата запроса (SUCCESS - запрос выполнен успешно; UPDATED – данные обновлены);statusMessage— описание статусного сообщения.
Пример неуспешной загрузки после проверки по endpoint’у /status (пример запроса описан в Проверка статусной информации по загрузке / удалению данных (Endpoint – status)) представлен ниже:
{
"requestId": "13f2475e-f3dc-4c9e-b2f6-3a98320261f1",
"statusCode": "ERROR",
"statusMessage": "Произошла ошибка"
}
где:
requestId— UUID идентификатор запроса;statusCode— статус код результата запроса (ERROR – запрос завершился ошибкой);statusMessage— описание статусного сообщения.
Для того чтобы удалить вложения из хранилища S3 необходимо направить следующий запрос:
curl -X DELETE "http://<ip-studio>:8088/api/v1/secure/<organization_ogrn>/<datamart_mnemonic>/<installation_name>/<installation_id>/deleteAttachment/Doc_1/requestId/<requestId>" -H "Authorization: Bearer <access_token>"
где:
requestId— UUID идентификатор запроса.
В результате успешного удаления Витрина данных вернет JSON-ответ, содержащий статус-сообщение:
{
"requestId": "13f2475e-f3dc-4c9e-b2f6-3a98320261f1",
"statusCode": "SUCCESS",
"statusMessage": "Файл Doc_1 успешно удален."
}
где:
requestId— UUID идентификатор запроса;statusCode— статус код результата запроса (SUCCESS - запрос выполнен успешно);statusMessage— описание статусного сообщения.
Если удаление завершилось ошибкой, то Витрина данных вернет JSON-ответ c кодом ошибки:
{
"requestId": "13f2475e-f3dc-4c9e-b2f6-3a98320261f1",
"statusCode": "NOT_FOUND",
"statusMessage": "Файл Doc_1 не найден."
}
где:
requestId— UUID идентификатор запроса;statusCode— статус код результата запроса (NOT_FOUND);statusMessage— описание статусного сообщения.
Наименование |
Код |
Описание |
|---|---|---|
EMPTY_ATTACHMENT |
400 |
Нет файла вложения |
ERROR |
500 |
Внутренняя ошибка |
SUCCESS |
200 |
Успешное выполнение |
UPDATED |
200 |
Данные обновлены |
В данном разделе описывается генерация файла маппинга. Endpoint предназначен для первичной настройки, а также перенастройки сервиса в случае изменения модели данных Витрины.
Файл маппинга генерируется источником данных в формате Kotlin-script. В файле описана модель данных Витрины данных в виде
структуры объектов Kotlin (table, column). Объекты table описывают таблицы, каждый из них содержит имя таблицы и
список колонок в том порядке, в котором они созданы на Витрине. Объекты column описывают колонки, каждый из них содержит имя
колонки, тип данных, признак обязательности (nullable), признак первичного ключа.
Файл используется сервисом для описания модели данных и валидации входящих данных. Выполняются следующие проверки:
проверяется соответствие состава полей входящей avro-структуры составу полей, описанных в файле маппинга;
проверяется соответствие порядка полей входящей avro-структуры порядку полей, описанных в файле маппинга;
проверяется соответствие типов данных полей входящей avro-структуры типам полей, описанных в файле маппинга. Для полей с установленным признаком обязательности (nullable = false) выполняется проверка на null.
При вызове Endpoint’а /generateMapping сервис генерирует файл на основе информации о модели, полученной из развернутой Витрины
данных. Файл складывается сервисом на диск, а также возвращается в ответе на вызов.
Пример запроса на генерацию маппинга представлен ниже:
curl -X GET "http://<ip-studio>:8088/api/v1/secure/<organization_ogrn>/<datamart_mnemonic>/<installation_name>/<installation_id>/generateMapping/aef2f195-0001-4aaa-b171-f2746511e889" -H "Authorization: Bearer <access_token>"
Результат Витрина данных вернет в формате Kotlin-script:
import ru.supercode.mapping.common.ColumnType.*
import ru.supercode.mapping.mapper.dsl.mappingAvro
mappingAvro {
table("product") {
column("id", INTEGER) { nullable = false; primary = true; }
column("name", STRING) { nullable = false; }
}
table("stock") {
column("product_id", INTEGER) { nullable = false; primary = true; }
column("count_pieces", INTEGER) { nullable = false; }
}
}
Валидация порции данных производится в момент обработки и вставки.
Примечание
Помимо валидации данных осуществляется валидация параметров запроса. Во всех Endpoint’ах requestId должен быть в формате UUID.
В случае ошибок валидации результат будет возвращен при вызове Endpoint’а /status.
Ошибки, возникающие в процессе обработки Endpoint’а /newDelta:
отклоняются запросы, которые получены в момент обработки порции данных (
statusCode: PROCESSED);если пустой параметр
dataSetName;прислан запрос с уже зарегистрированным
requestIdиstatusCodeданногоrequestIdне равенNOT_FOUNDилиWAIT_DATA.
Ошибки, возникающие в процессе обработки Endpoint’а /partOfDelta:
прислан запрос с незарегистрированным
requestId;прислан запрос с уже зарегистрированным
requestIdиstatusCodeданногоrequestIdне равенNOT_FOUNDилиWAIT_DATA;прислан запрос с
requestIdзарегистрированным для Endpoint’а/data;прислан запрос с параметром
dataSetName, который не был зарегистрирован в Endpoint’е/newDelta;нет файла вложения в параметре
upload.
Ошибки, возникающие в процессе обработки Endpoint’а /data:
отклоняются запросы, которые получены в момент обработки порции данных (
statusCode: PROCESSED);прислан запрос с незарегистрированным
requestId;прислан запрос с уже зарегистрированным
requestIdиstatusCodeданногоrequestIdне равенNOT_FOUNDилиWAIT_DATA;прислан запрос с
requestIdзарегистрированным для Endpoint’а/partOfDelta;нет файла вложения в параметре
upload.
Ошибки, возникающие в процессе обработки Endpoint’а /uploadAttachment:
нет файла вложения в параметре
upload.
Ошибки, возникающие в процессе обработки Endpoint’а /generateMapping:
не созданы логические таблицы в схеме.
2.2.12. Настройка REST-Uploader – Модуль асинхронной загрузки данных из сторонних источников
2.2.12.1. Конфигурация модуля REST-Uploader (application.yml)
Файл application.yml – основной конфигурационный файл модуля, в котором задана его логика и порядок работы модуля:
асинхронная загрузка данных из источников, настройка подключения к ядру витрины (секция: prostore), а также другие
настройки необходимые для корректной работы модуля.
2.2.12.1.1. Пример файла application.yml
В конфигурационном файле следует задавать только те настройки, которые необходимы для решения текущих бизнес-задач.
http-server:
port: ${SERVER_PORT:8081}
executor:
reader-pool-size: ${EXECUTOR_READER_POOL_SIZE:20}
file-size:
restriction: ${SEND_FILE_SIZE_RESTRICTION:512}
environment:
# Название окружения
name: ${ENVIRONMENT_NAME:test}
data-storage:
compress: ${DATA_STORAGE_COMPRESS:zstd} # zstd/none редактируется синхронно для модулей rest-uploader/data-uploader!!!
compression-ratio: ${DATA_STORAGE_COMPRESSION_RATIO:4} # допустимый диапазон [-7;22] где -7 самый быстрый, а 22 наибольшее сжатие
type: ${DATA_STORAGE_TYPE:dir} # redis|dir|s3|prostore
# Директория хранения файлов для типа dir
dir: ${DATA_STORAGE_DIR:/upload/data}
s3:
endpoint: ${S3_ENDPOINT:http://127.0.0.1:9000/}
region: ${S3_REGION:}
bucket: ${S3_BUCKET:data} # Имя бакета
access-key: ${S3_USER:minioadmin} # Пользователь, под которым происходит взаимодействие с s3
secret-key: ${S3_PASSWORD:minioadmin} # Пароль пользователя для взаимодействия с s3
conditions:
# включение ФЛК и поведение при обнаружении ошибок
mode: warning
# период хранения журналов ошибок
save-time: 1d
# путь хранения журналов ошибок на общем диске:
save-path: /tmp/rest-uploader/reports
# путь к хранению правил в Zookeeper
zookeeper-path: rest-uploader/conditions
# Таймаут обработки запроса. 0 - таймаут отключен
rest-timeout: ${CONDITIONS_REST_TIMEOUT:60s}
# период жизни группы
save_group_time: 1d
validation:
# таймаут выполнения асинхронной проверки
validation-timeout: 1h
# таймаут получения сообщений из redis (используется при persistence-mode: zookeeper&redis)
# значение должно быть меньше чем redis.net-client-options.tcp-user-timeout
poll-timeout: 15s
# таймаут периодического опроса prostore для получения данных из очереди (используется при persistence-mode: prostore)
poll-interval: 5s
# количество корутин асинхронной валидации
max-concurrent-handle: 1
# размер порции вычитки сообщений из redis
batch-size: 1
# признак выполнения проверки кодировки
charset-check-enabled: true
# допустимые кодировки для механизма автоопределения
valid-charsets: [ UTF-8, US-ASCII, TIS-620]
health-check:
# период жизни флага активности
timeout-active: 3m
# период обновления статуса
publish-period: 30s
zookeeper:
connection-string: ${ZOOKEEPER_DS_ADDRESS:localhost}
connection-timeout-ms: ${ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000}
session-timeout-ms: ${ZOOKEEPER_DS_SESSION_TIMEOUT_MS:40000}
chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}
retry-count: 3
retry-base-sleep-time-ms: 1_000
persistence-mode: ${PERSISTENCE_MODE:prostore} # prostore, zookeeper&redis
prostore-rest-client: # требуется синхронно менять в приложениях rest-uploader и data-uploader !!!
persistence-datamart: ${PERSISTENCE_DATAMART:persistence}
datasource: ${PERSISTENCE_DATASOURCE:} # по умолчанию пусто, тогда берется единственный датасорс из настроек Простора
table-conditions: ${PERSISTENCE_TABLE_CONDITIONS:rest_uploader_conditions}
table-ids: ${PERSISTENCE_TABLE_IDS:rest_uploader_ids}
# Таблица активных экземляров сервиса rest-uploader (используется при persistence-mode: prostore)
table-rest-uploader-health-check: ${PERSISTENCE_TABLE_HEALTH_CHECK:rest_uploader_health_check}
# Таблица групп файлов (используется при persistence-mode: prostore)
table-group-info: ${PERSISTENCE_TABLE_GROUP_INFO:group_info}
# Таблица данных о файлах в группе (используется при persistence-mode: prostore)
table-group-content: ${PERSISTENCE_TABLE_GROUP_CONTENT:group_content}
# Таблица уникальных значений полей в группе (используется при persistence-mode: prostore)
table-group-uniq: ${PERSISTENCE_TABLE_GROUP_UNIQ:group_uniq}
# Таблица очереди файлов на ФЛК (используется при persistence-mode: prostore)
table-validation-queue: ${PERSISTENCE_TABLE_VALIDATION_QUEUE:validation_queue}
# Таблица очереди файлов на загрузку (используется при persistence-mode: prostore)
table-validation-complete: ${PERSISTENCE_TABLE_VALIDATION_COMPLETE:validation_complete}
# Таблица статусов запросов (используется при persistence-mode: prostore)
table-requests-status: ${PERSISTENCE_TABLE_STATUS:status}
# Таблица с файлами (используется при persistence-mode: prostore)
table-files: ${PERSISTENCE_TABLE_FILES:files}
max-retry: 3 # количество попыток выполнить запрос, в случае переключения datasource
recovery-await-timeout: 10s # таймаут ожидания восстановления datasource
recovery-retry-delay: 1s # задержка между попытками восстановить datasource
host: ${PS_HOST:localhost}
port: ${PS_PORT:9090}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
migration:
enabled: ${MIGRATION_ENABLE:true}
response:
time-to-live: ${RESPONSE_TTL:10h} # Период хранения информации о статусе запроса
control:
delta:
# подключение возможности управления дельтами от клиента. Управление дельтами от клиента допускается только при настройках
# delta-> creating-delta-on-upload-request=disable у модулей data-uploader/podd-adapter-mppw
enable: ${CONTROL_DELTA_ENABLE:true}
redis:
type: ${REDIS_TYPE:STANDALONE}
connection-string: ${REDIS_CONNECTION_STRING:redis://localhost:6379}
password: ${REDIS_PASSWORD:eYVX7EwVmmxKPCDmwMtyKVge8oLd2t81}
max-pool-size: ${REDIS_MAX_POOL_SIZE:6}
max-pool-waiting: ${REDIS_MAX_POOL_WAITING:24}
max-waiting-handlers: ${REDIS_MAX_WAITING_HANDLERS:32}
net-client-options:
tcp-user-timeout-duration: 30s
idle-timeout-duration: 30s
auth:
secret: ${AUTH_SECRET:gPHaT%ACXGQaQ30%1id%K7@C}
enabled: ${AUTH_ENABLED:true}
access-list-path: rest-uploader/ids
metrics:
port: ${METRICS_PORT:9837}
# Настройки парсера csv файлов
csv-parser:
# Символ разделителя значений
separator: ${CSV_PARSER_SEPARATOR:;}
# Символ кавычки
quote-char: ${CSV_PARSER_QUOTE_CHAR:"}
# Символ экранирования значений
escape-char: ${CSV_PARSER_ESCAPE_CHAR:'}
# Настройка интерпретации значений как null. Допустимые значения:
# - EMPTY_SEPARATORS - пустое значение между двумя разделителями, например ;;
# - EMPTY_QUOTES - пустые кавычки, например ;"";
# - BOTH - оба варианта
# - NEITHER - никогда. Пустая строка всегда определяется как пустая строка
field-as-null: ${CSV_PARSER_FIELD_AS_NULL:EMPTY_SEPARATORS}
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# Массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается неактивным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- redis.password
# Настройки числа повторов и задержек в случае ошибок
retries:
# Задержка перед повторной попыткой повтора в случае ошибки удаления
delete-delay: 1m
# Число попыток удаления файла в случае ошибки удаления
delete-retries: 10
# Задержка перед повторной попыткой повтора в случае ошибки изменения статуса
status-change-delay: 1m
# Число попыток установить статус обработки ФЛК в случае ошибки изменения статуса
status-change-retries: 1000000
2.2.12.2. Параметры конфигурации
Настройка конфигурации REST-uploader осуществляется путем редактирования параметров настроек в файле
application.yml, где настраиваются секции:
http-server- указывается порт сервера;executor- настраивается размер пула для запросов;file-size- настраиваются ограничения на размер загружаемого файла;environment- настройки окружения;data-storage- директория хранения файлов для типаdir;conditions- включение форматно-логического контроля и поведение при обнаружении ошибок;zookeeper- настройки подключения к Zookeeper;persistence-mode- настройки хранения данных;prostore-api-client- блок параметров конфигурирования взаимодействия с Prostore;migration- настройки миграции;response- настройка периода хранения информации о статусе запроса;control- подключение возможности управления дельтами от клиента;redis- настройка подключения к Redis;auth- указывается секрет для валидации токенов;metrics- настройка получения метрик;csv-parser- настройка парсинга CSV;component-info- настройки модуля сбора информации о компонентах витрины;retries- настройки числа повторов и задержек в случае ошибок.
2.2.12.2.1. Секция http-server
В секции http-server указывается порт веб-сервера.
Например:
http-server:
port: ${SERVER_PORT:8081}
Параметры настроек
port- порт веб-сервера, например:SERVER_PORT:8081.
2.2.12.2.2. Секция executor
Секция executor предназначена для указания размера пула для запросов.
Например:
executor:
reader-pool-size: ${EXECUTOR_READER_POOL_SIZE:20}
Параметры настроек
reader-pool-size- Размер пула для запросов, напримерEXECUTOR_READER_POOL_SIZE:20
2.2.12.2.3. Секция file-size
В секции file-size можно настраивать ограничения на размер загружаемого файла.
Например:
file-size:
restriction: ${SEND_FILE_SIZE_RESTRICTION:512}
Параметры настроек
file-size-restriction- ограничение на размер загружаемого файла, напримерSEND_FILE_SIZE_RESTRICTION:512.
2.2.12.2.4. Секция environment
Секция environment предназначена для настройки среды окружения.
Например:
environment:
name: ${ENVIRONMENT_NAME:test}
Параметры настроек
name- Название окружения, напримерENVIRONMENT_NAME:test.
2.2.12.2.5. Секция data-storage
В секции data-storage указывается директория хранения файлов для типа dir.
Например:
data-storage:
compress: ${DATA_STORAGE_COMPRESS:zstd} # zstd/none
compression-ratio: ${DATA_STORAGE_COMPRESSION_RATIO:4} # допустимый диапазон [-7;22] где -7 самый быстрый, а 22 наибольшее сжатие
type: ${DATA_STORAGE_TYPE:dir} # redis|dir|s3|prostore
# Директория хранения файлов для типа dir
dir: ${DATA_STORAGE_DIR:/upload/data}
s3:
endpoint: ${S3_ENDPOINT:http://127.0.0.1:9000/}
bucket: ${S3_BUCKET:data} # Имя бакета
region: ${S3_REGION:}
access-key: ${S3_USER:minioadmin} # Пользователь, под которым происходит взаимодействие с s3
secret-key: ${S3_PASSWORD:minioadmin} # Пароль пользователя для взаимодействия с s3
Параметры настроек
compress- настройки сжатия директории хранения файлов, напримерDATA_STORAGE_COMPRESS:zstd;type- тип файлов, напримерDATA_STORAGE_TYPE:dir(возможные значения: redis / dir / s3);dir- директория хранения файлов для типа dir, напримерDDATA_STORAGE_DIR:/upload/data;s3- настройки облачного хранилища S3;endpoint- адрес конечной точки, напримерS3_ENDPOINT:http://127.0.0.1:9000/;bucket- имя бакета, напримерS3_BUCKET:data;region- регион хранилища;access-key- пользователь, под которым происходит взаимодействие с s3, напримерS3_USER:minioadmin;secret-key- пароль пользователя для взаимодействия с s3, напримерS3_PASSWORD:minioadmin.
Примечание
Блок compress редактируется синхронно для модулей REST-Uploader/DATA-Uploader
2.2.12.2.6. Секция conditions
В секции conditions - реализована возможность включения форматно-логического контроля и настройки поведения при
обнаружении ошибок.
Например:
conditions:
# включение ФЛК и поведение при обнаружении ошибок
mode: warning
# период хранения журналов ошибок
save-time: 1d
# путь хранения журналов ошибок на общем диске:
save-path: /tmp/rest-uploader/reports
# путь к хранению правил в Zookeeper
zookeeper-path: rest-uploader/conditions
# Таймаут обработки запроса. 0 - таймаут отключен
rest-timeout: ${CONDITIONS_REST_TIMEOUT:60s}
# период жизни группы
save_group_time: 1d
validation:
# таймаут выполнения асинхронной проверки
validation-timeout: 1h
# таймаут получения сообщений из redis (используется при persistence-mode: zookeeper&redis)
# значение должно быть меньше чем redis.net-client-options.tcp-user-timeout
poll-timeout: 15s
# таймаут периодического опроса prostore для получения данных из очереди (используется при persistence-mode: prostore)
poll-interval: 5s
# количество корутин асинхронной валидации
max-concurrent-handle: 1
# размер порции вычитки сообщений из redis
batch-size: 1
# признак выполнения проверки кодировки
charset-check-enabled: true
# допустимые кодировки для механизма автоопределения
valid-charsets: [ UTF-8, US-ASCII, TIS-620]
health-check:
# период жизни флага активности
timeout-active: 3m
# период обновления статуса
publish-period: 30s
Параметры настроек
mode- включение ФЛК и поведение при обнаружении ошибок, напримерwarning;save-time- период хранения журналов ошибок, например1d;save-path- путь хранения журналов ошибок на общем диске, например/tmp/rest-uploader/reports;zookeeper-path- путь к хранению правил в Zookeeper, напримерrest-uploader/conditions;rest-timeout- таймаут обработки запроса, например60s,0- таймаут отключен;save_group_time- период жизни группы, например1d;validation-timeout- таймаут выполнения асинхронной проверки, например1h;poll-timeout- таймаут получения сообщений из Redis (используется при persistence-mode: zookeeper&redis)15s, значение должно быть меньше чем redis.net-client-options.tcp-user-timeout;poll-interval- таймаут периодического опроса Prostore для получения данных из очереди (используется при persistence-mode: prostore);max-concurrent-handle- количество корутин асинхронной валидации, например1;batch-size- размер порции вычитки сообщений из rRdis, например1;charset-check-enabled- признак выполнения проверки кодировки, напримерtrue;valid-charsets- допустимые кодировки для механизма автоопределения, напримерUTF-8, US-ASCII, TIS-620;timeout-active- период жизни флага активности, например3m;publish-period- период обновления статуса, например30s;
Для настройки mode реализованы режимы:
skip_string
При необходимости пропуска строк формируется обновленный файл и сохраняется в queue с прежним ключом, после проверки всего файла;
Подтверждается чтение комплексной записи из stream
validation_queue, которая затем удаляется из стрима;Размещается запись в list с именем
validation_complete;Записывается статус 0 – Буферизирован;
В зависимости от наличия
group_idв комплексной записи:при отсутствии
group_id– завершается обработка файла;при наличии
group_id– обновляется статус в groupContent_[group_id] и выполняется проверка комплектности группы в соответствии с шагами 3-6 Журнал по группе файлов.
warning
Подтверждается чтение комплексной записи из stream
validation_queueи удаляется из стрима;Размещается запись в list с именем
validation_complete;Записывается статус 0- Буферизирован;
В зависимости от наличия
group_idв комплексной записи:при отсутствии
group_id- завершает обработку файла;при наличии
group_id- обновляет статус в groupContent_[group_id] и выполняет проверка комплектности группы в соответствии с шагами 3-6 Журнал по группе файлов.
skip_file/ skip_on_first_error
Подтверждается чтение комплексной записи из stream
validation_queue, которая затем удаляется из стрима;Удаляется файл из hset queue по ключу;
Записывается статус 7 – Ошибки ФЛК;
В зависимости от наличия
group_idв комплексной записи:при отсутствии
group_id– завершается обработка файла;при наличии
group_id– обновляется статус в groupContent_[group_id] и проверяется комплектность группы в соответствии с шагами 3-6 Журнал по группе файлов.
skip_string_except_last пропускаются строки не прошедшие ФЛК по уникальности кроме последней
При необходимости пропуска строк формируется обновленный файл и сохраняется в queue с прежним ключом, после проверки всего файла;
Подтверждается чтение комплексной записи из stream
validation_queue, которая затем удаляется из стрима;Размещается запись в list с именем
validation_complete;Записывается статус 0 – Буферизирован;
В зависимости от наличия
group_idв комплексной записи:при отсутствии
group_id– завершается обработка файла;при наличии
group_id– обновляется статус в groupContent_[group_id] и выполняется проверка комплектности группы в соответствии с шагами 3-6 Журнал по группе файлов.
2.2.12.2.7. Секция Zookeeper
В секции zookeeper указываются параметры настроек к Zookeeper.
Например:
zookeeper:
connect-string: ${ZOOKEEPER_DS_ADDRESS:localhost}
connection-timeout-ms: ${ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000}
session-timeout-ms: ${ZOOKEEPER_DS_SESSION_TIMEOUT_MS:40000}
retry-count: 3
retry-base-sleep-time-ms: 1_000
Параметры настроек
connect-string- Подключение к Zookeeper DS, напримерZOOKEEPER_DS_ADDRESS:localhost;connection-timeout-ms- Zookeeper DS таймаут подключения, напримерZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000;session-timeout-ms- Zookeeper DS таймаут сессии, напримерZOOKEEPER_DS_SESSION_TIMEOUT_MS:40000;retry-count- количество попыток подключения, например3.
2.2.12.2.8. Секция persistence-mode
В секции persistence-mode указывается настройка хранения данных: или в Prostore или в Zookeeper. в случае
выбора Prostore автоматически создаются необходимые таблицы.
Например:
persistence-mode: ${PERSISTENCE_MODE:prostore} # prostore | zookeeper
Параметры настроек
persistence-mode- настройка хранения данных, напримерPERSISTENCE_MODE:prostore.
2.2.12.2.9. Секция prostore-rest-client
В секции prostore-rest-client реализован блок параметров конфигурирования взаимодействия с Prostore.
Например:
prostore-rest-client: # требуется синхронно менять в приложениях rest-uploader и data-uploader !!!
persistence-datamart: ${PERSISTENCE_DATAMART:persistence}
datasource: ${PERSISTENCE_DATASOURCE:} # по умолчанию пусто, тогда берется единственный датасорс из настроек Простора
table-conditions: ${PERSISTENCE_TABLE_CONDITIONS:rest_uploader_conditions}
table-ids: ${PERSISTENCE_TABLE_IDS:rest_uploader_ids}
# Таблица активных экземляров сервиса rest-uploader (используется при persistence-mode: prostore)
table-rest-uploader-health-check: ${PERSISTENCE_TABLE_HEALTH_CHECK:rest_uploader_health_check}
# Таблица групп файлов (используется при persistence-mode: prostore)
table-group-info: ${PERSISTENCE_TABLE_GROUP_INFO:group_info}
# Таблица данных о файлах в группе (используется при persistence-mode: prostore)
table-group-content: ${PERSISTENCE_TABLE_GROUP_CONTENT:group_content}
# Таблица уникальных значений полей в группе (используется при persistence-mode: prostore)
table-group-uniq: ${PERSISTENCE_TABLE_GROUP_UNIQ:group_uniq}
# Таблица очереди файлов на ФЛК (используется при persistence-mode: prostore)
table-validation-queue: ${PERSISTENCE_TABLE_VALIDATION_QUEUE:validation_queue}
# Таблица очереди файлов на загрузку (используется при persistence-mode: prostore)
table-validation-complete: ${PERSISTENCE_TABLE_VALIDATION_COMPLETE:validation_complete}
# Таблица статусов запросов (используется при persistence-mode: prostore)
table-requests-status: ${PERSISTENCE_TABLE_STATUS:status}
# Таблица с файлами (используется при persistence-mode: prostore)
table-files: ${PERSISTENCE_TABLE_FILES:files}
max-retry: 3 # количество попыток выполнить запрос, в случае переключения datasource
recovery-await-timeout: 10s # таймаут ожидания восстановления datasource
recovery-retry-delay: 1s # задержка между попытками восстановить datasource
host: ${PS_HOST:localhost}
port: ${PS_PORT:9090}
http:
max-pool-size: ${PS_MAX_POOL_SIZE:8}
Параметры настроек
persistence-datamart- датамарт, где будут располагаться таблицы хранения данных, напримерPERSISTENCE_DATAMART:persistence. Используется при persistence-mode =prostore.datasource- по умолчанию пусто, в таком случае берется единственный датасорс из настроек Prostore;table-conditions- условия таблиц, напримерPERSISTENCE_TABLE_CONDITIONS:rest_uploader_conditions;table-ids- настройки идентификаторов таблиц, напримерPERSISTENCE_TABLE_IDS:rest_uploader_ids;table-rest-uploader-health-check- таблица с health-check, напримерPERSISTENCE_TABLE_HEALTH_CHECK:rest_uploader_health_check;table-group-info- таблица групп файлов, напримерPERSISTENCE_TABLE_GROUP_INFO:group_info;table-group-content- таблица данных о файлах в группе, напримерPERSISTENCE_TABLE_GROUP_CONTENT:group_content;table-group-uniq- таблица уникальных значений полей в группе, напримерPERSISTENCE_TABLE_GROUP_UNIQ:group_uniq;table-validation-queue- таблица очереди файлов на ФЛК, напримерPERSISTENCE_TABLE_VALIDATION_QUEUE:validation_queue;table-validation-complete- таблица очереди файлов на загрузку, напримерPERSISTENCE_TABLE_VALIDATION_COMPLETE:validation_complete;table-requests-status- таблица хранения статусов запросов. напримерPERSISTENCE_STATUS_TABLE:status;table-files- таблица хранения данных файлов, напримерPERSISTENCE_FILES_TABLE:files;max-retry- количество попыток выполнить запрос, в случае переключения datasource, например3;recovery-await-timeout- таймаут ожидания восстановления datasource, например10s;recovery-retry-delay- задержка между попытками восстановить datasource, например1s;host- адрес Prostore, напримерPS_HOST:t5-prostore-01.ru-central1.internal;port- порт Prostore, напримерPS_PORT:9195;max-pool-size- максимальное число подключений к Prostore, напримерPS_MAX_POOL_SIZE:8.
2.2.12.2.10. Секция migration
В секции migration настраиваются миграции из Zookeeper в Prostore.
Например:
migration:
enabled: ${MIGRATION_ENABLE:false}
Параметры настроек
enabled- подключение миграции, например{MIGRATION_ENABLE:false}.
Примечание
При включении миграции из Zookeeper должны быть заполнены настройки подключения к Zookeeper.
2.2.12.2.11. Секция response
В секции response указывается период хранения информации о статусе запроса.
Например:
response:
time-to-live: ${RESPONSE_TTL:10h}
Параметры настроек
time-to-live- период хранения информации о статусе запроса, напримерESPONSE_TTL:10h.
2.2.12.2.12. Секция control
Секция control определяет возможности управления дельтами от клиента. Управление дельтами от клиента допускается
только при настройках delta-> creating-delta-on-upload-request=disable у модулей DATA-Uploader и podd-adapter-mppw.
Например:
control:
delta:
enable: ${CONTROL_DELTA_ENABLE:true}
Параметры настроек
enable- подключение возможности управления дельтами от клиента, напримерCONTROL_DELTA_ENABLE:true.
2.2.12.2.13. Секция redis
Секция redis определяет настройки подключения к Redis.
Например:
redis:
type: ${REDIS_TYPE:STANDALONE}
connection-string: ${REDIS_CONNECTION_STRING:redis://localhost:6379}
password: ${REDIS_PASSWORD:eYVX7EwVmmxKPCDmwMtyKVge8oLd2t81}
max-pool-size: ${REDIS_MAX_POOL_SIZE:6}
max-pool-waiting: ${REDIS_MAX_POOL_WAITING:24}
max-waiting-handlers: ${REDIS_MAX_WAITING_HANDLERS:32}
net-client-options:
tcp-user-timeout-duration: 30s
idle-timeout-duration: 30s
Параметры настроек
type- тип подключения к Redis (STANDALONE/CLUSTER);connection-string- указывается список серверов для подключения (перечисление через запятую);password- пароль для подключения;max-pool-size- устанавливается максимальный размер пула;max-pool-waiting- устанавливается максимальный размер пула ожидающих команд;max-waiting-handlers- устанавливается максимальный размер ожидающих обработчиков;net-client-options- параметры Redis клиента:tcp-user-timeout-duration- таймаут на соединение;idle-timeout-duration- таймаут ожидания ответа от Redis.
2.2.12.2.14. Секция auth
Секция auth служит для хранения секрета валидации токена.
Например:
auth:
secret: ${AUTH_SECRET:gPHaT%ACXGQaQ30%1id%K7@C}
enabled: ${AUTH_ENABLED:true}
access-list-path: rest-uploader/ids
Параметры настроек
secret- cекрет для валидации токенов, напримерAUTH_SECRET:gPHaT%ACXGQaQ30%1id%K7@C;enabled- включение/отключение аутентификации, напримерAUTH_ENABLED:true;access-list-path- путь к списку доступов, напримерrest-uploader/ids.
2.2.12.2.15. Секция metrics
Секция metrics предназначена для настройки параметров метрик.
Например:
metrics:
port: ${METRICS_PORT:9837}
Параметры конфигурации
port- Порт для метрик, напримерMETRICS_PORT:9837.
2.2.12.2.16. Секция csv-parser
Примечание
При загрузке файлов с форматно-логическим контролем, важно, чтобы настройки секции csv-parser должны быть синхронизированы с соответствующими настройками csvparser Prostore. Так же настройки секции csv-parser должны быть одинаковыми в модулях CSV-Uploader (если используется его UI), REST-Uploader и DATA-Uploader.
Секция csv-parser - настройка парсинга CSV.
Например:
csv-parser:
# Символ разделителя значений
separator: ${CSV_PARSER_SEPARATOR:;}
# Символ кавычки
quote-char: ${CSV_PARSER_QUOTE_CHAR:"}
# Символ экранирования значений
escape-char: ${CSV_PARSER_ESCAPE_CHAR:'}
# Настройка интерпретации значений как null. Допустимые значения:
# - EMPTY_SEPARATORS - пустое значение между двумя разделителями, например ;;
# - EMPTY_QUOTES - пустые кавычки, например ;"";
# - BOTH - оба варианта
# - NEITHER - никогда. Пустая строка всегда определяется как пустая строка
field-as-null: ${CSV_PARSER_FIELD_AS_NULL:EMPTY_SEPARATORS}
Параметры конфигурации
separator- Символ разделителя значений, напримерCSV_PARSER_SEPARATOR:;;quote-char- символ кавычки, напримерCSV_PARSER_QUOTE_CHAR:";escape-char- Символ экранирования значений, напримерCSV_PARSER_ESCAPE_CHAR:';Настройка интерпретации значений как null. Допустимые значения:
EMPTY_SEPARATORS- пустое значение между двумя разделителями, например ;;EMPTY_QUOTES- пустые кавычки, например ;»»;BOTH- оба варианта;NEITHER- никогда. Пустая строка всегда определяется как пустая строка.
field-as-null- способ определения null поля, напримерCSV_PARSER_FIELD_AS_NULL:EMPTY_SEPARATORS;multiline-limit- параметры парсинга мультистроковых значений.
Примечание
Парсер может зависать, если в данных встречаются вложенные неэкранированные кавычки.
Параметр
CSV_PARSER_ESCAPE_CHARработает следующим образом: если символ экранирования и символ кавычки равны", то будет использован RFC4180Parser, который считывает все символы между двумя двойными кавычками, при этом двойная кавычка в тексте поля должна быть экранирована двойной кавычкой (Например"поле, ""содержащее двойную кавычку"""будет считано какполе, "содержащее двойную кавычку"). В противном случае будет использован CSVParser, использующий символ экранирования для обозначения «непечатаемых символов».Параметр
CSV_PARSER_FIELD_AS_NULLможет принимать следующие значения:EMPTY_SEPARATORS- два разделителя полей (см. csv-parser/separator) подряд считаются null. Например: строка [aaa,,ccc] содержит значения [«aaa», null, «bbb»], а строка [aaa,»»,ccc] содержит значения [«aaa», «», «bbb»].EMPTY_QUOTES- два «ограничителя строки» (см. csv-parser/escape-char) подряд считаются null. Например: строка [aaa,»»,ccc] содержит значения [«aaa», null, «bbb»], а строка [aaa,,ccc] содержит значения [«aaa», «», «bbb»].BOTH- оба варианта (см.EMPTY_SEPARATORSиEMPTY_QUOTES) считаются null. Например: обе строки [aaa,»»,ccc] и [aaa,,bbb] содержат одинаковое значение [«aaa», null, «bbb»].NEITHER- ни один из вариантов (см.EMPTY_SEPARATORSиEMPTY_QUOTES) не считается null. Например: обе строки [aaa,»»,ccc] и [aaa,,bbb] содержат одинаковое значение [«aaa», «», «bbb»].
2.2.12.2.17. Секция component-info
В секции component-info указываются настройки модуля сбора информации о компонентах витрины.
Например:
# Настройки модуля сбора информации о компонентах витрины
component-info:
enabled: true
# Массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте
datasource: []
# Схема Prostore
datamart: component_info
# Имя таблицы для записи информации о компоненте
table-name: component_info
# Период попыток создания схемы, при неуспехе
create-table-period: 60s
# Период публикации health-check
publish-period: 60s
# Период после которого компонент считается неактивным при отсутствии health-check
timeout-active: 300s
# Список элементов конфига маскируемых при отправке,
# если указан узловой элемент, то маскируются все вложенные в него элементы
secrets:
- redis.password
Параметры настроек
datasource- массив датасорсов типа ADP Prostore, которые нужно использовать для хранения данных о компоненте;datamart- схема Prostore;table-name- имя таблицы для записи информации о компоненте;create-table-period- период попыток создания схемы, в случае не успешного создания;publish-period- период публикации health-check;timeout-active- период, после которого компонент считается неактивным при отсутствии health-check;secrets- список элементов конфигурации, маскируемых при отправке, если указан узловой элемент, то маскируются все вложенные в него элементы.
2.2.12.2.18. Секция retries
В секции retries указываются настройки числа повторов и задержек в случае ошибок.
Например:
retries:
delete-delay: 1m
delete-retries: 10
status-change-delay: 1m
status-change-retries: 1000000
Параметры настроек
delete-delay- задержка перед повторной попыткой повтора в случае ошибки удаления;delete-retries- число попыток удаления файла в случае ошибки удаления;status-change-delay- задержка перед повторной попыткой повтора в случае ошибки изменения статуса;status-change-retries- число попыток установить статус обработки ФЛК в случае ошибки изменения статуса.
2.2.12.3. Проверка форматно-логического контроля
Проверка форматно-логического контроля включает в себя:
обязательные проверки, выполняющиеся вне зависимости от настроек модуля в синхронном режиме;
необязательные проверки, индивидуальные для каждой таблицы, которыми управляет администратор Системы, выполняющиеся в асинхронном режиме.
Наименование проверки |
Код ошибки |
Кириллическое описание |
|---|---|---|
Проверка уникальности |
|
Дубликат файла/группы |
Проверка парсинга файла |
|
Ошибка парсинга: текст ошибки |
Проверка кодирования |
|
Кодировка файла не соответствует кодировке UTF-8 |
Проверка превышения предельного размера файла (больше 512 Мб) |
|
Слишком большой файл |
Проверка наличия данных в файле |
|
Пустой файл |
Проверка соответствия заголовков инфосхеме |
|
Структура файла не соответствует схеме |
Проверка соответствия числа столбцов в строке |
|
Некорректное число столбцов в строке |
Проверка соответствия типам полей |
|
Значение не соответствует типу требуемый тип |
Проверка уникальности полей |
|
Значение не отвечает требованиям уникальности |
Проверка регулярных выражений |
|
Значение не соответствует регулярному выражению регулярное выражение |
Проверка соответствия условию |
|
Значение не соответствует условию условие |
Таймаут валидации |
|
Истек таймаут валидации файла |
2.2.12.3.1. Синхронная проверка ФЛК
Примечание
синхронные проверки выполняются вне зависимости от настроек модуля REST-Uploader;
синхронные проверки являются блокирующими;
ошибки синхронных проверок возвращаются в теле ответа по REST-API.
К синхронным проверкам относятся:
проверка соответствия инфосхеме:
проверка соответствия имен и количества полей в заголовках;
проверка типа данных;
проверка экранирования данных: проверка соответствия числа столбцов по каждой строке;
проверка соответствия файла кодировке UTF-8 , отсутствие BOM (при наличии BOM при загрузке удаляются начальные байты
efbbbf);проверка размера файла и наличия данных:
проверка предельного размера загружаемого файла 512Мб;
проверка наличия данных в файле.
2.2.12.3.2. Асинхронная проверка
Примечание
асинхронные проверки выполняются в зависимости от настроек модуля;
проверки не являются блокирующими (поведение при их наличии определяется конфигурацией модуля);
список проверок уникален для каждой таблицы и хранится в Zookeeper в виде отдельного YAML файла.
К асинхронным проверкам относятся:
проверка уникальности полей:
по сочетанию атрибутов (для комплексных ключей);
по заданному атрибуту;
сравнение значения с константой;
соответствие регулярному выражению.
Для одного поля возможно создать не более одной проверки одного типа, при этом у каждого поля может быть несколько проверок разных типов.
2.2.12.3.2.1. Проверка уникальности по одному или по сочетанию полей
Проверка уникальности проводится:
в рамках группы файлов, если заданы headers - для проверки в рамках группы обязательно заполнения всех полей:
group_id;group_file_num;group_file_count.
Пример запроса для проверки уникальности по группе файлов:
--проверка по сочетанию полей
fields:
id:
uniq: true
uniq-with: [type,region]
--проверка уникальности по одному полю
snils:
match: "/^[-\s\d]{11}$/"
uniq: true
2.2.12.3.2.2. Проверка соответствия заданному значению
проверка соответствия заданному значению проводится для каждого файла вне зависимости от наличия group_id;
проверка осуществляется для значений каждого поля в соответствии с заданным правилом;
проверка соответствия заданному значению включает в себя:
проверку сравнения с константой (
>,<,>=,<=,=,!=);проверку соответствия регулярному выражению (должна выполняться на основе Java Util Regexp https://docs.oracle.com/javase/7/docs/api/java/util/regex/package-summary.html )
2.2.12.3.2.3. Поведение в случае таймаута валидации
Период выполнения асинхронных проверок определяется конфигурационным параметром validation-timeout и по умолчанию
составляет 60 минут.
В случае если за указанное в настройках время асинхронные проверки не были выполнены, файл удаляется из очереди с
обогащением отчета о найденных ошибках ошибкой validationTimeout.
В случае возникновения подобной ошибки рекомендуется:
проверить регулярные выражения, по которым происходит проверка, так как неверно заданное регулярное выражение кратно увеличивает скорость проверки;
увеличить значение
validation-timeoutи повторить загрузку данных.
2.2.12.4. Статусная модель
Статус запроса к модулю 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.
Код статуса |
Описание статуса |
Действия при получении данного статуса |
|---|---|---|
-1 |
Загрузка данных в буфер |
Данный статус клиентскому приложению не возвращается, ответ вернется после того как загружаемые данные будут сохранены приложением REST-Uploader для дальнейшей загрузки |
0 |
Запрос буферизирован |
Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30 сек. |
1 |
Ожидает открытия дельты |
Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30 сек. |
2 |
В обработке (модулем DATA-Uploader) |
Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30 сек. |
3 |
Успешно обработан |
Дополнительных действий не требуется |
4 |
Ошибка обработки запроса |
Необходимо:
|
5 |
Идентификатор запроса не обнаружен |
Использовать действующий идентификатор запроса |
6 |
Форматно-логический контроль |
Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30 сек. |
7 |
Ошибки ФЛК |
В процессе ФЛК выявлены ошибки, необходимо запросить отчет ФЛК, обратившись к
REST-Uploader c запросом Далее проанализировать и устранить выявленные недочеты в загружаемых данных или скорректировать проверки ФЛК |
[1] Указанные коннекторы используются для обратной совместимости по ETL: для перехода Компонета с версии 1.х на версию 2.х без изменений ETL. По умолчанию настроено без использования Kafka и коннекторов к нему.
2.2.12.5. Спецификация модуля асинхронной загрузки данных из сторонних источников
Данная спецификация описывает эндпоинты API модуля «REST-Uploader».
2.2.13. Настройка сервиса журналирования
Сервис журналирования позволяет работать с логами прикладных модулей запущенных в средах WildFly и Kubernetes/OpenShift.
Настройка сервиса журналирования должна быть применена к каждому модулю.
Ниже приведены шаги по настройке сервиса журналирования:
Подключите FluentBit к приложению как отдельный контейнер в OpenShift:
containers:
- name: fluent-bit
image: fluent/fluent-bit:latest
volumeMounts: #перенос конфигураций, и лог файла из проекта в контейнер
- name: logger
mountPath: /fluent-bit/logger/
- name: fluent-bit-config
mountPath: /fluent-bit/etc/
terminationMessagePolicy: File
envFrom:
- configMapRef:
name: logger-fluent-bit-config-env
Создайте файл
logback.xmlдля логирования приложения ( подробнее см. документацию):
Примечание
Обязательно в appender FILE_FLUENT прописать путь до конфигураций FluentBit, иначе в контейнер логи не загрузятся. Например, <file>name-project/docker/fluentbit/conf/log.log</file>.
<configuration debug="true">
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<layout class="ch.qos.logback.classic.PatternLayout">
<pattern>
<Pattern>
%d{yyyy-MM-dd HH:mm:ss}%-5level %logger{36} - %msg%n
</Pattern>
</pattern>
</layout>
</appender>
<appender name="FILE_FLUENT" class="ch.qos.logback.core.FileAppender">
<file>docker/fluentbit/conf/log.log</file>
<append>false</append>
<layout class="ch.qos.logback.classic.PatternLayout">
<pattern>
<Pattern>
x-b3-traceid=%X{X-B3-TraceId:-} x-b3-spanid=%X{X-B3-SpanId:-} x-b3-parentspanid=%X{X-B3-ParentSpanId:-} x-b3-sampled=%X{X-B3-Sampled:-} x-b3-flags=%X{X-B3-Flags:-} caller_file_name=%file serverEventDatetime="%d" logLevel=%level threadName=%thread message="%replace(%replace(%m){'\n','\u2028'}){'\"','\''}" exception="%replace(%replace(%ex){'\"','\u2028'}){'\n','\u2028'}%nopex" callerLine=%L callerMethod="%replace(%caller){'\n','\u2028'}" loggerName="%10.10logger" callerClass=%logger{40} levelStr="%level" levelInt="%level" mdc= \n
</Pattern>
</pattern>
</layout>
</appender>
<root level="debug" additivity="false">
<appender-ref ref="STDOUT"/>
<appender-ref ref="FILE_FLUENT"/>
</root>
</configuration>
Добавьте описание конфигурации для FluentBit (подробнее см документацию ):
[SERVICE]
Flush 1
Log_Level info
Daemon off
Parsers_File /fluent-bit/etc/parsers.conf
[INPUT]
Name tail
Path /fluent-bit/logger/log.log
Tag kafka-efs
Buffer_Chunk_Size 400k
Buffer_Max_Size 6MB
Mem_Buf_Limit 6MB
Parser logfmt
Refresh_Interval 20
[FILTER]
Name record_modifier
Match kafka-efs
Record subsystem ${SUBSYSTEM}
Record distribVersion ${DISTRIBVERSION}
Record deploymentUnit ${DEPLOYMENTUNIT}
Record hostName ${HOSTNAME}
Record ipAddress ${IPADDRESS}
[FILTER]
Name modify
Match kafka-efs
Hard_copy callerClass className
[FILTER]
Name record_modifier
Match kafka-efs
Whitelist_key serverEventDatetime
Whitelist_key subsystem
Whitelist_key distribVersion
Whitelist_key deploymentUnit
Whitelist_key hostName
Whitelist_key ipAddress
Whitelist_key logLevel
Whitelist_key className
Whitelist_key threadName
Whitelist_key message
Whitelist_key x-b3-traceid
Whitelist_key x-b3-spanid
[FILTER]
Name lua
Match kafka-efs
script convert_date.lua
call convert_date_efs
[OUTPUT]
Name stdout
Match kafka-efs
Format json
json_date_key time
[OUTPUT]
Name http
Match kafka-efs
Host logstash-service.cloud.ru
Port 80
Format json
json_date_key time
Для правильной работы подключите parsers.conf.
[PARSER]
Name logfmt
Format logfmt
В конфигурационном файле
convert_date.luaнастройте форматирование даты:
function convert_date_efs(tag, timestamp, record)
local pattern = "(%d+)-(%d+)-(%d+) (%d+):(%d+):(%d+),(%d+)"
dt_str = record["serverEventDatetime"]
local year, month, day, hour, minute, seconds, milliseconds = dt_str:match(pattern)
ts = os.time{year = year, month = month, day = day, hour = hour, min = minute, sec = seconds }
ts = (ts * 1000) + milliseconds
record["serverEventDatetime"] = ts
return 2, timestamp, record
end
function convert_date_pprb(tag, timestamp, record)
local pattern = "(%d+)-(%d+)-(%d+) (%d+):(%d+):(%d+),(%d+)"
dt_str = record["serverEventDatetime"]
local year, month, day, hour, minute, seconds, milliseconds = dt_str:match(pattern)
ts = os.time{year = year, month = month, day = day, hour = hour, min = minute, sec = seconds }
ts = (ts * 1000) + milliseconds
record["timestamp"] = ts
return 2, timestamp, record
end
function convert_date_logstash(tag, timestamp, record)
local pattern = "(%d+)-(%d+)-(%d+) (%d+):(%d+):(%d+),(%d+)"
dt_str = record["serverEventDatetime"]
local year, month, day, hour, minute, seconds, milliseconds = dt_str:match(pattern)
ts = os.time{year = year, month = month, day = day, hour = hour, min = minute, sec = seconds }
ts = (ts * 1000) + milliseconds
record["time"] = ts
return 2, timestamp, record
end
Добавьте параметры модуля:
kind: ConfigMap
apiVersion: v1
metadata:
name: logger-fluent-bit-config-env
data:
MODULEID: 1.0.0
MODULEVERSION: 1.0.0
NODEID: 12345
HOSTADDRESS: 0.0.0.0
SUBSYSTEM: LOGGER-TEST
DISTRIBVERSION: 1.0.0
DEPLOYMENTUNIT: TEST-UNIT
IPADDRESS: 0.0.0.1
Настройте конфигурацию для OpenShift. Чтобы Prometheus мог идентифицировать сервис и собирать с него информацию, создайте
Serviceи укажите путь, на котором располагаются метрики приложения.
apiVersion: v1
kind: Service
metadata:
name: monitoring-rest
annotations:
description: 'Exposes Prometheus App by CLuster Ip'
prometheus.io.scrape: 'true'
prometheus.io.path: '/monitoring-rest/metrics'
prometheus.io.port: '8081'
labels:
app: monitoring-rest
spec:
type: LoadBalancer
ports:
- name: http
port: 9837
targetPort: 9837
selector:
app: monitoring-rest
2.3. Настройка сервиса мониторинга
Для мониторинга состояния работы Компонента «Витрина данных» используется связка Grafana + Prometheus.
Prometheus — система мониторинга, обладающая возможностями тонкой настройки метрик. Prometheus используется для отслеживания состояния работы компонентов системы на низком уровне.
Grafana — инструмент с открытым исходным кодом для визуализации данных из различных систем сбора статистики. Grafana используется для представления в графическом виде временных рядов и текстовых данных.
Примечание
Описание установки системы мониторинга приведено в разделе Установка системы мониторинга документа «Руководство по установке Компонента «Витрина данных».
2.3.1. Предоставление источника данных
Существует два способа предоставления источника данных:
с помощью конфигурационного файла;
с помощью интерфейса Grafana.
Каждый файл конфигурации предоставления источника данных содержит манифест, в котором указывается желаемое состояние набора подготовленных источников данных.
При запуске Grafana загружает файлы конфигурации и предоставляет источники данных, перечисленные в манифестах.
Ниже приведен пример настройки источника данных TestData , который можно использовать для информационных панелей.
В директории
provisioning/datasources/создайте файлdtm.ymlсо следующим содержимым:
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
url: <ip:port>
jsonData:
httpMethod: POST
manageAlerts: false
prometheusType: Prometheus
Перезапустите Grafana, чтобы загрузить новые изменения.
На боковой панели наведите курсор на значок « Конфигурация» (шестеренка) и нажмите «Источники данных». TestData появится в списке источников данных.
Примечание
Папка
provisioning/datasources/находится в/etc/grafana/.
Для работы Prometheus с Grafana необходимо добавить Prometheus в качестве источника получения данных в Grafana.
Откройте Grafana — Configuration — Data sources, нажмите Add data source и выберите Prometheus.
Рисунок - 2.39 Выбор Prometheus в качестве источника получения данных
В поле URL введите адрес и порт, по которому доступен Prometheus.
Рисунок - 2.40 Ввод URL Prometheus
Внизу страницы нажмите кнопку Save & test
Рисунок - 2.41 Применение настроек
После успешной проверки Prometheus будет добавлен в Grafana.
2.3.2. Предоставление информационной панели
Определить поставщика информационных панелей можно также двумя способами:
с помощью конфигурационного файла;
с помощью интерфейса Grafana.
Каждый файл конфигурации информационной панели содержит манифест, который определяет желаемое состояние набора поставщиков информационной панели.
Поставщик информационной панели сообщает Grafana, где найти и где разместить определения информационной панели.
Grafana регулярно проверяет изменения в определениях панели мониторинга (по умолчанию каждые 10 секунд).
В директории provisioning/dashboards/ создайте файл dtm.yml со следующим содержимым:
apiVersion: 1
providers:
- name: 'DTM Metrics' # Уникальное идентифицируемое имя поставщика
folder: 'dtm-metrics' # Папка, в которую помещаются дашборды
type: file
disableDeletion: false
updateIntervalSeconds: 10
allowUiUpdates: false
options:
path: <path to dashboard definitions>
foldersFromFilesStructure: false
Примечание
Папка provisioning/dashboards/ находится в /etc/grafana/.
2.3.2.1. Настройка конфигурационного файла Prometheus
Пример конфигурационного файла prometheus.yml:
global:
scrape_timeout: 5s
scrape_interval: 5s
scrape_configs:
- job_name: 'smevql-server'
static_configs:
- targets: ['ip:8080']
- job_name: 'blob-adapter'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9837']
- job_name: 'counter-provider'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9837']
- job_name: 'csv-uploader'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9837']
- job_name: 'data-uploader'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9837']
- job_name: 'podd-adapter-group-repl'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9837']
- job_name: 'podd-adapter-group-tp'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9843']
- job_name: 'podd-adapter-import-tp'
static_configs:
- targets: ['ip:19843']
- job_name: 'podd-adapter-mppr'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9843']
- job_name: 'podd-adapter-mppw'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9843']
- job_name: 'podd-adapter-query'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9837']
- job_name: 'podd-adapter-replicator'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9837']
- job_name: 'podd-avro-defragmentator'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9837']
- job_name: 'printable-form-service'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9837']
- job_name: 'rest-uploader'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9837']
- job_name: 'smev3-adapter'
static_configs:
# изменить стандартный порт в application.yml сервиса на кастомный, так как он совпадает с другими сервисами
- targets: ['ip:9033']
2.3.2.2. Health check
В данной концепции приведены health check по СМЭВ3, СМЭВ4, REST, BLOB и сервису формирования документов.
Каждый сервис, из перечисленных выше, дорабатывается таким образом, чтобы возвращать информацию liveness и readiness в виде метрик Prometheus.
Дополнительно, по каждому сервису реализуется соответствующие REST запросы: ../api/v1/health/liveness и ..api/v1/health/readiness, показывающим
liveness и readyness проверки соответственно. Обращение к каждому конкретному сервису из представленных ниже по REST, обусловлено передачей
хоста и порта в URL, соответствующих сервису согласно схеме развертывания.
liveness возвращает информацию о работоспособности сервиса.
readiness сообщает о готовности сервиса к работе.
Готовность сервиса к работе характеризуется доступностью окружающих его сервисов, с которыми ведется прямое взаимодействие.
Когда liveness проверка не проходит, то это сигнализирует о том что сервис мертв и должен быть как минимум перезагружен.
Когда readiness проверка не проходит, то это говорит о том, что проверяемый сервис не готов к принятию входящего сетевого трафика.
В будущем это приложение может прийти в готовность, но сейчас оно не должно принимать трафик.
Liveness и readiness проверки проходят успешно только в том случае, если все входящие в них проверки (свои для каждого сервиса) прошли успешно.
Примечание
Для управления всеми типами health check наружу выставляются рычаги/конфигурации, позволяющие включать/отключать проверки а также устанавливать частоту вызова и таймауты по каждой проверке. Readiness и Liveness проверки проходят в realtime. Таймауты для данных проверок должны быть выставлены с учетом того, что проверка сможет пройти в данный срок.
Liveness
Для liveness проверок вертиклов принимается следующее ограничение:
Если, например, для работы вертикла требуется Kafka, и она в данный момент времени недоступна - то, при условии что вертикл задеплоен, проверка liveness вернет положительный ответ. Отловить подобную ситуацию можно будет только на проверке Readiness.
2.3.2.2.1. BLOB-Adapter
Liveness
Проверяется состояние вертиклов. В рамках проверки осуществляется корректность деплоя вертиклов. Берется список всех вертиклов по сервису, и выполняется проверка, что они есть в списке задеплоеных вертиклов. В случае если все вертиклы задеплоены - проверка проходит успешно.
Readiness
Хранилище (внешнее или внутренне). Получение адреса хранилища. Проверка, существует ли хранилище по конкретному адресу. Порт доступен, открыт и доступен для подключения.
2.3.2.2.2. Сервис печатных форм
Liveness
Проверяется состояние вертиклов. В рамках проверки осуществляется корректность деплоя вертиклов. Берется список всех вертиклов по сервису, и выполняется проверка, что они есть в списке задеплоеных вертиклов. В случае если все вертиклы задеплоены - проверка проходит успешно.
Readiness
Prostore: получения адреса, подключение по JDBC и проверка выполнения запроса «CHECK_VERSIONS()».
Kafka агента СМЭВ4: получение строк подключения. Проверка, что Kafka существует по конкретному адресу, порт доступен, открыт и доступен для подключения.
2.3.2.2.3. СМЭВ3 адаптер
Liveness
Проверяется состояние вертиклов. В рамках проверки осуществляется корректность деплоя вертиклов. Берется список всех вертиклов по сервису, и выполняется проверка, что они есть в списке задеплоеных вертиклов. В случае если все вертиклы задеплоены - проверка проходит успешно.
Readiness
Prostore: получение адреса, подключение по JDBC и проверка выполнения запроса «CHECK_VERSIONS()».
VipNet SignerCP: если в файле конфигурации указан доступ к VipNet, то по указанной строке подключения проверяется доступность VipNet.
Postgress: получения строки подключения, подключение по JDBC и проверка выполнения запроса «select 1».
СМЭВ3: проверить telnet порт СМЭВ3 на доступность командой:
Опционально, проверить зафиксированные результаты обращений вертикла ресивера в СМЭВ3.