Debugger Features

You have the debugger open, but you can't decipher those funky messages that it is outputting? You can use the below guide as your Japanese interpreter, and help you figure out what the heck is going on with your application. First off, let's take a look at the debugger itself, shall we?

Send Results

At the top left of our window, you will notice that we have the option to send the logs to support for clinical analysis. Feeling wordy? Please give us some commentary about how your application is behaving, such as a simple walkthrough describing how we can recreate your errors.

If you include all 30,000+ lines of your log results to us, or if you have a slow connection, chances are good that this feature will time out on you. Try to send in only log files for one call, not the previous 20 attempts at testing the app.

Filters

Through this tab in the logger, we have the option to filter out CallXML or VoiceXML logging that might be running in your account at the same time as your testing. To further simplify things, we can click on the sessionID value in the output itself so that only log results for that session are displayed. We also have the option to show the full-bore output of the logs, through the 'show verbose logging' checkbox.....we currently have logging levels turned way down so as to minimize the extraneous output, but in some cases you may wish to see the complete, unfiltered output.

Debugger Command Bar

When testing a VoiceXML, CallXML, or Call Control XML application and using the debugger, we have even more features that we can utilize to make our lives easier. Notice that when you place a call with the debugger window open, a value will appear in the upper left pane for each active call we have. We can then select these calls on a per-session basis by clicking on this section, and utilize the debugger command console to interact with your application and debug mid-call.

We can pause, start, and stop your application mid-call, or we can also use the controls to send a specific event to a CCXML application, or grab the current document that is being processed by using the specific buttons detailed below:

"Stop" Clicking this button while a call is active allows you to stop the session specified, (i.e. remotely hang up the call). This is useful if you code yourself into a looping application.

"Pause" Clicking this command button allows to you pause application execution on an active call. This is useful for hunting down a particular debugger message, and is even more handy for coffee/cigarette breaks. Just don't let the Boss catch you.

"Play" This button only comes into action when we have a call session that is paused. Clicking this button allows you to continue with a formerly paused call session, resuming from the point in which it was last interrupted.

"Step" After pausing an application, you may wish to allow it to run 'step-by-step' so that you can watch the application's behavior more closely. Using this debugger command button will allow you to 'un-pause' the application so you may give it a single input, or allow it to execute the very next prompt or recognition state before pausing again.

"Get Variables" Possibly the most useful of all the command buttons, clicking this button will bring up a new window which shows any and all session, application, and user-defined variables that are available in the current call session.

"Get Current Document" This command button allows you to view the current XML document as the interpreter sees it. This is especially useful when attempting to view the XML output by the target of a POST, for instance.

"Send Event" This somewhat specialized button is only applicable when running a CCXML or a CallXML application. Clicking on this button will open a pop-up that allows you to specify a particular event to send to the application. For instance, if a CCXML application is running, one could pause the call, and then specify that an 'error.dialog.notstarted' event be thrown to the application in order to check that the appropriate event handlers are working correctly.

Are You Authorized?

If you decide to take a coffee break, or you simply want to check out the season finale of 'Fresh Prince Of Bel Aire', be advised that your debugger session, as well as your Voxeo Account Manager session might well time out, and you will see the ominous message "you must be authorized to view logging". If this happens, you will have to re-enter your username and password to resume your application testing.

Not Getting Any?

You do have the ability to programmatically turn the debugger output on and off within your code. If you have sensitive infomation being passed within your app that you would just as soon keep secret, you can turn the output off to protect this data from prying eyes. Simply add the below snippet to your code to turn the logger off:


<voxeo:logcontrol mode="disable"/>

And to turn it back on again within your code, add this command:


<voxeo:logcontrol mode="enable"/>

"Error 'xxx'" messages

When dialing into a failing application, you will undoubtedly get an error message in the real-Time Logger. In addition, you will heara Voxeo-specific error message stating the internal failure code. Do not be fooled, the truly helpful debugging messages are contained in the Logger output itself. However, for the curious, we list the auditory error messages and what they translate to here for your convenience.

Audible CCXML Error Messages:

Error 6 0 1. the application U R L could not be located.
Error 6 0 2. the primary and secondary application U R ells could not be located.
Error 6 0 3. the primary, secondary, and tertiary application U R ells could not be located.
Error 7 0 7. The application startup could not be completed.
Error 3 0 4: the application you are trying to reach is not available at this time.

What they mean:

Errors 601 through 6-3 are self-explanatory. The initial URL of the application could not be fetched for some reason. The application thus fails.
Error 707 is the generic "catch-all" error for the CallXML Router. It can mean something is failing on the CallXML browser itself or the redirect number failed to transfer, etc. Often there will be no logging visible in the logging stream when this error is tossed.
The 304 error has traditionally been worded differently, but is essentially a message that crops up when someone has called a phonenumber that is mapped as "CCXML" in the database, but has no actual application attached to it. Again, no logging will be visible.

Audible VXML Error Messages:

Error 6 2 6: the application URL could not be located.
Error 6 2 7: the primary and secondary application URLs could not be located.
Error 6 2 8: the primary, secondary, and tertiary application URLs could not be located.
Error 6 3 0: Application URL could not be reached and Redirection failed.
Error 3 0 6: the application you are trying to reach is not available at this time.

What they mean:

Errors 626 through 628 are self-explanatory. The initial URL of the application could not be fetched for some reason. The application thus fails.
The 306 error has traditionally been worded differently, but is essentially a message that crops up when someone has called a phonenumber that is mapped as "VoiceXML" in the database, but has no actual application attached to it.

Stay tuned, and we will dissect even more logger messages in the very near future!

ANNOTATIONS: EXISTING POSTS

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

The Motorola Meta Element

| TOC

| Prophecy Debugger Key