Get current step number and handling max steps exceptions

[cunningt]

We are using IPCC Express Premium 4.0.4 and would like to know:

1. Is it possible to determine the execution number for the current step? For example, x number of steps have been executed up until a certain point in the script. Possibly via a Set step using Java or a DB Read step?

2. When the system parameter "Max Number of Executed Steps" limit has been reached the exception "com.cisco.wfframework.obj.WFMaxExecutedStepsExceededException" exists within the CRS Engine MIVR log. This exception does not exist within the available exceptions list in the "On Exception Goto" step. Is there a way that we can intercept this specific exception or will we have to use the "com.cisco.app.ApplicationTaskInactiveException" exception instead?

We have been experiencing stuck Reserved agents and periodic callers stuck in queues, which has been occurring due to the maximum number of executed steps being exceeded. We have increased our "Max Number of Executed Steps" parameter from 1,000 to 2,500 for the time being and we may need that higher still.

Our script has a lot going on after every 30secs of hold music....to determine if notification pages/emails need to be sent out to Help Desk staff due to long wait times, or to play updated status prompts only when appropriate....to name a couple. To our knowledge we have made things as efficient as possible (using Sessions) and we will be making a few more tweaks, but nowhere near enough to stay under the default 1,000 limit.

I asked question # 1 to help us better assess what our step execution counts are for different logic scenarios, rather than manually trying to count the steps within our script. I asked question # 2 so that we can send pages/emails to ourselves if a WFMaxExecutedStepsExceededException exception does occur and include the phone number of the caller who would have ended up not getting through so we can call them back not long after.

Thank you for any info you can provide!

Tom

[ivillegas]

In most of the cases,you should not hit the 1000 step limit unless there's a loop in the script. If there is less than 2000 steps in your script, that you have a loop in your script.

[mciarfello]

Did you ever find a solution to this? I am in a similar situation. I want to check to see if the caller pressed 1 (to leave a message type functionality) anytime during the queue loop. Not just when a delay expires and a prompt is played. This easily exceeds the default max steps.

Even though it's not in there, the on exception goto sounds like a great idea. Let the script designer decide that "it's ok, we are not in a loop." It seems in order to get that to work. A max steps variable or something would have to be settable/resettable in the script.

[Aaron Harrison]

Hi

Anyone have a solution to this?

I need to override or reset this counter on a particular script...

Thanks

[mciarfello]

Not found a way except make the max steps very large and be careful of loops. Contact your channel manager and also put in for a feature enhancement. The more the merrier.

[vladimirbanker_2]

Hi!

Where I can make the max steps very large ?

I am using CRA3.5.

Please help ASAP,

Thanks

[mciarfello]

Try System -> System Parameters -> Max Number of Executed Steps

I don't have any 3.5 systems handy to see if that's where it is (or there at all), but in 4.0, that's where it is.

[Jonathan Schulenberg]

I'll try and answer the issues in this thread in turn:

"1. Is it possible to determine the execution number for the current step? For example, x number of steps have been executed up until a certain point in the script. Possibly via a Set step using Java or a DB Read step?

2. When the system parameter "Max Number of Executed Steps" limit has been reached the exception "com.cisco.wfframework.obj.WFMaxExecutedStepsExceededException" exists within the CRS Engine MIVR log. This exception does not exist within the available exceptions list in the "On Exception Goto" step. Is there a way that we can intercept this specific exception or will we have to use the "com.cisco.app.ApplicationTaskInactiveException" exception instead? "

----->Sadly this is not in the On Exception Goto step. Several people have commented on this to Cisco and I would recommend you join the crowd. Talk to your Cisco Account Manager. If you are a partner, submit a well thought out request to ask-icd-ivr-pm@external.cisco.com.

"Our script has a lot going on after every 30secs of hold music....to determine if notification pages/emails need to be sent out to Help Desk staff due to long wait times, or to play updated status prompts only when appropriate....to name a couple. To our knowledge we have made things as efficient as possible (using Sessions) and we will be making a few more tweaks, but nowhere near enough to stay under the default 1,000 limit. "

----->You should be using sub flows for this type of work. Sub flows are a separate script and as such, have their own maximum step count each time you call them. Put all of this extra logic into a separate script and call it each iteration through the queued loop.

"In most of the cases,you should not hit the 1000 step limit unless there's a loop in the script."

