The Meta Element

The Prophecy platform allows us a few edges over the other VoiceXML browsers when it comes to debugging options. When testing code on the Prophecy IVR platforms, you can specify an email address in your code so the platform can send error logs to you. This can be extremely useful for tracking problematic behavior on a deployed Production application; for instance if your app blows a gasket at 3 am and you don't want to have the application debugger open 24x7, this provides an excellent 'Lazy Mans' solution. To illustrate, let's look at some sample code:



<?xml version="1.0" ?>

<vxml version = "2.1">

 <meta name="maintainer" content="Me@MyEmailAddress.com"/>

 <meta name="speak_exceptions" content="true"/>

  <form>

    <block>

      <prompt>

       Hello World!

      </prompt>

    </block>

  <form>

</vxml>

Let's take into account three things in the above sample. First, you'll undoubtedly see that we have specified an email address to send error reports to. Second of all, we snuck in another <meta> option to speak the error type to the caller. Lastly, we have some bad code, where the <form> element is not properly closed. Naughty.

So what is going to happen when we give this app a ring? Well first off, we will get the audible error message that we loathe to hear, "Sorry, that content has an internal error". But, since we set "speak_exceptions" to 'TRUE', this will be followed by a TTS message stating that there was a parse error at www.MyServer.com, following with the specific details of the failure.

Then, a minute or two later, we will get an email that looks something like this:



============================================================

Error Summary

============================================================

An error occurred while executing the following dialog.



Initial URL:                file:///c:/nuance/callrouting/motnewcall.vxml

Current URL:                file:///c:/nuance/callrouting/motnewcall.vxml

Calling Number (ANI):       4071112222

Called Number (DNIS):       4072223333

Redirecting Number (RDNIS): ""

State:                      URL2

VoxGateway Version:         Load 123 (31 July 2003)

Date/Time:                  2008/8/5  22:16:16.510



(http://MyServer.com/MyApp.vxml? <SNIP>): The element type "form" must be terminated by the matching end-tag "</form>".



<SNIP>



VoiceException:

    error.semantic

    XML parse error(s) occurred in: http://MyServer.com/MyApp.vxml?



<SNIP>



Dialog stack trace:

    State (Dialog)          URL (Document)

    --------------          ------------------------------

    URL2                    file:///c:/nuance/callrouting/motnewcall.vxml



============================================================

Current Document

============================================================



<?xml version="1.0" ?>

<vxml version = "2.1">

<meta name="maintainer" content="Me@MyEmailAddress.com"/>

  <form>

    <block>

      <prompt> Hello World!</prompt>

    </block>

  <form>

</vxml>



============================================================

Session Log

============================================================

..

<SNIP>

..

===========================

An error occurred while executing the following dialog.



Initial URL:                file:///c:/nuance/callrouting/motnewcall.vxml

Current URL:                file:///c:/nuance/callrouting/motnewcall.vxml

Calling Number (ANI):       4071112222

Called Number (DNIS):       4072223333

Redirecting Number (RDNIS): ""

State:                      URL1

VoxGateway Version:         Load 123 (31 July 2003)

Date/Time:                  2003/8/5  22:16:13.526



VoiceException:

    error.semantic

    XML parse error(s) occurred in: http://MyServer.com/MyApp.vxml?

..

<SNIP>

..



Dialog stack trace:

    State (Dialog)          URL (Document)

    --------------          ------------------------------

    URL1                    file:///c:/nuance/callrouting/motnewcall.vxml



===========================

An error occurred while executing the following dialog.



Initial URL:                file:///c:/nuance/callrouting/motnewcall.vxml

Current URL:                file:///c:/nuance/callrouting/motnewcall.vxml

Calling Number (ANI):       4071112222

Called Number (DNIS):       4072223333

Redirecting Number (RDNIS): ""

State:                      URL2

VoxGateway Version:         Load 123 (31 July 2003)

Date/Time:                  2003/8/5  22:16:16.510



VoiceException:

    error.semantic

    XML parse error(s) occurred in: http://MyServer.com/MyApp.vxml?



<SNIP>



Dialog stack trace:

    State (Dialog)          URL (Document)

    --------------          ------------------------------

    URL2                    file:///c:/nuance/callrouting/motnewcall.vxml

 </log>

Obviously, the 'real' email has quite a bit more output, so we have trimmed down the information in order to make it more readable. You'll note that the gist of the problem is displayed in the very first section, (highlighted). It also displays the document that the error was encountered in, which makes it quite easy to skim over the code and match up the error message with the piece of problematic code. Now that we have covered the semantics for adding this to your code, we can look at a few more tweaks we can employ to custom-tailor the output.

Debug Flags

If you'd like a bit more control over what events will send an error email, then you have 2 options at your disposal. If you are looking to change this behavior application-wide, it is suggested that you simply use the <property name="com.mot.debugflags" value="X"/> setting in your root document. However, you can also use the <meta name="debug_flags" content="X"/> element value on a per-page level to fine-tune this. Appropriate values for both the <property> and the <meta> methods are detailed below:

Setting	Explanation
E	Character encoding related messages
P	Prints the current VoiceXML document on each listen for user input
T	TTS call information
b	Billing Messages
c	Cookie related messages
d	Document and dialog entry/exit messages
e	ECMAScript interpreter messages
f	Fetch messages
h	HTTP response header messages
p	Property change event messages
r	Speech recognition messages
s	Symbol table messages
w	Fetch work queue messages
x	Execution context messages
z	On each fetch, print out the contents of the fetch result
$	Print out performance cost messages, (Parse times, compilation times, fetch times)

So, how would this look in your code? Glad you asked:



    <meta name="debug_flags" content="$"/>

OR:



    <property name="com.mot.debug_flags" value="$"/>

When initially developing an application, chances are that you won't need to set any custom values to the debugging levels. However, once you are running live traffic, you will want to have a finer grain of control over what messages the Prophecy platform sends to your email address; the potential to fill up an inbox with system messages is a very real possibility in the event of an application failure with hundreds of users involved. Consider yourself warned, use this <meta maintainer> feature judiciously.

ANNOTATIONS: EXISTING POSTS

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

General Debugging Techniques

| TOC

| The Voxeo Real Time Debugger