Concepts: audit logging

Content Engine provides audit logging to monitor event activity of FileNet P8 objects.

Audit definitions represent information describing how to audit an event. The result of auditing is the automatic logging of audit entries. These entries are instances of one of the subclasses of the Event class (see Audit event classes for details). For example, a document class can be configured to automatically create audit entries whenever documents of that class are checked in provided that auditing has been enabled for the object store and belong to the Checkin Event class. See Enable Auditing for more information.

Applications can also programmatically create audit entries that are specific to their needs. See the appropriate help for developers for information.

Information contained in an audit entry

Audit entries contain the following information (properties):

Audit event log

The audit event logs exist as a table in the object store's database. You can view the log, export it to XML for reporting and other purposes, and administer it, but to do so you must run a query for the events you want and then perform actions against the result set of the query. See Query the audit log for more information.

Audit events remain in the audit log even if the audited object is deleted. If you no longer need these audit events, you can use the Content Engine Query Builder to find the audit events and specify delete on the Actions tab. Also, the FileNet P8 software provides search templates for deleting and exporting these "orphaned" audit events, described below.

Administrators can use the export list functionality to create tab- or comma-delimited XML files for reporting entries in the Audit Log. You can then generate reports from the XML, using other independent software vendor reporting tools.

Auditing property changes

The system property ModifiedProperties returns the symbolic names of the properties modified by the audited event operation. This property belongs to the subclasses of the Object Change Event class that logs audit events involving a change of properties. You can get the entire list of subclasses that contain this property by examining the system properties belonging to the classes in Enterprise Manager under Other Classes > Events tree of subclasses, or from the Java™ API description of the ModifiedProperties property.

Custom audit entries

For most auditing requirements, you will not need to add properties to the Custom Event class. In fact, all Object Change event audit classes are read-only. However, you can create custom events and properties for the purposes of auditing custom applications. See Create a custom audit entry for more information.

Managing audit log size

To manage the size of the audit log, the FileNet software provides search templates that perform the following actions:

See Manage audit log size for more information.

You can find these search templates under the Saved Searches node in Enterprise Manager. You can also write your own bulk operation search templates, or you can modify the provided samples. See Search and bulk operations for more information.

Object audit history

Property sheets of auditable objects include an Audit History property sheet:

Screen capture of an audit history property sheet

The audit history for all objects can be created by querying the audit event log.

Enabling auditing

Audit logging is enabled and disabled at the object store level. By default, auditing is disabled when you create a new object store. To enable auditing on an existing object store, see Enable auditing for an object store. Once enabled, you can configure auditing for classes within that object store. See Configure auditing for more information.

Performance implications

The performance impact of logging events is related to:

Auditing requires an extra trip to the database; therefore, enabling auditing could have performance implications for your applications. If you increase the number and volume of audited events, it is recommended that you monitor performance.

Storage implications

Each event object created by Content Engine's audit logging is stored as a row in the designated table in the object store database. For example, checking in a new version of a document uses one table row in the database. However, when that document's class has all possible events audited, a single checkin could create up to three more entries in the audit logging database table. Therefore, to avoid running out of space, you should allocate database storage accordingly.

NOTE  "Get object" is the most frequently created audit definition during normal Content Engine and Enterprise Manager activity. As a result, configuring this particular event for audit logging could result in a large storage requirement.

Security and ownership

Audit entries are stored in the object store database and are secured by the permissions placed on the default instance security list of their class.

You must be the object store administrator with Full Control access to configure auditing. Audit event objects have an ownership property, but it is not set by default.

The operations available on audit entries are: delete, change the owner, and change the security.