User Story (Required on creation):

The process instance modification and process instance restart features can be used to return a process instance to previous token state, for both running (modification) and historic (restart) instances. While there are APIs to set variables with these operations, it is not possible to conveniently restore the variable state of exactly when an activity was previously executed. This would be useful in order to accurately restore a previous state.

Example: A process instance is a sequence of activities A, B, C. Due to corrupt data produced by activitiy B, it fails in activity C. To recover the state, the process instance must be modified so that it starts before B. To fix the corrupt data, the previous data should be restored.

Functional Requirements (Required before implementation):

• The API has a concept of a variable snapshot, i.e. the state of variables when an activity was executed previously; the snapshot contains all variables that were visible in the execution hierarchy from that activity
• The process instance modification and process instance restart APIs are extended so that a modification/restart instruction can reference a variable snapshot of a previously executed activity instance
• When the instruction is executed, the variable snapshot is applied to the process instance. The variables are set on the correct levels of the execution hierarchy
• It is possible to reference a variable snapshot for the start or end of any historic activity instance
• The feature is intergrated in Cockpit in the restart and modification UIs; there is a way to select a variable snapshot (e.g. if an activity was executed multiple times); there is a solution if there are a lot of snapshots for one activity (e.g. in the case of multi-instance)
• Optional (potentially separate tickets): Cockpit has a way to inspect a variable snapshot. There is a corresponding Java and REST API to request variable snapshots for a particular historic activity instance

Technical Requirements (Required before implementation):

• Implement the concept of variable snapshots, e.g. by the following approaches
  1. Extend ACT_HI_DETAIL so that it allows to accurately recreate a variable snapshot and implement an algorithm that calculates a consistent view for a given activity instance id + "start/end" based on the data
  2. Create a new snapshot concept that is tailored to this use case (partly redundant to ACT_HI_DETAIL, but could also reference entries from ACT_HI_DETAIL so that variable values are not duplicated)
• Decide if the engine collects variable snapshots by default, only when activated via an engine configuration property, or only when defined in the BPMN model (e.g. by marking activities); can also be a mixed solution, so that users can decide on the tradeoff between size of history data and flexibility of the feature
• Snapshots are covered by history cleanup
• Decide how to handle the technical multi-instance variables (e.g. nrOfInstances)

Limitations of Scope (Optional):

• The feature works only with history level full
• It is okay if the snapshot calculation is not optimized for performance: the use case is a manual operation that must be performed only in exceptional cases; that said, the performance should still be good enough so that it is useable from a web application (e.g. a couple of seconds can be okay, a minute is certainly not)

Hints (Optional):

• The snapshot concept must answer the following questions:
  1. What are the variables that were set in the process instance at specific a point in the past?
  2. What are the variables that were visible from a certain historic activity instance?
  3. What was their assignment to the execution hierarchy (this is more than knowing the execution id)?
  4. How does that assignment translate to the execution tree of the process instance in which we want to set the variables?
• It must work fine with concurrent and non-concurrent executions, also with the situation that a variable may have been set on a concurrent execution in the snapshot but that concurrent execution does not exist in the hiearchy at the time the snapshot is applied