Hi all,
I admit that I’m very new to BPM Modelling. I tried to model a cancellation after a timeout. Here is the model:
If the timeout event happens, the process instance is ending in the end state “Timeout”. However, the pool “Interim Processing” keeps on running. When it tries to send the message “Processed”, I catch an exception. But I wanted it to just stop and do nothing more. What do I have to do to achieve that?
Many thanks in advance!
Regards
Christian
Hi Christian,
The way you have modeled your process is you end up with two distinct process instances. Is there a reason for this? If you model it as one cohesive process then your timer can be interrupting…
If you must model it as two distinct process models, then you could use an interrupting event driven subprocess in your interim processing model. Thus if your entry point times out, send a message to interim procesing to trigger the interrupting subprocess.
regards
Rob
Hi Rob,
thank you for your help attempt. I am very sorry, but I’m too new to modelling. Can you post a draft image of what you wanted to explain to me? That would be very great!
Thanks in advance
Christian
Hi Christian,
No problem - here is what I mean by a single cohesive process. I put an interrupting boundary timer on an inline subprocess…
Let me know if you want an example of an alternate approach using two distinct processes…
regards
Rob
Hi Rob,
thank you for your help. When I tried to adopt your hint to my use case, it first did not work. But then I found a reason: Service Tasks can not be interrupted by timer boundary events, at least not so easy. See here: Timer boundary event on service tasks - #6 by hassang .
My idea is now to try this approach:
The intermediate message receive event must be triggered in the service task when it has finished. I think this is worth a shot.
Regards
Christian
Hi Christian,
Yes you are right in terms of interrupting service tasks…Service tasks are usually short lived eg ‘turn on the light’. If the service task is dig a deep hole, ie a long duration, then you may want to consider an asynchronous approach (like you have), eg a service task to initiate digging and a receive event to notify me when the hole is complete…
When it comes to timeouts and interruptions, you cant avoid a race condition. What you need to focus on is the consistency implications…Consider the light switch example, its rare that it would be interrupted and if it, its probably because of a failure. Now consider the digging a hole, its long lived and could take longer or shorter depending on how hard the ground is… If the timer does expire, what do you want to do? Stop digging, abandon the hole or fill in what has already been dug? I suggest this is where you need to focus on what outcome do you want when the timer expires, then we may be able to suggest appropriate modelling patterns…
regards
Rob
