Exact way of modeling (non)-interrupting Timer event in BPMN notation

Maybe I am naive, but could it be as simple as this?

Explanation: A receive message task waits until the expected message is received. So the non-interrupting timer events at 7 and 14 days do not interrupt waiting for the message. The interrupting timer event at 21 days does and finishes your process with "Analysis cancelled". If ever the message is received within 21 days the process will continue to "Start up analysis" and no further timer events on "Receive start message" will occur. Also note that an end event only ends the process branch it occurs on, consuming the token arriving at it. Other tokens will continue.

EDIT: Updated process image with Customer pool.

And here is a further simplification, if the second reminder is not really different from the first:

This will reuse the "Send reminder to start" for both reminders. The task will be passed by two process tokens at different times, if the 14 day threshold is reached.

this looks a really good solution... the only thing I'd change is adding in a conditional gateway to join the reminder messages being sent and the receive start message completion.... the end event after sending reminder isn't really an end to the process is it? ... reference attached from Bruce Silver book.... additionally (but being very picky here!) I always put customer pool at top of a collaboration to highlight customer touchpoints and label them - and place in space between pools

Hello,

Thanks for the replies.

Mr.  Zschuckelt; I think we can move forward with the (more than one) timer events per [Function] Task. It is not described in the book/cheat cheats or any other source (?) but it will give us a way forward.

