I've already searched a bunch through these forums in an attempt to find a way to avoid hitting a WFMaxExecutedStepsExceededException. In my particular use case, I have a list of 100+ items that I get from an xml file. The script generates and plays an audio file for a particular item and then asks the caller to confirm, advance to the next, or skip ahead to the next major item in the list. If the caller skips ahead enough times, the script will eventually hit the 1,000 steps before even getting to the end of the list. Is there a way to reset the current steps or recursively spawn the same script to restart at 0 steps or something else to get around this error?
I am a fan of refactoring code. Here is the problem area:
As you can see, the max steps will be hit quickly if the caller keeps pressing the digit for next stop or next major stop. I'd rather catch the WFMaxExecutedStepsExceededException or reset the steps instead of having the phone system hang up on the caller.
I tried sort of browse through all the methods and fields of all objects available within a UCCX script (derived from the Call object) but I gave up. I guess it's safe to say there's no way to reset the counter "in transit". To be honest, if I were the Architect of UCCX, I would not let this option be available, either.
Anyway, what I would try to do is insert a counter that would increase if the caller presses the digit for next (major) stop, and if this counter reaches a certain threshold, I would just play a message ("hey, stop doing that"), or as Anthony said, exit the currently running script, and re-enter it via an application trigger or a redirect. This might mean some tradeoffs with the sanity of reporting, but I noticed you already have implemented custom logging so adding a few steps (wink) for pushing some reporting info to an external DB should not mean a problem, either.
The quick short answer is, increase your max step count. A lot of people do it. So much so, I think the warning needs to go away.
The next short answer is, Trigger Application or Call Redirect will reset counters. With the Trigger Application step you could achieve something great for your application. If you've never used it or heard of it, then you're in for a real treat.
The longer answer is of course to optimize your code. But in all reality, if you are providing a service in which a caller can spend all day going forward and backward like this, then no matter how much you optimize, the ceiling has the potential to be hit. Whether it's max execution, memory leakage, or the 12 hour phone call limit imposed by CUCM.
Please use the star ratings to help drive great content to the top of searches.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...