UCCX 8.5 On Exception Goto "catching" exceeded 1000 steps

[ivana vidakovic]

Hi all,

I have a system in which callers sometimes wait for their assigned agent for quite a long time. Long enough for the script to exceed 1000 steps. This happens about once a month, which isn't a problem because the agents use an application where they can see who called and call them back. The same application displays calls that are in queue. These calls are deleted after hanging up. When calls are abouted due to exceeding 1000 steps, they don't get deleted. Since changing the max. steps excecuted in the system parameters isn't advised,  I was hoping to "catch" the exeption with the On Exception Goto step (just to delete these calls in the application). Does anyone know which exception I need?

Most of the information here is irrelevant, the only thing I'm looking for is a On Exception Goto step that chatches WFMaxExecutedStepsExceededException

Thank you

Ivana

[Anthony Holloway]

Doing it that way is technically not possible.  If you exceed 1000 steps, then the script is deallocated from memory and the call is dropped (albeit after the default script plays.)  Which brings me to the next point: the default script can be customized and it can even receive the reason why the main script failed.

Here are the steps you can use in your customized default script to see if the main script failed for the max executed exception reason.

Variables

com.cisco.app.ApplicationException the_exception = null
String the_reason = ""

Script

...

the_exception = Get Trigger Info (Aborting Reason)
Set the_reason = the_exception.getMessage()
If ("No. of executed steps: 1000".equals(the_reason))
     True
          /* The main script failed due to the max steps being executed */
     False
          /* The main script failed for some other reason */
...

If you haven't used the default script on an application before, you may not know what I'm talking about.  See this screenshot for an example:

EDIT: I don't know if the reason is a String literal, or if it is derived from the value set on the parameters page.  Maybe someone with a higher value than 1,000 on their system can try this out for us and let us know what the reason is for them.  If it is different depending on your setting, and you want a solution to work with any value for max steps, then change the if step to this:

If (the_reason != null && the_reason.startsWith("No. of executed steps"))

Anthony Holloway
Please use the star ratings to help drive great content to the top of searches.

[julien.laffitte]

Anthony,

I've just found your post and applied your solution: it works like a charm!

My point was only to be able to inform the user that there was an issue and not leaving him with a faulty ringback, but it does the trick beautifully.

As always your post is to be bookmarked ;)

+5!

[Anthony Holloway]

Sweet!  Thanks for the feedback.  It's always amazing to think just how many people are reading these posts, and then only a subset are commenting.  Your feedback also helps others to know that it's a working solution as posted.  Thanks again.

[Stefano Pucci]

Hi Anthony,

could you please provide me any details for the script?

the_exception is a "Get Trigger Info" step,

but i didn't get which step is :

the_reason = the_exception.getMessage()


Thanks
Stefano

[julien.laffitte]

Stefano,

My answer might come too late, but you just have to use a standard "Set" step.

The the_exception.getMessage() code is in fact pure java code that is directly inserted in the value field of the step:

• the_exception is the name of the exception variable you have declared,
• getMessage is a built-in method of this java class that allows you to retrieve the exception message as a String variable.

Hope that helps,

Julien

[Genadi]

Can anyone explain how to declare ? There is no such variable type....

com.cisco.app.ApplicationException the_exception = null

[Anthony Holloway]

@Genadi I don't have a UCCX editor in front of me, but I believe if you just use the variable type drop down, it will show the exception variable type in the list.  And if not, this is a little known secret, you can type anything into the variable type field, so just copy and paste the variable type name into the field manually.

[Genadi]

Also how it's possible to variable from the first script using  context in get trigger info step ?

[Anthony Holloway]

The --Triggering Contact-- thing is a variable of type Contact, and it's a reference to the caller.  When the first script aborts, the reason is set within the Contact context, and because the default script can also access that Contact variable of --Triggering Contact-- (e.g., it's the same Contact variable in both scripts), then the default script can read the reason from within the context.

In other words, both scripts know about the caller and associated data attached to the caller, such as aborting reason.

[jim-j]

---

@ivana vidakovic wrote:
...

Since changing the max. steps excecuted in the system parameters isn't advised

...

---

Where is is stated that this isn't advised?  I always increase this.