Cisco Cisco Customer Voice Portal 8.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) 

 

 

 

46

 

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. The VoiceXML 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 Unified CVP VoiceXML 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 the VoiceXML 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 the VoiceXML 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 the VoiceXML Server and the VoiceXML 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 the VoiceXML 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 the VoiceXML Server requires. The voice element then adds to this page any custom 
VoiceXML content desired before passing it back to the VoiceXML Server to send to the voice 
browser. Most voice elements will require multiple pages, the content of each depending on the 
actions of the caller. When a voice element is done producing VoiceXML pages, it returns an 
appropriate exit state so the VoiceXML Server can visit the next element according to the call 
flow. As long as the proper VoiceXML is passed back through the execution method, the 
developer is free to do anything allowed by Java, including creating helper classes, accessing 
backend systems, etc.