4. Описание технических решений

4.1. Задачи реализованных технических решений

Технические решения, реализованные при разработке программы, решают следующие задачи:

упрощение процесса установки;
создание структуры таблиц витрины;
выгрузка шаблона;
загрузка данных в витрину:
- через графический интерфейс (CSV-файлы);
- через REST API;
- через файловый обмен.
настройка параметров работы витрины через графический интерфейс;
журналирование событий функциональных блоков;
мониторинг информации о работоспособности экземпляра программы;
совместимость Типового ПО Витрина данных конфигурации Лайт с РЕД ОС версии 7.2;
совместимость Типового ПО Витрина данных конфигурации Лайт с АЛЬТ Сервер 8 СП;
совместимость Типового ПО Витрина данных конфигурации Лайт с Astra Linux 1.7;
выполнение запросов с системными параметрами.

4.1.1. Задача «Упрощение процесса установки»

Для решения этой задачи используется ansible-плейбук (playbook.yml), который выполняет следующие функции:

запускает Docker;
конфигурирует сервер (в docker-контейнере);
устанавливает Portainer (web-приложение для управления docker-контейнерами);
устанавливает программу Компонент «Витрина данных Лайт»;
настраивает взаимосвязи между компонентами витрины;
запускает программу.

Программа Portainer предоставляет графический интерфейс для управления docker-контейнерами с компонентами программы.

4.1.2. Задача «Создание структуры таблиц витрины»

Для решения этой задачи администратор витрины через web-интерфейс CSV-uploader загружает заранее сконфигурированный XML-файл со структурой витрины. Витрина на основании содержимого XML-файла создает таблицы с указанными именами и полями в своей БД.

Внимание

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

Процесс загрузки структуры витрины см. в документе «Инструкция по эксплуатации CSV-uploader».

4.1.3. Задача «Выгрузка шаблона»

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

В графическом интерфейсе администратор имеет возможность выбрать нужную таблицу, Витрина по метаданным своей БД определяет структуру выбранной таблицы и передает на ПК администратора витрины CSV-файл с шаблоном для выбранной таблицы.

Процесс выгрузки шаблона см. в документе «Инструкция по эксплуатации CSV-uploader».

4.1.4. Задача «Загрузка данных в витрину»

В программе предусмотрено три варианта загрузки данных:

через графический интерфейс (CSV-файлы);
REST API;
файловый обмен.

4.1.4.1. Загрузка данных через графический интерфейс (CSV-файлы)

Для решения этой задачи администратор витрины через графический интерфейс модуля CSV-uploader выбирает таблицу и загружает csv-файл с обновленными/добавленными данными. Витрина записывает данные в таблицу своей БД (см. документ «Инструкция по эксплуатации CSV-uploader»).

4.1.4.2. Загрузка данных через REST API

Для решения этой задачи в программе предусмотрен модуль, который выступает в качестве REST-сервера, он позволяет выполнять стандартные POST, DELETE запросы для URL, содержащие имя таблицы. Полученные данные модуль передает модулю CSV-uploader, который загружает данные в витрину.

4.1.4.3. Загрузка данных через файловый обмен

Для решения этой задачи в программе настроена периодическая проверка папки выбранной для файлового обмена. В случае появления в папке нового CSV-файла, витрина считывает его, содержимое CSV-файла передает модулю CSV-uploader, который загружает данные в витрину. После передачи данных витрина удаляет CSV-файл из папки.

4.1.5. Настройка параметров работы витрины через графический интерфейс

Для решения этой задачи разработан графический интерфейс, в котором администратор Витрины имеет возможность настроить параметры витрины (см. документ «Инструкция по эксплуатации CSV-uploader»).

4.1.6. Задача «Журналирование событий функциональных блоков»

Задача включает журналирование событий функциональных блоков программы:

Prostore;
БД Prostore (PostgreSQL);
Брокер сообщений;
БД Брокера сообщений;
ПОДД-адаптер;
CSV-uploader.

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

запись системных событий (отдельно по каждому функциональному блоку) осуществляется в лог-файлы ( см. uml_lite_logs_schema ).
предоставление возможности просмотра журнала событий (лог-файла).

Просмотр лог-файлов возможен через графический интерфейс web-приложения Grafana.

Настройку детализации лог-файлов осуществляет администратор.

4.1.7. Задача «Мониторинг информации о работоспособности экземпляра программы»

Задача включает следующие действия:

