Using Checkpoints

A Checkpoint activity saves the state and data of a process instance so that it can be recovered at a later time, in case of a failure.

If an ActiveMatrix BusinessWorks engine fails, all processes that have a Checkpoint activity can be recovered and resume execution from the last checkpoint executed in the process instance.

Only the most recent state is saved by a checkpoint. If you have multiple checkpoints in a process, only the state from the last executed checkpoint is available for recovering the process.

Checkpoints save the state of the entire process instance. A process (parent process) can call another process (sub-process) in two ways: in-line and non-inline. An in-line sub-process is executed as part of the parent process job, while the non-inline sub-process spawns a new job. When a Checkpoint activity is executed in an in-line sub-process, the checkpoint saves the state of the current process instance, including the state of the parent processes. However, when a checkpoint occurs in a non-in-line sub-process, the checkpoint saves the state of the spawned process instance only.

Checkpoints require the engine persistence mode to be either datastore or group. To configure the persistence modes, see:

If the engine persistence mode is not configured with the correct value, an application with Checkpoint activity encounters an error at deployment.

Recovering After a Failure

Following a crash, when the engine is restarted, the process instances are recovered from the last checkpoint automatically. That is, all process instances that were check pointed will continue processing from the last executed Checkpoint activity.

Ensure that the process has all of the data required to continue processing following a recovery. When placing your checkpoint in a process, be careful with certain types of process starters or incoming events, so that a recovered process instance does not attempt to access resources that no longer exist. For example, consider a process with an HTTP process starter that takes a checkpoint after receiving a request but before sending a response. In this case, when the engine restarts after a crash, the recovered process instance cannot respond to the request since the HTTP socket is already closed. As a best practice, place the response activity before the checkpoint so that any response is sent before a checkpoint is taken. Also, do not place the Checkpoint activity in a critical section or an event handler.
Tip: Test checkpoints in your applications through the Admin UI or with bwadmin.