CallXML 2.0 Development Guide

| TOC

This documentation is for CallXML 2, which has been superceded by CallXML 3. The CallXML 2 language is not being updated any longer. CallXML 3, however, has many new features and is actively being enhanced. If you're writing a new CallXML application, you should use CallXML 3. Click here for the CallXML 3.0 documentation.

CallXML Debugging Techniques

To the uninitiated, writing a CallXML 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 <onerror/sendemail> element combinations. Adding these few simple lines of code to your CallXML 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:


        <onerror> 
        <sendemail from="Orwell@MinistryOfInformation.com"  
                      to="WinstonSmith@oceana.com" type="debug"> 
          Winston, we caught an error in our application.  Details follow... 
        </sendemail> 
      </onerror>

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 <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. While circumstances might dictate that you include a multiple <block> or <menu> structures in a single page, debugging an application is much easier when you are looking at a document with a single menu versus one that has thirty of them. 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 related. Next, check to see if our CallXML app mapped to a 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 CallXML 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 <playaudio>, <goto>, etc, elements point to an existing page.

Log Statements

Adding generous log statements that offer navigational information can tell us exactly where to look when our application goes belly-up. Add them everywhere in your code. When finished, go back and add even more of them.

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

E: Exceptions & Errors

| TOC

| The Voxeo Real Time Logger