Debugging
Last updated
Last updated
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. Script validation will check your vxml application for any out of place or mismatched elements to quickly let you know any simple semantic issues that may have been overlooked. 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:
Script Validation also applies to hosted application using a remote URL. In the application configuration menu of your hosted remote application (see image below) you can click “Validate” to validate your application code. If there were no errors in your remote script, you would see the following output when running Validation:
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, your first resource is the call logs for your application. To view your call logs, you can either navigate to the “Application Configuration”(which will allow you to quickly find the call log of the last call made to an application) page by clicking “Applications” to bring up the application settings menu and then clicking “Application Configuration” or you can navigate to the “Recent Call” page which will contain the logs of all calls made to or by your application for the past five days by clicking “Call Logs” to bring up the call logs menu and then clicking “Recent Calls”:
In the “Application Configuration” manu, clicking “View Log” in the “Last Call” column for the application will bring you to the call log for the last call made to or by this application.
In the “Recent Calls” menu, you can search for a call log by searching the ANI(source number) or DNIS(destination number) in the “Search” textbox or you can simply navigate the pages of call logs using the first, previous, next, and last navigation buttons. Once you have found the call you are looking for, clicking “View Log” in the “Call Log” column will bring you to the full call log for that specific call.
Once you have clicked “View Log” to bring you to the full call log, it should look similar to the following:
Once you're in your Call Log, you will be able to see all events which occurred in the call. Helpfully, any errors in your application will be marked in red.
The error in your call log could be a number of different types, but for each error type there will be some information specifying what went wrong in the 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 Plum DEV 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 Plum DEV. 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”.
If you are using a SOAP WSDL, there is a validation tool that you can use to check for errors. Here's a link to the validation tool: http://www.plumvoice.com/soaptester/.
