Deleting BPM Live process instances

[DFarran]

Good Morning,

Just a quick question regarding failed BPM instances, we have quite a few from when we initially went live back in August where some of our BPMs weren't quite setup correctly. I'm trying to go through and tidy these up but a lot of them I can't restart/resume as it says the instance cant be found, I assume its because its been a number of months since they initially failed. Is it ok to just delete the instances within Applications -> Hornbill Service Manager -> Business Processes -> Executed Processes? I assume this wont delete the actual request? I don't want to delete the requests just clear the failed BPMs that cant be restarted.

 

Thanks,

 

Daniel.

[James Ainsworth]

Hi Daniel,

At the moment if you delete a BPM instance the associated request will not be able to load.  The actual request will still be there.  If you are getting an error on a request saying that the request can't find the Business Process Instance this will be because the BPM instance has already been deleted.  We should be able to add check to ensure the request still loads when the BPM instance can't be found.

Provided that the BPM instance is not listed as version 0  you should be able to modify these to get them working again.  If you have other BPMs that are broken, I may be able to help with some suggestions on how to change to get them going again.

Regards,

James

[James Ainsworth]

We have added a check for when a request loads and the BPM Instance has been deleted, it will allow the request to display without error, and a message at the top of the request that makes the user aware that the workflow is no longer available.  

This should be available in one of the next couple of Service Manager updates.

Regards,

James

[DFarran]

Hi @James Ainsworth

Thanks for the advice, none of them say version 0. As the majority are from August I just wanted to clear the failures as the request itself would have been dealt with and I didn't really want it sending out emails for these old requests to customers which could cause confusion. What would you recommend should I wait for the update and then delete the failed instances?

 

Thanks,

 

Daniel.

[James Ainsworth]

The only problem with deleting the failed instances is this will completely remove the Process Tracker at the top of the request.  You will not be able to see what has been done or how far in the workflow you managed to get to.

One option for you is to look at is cancelling a process.  At the moment you can't cancel a failed process, so the option would be to make sure that there is a suspend node soon after the failed node, and before any emails go out.  If that is the case, you can fix the process and then cancel the process so that it doesn't proceed any further.

 

A cancelled process would look similar to this in the Process Tracker

I will also see if I can find out the reasons behind failed requests not having the option to be cancelled.

Let us know if this helps.

Regards,

James

[DFarran]

Hi @James Ainsworth

Thanks for the advice, which suspend would you recommend? I tried adding a suspend wait for request update on one of the failed processes but when I saved and restarted it the process didn't actually suspend but went past that stage and did end up sending an email. I was however able to cancel the process afterwards as it did end up on a suspend node further in the process.

 

Regards,

 

Daniel.  

[James Ainsworth]

Hi Daniel,

Sorry I didn't come back to your earlier question above.  The ability to cancel a failed workflow is now available.  Hopefully this will give you the option that you are looking for without having to do any additional configuration.

Regards,

James

 

[Estie]

Hello, 

I know this is an old post, however we are in a similar position which has just come to light, where we have a large number of old suspended workflows.  There are various reasons for them.  From looking at some of the requests associated to the workflows I can see that they have been closed despite the workflow being suspended.

I am wondering if I cancel the old suspended workflows will this affect reporting stats? ie where a report looks at the number of closed requests/Incidents?  Will the closed requests/Incidents showing suspended workflows still be counted in these reports?

Also is there an easy way to export the list of suspended workflows?

Thanks

[James Ainsworth]

1 hour ago, Stefania Tarantino said:

I am wondering if I cancel the old suspended workflows will this affect reporting stats? ie where a report looks at the number of closed requests/Incidents?  Will the closed requests/Incidents showing suspended workflows still be counted in these reports?

This could depend on what else is left for the workflow to do and if these things are reported on.  For example, you may be setting closer categories toward the end of the request, and if the workflow misses that out, it won't be set and would be missed out on a report that uses this.

1 hour ago, Stefania Tarantino said:

From looking at some of the requests associated to the workflows I can see that they have been closed despite the workflow being suspended.

As long as the Resolve/Close tab/action on a request is available to users, they can close a request before the workflow has finished.  There are nodes you can add to your workflow for locking these tabs/actions until the request has reached a certain point, so that they don't get closed before they should.

 

[Estie]

Thank you @James Ainsworth these are very good points which is very helpful. I will look at locking the actions.  It seems I have a big job ahead of me going through hundreds of suspended requests! 

[Estie]

Forgot about the exporting of the list of suspended workflows - is this possible?

[James Ainsworth]

I'm working on that  

You can't export directly from the list, but you can do this by creating a report.  I'm seeing if I can quickly throw something together for you.

[James Ainsworth]

Hi @Stefania Tarantino

Here is a report that lists all the requests that are Closed but have a suspended workflow.

To upload this report 