Мониторинг информации о работоспособности экземпляра Программы.

Для решения задачи применяются методы:

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

При реализации указанного метода программа предоставляет возможность контроля за рекомендуемыми метриками.

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

Сеть;
CPU.

Мониторинг осуществляется методом просмотра лог-файлов следующих компонентов программы:

Prostore;
Сервисная СУБД Prostore;
ПОДД-адаптер – Модуль исполнения запросов;
ПОДД-адаптер – Модуль MPPR;
ПОДД-адаптер – Модуль MPPW;
CSV-uploader.

Сбор лог-файлов программы c записями о событиях производится с помощью Prometheus. Процесс просмотра лог-файлов описан в разделе «Дополнительные возможности» документа «Руководство администратора».

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

4.1.8. Задача «Совместимость Типового ПО Витрина данных конфигурации Лайт с РЕД ОС версии 7.2»

Технические решения, реализованные в рамках работ по адаптации типового тиражируемого программного обеспечения «Витрина данных Лайт»» для операционной системы «РЕД ОС», выполнены в соответствии с Государственным контрактом .

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

Защита информации, обрабатываемой с использованием ПО «Витрина данных Лайт» обеспечивается самостоятельно обладателями (пользователями) государственных данных с учетом требований законодательства Российской Федерации.

ПО «Витрина данных Лайт» предназначено для загрузки публикуемых данных в отдельную базу данных на стороне обладателя данных.

В соответствии с положениями нормативных документов, указанных выше, целями создания версии ПО «Витрина данных Лайт» являются:

Адаптация ПО «Витрина данных Лайт» для расширения перечня операционных систем, под управлением которых работает ПО «Витрина данных Лайт» (операционной системы «РЕД ОС»);
Реализация и актуализация информационного контента, описывающего функциональные, архитектурные и эксплуатационные возможности ПО «Витрина данных Лайт».
Проведение тестирования модернизированного ПО «Витрина данных Лайт».

В рамках адаптации программы для работы в операционной системе «РЕД ОС» были выполнены работы:

Проверка работы CSV Uploader в операционной системе «РЕД ОС»:
- реализация загрузки схемы из XML ЕИП НСУД;
- загрузка данных CSV через интерфейс;
- загрузка данных CSV из каталога;
- журналирование загрузки со статусами;
- - экран для отображения статусов компонент;
Проверка работы ПОДД Адаптер в операционной системе «РЕД ОС»:
- чтение из Агента по алгоритму запроса;
- ответ в Агент по алгоритму запроса;
- сериализация в AVRO для запроса данных;
Проверка работы Health Check в операционной системе «РЕД ОС»:
- Health-Check - Liveness;
- Health-Check - Readyness.
Выполнение нагрузочного и регрессионного тестирования.

4.1.9. Задача «Совместимость Типового ПО Витрина данных конфигурации Лайт с АЛЬТ Сервер 8 СП»

Технические решения, реализованные в рамках работ по адаптации типового тиражируемого программного обеспечения «Витрина данных Лайт»» для операционной системы «АЛЬТ Сервер 8 СП», выполнены в соответствии с Государственным контрактом.

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

Защита информации, обрабатываемой с использованием ПО «Витрина данных Лайт» обеспечивается самостоятельно обладателями (пользователями) государственных данных с учетом требований законодательства Российской Федерации.

ПО «Витрина данных Лайт» предназначено для загрузки публикуемых данных в отдельную базу данных на стороне обладателя данных.

В соответствии с положениями нормативных документов, указанных выше, целями создания версии ПО «Витрина данных Лайт» являются:

адаптация ПО «Витрина данных Лайт» для расширения перечня операционных систем, под управлением которых работает ПО «Витрина данных Лайт» (операционной системы «АЛЬТ Сервер 8 СП»);
Реализация и актуализация информационного контента, описывающего функциональные, архитектурные и эксплуатационные возможности ПО «Витрина данных Лайт».
Проведение тестирования модернизированного ПО «Витрина данных Лайт».

В рамках адаптации программы для работы в операционной системе «АЛЬТ Сервер 8 СП» были выполнены работы:

