Cancelling a workflow by autotask

[Peter Clough]

We have a pair of autotasks tied to buttons that relog an incident into a service request and vice versa. From an analyst perspective, this works fine, and generates the new request and emails and links correctly, while setting the status to Cancelled.

In several workflows though, when the job is marked as cancelled, the workflow gets stuck in one of a variety of places and simply lists as failed when checking executed workflows. Is there a mechanism in an autotask to actually cancel a job, instead of just modifying the status, or would we need to find another way to stop these workflows?

[Berto2002]

@Peter Clough

We have a similar flow and we use just the "Cancelled" status. Cancelling a Request does not cancel the BPM. This is annoying. They stay in Suspended state.

I thought I had a way of finding these and performing some housekeeping but I was using BPM instances (com.hornbill.servicemanager)->Current State values of '4' which I thought was Suspended.

Just went down the rabbit-hole on this one checking-up on where we are with it and found most of them are in Oh boy, just went down the rabbit-hole and found most of them are BPM instances (com.hornbill.servicemanager)->Current State values of '3'. So I've realised I now have 'billions' of orphaned suspended BPM against cancelled Requests...

So I'm trying to work out what the difference is between state of '3' and '4' on BPM instances (com.hornbill.servicemanager)->Current State... Any ideas? Both show as "suspended" in the manage executed process...

I think there is a case for one or two seriously useful enhancement requests here

1. A housekeeping option in the UI to enable 'automatic' purge or cancellation of BPM/workflow after an elapsed time if the Request is in a certain status (closed/cancelled)
2. A workflow/BPM node option to enable cancellation of the BPM instance alongside 'cancellation' of the Request itself. This could be the addition of a "BPM_ID" outcome to the "Get Request Details" node and then a new 'Task' in the Updte Request settings to enable setting the status of the BPM_ID to the required value

@Gareth Cantrell do you have a solution to this? I was thinking to use the Clean Utility (link from here Managing Instance Storage Usage - Hornbill) but that's about removing Requests not just the BPMs.

[Berto2002]

@Peter Clough In the above I got worried by the BPM_current_state question which has now been separately answered. My statement above that the BPM does not get cancelled was incorrect and caused by the fact I use another Autotask to launch the BPM for a Request and that always shows under the 'path' of Suspended as per 

My test shows that if I use the above workflow to swap an IN to a SR, the old Request gets placed into a Cancelled status AND the BPM instances (com.hornbill.servicemanager)->Current State for it goes to 3 which is Cancelled. So it's all good and I have no suspended BPM for closed or cancelled Requests.

It never goes to Failed so what Autotask configuration are you using to cancel?

I note that, when you open the BPM linked, you see the BPM and it looks to be waiting on a node somewhere (highlighted in green) but it is Cancelled.

I have this report which I use to check if we have old requests which are cancelled or closed with a status of suspended BPM and I clear these (and try to fix causes) approx quarterly.

 

admins---list-of-all-requests-in-statusclosedcancelled-but-with-suspended-workflow.report.txt

[Gareth Cantrell]

1 hour ago, Berto2002 said:

 

@Gareth Cantrell do you have a solution to this? I was thinking to use the Clean Utility (link from here Managing Instance Storage Usage - Hornbill) but that's about removing Requests not just the BPMs.

 

@Berto2002 right now I have a slightly manual process to handle this:

I have a saved query that lists all orphaned BPM instances; I then download the results into a CSV file and then have a Python script that loads the CSV and calls the bpm:processDelete API for each instance.

The query I use is: 

SELECT bpm.h_id, bpm.h_reference 
FROM h_bpm_instance bpm
WHERE NOT EXISTS (
    SELECT req.h_bpm_id
    FROM h_itsm_requests req
    WHERE bpm.h_id = req.h_bpm_id
)
AND bpm.h_id LIKE 'BPM%'

... however, you have got me thinking about how I could use the HTTP cloud automation node to do this automatically ...

[Berto2002]

I got one result with that. I guess that's quote good.

I think that's a slightly different issue.

I was focusing on BPM that are still linked to Request but where there's a non-completed or non-cancelled BPM linked to a closed or cancelled Request.

[Peter Clough]

Thanks for confirming that I at the least haven't missed a node or setting somewhere, @Berto2002.

The specific workflows that get stuck tend to do so when marking the response timer.

The workflow suspends waiting for category, the autotask puts a category on it during it's process, and the workflow then moves through, but when it gets to marking response, it fails because the job is already cancelled and the timers have been stopped.

That in and of itself is a question of us potentially redesigning some workflows. But it's what got me looking, as it seems silly to have to design workflows with needing an out to cancel at multiple places throughout, just in case.