This page aims to outline the history support that is anticipated to be part of Activiti 5.0.
Purpose of History
The history module provides access to historic process execution data and acts as a base data provider for process execution reports. For an initial version, the history module should just provide enough information to feed simple statistical reports and queries about process instance / activity instance executions and their executon times.
History vs. Audit
While history is focussing on the fact that and when a specific process or activity has been executed and how long it took to execute it, audit aims for providing comprehensive information on what exactly has been done during a process execution. Typically, the data provided by history builds the base for creating reports and statistics while audit aims for satisfying the regulatory/legal requirements of providing traceability and information on who changed what and from what value to what new value. Due to this different requirements, the natural data model for history and audit differ fundamentally: a history data model contains a consolidated view on executed process steps, optimized for querying, an audit data model in contrast focus on persisting the actual events together with the context data (user, condition evaluations, process data, ...) needed to trace the change.
Scope of the initial history support is limited to reporting/statistics, not audit. Based on the current process event bus infrastructure, an audit component could be built without any dependency or relation to the history support.
The following reports should be included in Activiti 5.0:
- # of process instances created within a time range, grouped by process definitions
- minimal, maximal, and average execution process instance execution time, grouped by process definitions
- minimal, maximal, and average execution time for activity instances for a specific process definition
These reports should be made available as a chart within Activity Probe or Explorer (TBD).
The history data model consists of two main relations:
Italic attributes are there for providing a denormalized data view optimized for querying from external tools, directly based on the history data tables (e.g. activities can be grouped by processDefinitionId without the need for performing a join on the historic process instance table). As a consequence, the two relations are not linked in any way (i.e. no foreign key from historic activity instances to historic process instances). The same attributes and structure are reflected in the entities.
TBD: describe query API for querying historic process instances and historic activity instances with support for filtering, sorting, grouping, specifying date ranges, ...