Cancelled tasks in a request

[Mette Petersen]

Hi! 

We are coming across cancelled tasks in certain tickets and I do not know what is causing these tasks to be cancelled.

 

As far as I see, there are only 2 things that can happen to a task (for a normal user): 1) action it or 2) it expires (in some cases). What triggers a cancellation? This blocks the BPM and we have don't know how to restart the BPM. The process does not show as failed in the Executed Process.

 

When we click into the cancelled task, we see a message about "approval decision has already been taken...". 

 

Thanks!
Mette

 

 

[Victor]

30 minutes ago, Mette Petersen said:

What triggers a cancellation?

• When canceling a request will trigger canceling associated workflow which in turn will cancel BP tasks
• When having multiple authorisation tasks (assigned to various users/groups), when they are actioned and the autorisation weight is reached, any remaining pending authorisation tasks will be canceled

[Mette Petersen]

@Victor Hi Victor, 

 

OK so I understand that the cancellations are linked to authorisation nodes? There aren't any authorisation tasks  in the process though, so not sure what it is that has triggered the cancellation. Also, there is nothing in the history of the ticket that refers to an authorisation. 

[Victor]

@Mette Petersen hmm... perhaps another scenario then, although I can’t think of any... or a defect? What’s the request reference?

[Mette Petersen]

@Victor SR00000486. There is also another error that I can't fix in this request so I have to create another ticket. Leaving 488 open until I understand the cancelled task issue. Thanks!

[Victor]

@Mette Petersen right, that task on SR*486 should not have been cancelled... ok... I need to investigate this in more detail, leave this with me for a bit

[Mette Petersen]

@Victor thanks! 

[Victor]

@Mette Petersen the error on SR00000486 can be fixed... anyway... so definitely those tasks should have not cancelled... any chance we have this issue occurring consistently on this workflow or another? I found another request SR00000388 (and there could be more) where another BP task was cancelled when it should have not... I can't figure out (yet) why and how this happened if we have a consistent way of replicating this it would be very helpful...

[Mette Petersen]

@Victor that was my first thought but there are some requests that have gone further through the process so I ruled out that it was the process. 488 and 500 had the same cancelled task (requests have been cancelled) but 489 did not have a cancelled task (request also now cancelled).

[Victor]

@Mette Petersen there is some circumstance that incorrectly triggers the cancellation... sometimes it does sometimes it doesn't... didn't work out exactly how yet...  

[Mette Petersen]

@Victor Good morning! I think I have understood what goes on! I have another request which has failed using a different process and there is a cancelled task. 

The cancelled task is a parallel task to where we have the error. The error is because we have a node with outcomes and expiry followed by a decision node. There is no goto for the expiry and therefore the process fails and I am assuming that the system then cancels the parallel process node.

Example is 733 in our instance.

Let me know if this makes sense to you.

 

[Mette Petersen]

@Victor on that note, it doesn't look like I can correct the failed processes. For any other requests that have used this process and have not reached that node yet, is there anyway I can correct the problem before it reaches the node or is it a case of telling people to not let that particular task expire??

Thanks again!

Mette

[Victor]

@Mette Petersen Godmorgen

I know about the expirations and that was one of the first things I tested when I looked into this. Despite my test scenarios, with various parallel tasks and expiration settings, I was unable to replicate the same issue. I'll have a look at 733 to see if there is something I messed during my tests.

 

[Mette Petersen]

@Robert Charlton

[James Ainsworth]

After some discussions, I believe I understand what is happening.  

Within a parallel process in a workflow, the tasks within that parallel segment are seen as being dependent on each other.  In order for the BPM to flow and end the parallel segment, all tasks must be completed as they are a related group of tasks.  

In the event of a BPM failure that occurs when the workflow is within a parallel segment, what is happening is that if one of the tasks failed due to misconfiguration, it will cancel the other active tasks that also sit within the parallel segment.  This is by design in order to prevent further task completion when one of the dependent tasks have failed.  If a task remained accessible to a user while the request's BPM was in a failed state, and these tasks continued to be completed, the tasks and BPM are placed entirely out of sync causing additional logic errors or possibly business operation issues if the tasks are not completed correctly.

While there is a great tool for fixing most aspects of a failed BPM, this scenario can't be modified.  The recommended action to take when you come across a request where this has occurred, is to identify the failed BPM task and what was the cause of the failure. Then update the BPM workflow to ensure that the settings and logic are in place so that it doesn't fail again with another request.  

I hope this helps,

Regards,

James