Checkpoints
It is very common for a Fulfillment Provisioning application to require the ability to properly resume (after a crash for instance) from a known state. In order to match this requirement Fulfillment Provisioning provides a checkpoint mechanism which allows live data to be exported and imported.
The checkpoint framework is composed of three parts : a front-end that enables developers to directly access (create, remove, test, etc.) checkpoints from the runtime, a back-end implementing the actual storage method for checkpoints, and an administration layer that enables administrators to trigger migration and recovery from existing checkpoints.
Several components that are part of Fulfillment Provisioning use this low level checkpoint framework to implement checkpoints at various levels, including client adapter request, service order, work order. The swap mechanism offered by queues and reservoirs in Fulfillment Provisioning uses checkpoints too. Generally speaking a new data type will require a new checkpoint kind.
While a very uncommon procedure, applications may add their own checkpoint kind to handle their own data type. This support will generally consists of defining a new checkpoint kind, as well as when a checkpoint of this kind must be written/read and to implement recovery and migration procedures.
At the moment, the only backend provided by Fulfillment Provisioning is the file backend. It ensures data storage in a compact binary flat file.
A checkpoint is characterized by its key, its kind and the name of the node producing it. A { key, kind, nodeName } triplet uniquely identifies a checkpoint in a Fulfillment Provisioning node.