Plum Voice Platform v. 3.0
© 2008 Plum Group, Inc. All rights reserved.
While developing your application, you will inevitably run into errors. You can use a combination of our syntax validator and our call log tools to accelerate your debugging efforts.
Script validation is useful for catching common VoiceXML errors before calling into the VoiceXML application. For instance, let's create a VXML script using a scratchpad:
When you finish creating your script, you could click the "Validate" button to check the syntax of your VXML code. If your syntax is correct, you will see the message, "This document is valid VoiceXML".
Let's introduce a syntax error into the script by removing the </block> closing tag. When you click "Validate", you would see the following:
By putting in the URL of your remote script and clicking "Validate", you would see the following if there are no errors in your script:
If there was an error in your remote script, you might see the following:
Thus, the validator tool is useful at finding syntax errors and telling you exactly where the error is located before you even pick up a phone.
The validator will only help you find syntax errors. It will not help you fix syntactically sound but poorly programmed VXML code. For example, if your application was returning a male voice instead of a female voice, the validator would not help you find this error.
To debug programming errors, you would first look at your call log for where your error is occurring. To do this, first go to your "Application Setup" or "Call Activity" page:
Next, click "Last" under the "Last Log" column if you are in Application Setup or click "Last Log" if you are in Call Activity for the application with the error. This will bring you to the Call Log of your application. The Call Log of your application would look like this:
Once you're in your Call Log, the error in your application will be marked in red.
This error in your Call Log will explain what is wrong with your application.
One common error that you will encounter is the error.badfetch prompt during a phone call. The error would look like this in your call log:
This error means that that the document trying to be fetched does not exist. To fix this error, make sure that you check that the file you are specifying to be fetched does exist. Another example of this error is with bad VXML. For example, if you used the <goto> tag and tried to go to a <field> or <form> that did not exist, you would get an error.badfetch. Here's an application that demonstrates that example:
The call log would then look like this:
In this case, the call log tells you that there is a non-existent dialog, '#mainmenu'. Since the application tries to go to menu id, "mainmenu", and the actual menu id is "mainmenus", an error.badfetch.baddialog occurs. To fix this error, make sure that your spelling is correct when you are trying to go to another <form>, <field>, or <menu> element.
Another common error that will occur during a phone call is error.semantic.ecmascript. This error occurs when there is an error with the ECMAScript. For example, if you had an <if> tag that referred to a variable instead of a string and the variable did not exist, an error would occur. Here is an application that demonstrates that error:
The error would look like this in your error log:
Since we are missing single quotes around "Lassie" in our <if> tag, the application tries to look for the variable Lassie instead of the string "Lassie". Thus, the call log returns an error that states that Lassie is not defined and issues an error.semantic.ecmascript. To fix this error, make sure that you use single quotes when referring to a string and don't use them when referring to a variable.
Finally, the most common error that might occur for you is a server side script error. This error would occur if there was a problem with your application script. In your call log, this error would look like:
From this error, you can see that there is a parse error in the file. By clicking on "Click here to view saved VoiceXML script", you can see the contents of the file returned by your web browser:
Please keep in mind that you can only view saved VoiceXML scripts for your most recent call. Older call logs do not have saved VoiceXML scripts.
Remote errors in the server script often generate HTML based error messages. These error messages cannot be parsed by the VoiceXML platform and will result in an error.badfetch. As you can see above, viewing the saved script allows you to see the remote error that was received by the browser. To avoid seeing this error, make sure that the server script has no error before making a call into the VoiceXML platform. For example, let's take a sample application:
We could view this application in a web browser first to see if it returns what we would expect.
In our web browser, we can see that it returns valid VoiceXML to us with a string of "false" as we defined in our php for the VXML variable "asdf".