Проверка работы CSV Uploader в операционной системе «АЛЬТ Сервер 8 СП»:
- реализация загрузки схемы из XML ЕИП НСУД;
- загрузка данных CSV через интерфейс;
- загрузка данных CSV из каталога;
- журналирование загрузки со статусами;
- экран для отображения статусов компонент;
Проверка работы ПОДД Адаптер в операционной системе «АЛЬТ Сервер 8 СП»:
- чтение из Агента по алгоритму запроса;
- ответ в Агент по алгоритму запроса;
- сериализация в AVRO для запроса данных;
Проверка работы Health Check в операционной системе «АЛЬТ Сервер 8 СП»:
- Health-Check - Liveness;
- Health-Check - Readyness.
Выполнение нагрузочного и регрессионного тестирования.

4.1.10. Задача «Совместимость Типового ПО Витрина данных конфигурации Лайт с Astra Linux 1.7»

В целях поддержки отечественной операционной системы из реестра Российского ПО, устойчивого предоставления госуслуг и межведомственного обмена обеспечена совместимость Типового ПО Витрина данных на серверах с предустановленной операционной системой Astra Linux.

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

Проведено тестирование процесса развертывания витрины данных на серверах с предустановленными операционными системами Astra Linux.
Проведено регрессионное тестирование функционирования витрины данных без подключения к ПОДД на серверах с предустановленными операционными системами Astra Linux.
Подготовлен отчет о регрессионном тестировании витрины данных на серверах с предустановленными операционными системами Astra Linux.
По итогам регрессионного тестирования выполнены необходимые доработки Типового ПО Витрина данных для обеспечения совместимости с операционными системами Astra Linux.
Подготовлены скрипты и проведено нагрузочное тестирование.
Подготовлен отчёт о результатах нагрузочного тестирования.

4.1.10.1. Описание тестирования процесса развертывания витрины данных на серверах с предустановленной операционной системой Astra Linux

Целью тестирования процесса развертывания витрины данных на серверах с предустановленными операционной системой Astra Linux:

проверка работоспособности Типового ПО «Витрина данных» конфигурации Лайт на операционной системе «Astra Linux 1.7 (уровень защищенности «Воронеж»)»;

Для проведения тестирования на операционных системах «Astra Linux 1.7 (уровень защищенности «Воронеж»)» был подготовлен тестовый стенд (схема 1) с программными компонентами, приведенными в Таблица 4.1.

Таблица 4.1 Список компонентов и версий тестового стенда для проверки совместимости Типового ПО Витрина данных
№	Название компонента	Версия
1	ПОДД Агент	einfahrt:3.2.0-pre-2
2	Agent Driver	podd-jdbc-driver-3.2.0-SNAPSHOT-fat.jar
9	Модуль исполнения запросов	podd-adapter-query:5.2.0
10	Модуль подписок	podd-adapter-replicator:1.1.0
11	Модуль группировки чанков репликации	podd-adapter-group-repl:1.1.1
12	Модуль MPPR	podd-adapter-mppr:5.1.6
13	Модуль MPPW	podd-adapter-mppw:5.1.2
19	csv-uploader	csv-uploader:1.0.26
20	Prostore	query-execution:6.0.0 status-monitor:6.0.0
21	Prostore Driver	dtm-jdbc-6.0.0.jar
22	ADP	13.4
23	PG	0.5.0
24	FDW	0.10.2
25	Zookeeper	3.5.8
26	Kafka	2.6.0

В результате установки:

Типовое ПО «Витрина данных» полностью работоспособно;
все взаимосвязи между компонентами настроены автоматически;
все необходимые компоненты запущены.

В процессе установки используется единый конфигурационный файл (настраиваемый перед установкой).

Процесс установки поддерживает детализированную диагностику возникающих ошибок.

Все возникающие в процессе установки ошибки логируются.

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

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

4.1.10.2. Описание регрессионного тестирования функционирования витрины данных без подключения к ПОДД на серверах с предустановленной операционной системой Astra Linux

Целью проведения регрессионного тестирования является проверка работоспособности Типового ПО «Витрина данных» на операционной системе Astra Linux.

Для проведения регрессионного тестирования подготовлены основные сценарии тестирования модулей Типового ПО Витрина данных конфигурации Лайт.

Каждый сценарий тестирования содержит описание шага тестирования с указанием ожидаемого результата и статусом прохождения шага.

4.1.10.3. Описание подготовки отчетов о регрессионном тестировании витрины данных на серверах с предустановленной операционной системой Astra Linux

По итогам проведения регрессионного тестирования был подготовлен отчет о регрессионном тестировании Типового ПО «Витрина данных» на сервере с предустановленной операционной системой Astra Linux.

Отчет о регрессионном тестировании содержит разделы:

