Jump to content

Error when putting Incidents on-hold


Neil Smith

Recommended Posts

@Shamaila.Yousaf @PeterL,

This has been applied to your instances.

For the Requests that were effected by this failure, a restart may automatically resume the Request's progress. Please refer to "How to restart a failed workflow" section in the Wiki document below for instructions:

https://wiki.hornbill.com/index.php/Business_Process_Designer

Ehsan

Link to comment
Share on other sites

@Neil Smith,

We've been closely monitoring performance related issues and a restriction was added to prevent an UPDATE statement from being routed to the database server if the values that are being updated hadn't changed. The operation that updates a Request's status through the Business Process, contained a process to reset Request's sub-status in the event that a Request's status has changed. The code didn't include logic to prevent resetting the Request's sub-status if the value hasn't changed.

This was not caught by the application's automated tests in this area, as the tests in place validated that a Request's status and sub-status are changed accordingly. We've now added an automated test to validate the scenario where the Request's status is changed through a Business Process without changing the sub-status. The restriction that was added by platform tests did not include a scenario where the primary key of the database table in question had a customised "autoVal". We've also added a platform test to now test this scenario.

Apologies for the inconvenience that this has caused. As we've added more tests around this scenario, we aim to eliminate the occurrence of this issue in the future and we hope that the restriction added will improve the traffic on the database server.

Ehsan

Link to comment
Share on other sites

@Ehsan Can you advise how long it will take for the patch to take affect or anything we need to do,  i have tested with a few tickets and can still see the error shown below when taking tickets off hold:

 

FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/smUpdateStatus): nodeName: API Call - systemSmUpdateStatus; nodeId: 15ccd0bd-6cc4-4151-94f1-95008f16b270; At 109/1: "Uncaught EspMethodCall::invoke: Operation[apps/com.hornbill.servicemanager/Requests::systemSmUpdateStatus] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/systemSmUpdateStatus): nodeName: API Call: Clear Request Sub-status; nodeId: 151caee3-58c2-4106-a5eb-769c7cf35cfb; At 140/1: "Uncaught EspMethodCall::invoke: Operation[data::updateRecord] There are no values to update" throw(e); _fc_node_exec_151caee3_58c2_4106_a5eb_769c7cf35cfb" throw(e); _fc_node_exec_15ccd0bd_6cc4_4151_94f1_95008f16b270

Link to comment
Share on other sites

1 minute ago, PeterL said:

@Ehsan Can you advise how long it will take for the patch to take affect or anything we need to do,  i have tested with a few tickets and can still see the error shown below when taking tickets off hold:

 

FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/smUpdateStatus): nodeName: API Call - systemSmUpdateStatus; nodeId: 15ccd0bd-6cc4-4151-94f1-95008f16b270; At 109/1: "Uncaught EspMethodCall::invoke: Operation[apps/com.hornbill.servicemanager/Requests::systemSmUpdateStatus] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/systemSmUpdateStatus): nodeName: API Call: Clear Request Sub-status; nodeId: 151caee3-58c2-4106-a5eb-769c7cf35cfb; At 140/1: "Uncaught EspMethodCall::invoke: Operation[data::updateRecord] There are no values to update" throw(e); _fc_node_exec_151caee3_58c2_4106_a5eb_769c7cf35cfb" throw(e); _fc_node_exec_15ccd0bd_6cc4_4151_94f1_95008f16b270

Glad it's not just us affected following the statement that ALL instances have been patched.

Link to comment
Share on other sites

9 minutes ago, Ehsan said:

@Steven Cotterell, @PeterL,

Did you restart the Request's process for the affected Requests or are these new Requests? The patch has definitely taken affect.

Hi @Ehsan,

We've experienced it today during testing of Service Requests (only seen it so far for this request type) when the team complete a task whilst the request is on-hold - the outcome, when chosen, proceeds to set the status to 'Open' and we got this error

"Xmlmc method invocation failed for BPM invocation node 'stage-45048add/flowcode-00d3b0dc': 0200 apps updateReqStatus FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_bpm/updateReqStatus): nodeName: API Call: Clear Request Sub-status; nodeId: f3c2399f-f23a-4177-970c-0b74017039c9; At 184/1: "Uncaught EspMethodCall::invoke: Operation[data::updateRecord] There are no values to update" throw(e); _fc_node_exec_f3c2399f_f23a_4177_970c_0b74017039c9"

  • Like 1
Link to comment
Share on other sites

@PeterL @Steven Cotterell Please could you send me an API key via a forum message - please do not post this on the forum. If you haven't already done so this document will guide you through the key generation process:
https://wiki.hornbill.com/index.php/API_keys
If you are setting an expiry date please ensure that this is set to at least 24 hours from the time you create it, otherwise it is likely that the system will view it as expired.
Note: For this issue it is essential that the API key is generated against the System Administrator account.

Link to comment
Share on other sites

21 hours ago, Steve Giller said:

@Adam@Greggs Is this when putting Requests on hold, or taking them off hold?

Also, if this request was logged before the patch went out, you will need to restart the workflow (https://wiki.hornbill.com/index.php/Business_Process_Designer) to clear the error.

Thanks for your response.

It's happened in a request that was processed by a routing rule this morning at 10.20am. Not all requests are doing this and the total I've been made aware of are sub 10 so not a massive issue. I'll check by getting the same colleague to send an almost identical request to see that it processes as expected.

Link to comment
Share on other sites

  • 2 weeks later...
Guest Paul Alexander

@Ehsan

We're still getting this error even on requests logged yesterday....(i.e. call SR00175935)

Can you please check that our instance has been patched? 

thanks

Link to comment
Share on other sites

Guest Paul Alexander

Hi @Ehsan

Yes we do have that build...you updated us on 15th Jan. However the request in question was only logged yesterday so I would have thought that it wouldn't have this error still? I CAN press the restart button, but I'm wondering why it's happened again on a request which was logged yesterday?

thanks.....

Link to comment
Share on other sites

@Paul Alexander,

I believe the issue that you're experiencing with is not related to this issue, which was addressed well over 2 weeks. I've spoken to Customer Success and there's an existing support request open with them regarding "Requests not coming off-hold", which is currently being looked into.

Ehsan

Link to comment
Share on other sites

Guest Paul Alexander

@Ehsan

OK...thank you. BUT...this error has popped up when trying to put a request ON hold, so I assumed it was a different problem? I've restarted the BPM now and it's gone through....

 

 

Link to comment
Share on other sites

Guest Paul Alexander

Hi again @Ehsan

Sorry, but I've just had another call which has failed when being put on hold (SR00176065 )

Has this patch DEFINITELY been added to our instance please? 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...