Mr. Winterburn, we are going to join the process later on as shown in your example, otherwise (you're right) the process will end after those 'Send reminder' tasks. Coming back to your other point; A Customer pool (black box) and the interaction with them using message flows is also in place, whilst modeling the process in a separate pool with lanes.

BR,

Vincent

Hi Vincent... there is reference in the BPMN spec page 258/ 288 (the PDF page search/ page labels a bit off!) regarding one or more intermediate events. I often use multiples, but you're right it's hard to find examples.

Hello Vincent, Charlie,

regarding the usage of end events M. Zschuckelt wrote in his post and that's fully correct:

"Also note that an end event only ends the process branch it occurs on, consuming the token arriving at it. Other tokens will continue."

The process is still waiting in the task "Receive start message" and is NOT finished by reaching the end event after the task "Send reminder to start". If a process should be finished completely, interrupting all open sequence flows (consuming all tokens) the BPMN spec provides the element "Terminate end event":

In Charlie's proposed model the task "Start analysis" would initiated already after sending the first reminder.

Regards

Klemens

Hello Charlie,

thank you for the useful hints. By the specification an end event does not end the process, but only consumes the token arriving at it. Only when it is the last token in circulation the process will finish. So in this case your suggestion of joining the flows with a gateway is not strictly necessary. There are end events in the flavour "Terminate End Event", which signal to all process tokens in circulation to immediately terminate the entire process. So here it is a matter of taste, if you want to join all parallel flows at one end event.

The model you suggested would lead to starting the analysis immediately after sending the reminder, which does not really make sense when we assume that the customer response is required to start the analysis. This would make you start the analysis up to 3 times. Observe that the side flows at 7 and 14 days are not interrupting the "Receive start message" activity, which is waiting for the customer message. They are additional process tokens coming into existence with the non-interrupting timer events on the border of the activity.

The join could be before the end event.

Hi Klemens,

with regards 'In Charlie's proposed model the task "Start analysis" would initiated already after sending the first reminder.' ... just want to be clear I understand this correctly as I may be misunderstanding something.

My rationale for the model was trying to show a real process end event rather than some end event just because a reminder was sent. My reading of my model (sounds like I may be wrong) is that the gateway is conditional, and although the conditions not explicit, would mean the analysis wouldn't start until a response was received (this is always started) and that the reminder sent (if required) would then wait at the joining conditional gateway until response received and that's moved on the the gateway - as it's always required... not sure quite worded it correctly, but hope that makes sense...even if wrong :-)

thanks

Charlie

Hello Charlie,

the gateway you used is the "Inclusive gateway". That is kind of a logical "OR". So it will not wait for the path from receive start message to occur. Used as a joining gateway it will pass on any token immediately on the outgoing path as it is reached. If you used a Parallel gateway ("... AND that the reminder sent (if required)...") this gateway would wait, but the "if required" would cause you trouble. If the customer responds timely before 7 days there is no token on that path, yet an inclusive gateway would wait for ever.

With a "complex gateway" you could define arbitrarily complex conditions, but it is impossible to understand it without doing the reading on what the conditions are. And one more problem: When the 21-day case arrives, the gateway will wait forever for input from that path. So your complex gateway would have to be intelligent enough to re-evaluate from time to time if the 21 days might have timed out and then what? Start up the analysis anyway without customer input? If not, the 21-day case would leave your process lying around as a zombie, that will never die. 

If you have a preference for showing only a single end event for your process, you could join with your inclusive gateway after start up analysis, yet you would have to have a more generic term for the end event, where up to 3 process tokens will arrive.

I'd prefer the extra end event for the reminder side flow. Its end event should have a better name "Reminder sent". After all sending the reminder has no practical consequence for the process flow. It might increase the probability of the customer responding, but that's it.

So, what is a "real process end event" in your opinion? A process is running, when there is at least one active process token in the model. Sometimes there are more, created through parallel gateways or as in our example through non-interrupting border events. The process ends, when the last token was consumed, either by reaching an end event or completing an activity without outgoing control flow (BPMN allows this) or by being killed by an iterrupting border event like the 21-day-case here (which spawns a new token on the outgoing flow of the event). All process tokens are equal citizens in this respect. 

Finally there is the "Terminate end event". That is very much like pushing the reset button on your computer, killing all process tokens even in multi-instance activities, no matter where they are currently in the process.

Citing myself "or completing an activity without outgoing control flow" brings me to the idea that you can just omit the "Reminder sent" end event, if you feel you only want end events for a "successful" end of process.

Yes, you can do this (OMG spec says: "If there is a Start Event, then there MUST be at least one End Event" and the missing end event shall not have a result, i.e. is a NONE end event) but from my point of view this is not a good style. Btw: The BPMN validation in ARIS Connect shows this as an error.

Regard

Klemens

An inclusive merge gateway has also a synchronizing functionality, waiting until all active tokens have reached the gateway. So your statement "Used as a joining gateway it will pass on any token immediately on the outgoing path as it is reached." is not correct from my point of view.

Regards

Klemens 

Hi Charlie,

you are right, and I have to correct my statement in my post above, that "Start up analysis" is already initiated after sending the first reminder (btw. M. Zschuckelt made the same mistake from my point of view). The inclusive merging gateway has a synchronizing functionality as you described. 

Regards

Klemens

Hi Klemens, you are right. The Inclusive gateway synchronizes everything, that's under way. I was mistaken here. So, in Charlie's model the process would wait at the converging inclusive gateway from day 7 onwards until the receive task is killed at 21 days and then starts the analysis without input from the customer, because there is no more token to be expected at the gateway. Do I understand correctly?

Hi,

yes I fully agree. And because this is surely not the process to be depicted I proposed in an earlier post to use the terminate end event as "Analysis cancelled". My final recommendation would be to stay with your proposal in your post  Mon, 10/16/2023. This model is much easier to understand and a good style seeing the "happy path" directly. Modells with merging inclusive gateway are always a little bit tricky (and we both also misinterpreted it initially!)

Regards

Klemens

Hi, good points. The terminate end event would do the trick, however I don't like it very much, because it really is a killer and potentially leaves a mess at the point where a process token was killed.

Regards, M. Zschuckelt

I think, the default BPMN validation has inherited some ways of thinking from the EPC checks. It's up to you to customize your Semantic Check profiles with rules you want to enforce and deselect those you do not want to adhere to.