Audit Trails

Audit trails allow one to track changes to models as they are created, updated, or deleted. All core models are capable of supporting an audit trail. Application models must be configured to support audit trails when you create the model.

Figure 4.14. Audit Trails must be configured on application models in the model definition.

Once a model is capable of supporting audit trails, you must additionally elect to turn the audit trail on. Once enabled, the audit trail is kept automatically. If you review the database structure after enabling an audit trail on a model, you will find a table with _ADT appended to the model's name. This is the table that holds the audit trail. Each time a record is persisted, a copy of the record's old state is stored in the audit trail along with the date, time, and user information related to whomever changed the record.

While modules indicate whether Audit is turned on by default in their MPT (as per the screenshot above), the value chain administrator has the ability to override this at runtime in a running instance of the software. He can create records in the EXTERNAL_REFERENCE table to turn audit on and off at a model level.

Table 4.1. Configuration of Audit through EXTERNAL_REFERENCE

Models with audit trail enabled support views based on the audit trail allowing you to display the audit trail in your UI as you would any other data, except of course that audit trails cannot be edited by users under any circumstances.

• Showing Audit Trails in the UI