Cisco Cisco Customer Voice Portal Downloads 개발자 가이드
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
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.
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 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.
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.
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.