RIchard Horton Posted May 13, 2022 Share Posted May 13, 2022 I have a business process workflow where we have put a suspend of 1 minute at the start. This is because the ticket is created by an API call from a script, and there are 2 calls in the script (the 2nd updates custom variables within the ticket), so we want to give it time for both to execute. The problem is that the suspend seems to wait according to the working time calendar. So, if I submit a request at 1730 it doesn't release the suspend until 09:01, which I think is because of how the WTC is set up. While we do not expect our staff to work 24x7 we do expect that Hornbill will create tickets when they are raised, so want the suspend to be for 1 minute not 1 minute within service hours. Make sense ? Is there a way to do this ? Setting up a loop until a mandatory custom field has a value is the best I can think of. 1 Link to comment Share on other sites More sharing options...
Steve Giller Posted May 13, 2022 Share Posted May 13, 2022 I would suggest moving the delay into the script. That's not really what Suspend nodes are designed for, and quite aside from it honouring the WTC (which I don't expect to change) you are inviting other potential issues by using the node to "stick a delay in" Link to comment Share on other sites More sharing options...
RIchard Horton Posted May 13, 2022 Author Share Posted May 13, 2022 How does that work, Steve ? To do that I think I would need the script to do everything in one call. The original script was provided by Hornbill so I assume there's a reason it does it in two calls rather than one. Link to comment Share on other sites More sharing options...
RIchard Horton Posted May 13, 2022 Author Share Posted May 13, 2022 The way of doing this that I think we may have to adopt (unless someone can suggest something better) is to set up a decision loop that keeps interogating the request until the custom variable set in the 2nd call has been populated. Link to comment Share on other sites More sharing options...
Steve Giller Posted May 13, 2022 Share Posted May 13, 2022 @RIchard Horton Depending on how long that takes you may hit a hard limit - looping is not a "good thing" especially in a Cloud product, and that kind of loop normally takes microseconds to action. 6 hours ago, RIchard Horton said: While we do not expect our staff to work 24x7 we do expect that Hornbill will create tickets when they are raised, so want the suspend to be for 1 minute not 1 minute within service hours. I'm not sure why there is an issue here. Regardless of the delay in unsuspending, the Request creation time does not change. If no actions are being taken on the Request out of hours then the Custom Field updates not taking place until you reach working hours shouldn't affect things? The other option is that, unless everything about the Request completely relies on those Custom Fields, you can do "other stuff" before updating them - assigning a Priority and/or SLA, passing it to a Team/Owner, sending the Customer an acknowledgement email etc. These all take time that should give plenty of opportunity for both API calls to complete. Link to comment Share on other sites More sharing options...
Martyn Houghton Posted May 16, 2022 Share Posted May 16, 2022 @RIchard Horton We also would like the ability to control the use of the WTC with the expiry node, so that elapsed actual time pauses can be done form with the Hornbill process. Cheers Martyn Link to comment Share on other sites More sharing options...
RIchard Horton Posted May 18, 2022 Author Share Posted May 18, 2022 Thanks Steve. Unfortunately information we are picking up from the 2nd call is key to the next steps we want to perform. As you say, what we're wanting to do is simply instigate a short pause to allow the 2nd call to complete (I've now understood that the 2nd call is necessary because custom fields are in a separate table so you need the first call to complete to give you the relevant linkage to update them). You are right that in theory no one is working so why does it matter. However we don't work in an "everyone clocks off at 5" environment and it is frustrating if you are working beyond the standard service day defined in the WTC not to be able to work on requests that you know have come through. Link to comment Share on other sites More sharing options...
Steve Giller Posted May 18, 2022 Share Posted May 18, 2022 @RIchard Horton Without a deep dive into the process it's diffcult to be sure of the best way forward. On 5/13/2022 at 11:26 AM, RIchard Horton said: the ticket is created by an API call from a script, and there are 2 calls in the script On first read I was assuming that there are 2 API calls - one to raise the Request, then one to update the Custom Fields, however 59 minutes ago, RIchard Horton said: information we are picking up from the 2nd call is key to the next steps we want to perform suggests that there are 2 separate Requests. How to proceed with one Request ensuring that the Custom Fields have been updated may well take a different path to two Requests with the first waiting for the second to be raised and populated. Link to comment Share on other sites More sharing options...
RIchard Horton Posted May 24, 2022 Author Share Posted May 24, 2022 Thanks Steve. It's the first scenario. The form input needs some processing to determine the customer. I think I have found a way to deal with this combining your comment above with my looping idea. What I have done is a decision node that loops back if the custom field is not set. Within the loop it does a write to the timeline and then a get request. I have tested it and it only goes round the loop twice - the activity in the first loop is sufficient to allow the custom fields to have been set. Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted May 24, 2022 Share Posted May 24, 2022 @RIchard Horton Going back to your original idea of suspending a request, couldn't you use an 'on hold period' node, and set it to NOT use the WTC? Or use a Get Timestamp' utility and add a couple of minutes to 'now' and then place the request on hold UNTIL that time? Link to comment Share on other sites More sharing options...
RIchard Horton Posted May 30, 2022 Author Share Posted May 30, 2022 Those are interesting ideas, I'll have to look at those Link to comment Share on other sites More sharing options...
Martyn Houghton Posted June 8, 2022 Share Posted June 8, 2022 @Paul Alexander, @RIchard Horton The workaround of the on hold period should work, but has the disadvantage of putting the request on hold and pausing the timers. Cheers Martyn 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