Copyright © Cloud Software Group, Inc. All Rights Reserved

Checkpointing Service Orders

You define a checkpoint at a place in the stream where you want to guarantee that the work completed up to that point is not repeated. You can add as many checkpoints to your stream as you need.

When Fulfillment Provisioning re-injects a checkpointed service order, it does so at the last checkpoint that the service order passed.

When you add checkpoints or order queues, you also need to commit service orders at the end of a stream. You commit service orders with the Commitpoint module.

If there are no check points, makeCheckpoints is set to FALSE on drivers, sequencers, and so on.

Figure 27. Checkpointing Modules

Checkpoint

The Checkpoint module externalizes the current state of service orders. The module receives objects of type ::prov::ServiceOrder and saves an external representation of the object. You can use this module to ensure the persistence of service orders in the event of a system failure.

The following types of modules have built-in checkpoints so it is never necessary to place a checkpoint module immediately before or after them in a provisioning flow:

•

reservoir

•

driver

•

sequencer

•	orderqueue

•	token remover

•

gate

Type

prov::Checkpoint

For more details about this module, refer to the component documentation.

Commitpoint

The Commitpoint module removes all externalized versions of the request.

Type

prov::Commitpoint

For more details about this module, refer to the component documentation.

Reinjecting Service Orders

Following a system failure, you can reinject all service orders with checkpoints using the following commands:

provadmin reloadCheckpoints checkpoints

This command must be issued before opening the gates. This assures that the orders with a checkpoint are completed before other newer orders are admitted to the provisioning flow.

Data Storage Back Ends

When checkpoints are placed in service orders, a representation is saved in some external format. This is done in a flat file format.

Using Checkpoints

The use of checkpoints has a direct impact on system performance, so you should use them sparingly. There are two locations in a flow where the use of checkpoints is recommended:

•	immediately upon receiving work - so that the system can respond to clients with a "Pass" or "Fail" even in the event of downstream failures.

•	when an order enters a queue - this is a configurable feature of Fulfillment Provisioning queues.

The Fulfillment Provisioning flow controller swap level monitoring feature should also be used for memory management.

The Fulfillment Provisioning checkpoint feature reduces, but cannot eliminate, the risk of dropping orders. There are still failure modes in which in-flight orders will be dropped. Over-use of checkpoints may increase the risk of such failures.

Copyright © Cloud Software Group, Inc. All Rights Reserved