CHECK POINT

There are two ways of using checkpoint

1) Identify duplicate messages
2) 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.