Dan Munns Posted January 20, 2017 Share Posted January 20, 2017 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 Link to comment Share on other sites More sharing options...
David Hall Posted January 20, 2017 Share Posted January 20, 2017 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. Link to comment Share on other sites More sharing options...
Dan Munns Posted January 20, 2017 Author Share Posted January 20, 2017 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? Link to comment Share on other sites More sharing options...
David Hall Posted January 20, 2017 Share Posted January 20, 2017 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. Link to comment Share on other sites More sharing options...
Victor Posted January 20, 2017 Share Posted January 20, 2017 @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? 1 Link to comment Share on other sites More sharing options...
Dan Munns Posted January 20, 2017 Author Share Posted January 20, 2017 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 Link to comment Share on other sites More sharing options...
Victor Posted January 20, 2017 Share Posted January 20, 2017 @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... Link to comment Share on other sites More sharing options...
Dan Munns Posted January 20, 2017 Author Share Posted January 20, 2017 Hi @Victor Not a pain at all. Thanks Dan Link to comment Share on other sites More sharing options...
Victor Posted January 23, 2017 Share Posted January 23, 2017 @Dan Munns just a quick note, I have not forgot about this, still looking into... will send you an update as soon as possible.. Link to comment Share on other sites More sharing options...
Victor Posted January 26, 2017 Share Posted January 26, 2017 @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? Link to comment Share on other sites More sharing options...
Dan Munns Posted January 27, 2017 Author Share Posted January 27, 2017 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 Link to comment Share on other sites More sharing options...
Victor Posted January 27, 2017 Share Posted January 27, 2017 @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? Link to comment Share on other sites More sharing options...
Dan Munns Posted January 27, 2017 Author Share Posted January 27, 2017 Hi @Victor, It was on the same reference. (Attached is for the earlier screenshot above) Link to comment Share on other sites More sharing options...
Victor Posted January 27, 2017 Share Posted January 27, 2017 @Dan Munns can you post a screenshot with the task node configuration? Link to comment Share on other sites More sharing options...
Dan Munns Posted January 27, 2017 Author Share Posted January 27, 2017 @Victor Sure Link to comment Share on other sites More sharing options...
Victor Posted January 27, 2017 Share Posted January 27, 2017 @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... Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now