1. In Hornbill, Open Configuration using the cog icon in the bottom left menu bar
2. Select Platform Configuration
3. In the Navigator, scroll down to the Reporting section and select Reports
4. Click on New Report
5. Click on the green upload button to Upload a report definition file
6. Select Yes to overwrite the existing definition
7. Save the report
8. Run the report.

Let us know if this helps.

 

closed-requests-with-suspended-bpms.report.txt

[Estie]

Thank you so much @James Ainsworthyou are a star!  

I will have a go at doing this tomorrow and let you know. 

[Estie]

Hi James,

The report you gave me is showing no closed requests with workflow suspended which is good news.

I have amended the filter to show resolved requests with workflow suspended which works well.

However I don't seem to be able to just see a list of all suspended workflows.

I have tried:

- the same workflow current status filter (=4) and removed the filter for the status of the request - no results

- the workflow current status filter (=4) and added filter for request status = all statuses ie status.open etc - no results.

- removed all the filters - get a preview of what I think is all workflows, with all workflow current statuses - however both csv/xlsx downloads are appearing blank.

As soon as I try to re-add the original filtering or any ordering/grouping to the report the preview shows no data.

 

Are you able to advise how I would get a list of all suspended BPMs?

Many thanks

[James Ainsworth]

Hi @Stefania Tarantino

On the same report, I simply deleted the filter option for the status, and this is now showing me all requests with a suspended workflow.   You may want to try importing the report I sent again into a new report, and just delete the filter for the request status, just in case something else was mistakenly changed.  

[Victor]

On 11/10/2022 at 5:51 PM, Stefania Tarantino said:

exporting of the list of suspended workflows

@Stefania Tarantino may I ask why you need to have an exported list of these? The report provided by @James Ainsworth is quite all right however, I see it does query BP instances table which is a table that is not quite designed for reporting... in addition this is one of the most heavily used tables in HB so some care should be taken when used outside it's purpose...

[Estie]

Hi Victor,

Unfortunately we have 89 pages of suspended workflows - that is over 1000.  I need to analyse them to find out the reason they are suspended and see the types of requests and BPMs that may be causing them to be suspended.  I am finding it very difficult to filter and sort the list in the suspended workflow screens.  Everytime I sort by a column - if I move to another page and back again the sorting is removed.  I am also only seeing 22 workflows per page.  I need to be able to see all the workflows in one place and filter them and possibly add to other spreadsheets to cross reference data such as resolved by date/resolved by user etc. which is much easier in an Excel spreadsheet or csv.

I am happy for any other suggestions.

[Steve Giller]

@Stefania Tarantino "Suspended" is a valid state for a Workflow. Waiting for an Update, an Owner, an Impact Assessment, Customer Feedback (there are dozens of these) will all have the Workflow in a Suspended state ... for example:

It appears from the above post that you've formed the impression that a suspended workflow is in some kind of error state - this is not the case, so canceling these could severely impact the Requests they are attached to.
Even if you have Closed requests with a suspended workflow this does not necessarily indicate an error, for example they may be awaiting feedback.

[Estie]

@Steve Giller 

I am fully aware that many of our tickets will be in a suspended state for any of the above reasons.

However we have a substantial number that are from when we started using Hornbill back in July 2021.  Some of those tickets are still open in our system.  Some of them are resolved or closed.

I have already identified one improvement we can make to workflows to stop this happening.  However without analysing these I cannot tell what other improvements, if any, need to be made.

What is the consequence of me just leaving these as suspended workflows?  

Presumably they will never be unsuspended if there are errors in the workflow? - eg waiting on an owner when the ticket was resolved without an owner ever being added.

How will I know if there is a genuine reason for the suspended workflow or if these are being caused by an error in a workflow if I don't analyse some of these suspended workflows?

 

[Estie]

@James Ainsworth @Victor

James - I have tried uploading your report definition file again into a new report and just removed the filter for the request status, but the report is still not showing me any results.

I am still unsure on the best way to analyse and deal with the large number of old suspended workflows I have come across.

Any further help or advice on this issue is appreciated.

[Steve Giller]

@Stefania Tarantino I uploaded James's report onto my Instance, and removed the filter on Request Status to show:

and this returned all of my suspended Workflows.

It's possible that the query is timing out (as Victor mentioned, it is a table which is not quite designed for reporting) so you might need to reduce the size of the results.
As the Closed filter does return a recordset, maybe filtering on each status in turn rather than trying to dump the whole set?

[Estie]

@Steve Giller

I did exactly the same and doesn't seem to work. 

However I have now tried your suggestion of filtering on each request status in turn which is producing results - thanks for that.

I am still not getting any results for suspended workflows where request status is closed.  I initially thought that was OK but have come across some. 

The reports will make it easier to analyse the suspended workflows.

The ability to export the list of suspended/failed/cancelled workflows might be useful to others in the same circumstances - I wonder if this is something you would consider as an enhancement? 

Thanks again @James Ainsworth @Victor