The changes made to values in cube cells in the In-Memory (OLAP) DB can be tracked by enabling the Audit feature for specific cubes. The storing of audit information is disabled by default. To enable it, the audit parameter must be added to the configuration file palo.ini. It is a switch parameter and has no additional arguments. Additionally, audit storage has to be enabled for every database cube for which it should be kept.
Notes:
- At least W rights are required for the rights objects "dimension element" and "audit" to make changes to the audit settings. See Rights Objects in Jedox for more information.
- You cannot enable the parameter "audit" together with the parameter "crypt" in the file palo.ini. The data storage for audit information currently cannot be encrypted (meaning it would contain readable data information), which would conflict with the purpose of the "crypt" option.
The Audit manager can be found in Jedox Administration:
Enabling audit storage for cubes
You can enable Audit for cubes in two ways. First in the Modeler and second through the Audit in the Administration.
-
To enable the Audit for a cube in the Modeler, navigate to your cube’s Properties, and select Audit. Here, you can define a period for your audit or delete the audit trail.
-
Click on Audit in the Administration. Here you can select the Database, the Cube, the Cube type (i.e., Attribute cubes, Rights cubes, and System Cubes), the audit period, and the Cube slice.
Click on Audit Settings in the Audit toolbar to select the cubes and the period for which the audit information should be stored. Note that you may need to click on the menu icon in the toolbar if your screen is small:
The audit keeps track of all individual cell changes: it logs the cell path, time of change, user, new value, and operation (splashing, copy, etc.). When disabling audit for a cube, all stored audit data for this cube is deleted.
Note that auditing only stores the change for the cell that was directly modified. It does not store indirect changes, such as when a cell is affected by a splashing operation on a parent element. Also, mass data changes as performed by Jedox Integrator are not logged, nor are string cells written via Integrator.
Changes made with the API ICube.loadcells, which writes to multiple cells at once, do not appear in Audit data. Changes made with ICube.loadcell, which writes to a single cell, can be protocolled in Audit data; this API can be used to audit Groovy Jobs. See Integrator Scripting API for more information.
By contrast, cell changes initiated by a Supervision Server cube worker script will be logged in the audit information, provided that these are not using the API for mass data change themselves. The audit log would store the user who had made the initial change also for the changes made by the SVS script.
You can display the stored audit information in two ways:
- Audit manager (see below)
- Drill History in Jedox views (right click on a corresponding cell).
Changes made via Integrator cube loads are not protocolled in Audit data.
Audit manager
In the Audit toolbar, you can set the filter for the audit data you want to see. Click on Apply Filtering to see the selected audit data.
The first group of columns (in this case, Products, Regions, Months, Years, Versions, and Measures) reflect the dimensions in the cube. The TIME and USER columns indicate the exact time the change was made and by which user. The NUMERIC_VALUE and STRING_VALUE columns show the modified values, depending on them being numeric or string. The COMMAND column informs the command used for changing elements in the cube. The EVENT column can contain detailed information about SupervisionServer event if the COMMAND was performed by SupervisionServer and if any such information is available. Finally, the DETAILS column provides additional information available for the specific COMMAND. In the case of COPY_VALUES (and COPY_LIKE_VALUES), the target cell is where the value is written and for which the audit information is retrieved. In the DETAILS column there is the source cell, i.e. the cell from which the value is copied. The numbers are element IDs. The table below explains the mode results:
| mode=0 | Base cell write-back |
| mode=1 | Default splashing |
| mode=2 | Set splashing |
| mode=3 | Add splashing |
Updated September 25, 2024