While developing TIBCO BW processes in designer, Checkpoint activity available in General Activities is one of the widely used activities. This activity is used to tackle failure scenarios.
Using Checkpoint activity in TIBCO Designer processes you can achieve following benefits:
- In case of a process engine failure, all process instances can be recovered and resume execution at the location of their last checkpoint in the process definition.
- Any data being manipulated or created inside business processes at run time doesn’t get lost and same can be re-used once engine resumes its working.
- Overall load on the network may also be reduced by using check pointing as requests don’t need to be re-sent from the source system in case of failures.
In the below example business process, checkpoint activity is used after receiving RV message. So if process engine crashes at any point after this checkpoint activity, it will resume from this checkpoint after recovery.
What will happen if crash occur after checkpoint but before confirm…it will send the confirmation again …how to avoid this scenario
we start the process which is in a process archive and it keeps running.
Many messages are getting processed on a day- say 50 000 messages
Right after receiving a message in JMS Queue receiver we have check point.
Say we would have 50,000 Check pointed processes?
2. What if on the second day the process crashes. would it process those 50,000 Messages again?
we need to implement process using engine commend to get the recovery process and restart recovery process so that all failure jobs will be executed… we can configure using any database . generally failure job sate will be stored in file system if we run in designer . if we deployed in Admin , we need to advance and select recovery .
Hi Ajmal,
All your simplicity in lectures help us a lot. Could you please help us by giving a lecture on important activities of General Activities Palette.
Thanks,
Venkata Challa
Hi ajmal,
Can we use check point while using HTTP activites
If the process starter is waiting for an incoming HTTP request, and a checkpoint is taken after the process starts but before the response to the request is sent, the process cannot respond to the request when the process instance is restarted.
The socket for the HTTP request is closed when the process engine crashes, therefore the Send HTTP Response activity in the restarted process returns an error.
In this case, place the response activity before the checkpoint so that any response is sent before a checkpoint is taken.
Thanks for the excellent explanation
Hi Ajmal,
I have a question regarding confirm Pallete. If we don’t confirm a JMS message with acknowledge mode as Client , exactly how many times it will be redelivered. Is there a way we can control the number of times the JMS message to be redelivered in such cases where we are not confirming it with Confirm pallete.
Thanks
add queue property “Re-delivery” . this count we can give as per our requirement. 3 or 4 etc