Cisco Cisco Unified Customer Voice Portal 11.0(1) Developer's Guide
C
HAPTER
9:
C
ONFIGURABLE
E
LEMENTS
C
ISCO
CVP V
OICE
XML 3.1
Programmer
Guide
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
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
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 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.
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
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.
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 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 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 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 Server and the 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 Server to the voice element for it to manage.
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 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 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 Server and the 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 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 Server requires. The voice element then adds to this page any custom VoiceXML
content desired before passing it back to the Server to send to the voice browser. Most voice
VoiceXML the Server requires. The voice element then adds to this page any custom VoiceXML
content desired before passing it back to the Server to send to the voice browser. Most voice
Copyright 2001 - 2005 Audium Corporation. All Rights Reserved. 10/05
54