This document applies to K2BAudit versions prior to 6.0. The newer version is Using K2BAudit (6.0 and up).
In this stage, the application’s developer can select which transactions may be audited by K2BAudit. In order to do so, the developer must use the K2BAudit Extension inside the GeneXus IDE to select those transactions.
The developer can also choose which operations (Insert, Update or Delete) should be audited, and also add conditions involving the transaction’s attributes that will determine if each operation is to be audited.
When a transaction is audited, the developer can choose which attributes in the transaction should be included in the audited data. Some attributes cannot be audited, such as blob fields, inferred attributes, and non-redundant formulas.
After the initial setup is completed, the developer must execute the K2BAudit Reorganize action in order to create the triggers in the database.
See more in K2BAudit initial setup.
In this stage, an authenticated user can analyze the operations performed in the application using the K2BAudit Analyzer application. That application includes several features to understand the audited data and their context.
For each update operation, the user can see the data before and after the operation was performed. In insert and delete operations, K2BAudit shows the information that was inserted or deleted.
For performance reasons, K2BAudit Analyzer does not query the raw data created by the triggers. Instead, a normalized database is created and the raw data is converted to that database. Because of that, a conversion process must be executed periodically (preferably in times when the system’s load is low).
|