Cisco Cisco Unified Customer Voice Portal 10.5(1) Release Note

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) 

 

53 

generic decision elements as well. What makes a configurable decision element different is the 
fact that it defines a specific configuration, so the custom decision element must re-implement all 
the configuration methods rather than relying on the default implementation. Some of the default 
implementations, though, may be appropriate even for a custom decision element. For example, 
if the decision element creates no element data, the custom decision element need not implement 
the 

getElementData

 method as the default implementation is sufficient. 

The execution method, 

doDecision()

, receives an instance of the API class 

DecisionElementData

. This class belongs to the Session API and is used to access session 

information (See Chapter 3:  Session API for more on this API). In addition to providing access 
to session information, this API class is also used to return the decision element configuration 
that drives the functionality of the element. The 

getDecisionElementConfig()

 method in 

DecisionElementData

 returns a 

DecisionElementConfig

 object. VXML Server takes care of 

obtaining the appropriate configuration and returning it in this method, whether or not the 
configuration is dynamic. The element need not worry about where the configuration came from. 

DecisionElementConfig

 is almost a direct extension of the base 

ElementConfig

 class. It is 

kept separate for future differentiation.  

Voice elements are more complex custom elements because they are responsible for producing 
VoiceXML pages to send to the voice browser. The execution method for voice elements 
contains more arguments and the voice element class requires additional configuration methods 
to be implemented. Finally, while action and decision elements complete in one call of the 
execution method, a typical voice element requires multiple VoiceXML pages to be produced in 
a certain order determined at runtime. Voice elements, therefore, must have state management 
where other elements do not. 

It is important to understand how voice elements integrate with VXML Server and the voice 
browser to prepare the developer for constructing voice elements. Unlike a traditional static 
VoiceXML page or a script-generated VoiceXML page that is accessed directly from the voice 
browser, the system uses VXML Server as an abstraction layer between the voice browser and 
the voice element that produces the VoiceXML pages. This abstraction layer not only allows the 
developer to avoid coding to a specific browser, it also saves the developer from having to deal 
with HTTP request and response management. Each page the voice element produces is passed 
through VXML Server, which acts as the central access point for the voice browser. Each link 
for a new document specified in the VoiceXML page points back to VXML Server and VXML 
Server’ internal call flow data indicates which voice element it is currently visiting. All 
arguments passed by the voice browser through those links are sent by VXML Server to the 
voice element for it to manage. 

Each VoiceXML page generated by a voice element begins as a “shell” page that contains the 
VoiceXML VXML Server requires. The voice element then adds to this page any custom