Cisco Cisco Unified Customer Voice Portal 11.0(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) 

 

 

 

54

 

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

String[] getAudioGroupDisplayOrder() 

This method is provided for the developer to determine the order in which the sets of audio 
groups appear in VoiceXML 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. 

As listed in one of the recommended guidelines, interaction logging is a Unified CVP-defined 
mechanism for voice elements to record to the Unified 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 VoiceXML 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 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 VoiceXML 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 VoiceXML Server for parsing to place in the activity log. This means 
that every submit back to the VoiceXML Server must include this variable as an argument. If the 
voice element uses the 

getSubmitURL()

 method to obtain the submit URL, 

audium_vxmlLog