Аудит отчетов

Аудит отчетов#

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

Аудит позволяет отследить:

  • какой отчет или печатная форма были сформированы;

  • какая версия отчета использовалась;

  • для какого объекта выполнялось построение;

  • какой пользователь выполнил построение;

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

  • с какого IP-адреса выполнено действие;

  • из какой выборки и операции выполнено построение, если эти данные доступны.

В процессе построения отчетов используются два механизма:

  • Rpt_ReportAudit — фиксирует факт формирования отчета или печатной формы;

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

В этой статье описан аудит Rpt_ReportAudit.

Форма открывается по пути:
Аудит > Аудит отчетов.

Интерфейс аудита отчетов#

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

Форма работает в режиме просмотра. Создание, редактирование и удаление записей через пользовательский интерфейс не предусмотрены.

Для отбора записей используется универсальный фильтр.

Список записей аудита#

В основной таблице отображаются записи о формировании отчетов и печатных форм.

Колонка

Описание

Имя отчета

Наименование отчета или печатной формы

Имя версии отчета

Наименование версии отчета

gid объекта

Глобальный идентификатор объекта, для которого выполнялось построение

Дата и время формирования печатной формы

Дата и время построения отчета или печатной формы

Пользователь

Пользователь, выполнивший построение

IP-адрес клиента

IP-адрес клиента, с которого выполнено построение

Флаг распечатан для документов

Признак того, что документ был распечатан

Имя выборки

Имя выборки, из которой выполнено построение

Имя операции

Имя операции, через которую выполнено построение

Настройка аудита#

Аудит отчетов доступен только в режиме просмотра.

Через интерфейс недоступны:

  • создание записей;

  • редактирование записей;

  • удаление записей.

Аудит построения отчетов включается на уровне конкретного отчета.

Основной флаг:

  • Rpt_Report.bEnableAudit — поле Вести аудит построения.

При построении отчета Rpt_Pkg вызывает Rpt_ReportAuditApi.atInsertAudit(...). Метод Rpt_ReportAuditApi.insertAudit(...) сначала проверяет значение Rpt_Report.bEnableAudit. Если флаг выключен, запись в Rpt_ReportAudit не создается.

Для новых отчетов значение по умолчанию берется из настройки модуля rpt:

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

Практический порядок настройки:

  1. Для новых отчетов включите настройку rpt.bEnableWriteAuditByDefault, если аудит должен включаться по умолчанию.

  2. Для уже существующих отчетов откройте карточку отчета и включите поле Вести аудит построения.

  3. При необходимости массового включения для существующих отчетов проставьте bEnableAudit = 1 осознанным скриптом.

  4. Постройте отчет и проверьте появление записи в Rpt_ReportAudit.

Проверить настройку конкретного отчета можно запросом:

select id, sSystemName, bEnableAudit
from Rpt_Report
where sSystemName = '<код_отчета>';

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

select *
from Rpt_ReportAudit
order by dPrint desc;

События формирования записей#

Запись аудита создается автоматически в стандартном потоке Rpt_Pkg:

  • при одиночном построении — через Rpt_Pkg._beforeCreateReport(...);

  • при массовом построении — через Rpt_Pkg._beforeCreateReports(...).

Из этих точек вызывается метод Rpt_ReportAuditApi.atInsertAudit(...), поэтому запись аудита формируется автоматически.

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

  • идентификатор отчета;

  • идентификатор версии отчета;

  • системные имена отчета и версии;

  • объект построения;

  • пользователя;

  • дату и время операции;

  • IP-адрес клиента;

  • признак bIsPrinted.

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

Хранение данных#

Rpt_ReportAudit реализован как отдельная сущность. Одна запись соответствует одному факту формирования отчета или печатной формы.

В аудите фиксируются:

  • отчет;

  • версия отчета;

  • пользователь;

  • объект построения;

  • дата и время формирования;

  • IP-адрес клиента;

  • признак печати документа;

  • выборка и операция, если построение было вызвано из интерфейса.

При удалении:

  • отчета — связанные записи аудита удаляются по idReport;

  • версии отчета — поле idReportVersion устанавливается в null.

Хранимые поля#

Основные поля Rpt_ReportAudit:

Поле

Описание

idReport

Идентификатор отчета

idReportVersion

Идентификатор версии отчета

sReportName

Системное имя отчета

sReportVersionName

Системное имя версии отчета

dPrint

Дата и время формирования отчета или печатной формы

sUser

Пользователь

gidObject

Глобальный идентификатор объекта построения

sClientHostIp

IP-адрес клиента

bIsPrinted

Признак режима печати

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

Программная логика#

Основная логика реализована в Rpt_ReportAuditApi.

Ключевые методы:

  • Rpt_ReportAuditApi.insertAudit(...) — добавляет запись аудита;

  • Rpt_ReportAuditApi.atInsertAudit(...) — добавляет запись аудита в автономной транзакции;

  • Rpt_ReportAuditApi.beforeDeleteReport(...) — обслуживает записи аудита при удалении отчета;

  • Rpt_ReportAuditApi.beforeDeleteReportVersion(...) — обслуживает записи аудита при удалении версии отчета.

Особенности эксплуатации#

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

Если отчет или печатная форма формируется через нестандартный сценарий, который не вызывает Rpt_Pkg._beforeCreateReport(...) или Rpt_Pkg._beforeCreateReports(...), запись аудита может отсутствовать.

Аудит Rpt_ReportAudit фиксирует сам факт формирования отчета или печатной формы. Для детального анализа процесса построения, параметров, состояний и ошибок используется отдельный рабочий журнал Rpt_EntityExec.

Объем аудита отчетов зависит от:

  • количества формирований отчетов;

  • частоты массового построения;

  • количества пользователей, работающих с печатными формами;

  • срока хранения записей.

Ключевой фактор роста — количество записей, а не размер отдельной строки.

Хранение и очистка#

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

Рекомендуемый срок хранения:

  • 90–180 дней — рабочий ориентир;

  • более длительное хранение — при наличии требований к контролю или проверкам;

  • старые данные — через архивирование.

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

Рекомендуемая настройка:

  • spClass = "Rpt_ReportAudit";

  • npDeleteType = DeleteType.sqlDelete;

  • spAttrCreateDate = "dPrint";

  • npDaysKeep — по регламенту;

  • bpActive = 1.

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

Рекомендуется:

  • анализировать прирост записей по dPrint;

  • учитывать пики массового построения;

  • согласовывать срок хранения с требованиями к контролю формирования отчетов;

  • удалять или архивировать устаревшие записи.

Содержание