Data Change Auditing



In BBj.13.0 and higher, Data Change Auditing is the process of building an audit trail via Change Audit Jobs. Each job consists of a job name, location for the audit log database(s), a list of one or more directories and/or data files to be monitored, and the frequency at which the log database should rollover.

When an application changes a monitored data file using direct file access calls from a BBj program or via SQL, the auditing system logs the change and type of change to an “audit log database.” At any time, an administrator can query the log database using the interface built into the Enterprise Manager or query the log database tables directly using SQL. When using change auditing, overhead is typically minimal since in most cases, administrators configure jobs to use the default asynchronous mode. In asynchronous mode, the audit system adds audit details to a background queue rather than waiting for the log operation to complete before continuing. In synchronous mode (not recommended) it completes the logging of the audit details before allowing the original write or remove operation on the file to complete.

Create a Change Audit Job

To create a change audit job, select the “Auditing” item in the Enterprise Manager navigator to display the list of currently configured audit jobs. Click the [+] button shown below to create a new job.





Unique UUID identifier for the job.


Human readable name of the job.

DB Root Directory

Auditing writes notifications to a BBj SQL database. The root directory is the directory where the system creates the audit databases based on the rollover frequency. This is NOT the location of the data files being monitored.

Rollover Type

Rollover frequency options are none, daily, weekly, monthly, or yearly.

Rollover Frequency

Number of units before rolling over to a new audit database. For example, for rollover type weekly, and a rollover frequency of 2, the audit database would rollover every 2 weeks.


With synchronous enabled, all write or remove operations will wait to return until the audit database is updated. This can drastically slow down write and remove operations in applications so it is typically not enabled.


List of directories and/or files to include in the audit job.


List of files from included directories to be explicitly excluded from the job.


Once an audit job is queued, it appear in the Audit Job List Panel.




Job Name/Monitored Item

Displays the unique name of the job.


Indicated it is an audit job.

Last in Sync

Shows the last time the audit job was last in sync with all audit changes.


Auditing writes notifications to a BBj SQL database. The root directory is the directory where the system creates the audit databases based on the rollover frequency. This is NOT the location of the data files being monitored.


Since the auditing system stores audit log messages in a BBj ESQL database, the database list in the Enterprise Manager shows the auditing databases with all the other databases (see below). Audit job databases use the name of the job followed by the date created and a counter if there are more than one for a given date.


Viewing the Audit Log Data

Audit logging data resides in a BBj ESQL database so there are two ways to access the data: the Audit Log Viewer in the Enterprise Manager, or querying the database directly using SQL. We won’t go into the SQL option in detail except to say that the auditing system logs each type of operation to a different table in the audit database. The Audit Log Viewer makes it easy to search and access this data. Use the button to query the audit database.




Log Database

The specific audit log database to query.


Optionally limit the query to look at audit information for a particular file being audited.


Optionally limit the query to one or more users. Use the [ ... ] button to open a list of all user accounts to choose from.

Operation Type(s)

Optionally limit the query to look for specific types of operations. The example in Figure 4 searches for only SQL UPDATE, INSERT, and DELETE operations, as well as any WRITE or REMOVE file modification events from BBj applications. Use the [ ... ] button to open a list of operation types.

Start/End Date

Specify the range of dates to examine.


Displays the time the audited operation took place.


Displays the user who performed the audited operation.


Displays the file on which the operation occurred.

Operation Type

Displays the type of operation which occurred.


In addition to general information about each audited operation, the viewer provides drill-down support to further investigate the details of each change. Double-clicking on an operation in the viewer opens another dialog that displays the record details. For example, an UPDATE_RECORD operation shows the old record and the new record after the change, while an INSERT_RECORD operation shows only the new record added to the file. A string template entry box makes it easier to evaluate the record data since the audit operation stores the record data in its raw format. The Audit Item Detail shows what the user sees when viewing an UPDATE_RECORD detail.


Using a BBj ESQL database for the log gives the administrator the ability to configure user access permissions to the audit database in the same way one would configure user permissions on any other BBj database. In addition, using iReport or BBJasper enables administrators to create more robust, limited, and/or customized reporting for others to view in an external application without the need to grant them access to the Enterprise Manager.









Copyright BASIS International Ltd. BBj®, Visual PRO/5®, PRO/5®, and BBx® are registered trademarks.