цели тестирования;
конфигурация стенда для тестирования;
методика тестирования и ожидаемые контрольные результаты;
результаты тестирования;
замечания к разработке;
план доработок.

В разделе «Цели тестирования» приведены основные сценарии тестирования.

В разделе «Конфигурация стенда для тестирования» указаны версии программных компонентов ПО «Витрина данных».

В разделе «Методика тестирования и ожидаемые контрольные результаты» прописаны шаги воспроизведения каждого сценария с указанием ожидаемого результата и статуса прохождения шага.

В разделе «Результаты тестирования» приведено описание выявленных дефектов и результатов тестирования.

В разделе «Замечания к разработке» приведена таблица с описанием найденных дефектов.

В приложении «План доработок» приведен план доработок найденных дефектов.

4.1.10.4. Описание выполнения необходимых доработок Типового ПО Витрина данных по итогам регрессионного тестирования для обеспечения совместимости с операционными системами Astra Linux

По результатам регрессионного тестирования Типового ПО «Витрина данных» конфигурации Лайт на операционной системе Astra Linux замечаний к разработке не выявлено.

4.1.10.5. Описание подготовки скриптов и проведения нагрузочного тестирования

На целевых ОС нагрузочное тестирование проводится только на модулях слоя адаптеров, отвечающих за исполнение запросов LLR:

query-execution;
status-monitor;
podd-adapter-query.

Наполнение витрины данными:

модель данных тестовая с таблицей vehicleregdata (данные регистрации ТС);
1,5 млн записей в таблице vehicleregdata;
ключи генерируемых данных используют диапазон от 1 до 1,5 млн;
объем одной записи 100 байт;
избирательность прочих ( не ключевых) полей не важна, могут быть одинаковые значения.

Вид нагрузки:

запросы на получение одной записи по ключу с Limit 1 для работы в режиме LLR, фильтруемое значение выбирается случайным образом из диапазона генерированных данных;
запросы направляются в Кафка в топик query.rq, ответы фиксируются в топике query.rs;
каждый поток создает запрос и ожидает ответа, фиксирует время от запроса до ответа, следующий запрос посылает после получения ответа на предыдущий запрос.

Нагрузка:

(А) нарастает последовательно до тех пор, пока итоговая производительность не станет снижаться или пока не начнутся массовые ошибки;
1. Нарастает до расчётной стабильной и сохраняется на этом уровне.

Перед началом эксперимента необходим перезапуск ADB и стирание файлового кеша на ADB и рабочих узлах.

Накопление кеша в процессе одного эксперимента считаем естественным ускорителем.

4.1.10.6. Описание подготовки отчета о результатах нагрузочного тестирования

По итогам проведения тестирования был подготовлен отчет о нагрузочном тестировании Типового ПО «Витрина данных» на сервере с предустановленной операционной системой Astra Linux.

Отчет о нагрузочном тестировании содержит разделы:

Общие сведения;
Цели тестирования;
Основные сценарии тестирования;
Конфигурация стенда для тестирования;
Результаты тестирования;
Замечания к разработке.

В разделе «Общие сведения» приведены сведения об объекте тестирования.

В разделе «Цели тестирования» приведены основные цели проведения нагрузочных испытаний.

В разделе «Сценарии тестирования» прописаны шаги воспроизведения каждого сценария с указанием ожидаемого результата и статуса прохождения шага.

В разделе «Конфигурация стенда для тестирования» указаны версии программных компонентов ПО «Витрина данных».

В разделе «Результаты тестирования» приведено описание выявленных дефектов и результатов тестирования.

В разделе «Замечания к разработке» приведена таблица с описанием найденных дефектов.

4.1.11. Выполнение запросов с системными параметрами

4.1.11.1. Общее описание

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

Именованный параметр: указан в sql с :name, в зависимости от мнемоники, из массива namedParams в момент исполнения запроса в модуле query подставляется значение из элемента массива, соответствующего мнемонике.

Обработка системных и именованных параметров осуществляется Модулем исполнения запросов (podd-adapter-query).

Пример подстановки конструкции, соответствующей системному параметру в sql запрос представлена на рисунке ниже (см. Рисунок - 4.1).

Рисунок - 4.1 Подстановка системного параметра в sql запрос

Массив именованных параметров (для передачи системных и именованных параметров) имеет следующую структуру:

