Copyright © Cloud Software Group, Inc. All Rights Reserved

Checkpoint

Activity

The Checkpoint activity performs a checkpoint in a running process instance. A checkpoint saves the current process data and state so that it can be recovered at a later time in the event of a failure. If a process engine fails, all process instances can be recovered and resume execution at the location of their last checkpoint in the process definition. If a process instance fails due to an unhandled exception or manual termination, it can optionally be recovered at a later time, if the process engine is configured to save checkpoint data for failed processes. See TIBCO ActiveMatrix BusinessWorks Administration for more information about recovering failed process instances.

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

Configuration

The Configuration tab has the following fields.

Field	Description
Name	The name to appear as the label for the activity in the process definition.
Description	Short description of the activity.

Input

See TIBCO ActiveMatrix BusinessWorks Process Design for more information about mapping and transforming input data.

The input for the activity is the following.

Input Item	Datatype	Description
duplicateKey	String	A key value that is used to compare to other process instances to determine whether another process instance with the same duplicateKey value already exists. See TIBCO ActiveMatrix BusinessWorks Process Design for more information on detecting duplicate process instances.

Checkpoints and Transactions

A Checkpoint activity cannot be placed in or in parallel to a transaction. You can, however, specify that an implicit checkpoint should be taken as part of a transaction by checking the Include Checkpoint field on a transaction group.

For explicit Checkpoints, place the checkpoint activity outside of any transaction group. Also, make sure that if you have multiple paths in your process definition, the Checkpoint activity does not occur in parallel with a path that has a transaction group. Instead, any Checkpoint activities should be placed at points that are guaranteed to be reached before or after the transaction group is reached.

See TIBCO ActiveMatrix BusinessWorks Process Design for more information about creating groups for transactions and including an implicit checkpoint in a transaction.

Called Processes

Checkpoints save the state of the entire process instance. By default when a process calls another process, the subprocess is executed in the same process instance as the calling process. If the called process spawns a new machine process, however, the called process is a new process instance.

When a checkpoint occurs in a called process, the checkpoint saves the state of the current process instance. If no called processes spawn new process instances, then a checkpoint in any called process saves the state of the process instance, including state from the parent process(es) of the current process. In the case of a called process that spawns a new process instance, only the spawned process instance is saved.

Recovering After a Crash

If a process engine crashes, all process instances can be recovered up to the point of their last checkpoint. You must be careful with certain types of process starters or incoming events when placing your checkpoint in a process definition.

For example, if the process starter is waiting for an incoming HTTP request, and a checkpoint is taken after the process starts but before the response to the request is sent, the process cannot respond to the request when the process instance is restarted. The socket for the HTTP request is closed when the process engine crashes, therefore the Send HTTP Response activity in the restarted process returns an error. In this case, place the response activity before the checkpoint so that any response is sent before a checkpoint is taken.

There are other examples of situations where an incoming event must be handled before the checkpoint is taken. The following lists some of these circumstances:

•	An email message is received, then deleted from the email server.

•	An HTTP request is received.

You should exercise care in placing checkpoints in your process definitions. Make certain that the process has all of the data required to continue at the time of the checkpoint so that in the event of a failure, a restarted process does not attempt to access resources that no longer exist.

By default, checkpointed process instances are restarted when the engine restarts. If the engine encounters errors during startup, the restarted process instances continue to be processed and may eventually be lost depending upon the type of error at startup. You can specify to shut down the process engine if any errors are encountered during startup so that checkpointed jobs are not lost in the event of an error. The custom engine property named Engine.ShutdownOnStartupError controls this behavior. By default, the value of the property is false. Setting the property to true shuts the engine down if errors are encountered when the engine starts. See TIBCO ActiveMatrix BusinessWorks Administration for more information about setting custom engine properties.

Checkpoints and the Confirm Activity

In the case of confirmable messages (for example, a confirmable TIBCO Rendezvous or Adapter message is received), you must consider the consequences of performing a checkpoint before or after a Confirm activity.

If the checkpoint is taken before the Confirm activity, then a crash occurs after a checkpoint but before a confirm, the original message is resent. In this case, the restarted process can no longer send the confirmation. However, a new process is started to handle the resent message, and you can implement your process to handle the restarted and new processes appropriately.

If the checkpoint is taken after a Confirm activity, there is potential for a crash to occur after the Confirm but before the checkpoint. In this case, the message is confirmed and therefore not redelivered. The process instance is not restarted, because the crash occurred before the checkpoint.

You must consider the type of processing your process definition performs to determine when a checkpoint is appropriate if your process definition receives confirmable messages.

Copyright © Cloud Software Group, Inc. All Rights Reserved