Cisco Cisco Unified Customer Voice Portal 11.0(1) Developer's Guide

HAPTER

ONFIGURABLE

LEMENTS

ISCO

CVP V

OICE

XML 3.1

Programmer

Guide

•

The voice element cannot use a

<goto>

to link to a VoiceXML page external to

the Server. When it is time to return to the voice element in a VoiceXML page, a URL
pointing back to the Server must be used. This is required by the design using the Server as
the abstraction layer between the voice browser and the voice element. The only exception to
this rule allows for the call to continue from an CVP VoiceXML application to an external
application but only if steps are taken to properly end the Server session first.

•

The VoiceXML

<form>

the developer wishes the browser to visit first must be named

“start”.

•

The voice element must obtain the

VPreference

object to use in all VFC constructors by

calling the

getPreference()

method in

VoiceElementData

. This

VPreference

object

contains, among other things, the voice browser choice made by the application designer in
CVP VoiceXML Studio (or dynamically in a start of call action).

VPreference

is a VFC and

is described in more detail in Appendix A: The Voice Foundation Classes.

VoiceElementData

is described in more detail in the following sections.

Recommendations

•

The interaction category of the activity log is used to record the activity of callers within the
VoiceXML pages produced by voice elements. Since this activity occurs on the voice
browser, the only way to record this in the Server logs is to store the appropriate information
within the VoiceXML and submit it back to the Server. Cisco CVP VoiceXML defines an
interaction logging convention for recording caller behavior within the VoiceXML. By
conforming to this convention, the developer ensures that the activity log will contain the
detail expected for application testing and reporting. While interaction logging is not required
in a custom voice element, not performing logging will reveal nothing about what the callers
did within the element. See the section entitled “Interaction Logging” in this chapter for
more. A full description of the activity log can be found in Chapter 5 of the User Guide.

•

Try to produce VoiceXML that conforms to the VoiceXML specifications, understanding
that using browser-specific functionality will prompt that element to function correctly only
on that browser.

•

Throw an

ElementException

where appropriate so its message can be reported in the error

log. Exceptions should indicate the voice element encountered a situation which prevents it
from doing its assigned task. Non-fatal exceptions should be caught within the voice element
(and possibly linked to exit states) and warnings placed in the error log.

•

Do not end the call in the voice element manually using the

<exit>

tags.

Instead, exit the voice element with a specific exit state that can then be linked to a hang-up
element in the call flow. If it must be done, use

so that CVP VoiceXML

Server can detect the hang-up and execute the on end call action. Using

<exit>

would cause

the Server to not know the calls had ended, using up an Server port until it times out on its
own. This is obviously not a desirable situation.

•

A voice element can add any Java object to scratch space via the

setScratchData()

method

VoiceElementData

. Scratch data is used for voice element internal uses only since the