- name: namedParams
  description: Именованные параметры запроса
  default: [ ]
  type:
    type: array
    items:
      type: record
      name: NamedParam
      description: Описание именованного параметра
      fields:
        - name: name
          description: Имя (мнемоника) параметра
          type: string
        - name: type
          type: string
          description: Тип параметра
          enum:
            - BIG_DECIMAL
            - BINARY
            - BOOLEAN
            - DATE
            - DOUBLE
            - FLOAT
            - INTEGER
            - LONG
            - SHORT
            - STRING
            - TIME
            - TIMESTAMP
        - name: value
          description: Значение параметра
          type:
            - string
            - 'null'

4.1.11.2. Обработка системных параметров

Если блок namedParams не пустой, после парсинга запроса Calcite модуль podd-adapter-query проверяет наличие мнемоник системных параметров:

settings_for_system_time;

settings_for_system_time_started;

settings_for_system_time_finished.

В случае, если системный параметр есть, проверяет:

что параметр с префиксом settings_ один в списке;

сам запрос не содержит конструкцию FOR SYSTEM_TIME ни в одной из таблиц запроса;

в случае, если одно из перечисленных выше условий не выполняется, в топик query.err возвращается ошибка: DATAMART-17473 (Неверное sql-выражение: [Двойное указание темпоральности недопустимо]).

Модуль проверяет value системного параметра по маске:

для параметра settings_for_system_time value запроса должно быть таймштампом в формате YYYY-MM-DD hh:mm:ss
для параметров settings_for_system_time_started и settings_for_system_time_finished:
- два целочисленных числа разделенных запятой („int1,int2“)
в случае, если value параметра не соответствует маске, в топик query.err возвращается ошибка: DATAMART-17473 (Неверное sql-выражение: [ Недопустимое значение параметра [ имя параметра] - [ значение параметра ]])
В случае, если значение системного параметра null , возвращается ошибка: DATAMART-17473 ( Недопустимое значение параметра [имя параметра] = null )

Для параметров settings_for_system_time_started и settings_for_system_time_finished проверяет, что первое значение int или timestamp меньше последнего:

в случае, если первое значение в строке больше второго, в топик query.err возвращается ошибка: DATAMART-17473 (Неверное sql-выражение: [Недопустимый (отрицательный) диапазон значений параметра [ имя параметра] - [ значение параметра ]])

После выполнения проверок 1-4 модуль podd-adapter-query подставляет системный параметр во все таблицы запроса, после имени таблицы в блоке from. (если в запросе есть блок where, то перед этим блоком). Исключение: временные таблицы загрузки табличных параметров, так как временные таблицы являются standalone (определяем по префиксу readable в названии таблицы):

если в запросе используется системный параметр settings_for_system_time : FOR SYSTEM_TIME AS OF 'YYYY-MM-DD hh:mm:ss[.microseconds],
если в запросе используется системный параметр «settings_for_system_time_started»:
- FOR SYSTEM_TIME STARTED IN (delta_num1, delta_num2), если строка состоит из двух целочисленных значений, разделенных запятой
если в запросе используется системный параметр settings_for_system_time_finished:
- FOR SYSTEM_TIME FINISHED IN (delta_num1, delta_num2), если строка состоит из двух целочисленных значений, разделенных запятой

Подставляет в запрос остальные именованные параметры, в случае, если они присутствуют в запросе.
В случае, если в запросе есть limit и он меньше порогового значения или есть FORCE_LLR, то выполняются следующие действия:

в Prostore подается команду на получение данных через Rest-интерфейс Prostore;
данные из Prostore преобразуются в формат ПОДД и конвертирует timezone у полей, выгружаемых из Витрины к формату UTC в топик query.rs.
- в случае, если вернулась ошибка , то возвращается ответ в query.err с текстом ошибки

В случае, если в запросе отсутствует limit или настройка FORCE_LLR выключена, то передает сообщение в топик mppr.delegate.rq и завершает выполнение запроса.

Рисунок - 4.2 Схема взаимодействия компонентов

4.1.11.3. Примеры преобразования запросов

Примеры запроса query.rq с системными параметрами settings_for_system_time_started и settings_for_system_time_finished c номерами дельт

sql: select * FROM demo_view.ticket join demo_view.passenger on demo_view.passenger.id =demo_view.ticket.passengerid
__________________________________________________________________________________________
"namedParams" : [ {
    "name" : "settings_for_system_time_started",
    "type" : "STRING",
    "value" : {
    "string" : "122, 123"
    }
} ]
__________________________________________________________________________________________
преобразованный запрос, после подстановки параметра FOR SYSTEM_TIME STARTED IN:
select * FROM demo_view.ticket FOR SYSTEM_TIME STARTED IN (122,124) join demo_view.passenger FOR SYSTEM_TIME STARTED IN (122,124) on demo_view.passenger.id =demo_view.ticket.passengerid

