Using Exceptions in UCCX

I had opportunity to participate in a UCCX version 7.x to 8.x upgrade recently which involves a change in the underlying UCCX Operating System (From Windows to Linux).  Based on that and some of the changes Cisco has made, I think is critically important that scripts make use of Exception Statements.  If you have ever had a UCCX call trigger the dreaded; “I’m sorry we are currently experiencing system problems and are unable to process your call.   Please try again later“; then you most likely have generated an exception.  This results in the application using the Default Script.   In most cases, this may not be the optimum way to process the call.   Fortunately Cisco has two steps in the General Palette that we can use to handle these exceptions.  These steps are the “On Exception Clear” and the “On Exception Goto” steps.  Every script writer should consider adding these so that fatal errors when running the application do not result in fatal call handling for their customers.

The “On Exception Clear” step clears the exception so that the script can continue to run.  While this step may be helpful in certain situations, my opinion is that the “On Exception Goto” step is more valuable.  The “Goto” exception allows us to branch the script to an error handling section based on the type of exception generated.  So for example, if we are reading a document in order to set some call handling parameters, we can continue through the exception setting some default parameters.  Furthermore, we could classify the call such to alert agents that calls are not being handled efficiently.

An almost necessary exception for all scripts should be the “Contact Inactive” exception generated by callers hanging up.

This exception typically is routed to an end script location.

The “On Exception Goto” step has only two mandatory parameters; selecting the exception type and the branch label.

It does not matter where we program the exception step in the script.  The registration process is for the complete script, so if the exception occurs before, during, or after the given step, it will be handled accordingly.  Once the step executes, the handler is registered until either a new one is re-registered or the exception is cleared with the “On Exception Clear” step of the General palette.

In UCCX version 8.x, there are almost 200 exception events to choose from for routing.  In addition to the Contact Inactive exception, other exceptions areas include the following:

• Application errors
• Expression errors
• Database errors
• Document/Grammar/Prompt errors
• User errors
• Configuration errors

While we all would like to believe our scripts are flawless, UCCX applications depend on many systems beyond the scripts control including networks, database systems, file systems, and even the UCCX server hardware.  Exception programming gives us the tools to handle many errors while still being able to process the calls for our customers.

If you have used other exceptions, please feel free to post them for us all.