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.

One response to “Using Exceptions in UCCX

  1. Great blog.

    I would like to share a situation where this step helped me. On Exception Goto solved a problem that was bugging me for a while. I had a script that retrieved XML files stored on an IIS server which are used to control holidays, opening times etc. The theory is that a web front end can be written to manage these XML files in a user friendly way.

    This worked ok but if the IIS server was down then the script failed. I have used the On Exception Goto to detect this error and then forward to a label which uses Day of Week and Time of Day steps to provide fallback call routing control.

    Now I just have to get my head around writing the web portal front end!



Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.