CHECK POINT

There are two ways of using checkpoint

1) Identify duplicate messages2) To save process data

When check point is used to identify duplicate messages, we need to specify an element whose values will be considered as unique to the element duplicate key.

By default BW engine will store job data in memory while it is being executed. If the BW engine crashes before job is completed, the job data will be lost.

When checkpoint is used and BW engine crashes the job data will be store and given process state also will be save. With this information when the BW engine is restarted the data will be recovered and the process data will be also recovered.

For the checkpoint to work properly when the engine is restarted the job should not be resume immediately because the target servers may be offline.

In order to specify this where the check point job will not be start automatically we need to specify the BW engine specific check point property by starting BW engine. These properties are

bw.engine.enableJobRecovery=true

bw.engine.autoCheckpointRestart=false

Hawk.Enabled=true

If the check pointer jobs should be manages with in designer then we need to use engine command activity and we need to specify get recoverable process. We need to specify the checkpoint properties in a file whose extension should be “cfg” and this file should be passing using the command –p <cfg>

A process can have one or more checkpoint activities. But only last checkpoint will be save.

If the checkpoint activity is used for reliable systems we should always specify the confirm activity before checkpoint otherwise for one message two jobs will be created if BW crashes after checkpoint and before sending confirmation.

By default the check pointer jobs will be stored in JDB folder. Each check point job will be saved as <JOBID>.xjob

When checkpoint activity is used to identify duplicate messages each unique value will be saved as <unique value>.key in Jdb_dupkeys folder.

The check point data can also be stored in database.