Аудит изменений данных Hyperion Planning. Часть I – обработка данных

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

Например в старом, добром FinExpert было такой hotkey – “Ctrl + I” по нажатию которого отображалась табличка с историей изменений накладной или номенклатурного номера или карточки или проводки и т.д..
У Hyperion Planning тоже есть похожий протокол. Он включается для каждого приложения отдельно, для того чтобы его включить нужно зайти в приложение Planning, перейти в меню “Администрирование” > “Приложение” > “Отчеты”, перейти на закладку “Проверка” и напротив пункта “Данные:” поставить галочку.

Теперь все изменения данных в формах будут записываться в таблицу HSP_AUDIT_RECORDS внутри схемы соответствующей приложению.
Подключившись к схеме приложения и выполнив там запрос:


SELECT audit_rec.*
FROM hsp_audit_records audit_rec
ORDER BY audit_rec.time_posted DESC

получаем историю изменений данных

Но назвать такой способ работы с протоколом изменений – usability, язык не поворачивается это вам не FinExpert ЭТО СПАРТАААА это Hyperion Planning. Мало верится, что обычные пользователи будут учить SQL и смотреть таким образом историю изменений. Срез данных, на котором менялось значение, хранится в поле ID_2, это  списком элементов, перечисленным через запятую. То есть фильтр так просто не наложишь.

Поэтому прийдётся допиливать до usability варианта. В первой части статьи я расскажу как можно распарсить протокол изменений и сохранять его в отдельную схему, а во второй части как этот протокол визуализировать для конечного пользователя.

Шаг 1.
Создаем в базе Oracle схему в которой будет хранится консолидированный, по всем приложениям, распарсенный протокол изменений.

CREATE USER HYP_EXTENSIONS
IDENTIFIED BY
DEFAULT TABLESPACE HYP_SYS
TEMPORARY TABLESPACE TEMP
PROFILE DEFAULT
ACCOUNT UNLOCK;

-- 2 Roles for HYP_EXTENSIONS
GRANT RESOURCE TO HYP_EXTENSIONS;
GRANT CONNECT TO HYP_EXTENSIONS;
ALTER USER HYP_EXTENSIONS DEFAULT ROLE ALL;

-- 1 System Privilege for HYP_EXTENSIONS
GRANT UNLIMITED TABLESPACE TO HYP_EXTENSIONS;

-- 1 Tablespace Quota for HYP_EXTENSIONS
ALTER USER HYP_EXTENSIONS QUOTA UNLIMITED ON HYP_SYS;

Шаг 2.
Создаем объекты схемы: типы данных, таблицы, последовательности, функции процедуры.

Сгененировать их можно из файла

Центральные объекты, куда будет складываться распарсенный протокол, это две таблицы EXT_AUDIT и EXT_AUDIT _DETAIL.

EXT_AUDIT хранит:

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

EXT_AUDIT_DETAIL хранит информацию о срезе данных на котором произошли изменения:

  • код измерения
  • имя измерения
  • код элемента
  • имя элемента

Таблицы связаны друг с другом – один ко многим.

Шаг 3.
Схеме, с которой работает приложение, даем дополнительные права, если схема называется, например, HYP_DEV то скрипт выглядит так:

-- 2 System Privileges for HYP_DEV
GRANT CREATE SYNONYM TO HYP_DEV;
GRANT CREATE JOB TO HYP_DEV;
-- 3 Object Privileges for HYP_DEV
GRANT EXECUTE ON HYP_EXTENSIONS.DIM_TYPE TO HYP_DEV;
GRANT EXECUTE ON HYP_EXTENSIONS.EXT_AUDIT_PKG TO HYP_DEV;
GRANT EXECUTE ON HYP_EXTENSIONS.MBR_TYPE TO HYP_DEV;

Шаг 4.
В схеме, с которой работает приложение, создаем необходимые синонимы, если схема называется, например, HYP_DEV то скрипт выглядит так:

CREATE SYNONYM HYP_DEV.DIM_TYPE FOR HYP_EXTENSIONS.DIM_TYPE;
CREATE SYNONYM HYP_DEV.MBR_TYPE FOR HYP_EXTENSIONS.MBR_TYPE;
CREATE SYNONYM HYP_DEV.EXT_AUDIT_PKG FOR HYP_EXTENSIONS.EXT_AUDIT_PKG;

Шаг 5.
В этой же схеме приложения создаем объекты которые будут парсить информацию аудита

Сгененировать их можно из файла

Главные объекты пакета это две процедуры

  • Parse_Audit_P
  • Exec_Parse_Audit_P

Первая парсит строку аудита. Принимает в качестве аргумента ROWID записи из таблицы HSP_AUDIT_RECORD, в этой процедуре, жёстко зашито имя приложения, его нужно поменять на имя вашего приложения, строка 424.

Вторая процедура запускает первую фоновом режиме, с помощью DBMS_SCHEDULER.CREATE_JOB.

Шаг 6.
Вешаем триггер на событие AFTER INSERT таблицы HSP_AUDIT_RECORD

CREATE OR REPLACE TRIGGER HSP$AUDIT_PARSE_TRG
AFTER INSERT
ON HYP_DEV.HSP_AUDIT_RECORDS
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN

IF UPPER(:new.TYPE) = 'DATA' THEN
 HSP$DELTA_EXTRA_PKG.Parse_Audit_P(
                          in_Form_Name => :new.id_1,
                          in_Form_Audit => :new.id_2,
                          in_User_Name => :new.user_name,
                          in_Time_Posted => :new.time_posted,
                          in_Old_Value => :new.old_val,
                          in_New_Value => :new.new_val
                         );
END IF;
END ;
/

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

А как визуализировать протокол в Hyperion Planning я расскажу во второй части статьи.

To be continued …

1 thought on “Аудит изменений данных Hyperion Planning. Часть I – обработка данных”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s