VoiceXML Debugging Techniques

To the uninitiated, writing a VoiceXML 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 standard method of debugging and tuning your app so that it behaves.

Modularize It!

While the term 'modularize' might be better suited to a G.W. 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 <form> structures within a single page, debugging an application is much easier when you are looking at a document with a single <form> 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 itself. Passing along any querystring parameters? You will want to open the full URL displayed in the debugger 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 Internet Explorer, 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 VoiceXML. Next, check to see if our VoiceXML application is mapped to a CallXML number in the Voxeo Account Manager. While we are at it, we should also make sure that our URL is correctly entered, with no extra spaces carried over from a hasty copy/paste operation. Yes, these are dopey mistakes to be certain, but they are as common as locking your keys in the car....it happens to everyone at one time or another.

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>, <subdialog> or <submit> elements point to an existing page. Also check your 'src' attributes for any <audio>, <grammar>, and <script> elements that you may have 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 debugger as a big fat error message, but for the myopic, we have included this suggestion here as well. Check especially for misspellings, and also be certain that your variables have the proper scope to be recognized in the script.

Log Statements

Adding generous log statements that offer navigational information can tell us exactly where to look when our application goes belly-up, as evidenced below:


<?xml version="1.0" encoding="UTF-8"?>

<vxml version="2.1">
 
 <meta name="maintainer" content="yourEmail@here.com"/>

<form id="F1">
  <block name="B_1a">
    <prompt> entering the first block in the first form</prompt>
    <log expr="' *** entering B_1a *** '"/>
    <goto next="#F2"/>
  </block>
</form>

<form id="F2">
  <block name="B_1">
    <log expr="' *** entering B_1b *** '"/>
 <goto next="BrokenPage.vxml"/>
  </block>
</form>
</vxml>

BrokenPage.vxml


<?xml version="1.0" encoding="UTF-8"?>

<vxml version="2.0">
<form id="F1">
  <block name="C_1">
    <log expr="' *** entering C_1 *** '"/>
    <goto next="BogusURL.vxml"/>
  </block>
</form>
</vxml>

If we were to run this code, we would get an error.badfetch when we entered the second document. However, if we watched the logger closely when we called, we will see from our debug statements that the last item executed was Block name "B_1b". By the process of elimination, this tells us that we have something wonky with our second document. Log statements are also very useful for tracking variable values throughout your application, and they don't cost you anything. Put lots of them 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.

Use the <meta maintainer> Feature!

If you add a single line of code to all your VoiceXML documents, you can save yourself hours, and I mean hours of 'blind' troubleshooting. We have an entire chapter devoted to this debugging technique, so we won't get too wordy here. In a nutshell, adding the <meta> tag just below our initial <vxml version="2.1"> declaration will programmatically email you an enormously detailed error log that you can use to determine where your application is failing. Map the below sample snippet, (making sure to specify your own email address), to get a taste:


<vxml version="2.1">
 
 <meta name="maintainer" content="YourEmail@Wherever.com"/>
 <form>
  <block>
   <log expr="Bogusvariable"/>
  </block>
 </form>
</vxml>

ANNOTATIONS: EXISTING POSTS

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

B: Debugging Techniques

| TOC

| The Motorola Meta Element