Cisco Cisco Unified Customer Voice Portal 10.5(1) Developer's Guide
C
HAPTER
9:
C
ONFIGURABLE
E
LEMENTS
V
OICE
XML
P
ROGRAMMING
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
49
The voice element cannot use a
<submit>
or
<goto>
to link to a VoiceXML page external to
the VoiceXML Server. When it is time to return to the voice element in a VoiceXML page, a
URL pointing back to the VoiceXML Server must be used. This is required by the design
using the VoiceXML 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 Unified CVP
application to an external application but only if steps are taken to properly end the
VoiceXML Server session first.
URL pointing back to the VoiceXML Server must be used. This is required by the design
using the VoiceXML 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 Unified CVP
application to an external application but only if steps are taken to properly end the
VoiceXML 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
Unified CVP VoiceXML Studio (or dynamically in a start of call action).
Unified CVP VoiceXML Studio (or dynamically in a start of call action).
VPreference
is a
VFC and is described in more detail in 0 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 VoiceXML Server logs is to store the appropriate
information within the VoiceXML and submit it back to the VoiceXML Server. Cisco
Unified CVP 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
VoiceXML Server User Guide for Cisco Unified Customer Voice Portal.
browser, the only way to record this in the VoiceXML Server logs is to store the appropriate
information within the VoiceXML and submit it back to the VoiceXML Server. Cisco
Unified CVP 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
VoiceXML Server User Guide for Cisco Unified Customer Voice Portal.
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.
on that browser.
Throw an
ElementException
where appropriate so an error logger event can be thrown.
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.
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>
or
<disconnect>
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
element in the call flow. If it must be done, use
<disconnect>
so that Unified CVP
VoiceXML Server can detect the hang-up and execute the on end call action. Using
<exit>
would cause the VoiceXML Server to not know the calls had ended, using up an VoiceXML
Server port until it times out on its own. This is obviously not a desirable situation.
Server port until it times out on its own. This is obviously not a desirable situation.