in the example is a timer boundary event non-interrupting, type cycle, attached to an user task. When the user task is not executed, the timer boundary event creates lots of flows. The timer defintion type is cycle and set to “R10/PT5S”, so 10 times repeating intervals each 5 seconds. In my point of view there should be then 10 resulting flows. Why is the behaviour so unexpected?
Thank you very much!
I can replicate the problem, and it is indeed an unexpected behavior. Does it also occur if you disable the
asyncAfter flag on the Timer boundary event?
Also, what happens if you define an end (or start) time. Does the behavior change?
Hello, thanks for fast reply.
- Yes it also occurs when the asyncAfter flag is off.
- Do you mean to use the timer defintion type “date”? Or how can I set a start and end time with the type cycle?
I only had the behaviour with the definition type “cycle”.
With cycle Timers, you can define the start, or end time of the Timer. For example, you can set:
The former will start at
2019-09-10T13:00:00Z and repeat 10 times in 5 second intervals, while the latter will start 50 seconds before 2019-09-10T13:00:00Z and repeat 10 times in 5 second intervals.
Does defining the timer in one of these ways change anything?
thank you for your answer.
I am not looking for a solution for this particular behaviour anymore.
In case it does not conform with the BPMN specification I think it is good if Camunda consider to have a short look on this.