Error relating to service level agreements

[Dan Munns]

Hi all,

I have made a few changes to our organisation structure and have been through and made sure all the team refs are pointing at the newly created and correct teams.

I have not run any of our BPMs since the introduction of the Corporate Service Level Agreements but I am now getting errors when the timer is started. The error is as below:

Line	Timestamp	Severity	Group	TID	Description
31448	20/01/2017 11:13	error	scripts	14932	nodeName: Invoke Flowcode: smSLMGetServiceLevelAgreement; nodeId: d80806a7-b7bb-4399-9c1d-8aea35df601d; "EspMethodCall:invoke: Operation[apps\/com.hornbill.servicemanager\/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager\/entities\/Requests\/fc_ops\/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId"
31447	20/01/2017 11:13	error	comms	14932	Operation[apps/com.hornbill.servicemanager/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId
31446	20/01/2017 11:13	error	comms	14932	Operation[apps/com.hornbill.servicemanager/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId
31075	20/01/2017 11:13	error	scripts	14932	nodeName: Invoke Flowcode: smSLMGetServiceLevelAgreement; nodeId: d80806a7-b7bb-4399-9c1d-8aea35df601d; "EspMethodCall:invoke: Operation[apps\/com.hornbill.servicemanager\/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager\/entities\/Requests\/fc_ops\/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId"
31074	20/01/2017 11:13	error	comms	14932	Operation[apps/com.hornbill.servicemanager/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId
31073	20/01/2017 11:13	error	comms	14932	Operation[apps/com.hornbill.servicemanager/Requests:smSLMGetServiceLevelAgreement] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/smSLMGetServiceLevelAgreement): FlowCode failed to return required output parameter: serviceLevelAgreementId
30897	20/01/2017 11:13	error	scripts	14932	nodeName: API Call: Resume BPM Process; nodeId: 39535400-73fd-4464-80d7-bec0dc811f07; "EspMethodCall:invoke: Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy"
30896	20/01/2017 11:13	error	comms	14932	Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy
30895	20/01/2017 11:13	error	comms	14932	Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy
30894	20/01/2017 11:13	error	perf	14932	bpm:processResume() Operation Invocation results: failure (199958528 B, 13 ms, 0 kB, 1 ms, 0 kB)
30421	20/01/2017 11:13	error	scripts	14932	nodeName: Resume BPM Process; nodeId: f107f874-7ca7-46c2-b9dd-e564153cdb71; "EspMethodCall:invoke: Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy"
30420	20/01/2017 11:13	error	comms	14932	Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy
30419	20/01/2017 11:13	error	comms	14932	Operation[bpm:processResume] The specified bpmProcess cannot be resumed: The process is currently busy
30418	20/01/2017 11:13	error	perf	14932	bpm:processResume() Operation Invocation results: failure (195932160 B, 10 ms, -28 kB, 0 ms, 0 kb

[David Hall]

Hi @Dan Munns

Thanks for post.  I've found the cause of the error, I've raised a problem reference and I'll look to get a fix for it into a forthcoming release.

In summary, this error only occurs when you do not have a valid service level agreement configured against the service being used in your request at the point at which your business process attempts to start the service level timers.  

I'm not sure if you have configured SLAs for your services yet (Service Details Form -> SLA tab), but the error will occur if:

a. You have no SLAs configured

b. You have more than one SLA configured but you have no valid rules which would result in none of the SLAs being used.

If you do not yet use SLAs then the error will occur but will not have any operational impact, or if you are using SLAs then you will just need to check that you have either:

- a single SLA

or

- a valid SLA rule configured to choose one of your multiple SLAs.

Hope that helps, let me know if you have any further questions.

Regards,

Dave.

[Dan Munns]

Hi @David Hall,

So we have Service Levels configured and they have worked since I started work on Service Manager.

I have not configured any of the Corporate Service Level Agreements so would expect that as stated in the Wiki:

"Existing customers (those who have subscribed prior to December 2016) may well have already configured a number of Service Levels within Hornbill before this functionality was introduced. Rest assured, as with any new feature thats introduced to Hornbill, any existing set up will be retained and you can continue working without having to make any changes to your configuration."

At the moment it stops the BPM and once I force it to the next step (assign to analyst) it properly crashes (with red error box) and is unrecoverable.

So now I am going to have to create and configure Corporate Service Level Agreements for all our services?

 

[David Hall]

Hi @Dan Munns

Sorry if I've caused any confusion with my previous response.

If you previously had "Service Levels" configured and (as you have stated) not configured the new Corporate Service Level Agreements or Service Level Agreements against a service then the original service levels should continue to work as before (as detailed in the wiki note), you should not have seen any change in the application of service levels to your requests.  If this is not the case (e.g. you are no longer getting service level timers on your requests) then please let me know and we can investigate further.

In order to maintain use of both the original service levels and the new SLAs we altered the order of checks so it will initially try to see if the new SLAs are configured for use and if not then fall back to the original service levels if present, so even if using the original service levels, you may still see this error in the log.

 

[Victor]

@Dan Munns the red box/error appearing on the requests could be something different (i.e. caused by a different issue). As @David Hall mentioned, the log entries you posted should not affect the BP functionality, meaning teh BPs should work fine...

Do you have some recent examples of requests where this error occured? If yes, would it be possible to send me a reference and a date/time when the request was raised and also when the error occurred?

[Dan Munns]

Hi @Victor

 

Ref: SR00000133. Logged 13:22.

I get the SLA error. I also get an error saying that the task cannot be created as the analyst doesn't exist when he does.

I have no idea what is going on with this today

Thanks

 

Dan

[Victor]

@Dan Munns sorry to be a pain, do you have a screenshot of the SLA error in the browser by any chance? ... The analyst one I can probably see what is going in the logs, I was curious about the SLA one, because, as mentioned previously, it should only be a recorded in the logs, not displayed to the user...

[Dan Munns]

Hi @Victor

Not a pain at all.

Thanks

Dan

[Victor]

@Dan Munns just a quick note, I have not forgot about this, still looking into... will send you an update as soon as possible..

[Victor]

@Dan Munns apologies for the delayed reply. I had a thorough look on the events recorded when SR00000133 was logged. So, it seems the SLA timer does not start because the SLA is not associated to the service... at least this is what I understand from the event logs. I can see you are using SLM functionality.

So, how did you set up the SLAs in your instance? Are they corporate SLAs or service SLAs? If they are corporate, did you associate/linked them to the service?

[Dan Munns]

Hi @Victor,

To be fair I kept getting the errors no matter what I did so Wednesday evening / yesterday morning I changed all the BPMs to use the corporate SLAs and I haven't had the issue since.

They were set up using the old service SLAs so there was no SLA to attach to a service.

As far as this goes now the BPM breaking error is no more.

I was hoping to find out what the error saying that the task cannot be created as the analyst doesn't exist when he does was about as that happened in total about 5 times and I just wondered if it was a bug or something I had changed

Thanks

[Victor]

@Dan Munns ah, I see... what I think it happened then is that your instance had/has guest.app.view.ITSM.serviceDesk.enableSLM setting enabled. In this case, using "old" service levels won't work, you will have to use SLAs...

Is the task error on the same request reference? Or you getting it in all requests/tasks you try and create?

[Dan Munns]

Hi @Victor,

It was on the same reference.

(Attached is for the earlier screenshot above)

 

[Victor]

@Dan Munns can you post a screenshot with the task node configuration?

[Dan Munns]

@Victor

Sure

 

[Victor]

@Dan Munns hmm.. I was hoping to see something there but all looks configured correctly... unless there is something else going on...

Is the error occuring everytime BP tries to create a task for James as owner? Does James, as user has the ID as 'James Handscombe'?

Trying to establish if by any chance taskCreate used the display name to retrieve the user record instead of the ID...