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 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 Studio.

String[] getAudioGroupDisplayOrder()

This method is provided for the developer to determine the order in which the sets of audio
groups appear in Studio. 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 an CVP VoiceXML-
defined mechanism for voice elements to record to the CVP VoiceXML 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 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 Cisco CVP VoiceXML 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 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.

Once a VoiceXML page is visited and the

audium_vxmlLog

variable is filled with content, it

must be passed back to the Server for parsing to place in the activity log. This means that every
submit back to the Server must include this variable as an argument. If the voice element uses the

getSubmitURL()

method to obtain the submit URL,

audium_vxmlLog

must be explicitly added