Trying to keep an incident at wait for request update/execution count question

[James Gallally]

Good afternoon,

On a test BPM I have created a decision loop to try and get the BPM to wait at the wait for request update stage unless the status has been changed to resolved. In my mind, after every update to an incident, it would run through the loop and see if the status was resolved, if it had it would proceed, and if it wasn't go back to waiting for an update

 

I created a test ticket and it worked the way I was expecting, I was able to keep updating the incident and it did what I wanted, then after changing the status to resolved it progressed and completed as desired. I then tried it again and kept the ticket open for longer, proceeded to make more updates to the ticket, but not a massive amount. I then got the attached error

I have read this post here: https://community.hornbill.com/topic/13117-maximum-step-count-error/ and understand that this was put in to stop infinite loops which is fine. I am just trying to understand that even if the node is a wait action, it will continue looping through in the background and not just when someone updates the ticket? I thought that I would get this error after 1000 customer/technician updates to a ticket.

I know that at the time (the post is 2 years old) the recommendation was to break the loop by inserting two additional nodes  on the No Match:

+ one node to update the request and blank out the previous resolution

+ another to wait for (new) resolution (if the above node is missing, this one will be bypassed because a resolution already exists)

I have been asked to see if it is possible to not have it wait at the resolution stage by default. I still need a wait for resolution as there is further actions taken after the resolution is set.

 

Thanks

James

 

 

[Victor]

@James Gallally well... I learned a few (more) things since a few years ago...  ... basically the advice is theoretically correct. The loop occurred because the request was resolved, so it had a resolution, as such the Wait For Resolution was no actually waiting, thus, the loop. However, the idea to blank out the resolution, sadly, does not work, as you cannot set an empty value for any request detail, including resolution, which is what the Wait For Resolution would have needed to actually wait.

Now, the issue you described. A few things first:

1 hour ago, James Gallally said:

if the node is a wait action, it will continue looping through in the background

Ermm.. sort of but not quite. I'll explain... when the workflow reaches a Wait node, it will suspend. Then the workflow will resume from the suspended node when the correspondent action is performed (e.g. update, resolve, on hold, email, etc). If you create a loop sequence like the one you configured, there won't be a scenario where the workflow is suspended having activity in the "background". In a "maximum execution count" scenario the workflow never actually suspended... the Wait node never triggered the suspend because the conditions for suspend are not met (for example Wait For Resolution when there is already a resolution on the request).

The Wait For Update node. IIRC, the way this node works is that it will wait for a request update. Important to note is that the resume for this Wait will happen if there is a (any) update on the request regardless when that update occurred. Therefore the suspend will only happen if there is no previous timeline entry of type "Update" on the request and the resume will always happen if there is one. As soon as the request has this type of update, the "Wait For Update" will no longer work. This, again IIRC. Based on your description of what you are trying to achieve is that you need a type of "Wait for New Update" node that, for resume, will look for any new update which is one made after (each time) the node suspended the workflow. I don't think that's how the "Wait For Update" node works, but is been a while since I tested this particular node in various scenarios.

 

However:

1 hour ago, James Gallally said:

I created a test ticket and it worked the way I was expecting, I was able to keep updating the incident and it did what I wanted, then after changing the status to resolved it progressed and completed as desired.

Now, if during this test, you have updated more than once (had to be a timeline entry of type "Update") and at each update the workflow suspended then resumed, this would invalidate the above. Which means that:

1 hour ago, James Gallally said:

I then tried it again and kept the ticket open for longer, proceeded to make more updates to the ticket, but not a massive amount. I then got the attached error

..might be actually a defect which might have to investigate.

[James Gallally]

Thanks @Victor for the quick reply. I was trying this the morning this week where things went a bit crazy in Hornbill. I will re-create my BPM and do some more tests to confirm that what I did wasn't a one off and that it does actually do what I am expecting it to do.

I am guessing that there is currently Wait for New Update type node?

15 hours ago, Victor said:

Based on your description of what you are trying to achieve is that you need a type of "Wait for New Update" node that, for resume, will look for any new update which is one made after (each time) the node suspended the workflow.

 

[Victor]

9 minutes ago, James Gallally said:

I am guessing that there is currently Wait for New Update type node?

Correct

[James Gallally]

Hi @Victor

So after some testing and scratching of head, I have realized that I posted the wrong screenshot. If I use the Wait for Request update, I do not get the execute error message, however after I have resolved the the ticket it does nothing, and I have to put an update in for it to close because of the afore mentioned Wait for Request update vs Wait for New Update.

What I had actually done, is had the same logic and loop setup but had a Wait for Status Change.

I must have tried the Wait for Request Update, found it not working and then tried this. I have tested and confirm that if I have the logic above, I can create an incident, apply some updates, and resolve it quiet quickly, it works the way I envisioned. However if I am slow and wait, then it generates the following error:  

Should I create a support ticket for this or is this as intended?

Thanks

James

 

 

[Victor]

@James Gallally not sure I follow  ... could be that is Friday... best raise a support request then we can have a better look...

[James Gallally]

@Victor Thanks, could be its Friday and I just can't explain what I mean - has been known to happen on occasion