Cisco Cisco Unified Customer Voice Portal 11.0(1) Developer's Guide
C
HAPTER
2:
C
ISCO
U
NIFIED
CVP
API
I
NTRODUCTION
V
OICE
XML
P
ROGRAMMING
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
3
The classes used to obtain and change environment information are referred to as the Session
API. All components receive an instance of one of the classes to act as the conduit between the
component and Unified CVP VoiceXML Server. The classes in the Session API are organized
into a hierarchy where the classes for each component add unique capabilities to the common
base with regards to what data is available to it and what it is allowed to modify.
API. All components receive an instance of one of the classes to act as the conduit between the
component and Unified CVP VoiceXML Server. The classes in the Session API are organized
into a hierarchy where the classes for each component add unique capabilities to the common
base with regards to what data is available to it and what it is allowed to modify.
When building a component, the design requires the component to implement a single execution
method Unified CVP VoiceXML Server uses to access the component. This method can be seen
as the “main” method for that component; it is where the VoiceXML Server leaves its context
and enters the component’s. It is this execution method that receives as a parameter a class
belonging to the Session API to provide the component access to environment information.
method Unified CVP VoiceXML Server uses to access the component. This method can be seen
as the “main” method for that component; it is where the VoiceXML Server leaves its context
and enters the component’s. It is this execution method that receives as a parameter a class
belonging to the Session API to provide the component access to environment information.
The execution method is used exclusively by Unified CVP VoiceXML Server. Two components,
custom configurable elements and Say It Smart plugins, require integration with Unified CVP
VoiceXML Studio. For those components, the API additionally requires methods that define how
to render it.
custom configurable elements and Say It Smart plugins, require integration with Unified CVP
VoiceXML Studio. For those components, the API additionally requires methods that define how
to render it.
For those components that need to produce VoiceXML (primarily configurable voice elements
and hotevents), Cisco Unified CVP provides another set of Java API classes called the Voice
Foundation Classes (VFCs). These classes act as an abstraction layer to VoiceXML and allow
Unified CVP components to work seamlessly on any supported voice browser. Building
VoiceXML using the VFCs is very much like building VoiceXML statically, except in a Java
environment.
and hotevents), Cisco Unified CVP provides another set of Java API classes called the Voice
Foundation Classes (VFCs). These classes act as an abstraction layer to VoiceXML and allow
Unified CVP components to work seamlessly on any supported voice browser. Building
VoiceXML using the VFCs is very much like building VoiceXML statically, except in a Java
environment.
The API Javadocs for Cisco Unified Customer Voice Portal contain detailed descriptions for
each of the classes in the Java API, including the Session API and the VFCs.
each of the classes in the Java API, including the Session API and the VFCs.
Design Considerations
A few notes on Unified CVP VoiceXML Server and how it interacts with custom components
written in Java are warranted. This information is important to keep in mind since how a
developer approaches the design of the components they wish to build is impacted by them:
written in Java are warranted. This information is important to keep in mind since how a
developer approaches the design of the components they wish to build is impacted by them:
Each application is run by the VoiceXML Server in its own separate classloader. The
classloader’s focus includes all Java classes found in the local application’s
java
folder, all
classes found in VoiceXML Server’
common
folder, and the other classes available in the
application server’s
CLASSPATH
. The advantage of this approach is that developers need only
worry about class name conflicts within an individual application. One consequence,
however, is that static class variables are static only within each application, even if they
appear in classes stored in
however, is that static class variables are static only within each application, even if they
appear in classes stored in
common
. Additionally, when an application is updated, a new
classloader is created for the application, replacing the previous one. This is not a problem
unless dealing with static variables, which would be reset once the application is updated.
While knowledge of classloaders is not required in order to know how to build custom
components, it can be useful to understand how classloaders work in Java to understand how
custom component code integrates with the VoiceXML Server.
unless dealing with static variables, which would be reset once the application is updated.
While knowledge of classloaders is not required in order to know how to build custom
components, it can be useful to understand how classloaders work in Java to understand how
custom component code integrates with the VoiceXML Server.