Steve Giller Posted June 13, 2018 Share Posted June 13, 2018 Error message:Process::Execute: exceeding maximum step count (1000)... Process::Execute: exceeding maximum step count (1000)... We get this occasionally on some of our Facilities requests - I have no idea what causes them, and the vast majority of requests go through without issue. It's on our Facilities Incident business process, but I can't identify anywhere that might be causing it - although without really understanding what the error indicates I'm not sure what I'm looking for anyway. If it helps it most recently happened on IN00026767 and IN00027271 Any ideas? Link to comment Share on other sites More sharing options...
Steven Boardman Posted June 13, 2018 Share Posted June 13, 2018 @DeadMeatGF just a thought, but one of my colleagues has suggested this limit was put in to handle Infinite Loops which may have been introduce into a business process - for example, using the raise new request node is used, which in turn uses the same business process which again then raises a new request, and on and on etc........ The tricky bit may now be looking for where this might occur in the facilities requests, could you share the business process perhaps? Steve Link to comment Share on other sites More sharing options...
nasimg Posted July 3, 2018 Share Posted July 3, 2018 @Steven Boardman, @DeadMeatGF I've seen this error too. On request SR00246717 in our instance, nothing special about this request but I can't restart the BPM. This request was reopened by the customer - so the HUD is showing resolved, but the status is open. Anything I can do to repair the request? Nasim Link to comment Share on other sites More sharing options...
Steven Boardman Posted July 3, 2018 Share Posted July 3, 2018 @nasimg could you share the stage final stage of this process? the error is indicating a loop has occurred, so would probably need to see the configuration of the final stage and if you are using the await status change node something like below: Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted July 4, 2018 Share Posted July 4, 2018 +1 for me.....we're also getting this error on a few of our BPM's. We DO use the 'wait for status change' node which has an expiry of 5 days set on it (so, once 5 days has elapsed, if there is no update, then the call is closed). thanks Link to comment Share on other sites More sharing options...
Steven Boardman Posted July 5, 2018 Share Posted July 5, 2018 @Paul Alexander @nasimg this might be something we need to look at in regard to your specific processes and example tickets where this issue has occurred. Could you point us to some examples on your instances and the every helpful @Victor can perhaps take a look and see if there is something causing these loop errors Steve Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted July 5, 2018 Share Posted July 5, 2018 @Steven Boardman.....as soon as it happens again I'll be sure to let you know. Although we all know it won't happen again now that it's been mentioned...... Link to comment Share on other sites More sharing options...
Victor Posted July 5, 2018 Share Posted July 5, 2018 1 hour ago, Steven Boardman said: every helpful Let's not get carried away, ok? Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted July 17, 2018 Share Posted July 17, 2018 @Victor....I've now had another of these 'step count error' tickets. Call ref SR00039172 The BPM being used is the ' SERVICE REQUEST - CONQUEST - New User' one. This does have a 'wait for status update' loop in the last stage - is this what's causing the error? (Do you need the BPM def file or can you see this on our instance?) thanks Link to comment Share on other sites More sharing options...
Victor Posted July 18, 2018 Share Posted July 18, 2018 @Paul Alexander I’ll have a look this morning... Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted September 4, 2018 Share Posted September 4, 2018 On 7/18/2018 at 7:37 AM, Victor said: @Paul Alexander I’ll have a look this morning... Hi @Victor....did this ever get looked at please as we're getting a few more of these errors popping up. I can get around it by using the 'restart' option on the HUD, but it does get a bit annoying... thanks Link to comment Share on other sites More sharing options...
Victor Posted September 4, 2018 Share Posted September 4, 2018 @Paul Alexander 55 minutes ago, Paul Alexander said: did this ever get looked at I want to say yes but that would be a lie ... Do you trust me if I say again that I will have a look Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted September 4, 2018 Share Posted September 4, 2018 @Victor Of course I do! Because it's in writing for all to see AGAIN Link to comment Share on other sites More sharing options...
Victor Posted September 4, 2018 Share Posted September 4, 2018 There is nothing in writing... it was all destroyed in a mining accident! Also, this is a moon! Link to comment Share on other sites More sharing options...
samwoo Posted September 4, 2018 Share Posted September 4, 2018 11 hours ago, Victor said: There is nothing in writing... it was all destroyed in a mining accident! Also, this is a moon! The moon is really bright tonight... And getting brighter by the second... Link to comment Share on other sites More sharing options...
Victor Posted September 6, 2018 Share Posted September 6, 2018 On 7/17/2018 at 11:04 AM, Paul Alexander said: This does have a 'wait for status update' loop in the last stage - is this what's causing the error Yes, that is the reason why: The loop occurs when the status changes to anything but "Closed" and before the node expires. In this scenario (e.g. status changed to open) the infinite loop is initiated because the "Wait" node will be bypassed because is configured to wait for a status change from "Resolved" to something else. It is bypassed because the request is not in a resolved state anymore. Same situation that @nasimg has... My solution would be in the "No Match" branch (which I assume is there in case the request is reopened) to add two new nodes: 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) Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted September 7, 2018 Share Posted September 7, 2018 Thanks @Victor I'll take a look at implementing this today and see if it stops the errors (of course it will!) thank you Link to comment Share on other sites More sharing options...
Victor Posted September 7, 2018 Share Posted September 7, 2018 @Paul Alexander good... it looked like for a second there that you were doubting me but it must have been my imagination Let me know how it works Link to comment Share on other sites More sharing options...
Guest Paul Alexander Posted September 7, 2018 Share Posted September 7, 2018 2 minutes ago, Victor said: it looked like for a second there that you were doubting me It's not YOU I doubt, it's my ability to follow instructions Link to comment Share on other sites More sharing options...
Victor Posted September 7, 2018 Share Posted September 7, 2018 @Paul Alexander ah, very nicely put sir, very nice indeed 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