Checkpoints and Confirm Activity
In the case of confirmable messages (for example, a confirmable TIBCO Rendezvous is received), consider the consequences of performing a checkpoint before or after a Confirm activity.
If the checkpoint is taken before the Confirm activity, a crash occurs after a checkpoint but before a confirm, the original message is resent. In this case, the restarted process can no longer send the confirmation. However, a new process is started to handle the resent message, and you can implement your process to handle the restarted and new processes appropriately.
If the checkpoint is taken after a Confirm activity, there is potential for a crash to occur after the confirm but before the checkpoint. In this case, the message is confirmed and therefore not redelivered. The process instance is not restarted, because the crash occurred before the checkpoint.
You must consider the type of processing your process performs to determine when a checkpoint is appropriate if your process receives confirmable messages.