Every single action in AdaptableBlotter.JS can, optionally, be fully audited for internal review purposes: each keystroke, menu click, configuration change and data edit. This provides you with complete oversight over everything that ever happens in the Blotter.
You are able to choose what is audited and where the message are sent to.
Information sent to Audit Log lives entirely within your systems at a destination specified by you.
Adaptable Blotter has no knowledge of where you are storing this data and what is sent. And it has no ability to access this data. Any data sent to the Audit Log is known only to you, and is accessible only by you.
For instance you can set up an alert to be informed whenever a value changes in a particular column, or if the new value exceeds set limits; or you can run reports showing a particular user's activity, or how data has changed over any time period.
Audit Log is enabled - and configured - when setting up the Adaptable Blotter in AdaptableBlotterOptions via the AuditOptions property.
When Audit Log is turned on, all changes are streamed automatically - both data and user / config changes. However administrators have the ability to listen only to certain categories of audit change.
They do this through setting 3 boolean properties in each of the 5 sections in the AuditOptions object when creating Blotter Options at design time (see Audit Options). The 5 sections are:
Cell Edits - provides full details of any edits made to data inside the Blotter.
Function Events - details any changes made within Adaptable Blotter functions (e.g. Advanced Search selected, Smart Edit applied, layout changed etc.).
User State Changes - logs any changes to the user's state (e.g. Conditional Style deleted, Quick Search highlight colour changed etc.) . It uses a Diff function so that the change in the State (and the cause of the change) is logged. Also includes the StateChangedDetails object which describes both State property and State object changes and gives full details about exactly what the change includes.
Internal State Changes - logs any changes to the internal state used by the Adaptable Blotter (e.g. popup closed, cells selected). This is the most verbose of the 4 types of audit events and uses the same Diff function as the User State changes.
Ticking Data Changes - logs any changes to the underlying data source in the Grid.
For each of the 5 types of of Audit (see above) you can configure where the Audit Message gets sent. There are 4 possibilities (though you can select more than one):
auditToHttpChannel: sends Audit Messages to an HTTP channel for you to listen to with the software of your choice (see below for more details)
auditToConsole: sends Audit Messages to the Console - usually used in development or by Support to test
auditAsEvent: fires Audit Messages as Audit Events.
auditAsAlert: fires an Adaptable Blotter Alert for each Audit Message that is created (use sparingly!).
If all 4 options for all 5 Audit Types is set to false (the default) then nothing will be audited.
Audit Log is a simple stream of JSON objects sent over an HTTP channel to an internal destination that you specify and that you set. Each object contains full details of what the type of change was, the user, the time and any other related information.
You can use any appropriate software that you like to "listen" to the message stream and then run reports, send alerts or react in any other way to the data coming in.
Alternately you can choose to log messages only to the Console.
If the Adaptable Blotter determines that nothing is listening to the audit stream then the Audit Log will stop sending messages automatically.
When Audit Log is turned on, all changes are streamed automatically - both data and user / config changes. However administrators have the ability to listen only to certain categories of audit change. They do this through setting the Audit Options object in Blotter Options.
Many organisations will have their own reporting and auditing software with which they are already familiar.
If this is the case then it should be trivial for you to configure that software to listen to the Audit Log when sent to the HTTP channel and you will be immediately able to report on it.
If you don't have your own existing auditing or reporting software in your organisation, then a good choice is the Elastic Stack. Containing 3 associated products from Elastic (ElasticSearch, Kibana and Logstash), its a very advanced and powerful auditing suite, yet easy to use and set up. You can find more details on the Elastic website about their Elastic Stack.
The Adaptable Blotter team will be able to advise you on how to set up the Elastic Stack so you can take full advantage of power of Audit Log.
The image below shows the raw details of a Cell Edit ('BidOfferSpread' has changed from 0.35 to 0.85) in Kibana. You can see that details of the user, the timestamp and much else is included.