History Service

The History worker provides a flexible way to store and retrieve data for any service capable of communicating with the API Server.

The data that the history service records are known as "Histories". Each history relates to one chain of events and is identified by a unique compound key made up of between one and five parts called "labela", "labelb", "labelc", "labeld" and "labele". We've developed a set of conventions for these labels, described in the Conventions - Standardising History Data. A history is also identified by a single internally generated "id" string. The data from a single history can be retrieved by using its unique key. The data from multiple histories can be retrieved by using "Filters".

Each history has one packet of "Subject" data, written at the time the history is created. The subject data cannot be edited or deleted once a history has been created in the database.

Histories can have any number of "Event" data packets. The data packets are added sequentially to the end of a history, they cannot be edited or deleted once they have been added.

Subject and event data can have any arbitrary JSON structure. The worker is also able to log geographic data, and provides a range of filters for its retrieval.

Histories can be "sealed". A sealed history is switched into a read only mode where no more events can be added. Sealed histories can still be deleted.

Histories are commonly created and updated throughout the lifetime of a workflow process instance. A history is written when a process instance starts, setting the subject data and an initial start event. Further events are added as tasks are carried out (both user tasks via form submissions and scripted/history tasks within the process model). The iCM Forms Designer and Process Modeller write events with special properties, like public/private and summary, which are in turn used by the Self Service range of GOSS products and solutions.

Worker Configuration Properties