CheckpointWorkflow Activity

For in-memory workflows, since the workflow state is not saved to the database during the workflow execution, in case a failure or recovery scenario occurs, workflow execution starts from the first activity in the workflow.

To avoid such re-execution of workflows post failure, using the CheckpointWorkflow activity, the process state can be saved to the database at workflow milestones. CheckpointWorkflow saves minimal data required for recovery, and in case of failure, workflow execution starts with the next activity.

Note: The CheckpointWorkflow activity has no impact on regular (transactional) workflows, and it behaves like a NoOperation activity. For regular workflows with Cache documents enabled, CheckpointWorkflow persists all documents in the workflow in that activity.

How It Works

If a CheckpointWorkflow activity is present in a workflow, it persists minimal process-related objects required for recovery, such as the event, event details, process, process details, the last process log, all non-eliminated documents, and the process state.

No process data is persisted before the CheckpointWorkflow activity in an in-memory workflow. After CheckpointWorkflow is executed, the data required for recovery is saved for that process, and the required data is committed to the database.

If multiple CheckpointWorkflow activities are present in a single in-memory workflow, the first time CheckpointWorkflow runs, it saves the required process data, and for subsequent times, the process data (but not the process log and documents) is updated. After that, the last process log and non-eliminated documents are saved. The transaction initiated after the last CheckpointWorkflow is committed and a new global transaction is started for the next activity.