Jump to content

Dan Munns

Hornbill Users
  • Posts

    1,703
  • Joined

  • Last visited

  • Days Won

    38

Posts posted by Dan Munns

  1. 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?

     

  2. 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

  3. Thanks for that @Martyn Houghton

    The "mail" attribute was there but I had missed a comma so I am guessing it wouldn't see it.

    Finally (I think) how do you get it to search some sub OUs in a given OU?

    Our AD is set out as such: 

         Business

              Site

                   Building

                        Wing

    Users with no site (remote workers for example) are in a sub OU in the Business OU. Hot deskers may be in a sub OU in the Building or Wing OUs. As the sub folders will change and others may be added I don't want to have to set up a config file for each folder and have a larger number of imports every night.

    I also don't want it to search the whole subtree as it will pull in all the test and service account OUs

    Any help appreciated

    Thanks

    Dan

        

     

  4. Hi all,

    So today marks my first time working with LDAP and I am having a little trouble.

    I have managed to get it to see the LDAP server and the credentials are correct and I am not getting any credentials error. However when I run the Hornbill app (from CMD as Admin as a dryrun) I get the following error after 'Finished message 2':

    [ERROR] Search Error: LDAP Result Code 201 "ErrorNetwork": Invalid packet format

    I have no idea what it means at all. I have tried leaving the ConnectionType as blank and changing it (and the port numbers) to SSL with no joy.

    All the Infrastructure guys are away this week so I am sort of running around in the dark with this as the moment.

    Any help appreciated.

    Thanks

    Dan

     

  5. Hi @Victor

    I changed this post as it had saved text from a previous post I had typed and not posted after opening my eyes and having my morning coffee.

    Apologies. 

    I was hoping for a way of changing the questions on a call should the user input incorrect data. 

    As in rather than select distribution list creation they select mailbox instead and then wish to change it.

    Or is that something we would have to add as an update to the call? 

    Thanks

    Dan

  6. Hi @cchana,

    All the feedback is set to expire within 5 days.

    It is looking like a lot of the requests are left in the awaiting feedback but not all.

    I have cleared down the old set of test requests (incidents and service requests only) a couple of weeks ago using the Hornbill cleaner app. I also reset the numbers for all requests so they started back at 00000001 and we are currently on 00000106

  7. Hi @Victor

    IN00000099 was a test for this timer issue so that should be one to look at. 

    Resolved 15/12/2016 14:27

    Closed 15/12/2016 14:32 (I had set the auto close to 5 minutes for the purposes of the test)

    As soon as the resolution is entered the 'Resolution Target Time' timer is ticked even though the timer should still be running and the BPM suspended. 

    Even if the timer is still running, with the timer ticked we can't see that.

  8. Hi @Victor 

    There is a suspend node. As per the image above I have the auto close node directly followed by a suspend - await request closure.

    Therefore I would expect that the BPM would set the auto close timer and then, as the request is set to resolved rather than closed, suspend the BPM until the status is set to closed and then resume to the end of the BPM. 

    Edit: Also the stage check point of 'Request Closed' is not marked even though the timer is stopped. This would seem to indicate that the suspend is working and resolving the request is stopping the timer automatically regardless of the BPM.

  9. Hi all, 

    I am having an issue with auto closing incidents and stopping the resolve timers.

    At the moment I have the resolution phase of our incidents set out as per the attached image.

    Capture.PNG

    The issue I am having is that even though the BPM is set to suspend - wait request close (which should be set by the auto close node) and the resolve timer - end is the last node, as soon as the resolution is entered in the call the resolve timer is marked.

    If the user then says that the issue is not resolved the timer cannot resume as it has already been marked end. 

    Is there a way of setting out this part of the BPM to wait for two days and suspend the timer in case the user is still having issues? I know I can have human tasks with an expiry but I don't really want to have a task here, 

    Thanks 

    Dan

  10. Good morning all, 

    I have been looking at the feedback feature some more and have found that even though feedback has passed the timeout cut off it still shows in a users 'awaiting feedback' list.

    Once a user clicks the request it doesn't present them with the option to leave feedback as it has expired. Is there a way to auto remove these expired feedback requests?

    Some of our users log a large amount of requests each month and I don't want expired ones to stay in the list and put people off using the feedback tool as it seems that we are forcing them to leave feedback for every call or else they will have a huge list of expired feedback.

    Thanks 

  11. In the timeline you can tell. Either closed by <userID> or closed by System Internal Context.

    You could then create a report based on call closed by: and filter on System Internal Context. That would tell you how many calls the system closed due to timeout.

    You could then assume that anything the system hasn't closed was closed by the user.

     

×
×
  • Create New...