Cisco Cisco Unified Customer Voice Portal 11.0(1) User Guide
C
HAPTER
2:
V
OICE
XML
S
ERVER
C
OMPONENTS IN
D
ETAIL
V
OICE
XML
S
ERVER
U
SER
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
40
Unified CVP VoiceXML Server requires the elapsed time from the start of the element, not the
page. So, in VoiceXML, the line to appear must look like:
page. So, in VoiceXML, the line to appear must look like:
<assign name="audium_element_start_time_millisecs" expr="new Date().getTime()" />
For best results, this should appear as early as possible in the first page, preferably in a
<block>
in the first
<form>
of the page, certainly before any additional logging is done.
In VoiceXML, setting the value of an existing variable requires the
<assign>
tag. Since the
expression contains a Javascript function, the
expr
attribute must be used. Additionally, in order
to avoid overwriting previous log information, the expression must append the new data to the
existing content of the variable. For example, to add to the interaction log the fact that the xyz
audio group was played, the VoiceXML line would look like
existing content of the variable. For example, to add to the interaction log the fact that the xyz
audio group was played, the VoiceXML line would look like
<assign name="audium_vxmlLog" expr="audium_vxmlLog + '|||audio_group$$$xyz^^^'
+application.getElapsedTime(audium_element_start_time_millisecs)"/>
+application.getElapsedTime(audium_element_start_time_millisecs)"/>
In another example, the utterance of a field named xyz is to be appended to the log. The
VoiceXML would look like
VoiceXML would look like
<assign name="audium_vxmlLog" expr="audium_vxmlLog +'|||utterance$$$'+ xyz.$utterance
+ '^^^' + application.getElapsedTime(audium_element_start_time_millisecs)"/>
+ '^^^' + application.getElapsedTime(audium_element_start_time_millisecs)"/>
See Chapter 5: VoiceXML Server Logging for more detail about Unified CVP logging.
Root Document
The subdialog context written by the developer must refer to a Unified CVP-generated root
document. This is essential for proper integration of the VoiceXML insert element with Unified
CVP VoiceXML Server. The root document call must look like:
document. This is essential for proper integration of the VoiceXML insert element with Unified
CVP VoiceXML Server. The root document call must look like:
“/CVP/Server?audium_vxml_root=true&calling_into=APP&
namelist=element_log_value|RTRN1|RTRN2|…
namelist=element_log_value|RTRN1|RTRN2|…
”
Where APP is the application name and RTRNX represent the names of all the element data,
session data, and custom log entries (delimited by ‘|’ characters) the insert element returns, using
the same naming convention described in the outputs section above.
session data, and custom log entries (delimited by ‘|’ characters) the insert element returns, using
the same naming convention described in the outputs section above.
The purpose for this requirement is related to how events are handled within the root document.
The Unified CVP-generated root document catches events such as the activation of a hotlink or a
hangup, which then requires the call flow to leave the insert element. The insert element,
however, may have created element and session data or added custom content to the log. This
information is stored in VoiceXML variables that would be deleted once the subdialog context is
exited. So the root document needs to be told which VoiceXML variables to send along to
Unified CVP VoiceXML Server when one of these events is triggered so that it can store them
accordingly. In order to avoid problems that might occur if a hotlink or hotevent was activated
right after the insert element began the variables to be returned should be declared as near the
start of the VoiceXML insert element as possible, even if they are not assigned initial values.
The Unified CVP-generated root document catches events such as the activation of a hotlink or a
hangup, which then requires the call flow to leave the insert element. The insert element,
however, may have created element and session data or added custom content to the log. This
information is stored in VoiceXML variables that would be deleted once the subdialog context is
exited. So the root document needs to be told which VoiceXML variables to send along to
Unified CVP VoiceXML Server when one of these events is triggered so that it can store them
accordingly. In order to avoid problems that might occur if a hotlink or hotevent was activated
right after the insert element began the variables to be returned should be declared as near the
start of the VoiceXML insert element as possible, even if they are not assigned initial values.