Hi everyone.
Currently I’m building a small process to send out reminders to customers about documents they have to send back to us.
In general the process is quite easy since the reminders get triggered every four weeks.
What I did is I have an external task which checks whether or not we have received an answer and this task has a non-interrupting boundary timer event with definition type cycle e.g. R2/P28D.
A new requirement now is, that I have to pause this process. E.g. customer calls us, he needs more time for reason xyz. We would now delay the process for x days and after that the process has to continue as usual.
My first idea now was I may simply suspend the process for the given time. To test how camunda reacts I created a small test workflow and discovered a strange behavior I didn’t expect.
After I suspend the process instance and restart it later, camunda completely ignores how often the boundary event should be triggered and just fires it once after it has been reactivated.
For example. The test process waits on an user task with the cycle R10/PT1M and branches in another user task after the event has been fired.
I started two instances, one which gets suspended and restarted after a while and one that does not get touched. The instance I didn’t touch now has 11 activity instances. One still standing in the original user task and 10 in the one behind the boundary event.
The instance I suspended does only have 2 activity instances. The one in the original user task and one in the user task behind the boundary event.
So how does the engine treat those cycles? Does it calculate the time between being suspended and reactivated and decides about how often the boundary event still has to be triggered? That cannot be the case since it didn’t make a difference whether I reactivated it after 15 or 4 minutes. In both cases the boundary event got triggered only once.
Thanks!
PS: And while I write this and doing some more testing it totally screwed up. In another instance after reactivating the instance it triggered the boundary event 110 times(!) simultaneously before then being triggered 9 more times just as I would have expected. Now seeing this, I should rather not suspend any process instance…
We’re still using v7.9.0.