Audit Trail
Architecture
Since audit trail information accumulates over time, the requirements for storing this data are different than the actual product data which always only contains the latest data and is always in sync with the metadata (domain model) and other elements of the overall system.
During the persistence logic in Product 360 Server, the Entity Item Change document is created. While the modifications of the clients are being persisted in the relational database, we send this document to the Elasticsearch document store where it is being persisted and it's meta attributes are being indexed. After this has been successfully done, the change document is used as payload for item created, item changed and item deleted triggers. In case one or multiples of those will fire (based on their trigger rules), the document is sent to the Message Queue from where it is picked up by the BPM server or a third party server which listens to the corresponding queue.
A watchdog process runs in the Product 360 cluster which makes sure that in case of any crash the data is in sync between the relational database and audit trail. This watchdog also takes care that the trigger framework is called at least once per entity item change document.
Configuration
Multiple configuration options are available for audit trail. From a developer mode which disables the persisting of the change documents in elastic, but keeps the trigger logic in place, to different configurations for on-premises Elasticsearch vs. cloud services. Audit trail can also be configured for each entity and field in the repository. All this is described in detail in the Configuration Manual.
Customizing
The audit trail feature can also be customized to some degree. Special transformational logic can be contributed for fields which have special requirements. More details on this can be found in the Customization Manual, section Data Audit. Also, the detailed description of the entity item change document can be found there. This should be very helpful for workflow development or in case the elastic search index should be accessed by 3rd party tools. Contrary to the relational database, we do allow the read-only access of the audit trail indexes within the elastic.
Backup
Additionally to the build-in snapshot features of Elasticsearch (please refer to the Elasticsearch documentation on this), a script is provided which can be used to export the entity item change documents from the document store into a zip archive. In the case of cloud SaaS customers, these archives can be provided for download. Since the entity item change document is consumable by any application which can read JSON files and since the document is even human-readable, it can be long term archived for multiple years and even processed without a running Product 360 server.
Please have a look at the Operation Guide for details on this job.
Migration
A migration job is provided which reads from the old, relational audit trail database and transforms those entries into entity item change documents and stores them into elastic search.
Please have a look at the Migration Guide for details on this job.
User Interface
The web as well as the desktop client provide identical views to search and visualize the history based on the stored audit trail documents in Elasticsearch.
Please see the User Manual or Online Help for details on the audit trail User Interface
History Tab
The "History" tab shows the history of changes of the selected objects. For all root entities that support audit trail, a "History" view will be generated automatically. No customization is needed. An entity can be enabled or disabled for audit trail in the repository (see Configuration Manual).
Exceptions are Tasks, Multimedia attachments and Assortments in the Web.
For changes on hierarchical objects like characteristics/characteristic values, the full hierarchy is shown.
Special case for characteristic values: the hierarchy starts with field category, following by characteristic category and the characteristic object hierarchy itself.
Revert a value
The history tab does have a revert value functionality which can be used to set the current value of a field based on a historical value. Please note that this is not an undo. It will apply the old value, and the history will be continued, not deleted! Please find more details on the Revert to old value page.
Audit Trail Search
For advanced needs, a powerful audit trail search is available. This allows you to find changes across data types, change types (e.g. deleted objects), time frames, initiators, and users. For the search with identifiers, one or multiple identifiers are possible to be set, and wildcards are supported as well. It can also be searched by unqualified fields (e.g. any "Price"), and containers can be selected (e.g. the catalog of an item), including searching across all catalogs, or only within supplier catalogs.
