Guidelines for checkpoint placement and usage

In a workflow definition, place checkpoint system functions in the following order: BeginCheckpoint, RollbackCheckpoint, and EndCheckpoint.

More specifically, the order is as follows:
  1. BeginCheckpoint. Save the work item data fields that are specified in the corresponding RollbackCheckpoint.
  2. A number of steps that might have some risk.
  3. A step that checks if the previous steps executed correctly and decides either to execute the rollback or to end the checkpoint processing.
  4. RollbackCheckpoint. Restore the saved data field values.
  5. EndCheckpoint. Discard the saved data fields values.

Placement

  • Checkpoint blocks (that is, a sequence of BeginCheckpoint, RollbackCheckpoint, and EndCheckpoint calls) cannot be nested.

    After a BeginCheckpoint function executes, if another BeginCheckpoint function is encountered (and no EndCheckpoint function was executed), an EndCheckpoint for the first BeginCheckpoint is assumed. The information that the first BeginCheckpoint saves is discarded; information is then saved for the second BeginCheckpoint.

  • If a RollbackCheckpoint function does not have an associated BeginCheckpoint instruction, a malfunction exception is raised at run time.
  • If an EndCheckpoint function is encountered before a BeginCheckpoint function is executed, the EndCheckpoint function is ignored.

Usage considerations

  • The RollbackCheckpoint function rolls back only designated work item data fields. The ramifications for system functions and user-defined steps that execute between the BeginCheckpoint and RollbackCheckpoint functions are as follows:
    • The effects of any system functions are not erased. For example, work items that are created by a Create system function are not deleted.
    • The results of any automated external process remain unless you undo them manually or with another automated process. For example, an automated process that is outside the scope of Content Cortex software might update an external database.
  • If you roll back a work item that previously satisfied a WaitForCondition condition in another work item, the previously waiting work item does not begin waiting again. The following sample sequence of events explains this behavior:
    • A BeginCheckpoint executes for work item B.
    • Data field C in work item B = 123.
    • A WaitForCondition executes for work item A. A work item with data field C = 123 satisfies the wait condition.
    • Work item A's WaitForCondition is satisfied by work item B.
    • The next step for work item A executes.
    • A RollbackCheckpoint executes for work item B.

    Even if the value of data field C is changed (from 123) during the rollback, work item A is not affected because the WaitForCondition function completed processing.