Checkpoint blocks (that is, a Begin/Rollback/EndCheckpoint sequence)
cannot be nested.
After a BeginCheckpoint function executes, if another BeginCheckpoint
function is encountered (and no EndCheckpoint function has executed),
an EndCheckpoint for the first BeginCheckpoint is assumed. The information
saved for the first BeginCheckpoint 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 runtime.
If an EndCheckpoint function is encountered before a BeginCheckpoint
function has executed, the EndCheckpoint function is ignored.
Usage considerations
The RollbackCheckpoint function only rolls back designated work item
data fields. Note the ramifications for system functions and user-defined
steps that execute between the BeginCheckpoint and RollbackCheckpoint
functions.
The effects of any system functions are not erased. For example,
work items created by a Create system function are not deleted.
If an automated process completed tasks outside the scope of FileNet software,
such as updating an external database, the results of those tasks
remain unless you undo them manually or via another automated process.
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. Following is a sample sequence of events that
explain 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 will satisfy 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
roll back, work item A is not affected because the WaitForCondition
function has completed processing.