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
7.0(1)
61
full description of how dependencies work. Configuring audio groups to depend on settings
works the same way as configuring settings to depend on other settings.
works the same way as configuring settings to depend on other settings.
The audio groups are arranged in sets by storing them in a
HashMap
Java collection. The keys of
the
HashMap
are the names of the audio group sets and the values of the
HashMap
are arrays of
AudioGroup
instances that belong to their set. The array represents the audio groups to display
within that set. The order specified in the array is the order they appear in the Builder.
String[] getAudioGroupDisplayOrder()
This method is provided for the developer to determine the order in which the sets of audio
groups appear in the Builder. The
groups appear in the Builder. The
String
array is a list of set names in the order in which they
should appear in the dropdown menu. The values must match those used as keys to the
HashMap
returned by the
getAudioGroups()
method.
Interaction Logging
As listed in one of the recommended guidelines, interaction logging is a Unified CVP-defined
mechanism for voice elements to record to the VXML Server logs the actions of a caller when
they are interacting with the voice browser. Many voice browsers have the ability to record
detailed logs of a phone call and a caller’s interaction with a VoiceXML page. These logs,
however, are stored on the voice browser, which may be inaccessible or at least difficult to
access. Additionally, logs on the VXML Server side and the browser side would need to be
cross-referenced in order to determine what happened in a particular call. It would be desirable to
store all pertinent information in one place, which is what the interaction logging attempts to do.
Interaction logging is stored in the application’s activity log, which already stores other
information such as the ANI and DNIS, what elements were visited in the call with what exit
states, element data, etc. While it does not have the fine level of detail that a browser log can
provide, interaction logging is sufficient for an administrator to determine what happened in a
call or a designer to calculate call statistics to aid in improving the application.
mechanism for voice elements to record to the VXML Server logs the actions of a caller when
they are interacting with the voice browser. Many voice browsers have the ability to record
detailed logs of a phone call and a caller’s interaction with a VoiceXML page. These logs,
however, are stored on the voice browser, which may be inaccessible or at least difficult to
access. Additionally, logs on the VXML Server side and the browser side would need to be
cross-referenced in order to determine what happened in a particular call. It would be desirable to
store all pertinent information in one place, which is what the interaction logging attempts to do.
Interaction logging is stored in the application’s activity log, which already stores other
information such as the ANI and DNIS, what elements were visited in the call with what exit
states, element data, etc. While it does not have the fine level of detail that a browser log can
provide, interaction logging is sufficient for an administrator to determine what happened in a
call or a designer to calculate call statistics to aid in improving the application.
Since VoiceXML is used to tell the voice browser how to interact with the caller, it must also be
used to keep track of the caller’s activity. The mechanism Unified CVP uses to do this is to
create a single VoiceXML variable in which all the interaction logging data is stored. As new
data becomes available, it is appended to the variable using a convention to delineate the data.
This variable is automatically defined in the VXML Server-generated root document; all the
voice element developer needs to do is append content to it. The variable is named
used to keep track of the caller’s activity. The mechanism Unified CVP uses to do this is to
create a single VoiceXML variable in which all the interaction logging data is stored. As new
data becomes available, it is appended to the variable using a convention to delineate the data.
This variable is automatically defined in the VXML Server-generated root document; all the
voice element developer needs to do is append content to it. The variable is named
audium_vxmlLog
, though a voice element developer should not use this name directly in their
code. Instead, they should use the Java constant
VXML_LOG_VARIABLE_NAME
, defined in
VoiceElementBase
to refer to the variable. The reason for this is that the VoiceXML variable
name is subject to change while the Java constant name is not. The Java constant will always
contain the name of this variable so the developer need not recompile their code if the
VoiceXML variable name changes.
contain the name of this variable so the developer need not recompile their code if the
VoiceXML variable name changes.