Log In
Home
Support
Demos
Documentation
Blogs
Training
Webinars
[Expand]General Information
[Expand]WinForms Controls
[Expand]ASP.NET Controls and MVC Extensions
[Expand]ASP.NET Bootstrap Controls
[Expand]WPF Controls
[Expand]Xamarin Controls
[Expand]Windows 10 App Controls
[Expand]Document Server
[Expand]Reporting
[Expand]Report Server
[Expand]Dashboard
[Collapse]eXpressApp Framework
 [Expand]Fundamentals
 [Expand]Getting Started
 [Collapse]Concepts
  [Expand]Application Solution Components
  [Expand]Business Model Design
  [Expand]Application Model
  [Expand]UI Construction
  [Expand]Extend Functionality
  [Expand]Data Manipulation and Business Logic
  [Expand]Security System
  [Expand]Localization
  [Expand]System Module
  [Collapse]Extra Modules
   [Collapse]Audit Trail Module Overview
     Analyze the Audit Log
     Customize the Audit Trail System
     Server-Side Timestamping in the Audit Trail System
    Business Class Library Customization Module
    Chart Module
    Clone Object Module
   [Expand]Conditional Appearance Module Overview
   [Expand]Dashboards Module
    File Attachments Module Overview
    HTML Property Editor Module
   [Expand]Notifications Module
    KPI Module
   [Expand]Maps Module
   [Expand]Pivot Chart Module
    Pivot Grid Module
   [Expand]Reports V2 Module
   [Expand]Reports Module (Obsolete)
   [Expand]Scheduler Module
    Script Recorder Module
   [Expand]State Machine Module
   [Expand]TreeList Editors Module
   [Expand]Validation Module
    View Variants Module
   [Expand]Workflow Module
  [Expand]Debugging and Error Handling
  [Expand]Filtering
  [Expand]Application Life Cycle
 [Expand]Design-Time Features
 [Expand]Functional Testing
 [Expand]Deployment
 [Expand]Task-Based Help
 [Expand]Frequently Asked Questions
 [Expand]API Reference
[Expand]CodeRush
[Expand]Cross-Platform Core Libraries
[Expand]Tools and Utilities
[Expand]End-User Documentation

Audit Trail Module Overview

The eXpressApp Framework supplies the Audit Trail System. This system is intended to provide you information on changes that are being made to the application's persistent objects. For example, you can retrieve information on the kind of change (object is created, changed, etc.), who made this change, with what object, the previous and new property values, and so on. A change is registered between two sequential events of object saving to a data storage. To have this system in your application, you should use the Audit Trail module, which represents it. This topic explains the mechanisms for trailing object changes, and provides ways to customize them.

Note

  • Currently, we do not to provide built-in support for Entity Framework (EF) in this module, because its implementation heavily depends on our XPO ORM, and we do not have a sufficient number of customer requests in this regard. If you use EF for data access in your XAF application and require a similar functionality for your project, feel free to contact us and describe your business requirements so we can provide you with alternative solutions. In general, you can integrate any custom or standard solution for Entity Framework, which you would implement to solve the same requirement in non-XAF applications. We will also continue monitoring user demand in this regard and it is possible that we will review our current decision in the future.
  • We have designed this module to manage up to a hundred of audited changes in one transaction. It will take significant time to save thousands of audit data records. We recommend that you investigate whether or not this performance specificity is important before using this module in your application.

The AuditTrailModule is represented by the DevExpress.ExpressApp.AuditTrail.v17.1.dll assembly. To use the module in an application, add it to your application project or one of the application modules via the Application Designer or Module Designer, respectively. In addition, check that the DevExpress.Persistent.Base.v17.1.dll assembly is referenced in your application, since it contains XAF-independent services used by the Audit Trail module.

Important

Expanded Audit Module Overview

After the necessary assemblies listed above have been referenced, all persistent objects in the application will be audited. In addition, their simple, reference and collection properties, which are persistent, will be audited as well. The changes made to these objects and their properties will be logged in the database.

The following table lists the changes which are logged by the Audit Trail module:

Change

Description

ObjectCreated The audited object has been created.
InitialValueAssigned An initial value has been assigned to the audited object before the first save.
ObjectChanged The audited object's property has been changed.
ObjectDeleted The audited object has been deleted.
AddedToCollection The audited object has been added to a collection.
RemovedFromCollection The audited object has been removed from a collection.
CollectionObjectChanged An object from the audited object has been changed.
AggregatedObjectChanged The object aggregated by the audited object has been changed.
CustomData Custom data has been added to the audit log.

In code, changes are represented by the AuditDataItem class. This class' properties are logged. By default, they are saved to the database by an AuditDataStore object. This object creates an AuditDataItemPersistent persistent object and saves it to the database. To save changes represented by the AuditDataItem objects in another storage, inherit a custom class from the AuditDataStore class and override the Save method (see the Customize the Audit Trail System topic).

To analyze the audit log, you need to know what database tables represent it. With the Audit Trail module, the following tables are added to the database:

  • AuditDataItemPersistent

    Represents the table where the AuditDataItemPersistent objects are stored. Each time one of the changes listed above is made, a new record is added to this table. The table's AuditedObject field contains references to the corresponding records in the AuditObectWeakReference table. The OldObject and NewObject fields contain references to the corresponding records in the XPWeekReference table. These fields' string representations are stored into the OldValue and NewValue fields, respectively.

    Note

    • The AuditedObject is null for deleting operation when the deferred deletion option is disabled for the audited type. Use the DeferredDeletionAttribute to enable it.
    • For collection modification entries (AddedToCollection, RemovedFromCollection, CollectionObjectChanged, AggregatedObjectChanged), a reference to the modified persistent object along with the object's string representation are always stored into the OldObject / OldValue fields.

  • XPWeakReference
    Contains data on the objects that have been changed. Object identifiers are stored as strings.
  • AuditedObjectWeakReference
    Contains data on both the objects that have been changed and the objects that have taken part in a change. Object identifiers are stored in the GuidId or IntId field, depending whether they are stored as Guid or integer values. So, the AuditedObjectWeakReference table represents a more convenient way to access object data than via the XPWeakReference table.

It is possible to lose some of the object changes, if these changes are performed within a session that is not audited. This can occur if you manually create a Session or UnitOfWork. To avoid such a failure, use the Application.CreateObjectSpace method, when you need to create your own Session or UnitOfWork:

Do not write a statement like the following:

Expanded See Also

How would you rate this topic?​​​​​​​