CCXML Voxeo 1.0 Development Guide

| TOC

This documentation is for CCXML 1.0-Voxeo, which has been superceded by CCXML 1.0-W3C. The CCXML-Voxeo platform is not being updated any longer. The CCXML 1.0-W3C version, however, has many new features and is actively being enhanced. If you're writing a new CCXML application, you should use CCXML 1.0-W3C. Click here for the CCXML 1.0-W3C documentation.

Appendix B: CCXML Debugging Techniques

To the uninitiated, writing a Call Control XML application is hard enough, but debugging them can be a downright frustration. In this document, we will cover all the standard techniques used to tame a troublesome application. We can use the following suggestions as the deFacto method of debugging and tuning your app so that it behaves.

Use the Debugging Tools

We can't stress this one enough. Get aquainted with the Voxeo Realtime Logger, as it will save you massive headaches when you encounter cantakerous code. the logger provides messages relating to fetch failures, parse errors, and CallXML-specific problems, that you can use to figure out What Went Wrong. Also, make use of the <voxeo:sendemail> element. Adding these few simple lines of code to your Call Control XML applications will serve as an immense help when you attempt to debug your apps. Using this combo will, predictably enough, send you an email that details the error whenever your application takes a high dive:


    <transition state="'fetching'" event="error.fetch" name="evt"> 
      <log expr="'*** FETCH ERROR [' + evt.error + '] ***'"/> 

      <!-- CATCH ERROR, AND SEND EMAIL --> 
      <voxeo:sendemail to="'yourEmail@there.com'" 
                        from="'myApp@here.com'" 
                        type="'debug'" 
                        body="'We had an error! \n Time to panic! \n 
                            Flee the cities, abandon all hope! \n 
                            Or, just send this email to the support  
                            folks.'"/> 
      <exit/> 
    </transition>

You can find more information on the realtime logger within the following chapter of the documentation set, and you can find full-blown code samples illustrating the <voxeo:sendemail> tag within our handy element listing.

Modularize It!

While the term 'modularize' might be better suited to a GW Bush speech than a debugging primer, the message is still just as important. Try to avoid writing a huge application that is contained within one page. Try to break your code up into small, manageable portions to save yourself a lot of headaches.

Check For Parse Errors

Does the code parse in Internet Explorer? Newer versions of IE allow you to catch parse errors before running your script, and any parse errors will be evident in the window. Passing along any querystring parameters? You will want to open the full URL displayed in the logger that include the variable/value pairs in order to see what is getting sent to the voice browser. If IE tells you that your script is indeed hunky dory, then we can go along to the next step in troubleshooting our app.

Eliminate the Obvious

If our code parses fine in IE, but bombs when we call it, then we have to check the obvious stuff first. In IE, choose 'view' then 'source' and make certain that there is no whitespace preceding the initial xml declaration. An extra line of whitespace is the bane for all things xml. Next, check to see if our CCXML app mapped to a CallXML or VoiceXML number in the Voxeo Account Manager. While we are at it, we should also make sure that our URL is correctly entered. Yes, these are dopey mistakes to be certain, but they are as common as locking your keys in the car.

Check the URL's

Statistically speaking, a good proportion of vxml errors are the result of having malformed URL's in the code. When the logger indicates that a particular page is having problems, we will want to make absolutely certain that any URL's referenced there are valid. Specifically, make sure that the targets of any <goto>, or <send> elements point to an existing page. Also check your 'src' attributes for any 'wavurl', parameters and the like to ensure that they are pointing to valid destinations.

Variable Errors

Next, we will want to ensure that we arent using any variables that are yet undeclared. Chances are, this will show up in the logger as a big fat error message, but for the myopic, we have included this suggestion here as well. Check especially for misspellings!

Log Statements

Adding generous log statements that offer navigational information can tell us exactly where to look when our application goes belly-up. Within each <transistion>, <eventhandler>, and <assign>, you should include a log statement as well to help track variable errors in your code. Remember, it takes but a few seconds to add a log statement, but hours to track down errors......you make the choice.

Use The Debugger!

Once you have logged into the community site with your username and password, you can find the debugger right there at the 'Account Overview' page. You can also open the debugger from anywhere within your account by using the top navigation bar and clicking 'Account', and then 'Application Debugger', as illustrated below:

The Voxeo debugger is your best friend when it comes to debugging your application. While at first, it may seem like your new friend speaks only Japanese, careful study will get you acclimated in what it has to say. Logger errors will show up in bold red, while any explanations for this error will show up in black. Debug, (log) statements will show up in green, making the logger your one stop source for all things in the color spectrum.

ANNOTATIONS: EXISTING POSTS

0 posts - click the button below to add a note to this page

Caching Techniques

| TOC

| The Voxeo Real Time Logger