How is Tracing Secured via Event Sourcing and Logging?

Casewhere applies several concepts and technologies that ensure tracing and audit-ability of everything that has happened in the system.

First of all, the architecture of the system is based on Event Sourcing. The fundamental idea of Event Sourcing is ensuring every change to the state of an application is captured in an event object and that these event objects are themselves stored in the sequence of they were applied for the same lifetime as the application state itself. Each event has references to the exact case, workflow, and activity that caused it as well as who did it and when it was done. So by looking at the events, it will be possible to backtrack the reason for the current state of the system from the very start. The most important thing is by storing events, we never actually overwrite an old object with new data. We simply just add a new object as a newer version of the old one. Even when deleting an object, it happens by creating a new version of the prior one that is then tagged as being deleted. In this way, we are sure that nothing is ever overwritten by accident and that no information is ever lost.

Read and Write operations are known as Queries and Commands in Casewhere (CQRS pattern). A command, which changes the system’s state, will trigger events that can be captured for different purposes e.g. event sourcing, audit log, and notification broadcasting. Technically, commands, queries and events are just messages that sent from a source and go through a pipeline consisting of layers in series before reaching their destination. Casewhere’s framework makes it easy for an extension to subscribe to the events or to hook into a command/query pipeline to do custom processing.

By applying Event Sourcing, we have a free audit log, which in many cases, is all you will need. However, some projects may also need an Audit Log, especially where the log data can tell valuable stories about the business rather than just backtracking events. Casewhere provides a Standard Audit Log in a separate module that can be installed along with Casewhere core as an optional feature. By choosing to install this feature, you are able to log not only ‘Write’, but also ‘Read actions’. E.g. when users retrieve lists, open pages, or view a dashboard. The system will be smart enough not to log heavy data by default such as byte arrays and query results, but still provide a mechanism to decide to save more data through a scripted function.

Furthermore, we understand how important it is to make log messages look friendly. We will in Workflow Definitions and Activity Definitions add a setting called “Logging Message Template”, which will make it possible to define exactly how the events are named in the Event Source; e.g. “Case person {casePerson} was registered by {user} in {court}”. In other words, we will enable merging in the actual data values from the session, so that there is “human readable text” available, as well as more useful information enriched for the event that will later enable full text search or advanced filters. Please note that this setting will not affect how the event is persisted in Event Source. We want to keep the Event Source normalized to ensure overall performance. All the enriched information will be saved independently to the external DB dedicated to the audit log.

Finally, while the Event Source is quite limited for searching (since it is designed to optimize write), our Standard Audit Log can write to a few popular storage systems that are more suitable for searching and archiving.