Return to original location after escalation

Camunda 7 Topics Discussion & Questions
1

I am looking to model a workflow that needs something in-between an interrupting and a non-interrupting event. I wish to be able to initiate an event sub-process (or maybe a completely new process) and require that this sub-process be completed before returning to the original process. This escalation event could occur at any point in the workflow.

If I initiate the sub-process with an interrupting event, the existing tasks end and are ‘forgotten’. I don’t have an easy way to go back to where I was at when the interruption occurred. If I initiate the sub-process with a non-interrupting event, then the existing tasks will continue to be processed, and I want them to be on ‘hold’ until the sub-process completes.

The Tasks I wish to ‘hold’ are User Tasks, presented to the users by a queueing mechanism. Would placing these Tasks in a Pending status, or inactivating the entire process be a viable option?

I’ve attached a simplified version of a workflow to illustrate the problem.
priority_task.bpmn (5.4 KB)

2

Hi Bill,

If I think about a user task, I tend to think it has states;

Created->Claimed->Working On It-> Completed.

So when your main process gets interrupted, how do you need to treat these states? If you do use an interrupting mechanism, user tasks in the first two states can just disappear. In the working on it state, the user experience may be sub-optimal as when they complete the task, an error will be thrown. The last state is the tricky one. Do you need to back out any business object changes associated with the completed task etc… If thats the requirement, then consider a compensation task associated with these interruptable user tasks…

I would probably use an interrupting approach. So how do you know where to return to? Id design my process with scopes defining checkpoints. Within each scope Id use an interrupting event sub-process. If interrupted, Id set a flag so that when the scope completes, if its been interrupted, the process can loop back around and recreate the entire scope…

regards

Rob

1 Like
3

I created this example project a little while ago which can help solve some of what you’re looking for. Might be a good starting point.

I discussed the problem it solves in detail on this thread.
Hope that helps.

1 Like
4

Thanks, that looks like what I need. One part I am not completely clear on - when the interrupting sub-process starts, it is not inevitable that the parent process will complete? You have an opportunity, through Process Modification, to set the token back to a given location in the workflow, which is what your ReturnToFlowAfterError class does?

5

In the example the process will always continue, but you can decided to do whatever you like after you catch the error.

6