----->Exceeding this is not recommended by Cisco as it increases the amount of memory being used by each script instance. I would proceed with a great deal of caution.

"I want to check to see if the caller pressed 1 (to leave a message type functionality) anytime during the queue loop. Not just when a delay expires and a prompt is played. This easily exceeds the default max steps. "

----->The common way of doing this is uploading a WAV of your music on hold to the prompt repository and then using a Get Digit String step with the MoH WAV file as the prompt for it. This allows the caller to press it at the IVR is essentially always waiting for a DTMF digit. You can use Match or If statements within the Success branch to determine if they pressed the correct digit.

"Where I can make the max steps very large ?

I am using CRA3.5.

Please help ASAP,

Thanks"

----->Again, not recommended! You can almost certainly break your script into appropriate functional components and use subflows to drastically reduce the likelihood of hitting the maximum.

[h.lindstrom]

I tried to use subflows, but it seems like it is the same counter for the subflow as for the mainscript.

It only got it worse-

For this actual case im running ccx 7.0.1.

I'd really need to get a solution for this sinse it's not recommended to increase the maxnum ex script steps param.

Or is it?

Somebodys got a workaround.

Thanks

[Aaron Harrison]

Hi

The max steps counter is there so if you create a loop it won't run forever.

You can increase it without causing any problems (as a real non-ending loop will still get terminated, albeit a little later than it would now).

If you really are looping around so much that you hit the limit, you should probably rethink the parts of your script that are causing this. You may be able to reduce the step count it uses, or even condense a given long-running loop into a single java step (carefully).

Regards

Aaron

[h.lindstrom]

Hi Aaron

I have already increased the max number of executed script steps parameter.

Even though I've seen in several posting it wasn't advisible.

The loop isn't including much, it just goes on for a long time.

It's about 15 steps and loops for 46 minutes until it reaches the limit.

(Yes, our customes lets theis customers wait in queue for that long)

Thanks for the quick reply.

Now I'm not too worried about the increased parameter.

Best regards

Hans

[Anthony Holloway]

Glad to see people searching the forums, instead of posting first.

I posted this to the old mailing list back on December 19, 2008, in response to the max number of steps:

I should also mention…



Where possible (because sometimes it’s not), do not use the comment
step or label step.  Instead use the comment tab and label tab on the step
that is required.



Take a look at the two attachments.



The one with fat takes 9 steps to get the customer ID, and 14 steps
if the Timeout or Unsuccessful branches are hit first.

The one without fat takes 2 steps to get the customer ID, and 4
steps if the Timeout or Unsuccessful branches are hit first.



That’s a 75% decrease in the number of steps required.

Attachments included

[Steven Griffin]

"I want to check to see if the caller pressed 1 (to leave a message  type functionality) anytime during the queue loop. Not just when a delay  expires and a prompt is played. This easily exceeds the default max  steps. "

----->The  common way of doing this is uploading a WAV of your music on hold to  the prompt repository and then using a Get Digit String step with the  MoH WAV file as the prompt for it. This allows the caller to press it at  the IVR is essentially always waiting for a DTMF digit. You can use  Match or If statements within the Success branch to determine if they  pressed the correct digit.

I would comment that perhaps a better way of doing this is the following:

Call Hold

Menu ( *P[Empty.wav], timeout set to your queue loop delay time, and retry set to zero)

     Menu Option 1:

          Call Unhold

          DeQueue

          Call Redirect (Destination is VMPilot DN and reset called number to Mailbox DN)

               Successful:

                    Set Contact Info (Handled)

                    End

               Unsuccessful, etc:

                   Increase Priority (Increment 1)  /* Optional */

                   GoTo Select Resource

     Timeout:

           /* Do Nothing  */

     Unsuccessful:

           /* Do Nothing  */

Call Unhold

The benefit of this approach is that you don't need to play the MoH music as part of the prompt, instead you can let CallManager do that work and still capture DTMF the instant they press a key.   Since the caller is already on hold any prompt you put in the Menu step will never get played to the caller. Neither will they hear the Cisco lady say, "Are you still there?"

*Note on the P[Empty.wav] file in the Menu Step:  Because I generally do some prompt exception checking in my scripts I usually upload a blank G.711 or G.729 WAV file to the prompt repository.  When I need to play nothing to the caller I use that WAV file so I don't throw an exception.

- Steven