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.
Audit entries contain the following information (properties):
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 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 third-party reporting tools.
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.
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 may create custom events and properties for the purposes of auditing custom applications. See Create a custom audit entry for more information.
To manage the size of the audit log, the FileNet software provides search templates that do the following:
See Manage audit log size for more information.
You can find these search templates under the Enterprise Manager's Saved Searches node. 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.
Property sheets of auditable objects include an Audit History property sheet:
The audit history for all objects can be created by querying the audit event log.
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.
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.
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/Enterprise Manager activity. As a result, configuring this particular event for audit logging could result in a large storage requirement.
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.