Cisco Cisco Customer Voice Portal Downloads 开发者指南
C
HAPTER
9:
C
ONFIGURABLE
E
LEMENTS
P
ROGRAMMING
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
R
ELEASE
4.1(1)
52
•
The voice element cannot use a
<submit>
or
<goto>
to link to a VoiceXML page external to
VXML Server. When it is time to return to the voice element in a VoiceXML page, a URL
pointing back to VXML Server must be used. This is required by the design using VXML
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 a Unified CVP application to an
external application but only if steps are taken to properly end the VXML Server session
first.
pointing back to VXML Server must be used. This is required by the design using VXML
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 a Unified CVP application to an
external application but only if steps are taken to properly end the VXML 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
Builder for Call Studio (or dynamically in a start of call action).
Builder for Call 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 VXML Server logs is to store the appropriate
information within the VoiceXML and submit it back to VXML Server. 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 User Guide for
Cisco Unified CVP VXML Server and Cisco Unified Call Studio.
VoiceXML pages produced by voice elements. Since this activity occurs on the voice
browser, the only way to record this in the VXML Server logs is to store the appropriate
information within the VoiceXML and submit it back to VXML Server. 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 User Guide for
Cisco Unified CVP VXML Server and Cisco Unified Call Studio.
•
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.
that using browser-specific functionality will prompt that element to function correctly only
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 VXML Server can
detect the hang-up and execute the on end call action. Using
<exit>
would cause VXML
Server to not know the calls had ended, using up an VXML Server port until it times out on
its own. This is obviously not a desirable situation.
its own. This is obviously not a desirable situation.