Cisco Cisco Customer Voice Portal Downloads Release Note

Page of 113
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) 
 
 
 
 
48 
RMI. Voice elements must extend 
VoiceElementBase
, action elements 
ActionElementBase
and decision elements 
DecisionElementBase
, all found in the 
com.audium.server.voiceElement
 package. These three base classes all extend a common 
base class for configurable elements, 
ElementBase
In order for Builder for Call Studio to identify the Java class representing the actual element (as 
opposed to another class lower in the class hierarchy or a standard element that also extends that 
class), a “marker” Java interface named 
ElementInterface
 must be implemented. Only those 
classes that implement this interface are shown in the Builder’s Element Pane. 
Each configurable element contains a single execution method in which the element performs its 
function. This method is called by VXML Server when that element is visited in the call flow. 
One can equate this method to the element’s 
main()
 method, it begins and ends there.  
One argument to the method is an instance of a Session API class. Aside from the standard 
functionality available in this class such as obtaining the ANI and setting element data, this API 
class can be used to obtain a Java object representing the element’s configuration. VXML Server 
automatically creates this configuration object with the data entered by the application developer 
in the Builder or made available through a dynamic configuration. The name of the execution 
method and the API class passed to it differ for each element type as do the classes encapsulating 
the element’s configuration. The execution method for decision and voice elements must return 
an exit state and the execution method for action elements do not return anything (since all action 
elements explicitly have a single exit state). 
The execution method for action and decision elements can throw an 
AudiumException
 while 
voice elements can throw an 
ElementException
. The developer would throw this exception if 
an error was encountered within the execution method that the developer wishes to end the call. 
A call that encountered this exception would then visit the error element (or the application-
specific error message if the error element was not defined), and the error message is placed in 
the error log including the exception’s full stack trace. 
The base class also includes various methods used to define the element’s configuration. These 
methods define everything from the element’s name to its possible exit states. These methods are 
essential for Builder for Call Studio to visually render the element and its configuration 
correctly. Custom elements will be indistinguishable from Unified CVP Elements within the 
Builder. The developer can choose as simple or complex a configuration as desired (or even no 
configuration at all, though it wouldn’t be very reusable). 
Note that element data generated by an element will be overwritten if that same element is 
visited again in the call flow. For example, a variable set by a voice element handling the main 
menu of an application will be reset the next time the main menu is visited. The activity log, 
however, is a historical account of the call, so would have all values of the element data. Should 
the developer wish to retain all data created by all visits to the element, they must build that into 
the element, such as creating new variables or appending the new value to an existing variable.