Although I used the the timer as an example of a waiting state, the use case will work with message catching and signal catching events. From a BPMN point of view, it would be something like:
Task1 will task some asynchronous work to be performed by a separate process. The work could theoretically take minutes to days, so the workflow will wait on a message catching event that will be sent by the other process when it is complete.
In a catastrophic fail case where the other process mysteriously fails during its asynchronous work, we would like to be able to have the process send us a generic message and then roll back to right before AssignAsynchronousWork. This way AssignAsynchronousWork can be run again and then wait on the message once more.
In a normal case, when we have successfully received the message, then the transaction is complete.
I realize this could probably be done in the BPMN through something like this:
But the pattern I am describing would be used so frequently that doing this would pollute the BPMNs. There is also the issue that, in terms of my understanding, the transaction is set at the beginning of waiting stage, so that if Activiti rolls back, it will roll back such that it must receive AsynchronousWorkComplete again in order to progress – unless every task immediately after a message catching event is set to activiti:async="true". I would prefer to avoid that if possible.
This might all be for folly anyways as there appears to be no mechanism to fail or rollback a workflow through the RuntimeService.
Even though what I am asking for might not be possible, I appreciate you taking the time. Thanks.
