База отчётов

Записи пользовательских отчётов и копия данных для SQL-запросов хранятся в отдельной базе PostgreSQL — базе отчётов. Определения отчётов, права, журнал и всё остальное остаются в основной базе. Тяжёлые запросы аналитиков так не мешают роботам, а данные отчётов отделены от паролей и журналов.

Как устроено #

• По умолчанию — база <основная база>_reports (tulpar_reports) на том же сервере PostgreSQL с тем же логином. Сервер сам применяет её миграции и закрывает обе базы от остальных ролей (REVOKE CONNECT, TEMPORARY … FROM PUBLIC).
• У каждой рабочей области — своя схема ws_<идентификатор области> и своя роль PostgreSQL только для чтения (trq_<хэш>_<область>). SQL-запросы области выполняются от этой роли: к основной базе и к схемам других областей у неё доступа нет, изменить данные она не может, у неё свой тайм-аут и не больше 4 подключений.
• Пароли ролей областей случайные и хранятся в основной базе зашифрованными ключом шифрования. Роли и права сервер создаёт сам при первом обращении к отчётам области.
• Если база отчётов недоступна, оркестратор работает дальше: отчёты отвечают „База отчётов недоступна“ с причиной, запись в отчёт роботом получает повторяемую ошибку ReportsUnavailable, /health/ready — degraded. Сервер пробует подключиться снова не чаще раза в 30 с.

Права роли сервера #

В Docker роль tulpar — администратор PostgreSQL контейнера: ей ничего выдавать не нужно, базу сервер создаёт сам.

Проверка — Tulpar.Orchestrator.exe check: строка „База отчётов …: доступна, миграции применены“ или причина с командой для администратора PostgreSQL. В панели — карточка «База отчётов» на странице «Состояние системы».

Прямое подключение BI #

Power BI, Excel и другие BI-системы могут читать базу отчётов напрямую через коннектор PostgreSQL — ролью рабочей области. Логин и пароль роли — в «Настройки» → «Отчёты» (только администратор).

• Блок «Подключение BI к базе отчётов» — «Сервер», «Порт», «База данных» и «Режим SSL» так, как их видит оркестратор. BI-система подключается к адресу PostgreSQL, доступному с её компьютера: если оркестратор обращается к базе как к localhost или к контейнеру postgres, укажите в BI сетевое имя сервера PostgreSQL.
• Таблица «Роли рабочих областей» — для каждой области «Роль (логин)» и её схема. «Показать пароль» открывает окно с логином и паролем — «Скопировать логин», «Скопировать пароль». Пароль показывается по запросу, каждый показ записывается в аудит („Показан пароль роли базы отчётов“, без самого пароля). Если роль области ещё не создана, она создаётся при первом показе пароля.
• «Сменить пароль» задаёт роли новый случайный пароль (в аудите — „Изменён пароль роли базы отчётов“). Отчёты BI со старым паролем перестанут обновляться — введите в них новый; уже открытые подключения работают до отключения. Меняйте пароль, если он мог попасть к посторонним, и когда сотрудник с доступом к нему уходит.

Что может роль области: только читать (default_transaction_read_only = on) таблицы и представления своей схемы ws_<область> (она же схема по умолчанию); запрос — не дольше 60 с (statement_timeout), не больше 4 подключений одновременно вместе с самим оркестратором — в BI не включайте параллельную загрузку многих таблиц. К основной базе и к схемам других областей доступа нет.

Сетевой доступ: PostgreSQL должен принимать подключения с компьютеров BI (listen_addresses, строка в pg_hba.conf для базы отчётов и ролей trq_…, правило брандмауэра на порт 5432). В Docker порт PostgreSQL наружу не опубликован — добавьте ports у сервиса postgres в своём docker-compose.override.yml только для сети BI. После восстановления из копии пароли ролей остаются прежними: сервер пересоздаёт роли с сохранёнными паролями.

Отдельный сервер PostgreSQL #

Если отчётов много, базу можно вынести на другой сервер — задайте строку подключения в orchestrator.json:

{ "Tulpar": { "Reports": { "ConnectionString": "Host=pg-reports;Port=5432;Database=tulpar_reports;Username=tulpar_reports;Password=…" } } }

(или переменной Tulpar__Reports__ConnectionString). Такую базу сервер не создаёт: создайте её заранее (UTF-8, владелец — роль из строки подключения, у роли право CREATEROLE) и перезапустите службу.

Резервные копии и восстановление #

• backup.ps1 и backup.sh копируют базу отчётов в tulpar-reports.dump вместе с основной (см. Резервные копии). В Docker другое имя базы задаётся переменной REPORTS_DB.
• restore.ps1 и restore.sh пересоздают базу отчётов и загружают дамп без владельцев и прав (--no-owner --no-privileges): роли областей принадлежат всему серверу PostgreSQL и в дамп не входят. Сервер создаёт их заново при первом обращении к отчётам — после загрузки ключа шифрования.
• Копию данных оркестратора (jobs, queue_items …) сервер поддерживает сам; ценны записи отчётов — таблицы r_*, поэтому база отчётов должна входить в каждую копию.