Thanks for your input. It contains ideas that I can use but the model is solely for documenting a process for end users and I think it won’t be obvious to many how the processes come together. They are used to the concept of pools or something similar
I want to know whether my use of interruputing events to end process flows is valid. The model is oversimplified. Once I know I’m on the right track I intend to add more detail.
I’m using the Receive event update… and Receive registration application… as listening subprocesses as I don’t know how many registration requests and event updates we’ll receive. All I know is at the end of the registration period those activities will be terminated.
Rather than building it in BPMN as your first round, can you build it as a generic workflow digram.
Something to consider (i do this constantly): Unless the organization understands how to read and interpret BPMN, there is not much value in spending your time trying to force a BPMN diagram when a simple diagram will do just as well.
Thanks again. I understand your point but I’m also using this as a learning experience. I’m really looking for a critique of my model my use of the interrupting timer event as the sole means of continuing a process flow in particuar.
Provided that the “Receive event update and update event” and “Receive registration application and send reply” activities are Call Activities or Sub-processes that are looping infinity until the timer goes off it should work pretty much as you expect. So the answer to your question is yes, your process will continue after the timer event is fired.
But you should know It’s really bad practice to model it this way
I was seeing that this use case is likely better covered as a CMMN with multiple tasks and processes are part of the case plan. Sort of mentioned here Retrieve form key of message start event as a conversation of when could you use bpmn to model many aspect of case management until you reach that tipping point.
Thanks Niall. The Receive event update… and Receive registration application… are sub processes that receive messages (updates and applications respectively) and will process/loop for each message until the timer goes off. Why is it bad practice to model it this way. I’m not disagreeing, merely trying to understand and learn.
From a best practice point of view every activity should have a sequence flow going into it and a sequence flow leaving it - because we need to know what must happen before this activity is started as well as what happens when the task has successful finished.
In your model the activities you’ve created will ALWAYS be interrupted - there is no case where the task “finishes correctly” which would be considered bad practice instead you should probably have the timer functionality within the scope of the sub-process.
Hope that makes sense.
