Strange timer boundary behaviour

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

lmollea

I experienced a "curious" behaviour on a user task with a boundary timer and a output fanout with conditions.

It happened that even if the task was closed, the timer on the task wasn't cancelled and thus fired at the appointed time, causing an unexpected behaviour.

The process which caused the issue is shown in this image.
"Task 3" has 4 output flows 3 of which get activated based on a set of conditions and a 4th one (the bottom one that skips the parallel work) which is activated when all the previous three conditions are not met.
As I mentioned, when completing "Task 3" the process went on to the various legs, but after the boundary timeout on "Task 3" was reached, that boundary timer fired and we had also the task "Timeout Task 3" active.
By launching again the process and looking at the tables, we noticed that the ACT_RU_EVENT_SUBSCR still had a line for the timer on "Task 3" even when only the "Postprocess" tasks were active.
To avoid the problem, the process was changed to this one. The only change is the addition of the inclusive gateway after "Task 3". With this change, no spurious timer is left behind when Task 3 is completed.

To me the two process seems equivalent, but at runtime, they are not. I don't know if this is an expected behaviour or is a bug.
The user guide doesn't seem to imply that this should happen (quoting):
"A sequence flow can have a condition defined on it. When a BPMN 2.0 activity is left, the default behavior is to evaluate the conditions on the outgoing sequence flow. When a condition evaluates to true, that outgoing sequence flow is selected. When multiple sequence flow are selected that way, multiple executions will be generated and the process will be continued in a parallel way."

If this is a bug, let me know, I'll set up a test case and raise an issue.

Thanks

trademak

Having multiple sequence flows out of a user task is not a best practice in BPMN. It causes behaviour which you might not expect like mentioned in your post. The inclusive gateway is indeed necessary for your use case. You might event want to have an exclusive gateway before the inclusive gateway if you need to go directly to task 3, if not you go to the inclusive gateway.

Best regards,