__________________________________________________________________________________________
sql: select * FROM demo_view.ticket join demo_view.passenger on demo_view.passenger.id =demo_view.ticket.passengerid
_________________________________________________________________________________________
"namedParams" : [ {
    "name" : "settings_for_system_time_started",
    "type" : "STRING",
    "value" : {
    "string" : "122,123"
    }
} ]
___________________________________________________________________________________________
преобразованный запрос, после подстановки параметра FOR SYSTEM_TIME FINISHED IN:
select * FROM demo_view.ticket FOR SYSTEM_TIME FINISHED IN (122,124) join demo_view.passenger FOR SYSTEM_TIME FINISHED IN (122,124) on demo_view.passenger.id =demo_view.ticket.passengerid

**Пример запроса query.rq с системным параметром settings_for_system_time:

sql: select * FROM demo_view.ticket join demo_view.passenger on demo_view.passenger.id =demo_view.ticket.passengerid
___________________________________________________________________________________________
            namedParams:
            - name: settings_for_system_time
                type: TIMESTAMP
                value:
                string: 2022-11-14 16:00:00
__________________________________________________________________________________________
преобразованный запрос, после подстановки параметра FOR SYSTEM TIME: select * FROM demo_view.ticket FOR SYSTEM_TIME AS OF '2022-11-14 16:00:00' join demo_view.passenger FOR SYSTEM_TIME AS OF :p2 on demo_view.passenger.id =demo_view.ticket.passengerid

query.tp, системные параметры (к табличному параметру не подставляем, так как таблица standalone):

sql:  select count(*) from @tbl el LEFT JOIN demo_view.passenger on @tbl.firstname.firstname = demo_view.ticket.firstname
___________________________________________________________________________________________
            namedParams:
            - name: settings_for_system_time
                type: TIMESTAMP
                value:
                string: 2022-11-14 16:00:00
__________________________________________________________________________________________
преобразованный запрос, после подстановки  параметра  FOR SYSTEM TIME:  select count(*) from @tbl el LEFT JOIN demo_view.passenger FOR SYSTEM_TIME AS OF '2022-11-14 16:00:00' on @tbl.firstname.firstname = demo_view.ticket.firstname

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

Пример недопустимой конструкции запроса с системными и именованными параметрами:

sql: select * FROM demo_view.ticket join demo_view.passenger FOR SYSTEM_TIME AS OF :p2 on demo_view.passenger.id =demo_view.ticket.passengerid
________________________________________________________________________________________________
            namedParams:
            - name: settings_for_system_time
                type: TIMESTAMP
                value:
                string: 2022-11-14 16:00:00
            - name: p1
                type: TIMESTAMP
                value:
                string: 2022-11-14 15:00:00
__________________________________________________________________________________________
преобразованный запрос, после подстановки  параметра  FOR SYSTEM TIME: select * FROM demo_view.ticket FOR SYSTEM_TIME AS OF 2022-11-14 16:00:00 join demo_view.passenger FOR SYSTEM_TIME AS OF :p2 on demo_view.passenger.id =demo_view.ticket.passengerid

Пример запроса с системными и именованными параметрами в блоке where:

sql: select * FROM demo_view.ticket JOIN demo_view.passenger on demo_view.passenger.id =demo_view.ticket.passengerid WHERE passengerid=:p1 and price=:p2
___________________________________________________________________________________________________________________________________
            namedParams:
            - name: settings_for_system_time
                type: TIMESTAMP
                value: 2022-11-14 16:00:00
            - name: p1
                type: STRING
                value:
                string: 0fe26963-6cdf-4db6-b632-03825a408d35
            - name: p2
                type: DOUBLE
                value: 719.4501969260996

__________________________________________________________________________________________
преобразованный запрос, после подстановки  параметра  FOR SYSTEM TIME: select * FROM demo_view.ticket FOR SYSTEM_TIME AS OF '2022-11-14 16:00:00' JOIN demo_view.passenger FOR SYSTEM_TIME AS OF '2022-11-14 16:00:00' on demo_view.passenger.id =demo_view.ticket.passengerid WHERE passengerid=:p1 and price=:p2