Requests not being cancelled

[Dan Munns]

Hi all,

I have an issue with calls suddenly (this used to work) not being cancelled by the BPM.

My BPMs are all set basically the same at the start and part of the BPM is to check the user account of the customer and see if they are authorised to raise requests. This is done by us adding 'Authoriser' into custom field 1 on each account.

The decision node works (slowly) and my test user received the 'Your call has been rejected' email, however the call is still set to 'New' status when the BPM should have marked it as 'Not Authorised' closure category and cancelled the call.

I cant see why the BPM is stalling and there is not log that I can see which would explain it.

As I said this used to work and I have made no changes to this area of the BPM (I have added the human task to check to see if it is *really* an emergency request or if the customer is just trying to pull a fast one)

Any ideas?

 

new-starter.bpm.txt

[Steven Boardman]

Hi @Dan Munns

Can i just confirm that the Email Customer Rejected email is sent?

If so we know it is branching correctly.  

I have tested the closure category, and cancellation operations and they seem to work as expected

One thing this maybe given you are testing - and i am going to assume you are logging the requests through the user app, and then opening the request details after progressive capture, is if you have async option enabled?

If that is the case, it maybe that you are opening and viewing the request before the BPM has had a chance to carry out the operations i.e Get info, update summary, assign, evaluate user, send email notification, update closure code, change status. 

A couple of ways to test this, as it appears the email is firing is to F5 the request details to see if that then shows the correct Cancelled Status, or if you are logging a new one, get to the last PC form, hit Finish, and then wait say 15 seconds before clicking View to open the request details

Would it be possible to try this and let us know either way?

Steve

 

 

 

[Dan Munns]

Hi @Steven Boardman

I have tried both refreshing and waiting (upwards of 5 minutes) and even though the email is sent (sometimes taking a couple of minutes, as long as 9 minutes though) the call is still shown as open and the BPM appears to have stalled.

This was all working and I only tested the call to make sure the procap showed the correct info after a change.

I have tested with and without the setting you mentioned enabled and there is no change in the behavior, the call still fails to cancel.

The only error I can find around the same time (although it is 4 minutes after) I log the ticket is:

97

14/03/2017 21:51

error

process

15592

Corresponding folder for /apps/com.hornbill.servicemanager/flowcode/fc_bpm_evt/fcindex.xml not found: The system cannot find the path specified

I can see the email is set correctly via the log at the time I create the ticket (less than 1 minute difference) I can also see success messages for update closure category and for set request status closed but it just isn't having any effect on the actual ticket.

Thanks

Dan

[Guest Ehsan]

Hi @Dan Munns,

Could you please check if the following Application Setting (through the Administration Tool > Hornbill Service Manager > Settings) is enabled:

• app.requests.cancel.commentMandatory

If it is enabled, could you please disable it and then give your BPM another try?

Thanks,

Ehsan

[Dan Munns]

Hi @Ehsan

I have disabled the option you mentioned and the BPM now works correctly. However looking at the time line the system always automatically adds the cancellation description anyway as below;

"Reason supplied: The request has been cancelled by the business process engine"

 

Also with the option disabled I still have to input a description when manually cancelling a call so I see no change other then the BPM now works again.

 

Any ideas there?

[Guest Ehsan]

Hi @Dan Munns,

The cancellation reason (i.e. "The request has been cancelled by the business process engine") is the default text for this BPM task. We can however make this configurable (through Admin Tool > Service Manager > Translations), so that you can modify the default reason.

Regarding the 2nd point - that may well be a defect, if the Application Setting is not respected while cancelling a request manually.

We will need to investigate these and may potentially need to raise a defect for both points.

As a Platinum Success Customer (https://wiki.hornbill.com/index.php/Hornbill_Platinum_Success), you can raise a request through the Webform (https://www.hornbill.com/request/) to track the progress of our investigations and your progress with defined Service Levels. Could you please raise a request through the Webform to investigate both defects?

Thanks,

Ehsan

[Dan Munns]

Hi @Ehsan

My point regards the auto description was the fact that as the system inputs a description surely this would cover the 'description required for cancellation' and if the call is closed by the BPM it should still cancel correctly regardless of the setting?

I will raise a defect ticket as you suggested.

Thanks

Dan

[Guest Paul Alexander]

Hi @Dan Munns

Did you get your 'call not cancelling' request sorted out? 

We seem to have a similar problem where a BPM should cancel a call if  a Manual Task is not updated in 21 days. However, although the correct route is taken by the BPM, the call still stays in an Open state, even though I have an 'Update Request Status' node set to cancel the call. The node updates the timeline with the text I've added to the 'manual timeline update' field of this node, but the status does not change. 

thanks

Paul

[Victor]

@Paul Alexander 

1 hour ago, Paul Alexander said:

However, although the correct route is taken by the BPM, the call still stays in an Open state, even though I have an 'Update Request Status' node set to cancel the call. The node updates the timeline with the text I've added to the 'manual timeline update' field of this node, but the status does not change.

This looks like an issue that needs to be investigated by support. I would suggest raising a support request with us: https://www.hornbill.com/support/