Home > Engine & Repository

Audit Trail

Overview

Any persistent update performed on the EBX.Platform repository is logged to an audit trail XML file. This is also the case for any procedure execution (even if it does not perform an update, a procedure is always considered as a transaction). The following information is logged:

• the transaction type (instance creation, record modification, record deletion, specific procedure, etc.);

• the branch or version on which the transaction is executed;

• the transaction source: if the action is initiated by EBX.Manager, this source is described by the user identity, HTTP session identifier and client IP address; if it is initiated programmatically, only the user identity is shown;

• also concerning the session, the optional value "trackingInfo";

• the transaction date and time (in milliseconds);

• the transaction UUID (conforming to Leach-Salz variant, version 1);

• if the transaction has failed, information about the error;

• the detail of updates done (if there are any updates and if history detail is activated, see next section).

Updates detail and disk management

The audit trail is able to describe all updates made into the EBX.Platform repository, at the finest level. Hence, the files can be quite large and the audit trail directory must be supervised with caution. The following facts should be taken into account:

1. If an archive import is executed in non-interactive mode (without a change set), the audit trail does not detail the updates: it only specifies the archive that has been imported. In this case, if it is important to keep a fine trace of the import-replace, the used archive must be preserved.

2. If an archive import is executed in interactive mode (with change set), or if a branch is merged to its parent, the resulting log size will be nearly equal to the unzipped size of the archive multiplicated by three. Furthermore, for consistency issues, each transaction is logged into a temporary file (in the audit trail directory) before being moved into the main file. So EBX.Platform requires at least six times the unzipped size of the largest archive that can be imported . 

3. In the context of a specific procedure that performs many updates that need not be audited, it is still possible for the developer to disable the detailed history with the method ProcedureContext.setHistoryActivation(boolean) .

See also:

• EBX.Platform monitoring

Files organization

All audit trail files are stored in the directory ${ ebx.repository.directory }/History . 

"Closed" audit files

Each file is named as:

aaaa-mm-dd -part nn .xml

where aaaa-mm-dd is the file date and nn is the file index in this day.

Current audit files for writing

When an audit file is being written, the XML structure implies to work in an "open mode". XML elements of the modifications are added to a text file named:

aaaa-mm-dd -part nn Content.txt

The standard XML format is still available in an XML file that references the text file. This file is named:

aaaa-mm-dd -part nn Ref.xml

Those two files are then re-aggregated in a "closed" XML file when the repository is cleanly shut down or EBX.Platform is restarted.

Example of an audit directory:

2004-04-05-part00.xml 2004-04-05-part01.xml 2004-04-06-part00.xml 2004-04-06-part01.xml 2004-04-06-part02.xml 2004-04-06-part03.xml 2004-04-07-part00.xml 2004-04-10-part00.xml 2004-04-11-part00Content.txt 2004-04-11-part00Ref.xml

Home > Engine & Repository