CHECKPOINT ACTIVITY

There are two ways of using checkpoint activity

1) For identify the duplicate messages
2) To save process and state in the event of BW engine failure
If checkpoint is used to identify duplicate messages, we need to specify the
element whose value will be considered as unique as the value for duplicate key.
By default the job will be stored into memory while BW engine is processing it.
Before completing the job if the BW engine crashes the job data will be lost.
If checkpoint is used, the job data will be safe. When the engine is restarted the job
data can be recovered.
A process can have one or more checkpoint activities but only the last checkpoint
will be saved. When the engine is restarted the BW engine will be resume the job
from the last checkpoint.
To save the process data we need to pass the BW engine checkpoint properties.
bw.engine.enablejobRecory

--------------------True

bw.engine.autoCheckpointRestart--------------------False
Hawk.Enabled

--------------------True

After engine is restarted, the checkpoint job can restart from the administrator or
from BW or during testing time using engine command activity.
In one engine command activity we need to specify get recoverable process, in the
second engine command we need to specify restart recoverable process.
The checkpoint data can be stored into database or file.
The default is file.
If it is file for each unique key a file will be created in jdb_dupkeys folder and each
check pointer job Xjob file created in jdb folder.
<jobid>.xjob in jdb

If it is database the unique keys will be stored into duplicates table, the check
pointer jobs will be stored into jobs table.