Cisco Cisco Customer Voice Portal Downloads Guía Del Desarrollador
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)
4
An application is loaded into memory when the VoiceXML Server first starts up or the
application is updated. During this process, a single instance of each element (both standard
and configurable) is created and cached for the application to use. Whenever a call to that
application encounters an element, the VoiceXML Server will call the execution method of
that single instance. This means that a single element instance will handle requests made
across all calls to the application. This applies to multiple uses of an element type in the call
flow (e.g. if the call flow contains two Digits elements, the VoiceXML Server will actually
use the same instance for both across all calls). This is very important because in this design,
the element class acts as if it is static. The consequence of this is that all member variables
defined in the element class act as static variables, meaning that once changed, every caller
experiencing that element type is exposed to the same value. It is highly recommended to use
only static final member variables, store any persistent data in the session (which the API
provides access to), and keep all other variables local to the execution method. Everything an
element needs is provided by the API so while this is important to be aware of, this design
restriction should not prevent the developer from implementing any desired functionality
within the element.
and configurable) is created and cached for the application to use. Whenever a call to that
application encounters an element, the VoiceXML Server will call the execution method of
that single instance. This means that a single element instance will handle requests made
across all calls to the application. This applies to multiple uses of an element type in the call
flow (e.g. if the call flow contains two Digits elements, the VoiceXML Server will actually
use the same instance for both across all calls). This is very important because in this design,
the element class acts as if it is static. The consequence of this is that all member variables
defined in the element class act as static variables, meaning that once changed, every caller
experiencing that element type is exposed to the same value. It is highly recommended to use
only static final member variables, store any persistent data in the session (which the API
provides access to), and keep all other variables local to the execution method. Everything an
element needs is provided by the API so while this is important to be aware of, this design
restriction should not prevent the developer from implementing any desired functionality
within the element.
The VoiceXML Server runs in a multi-threaded environment. If the guidelines above are
followed, such as avoiding member variables and non-final static variables this does not pose
a problem. The developer does not need to worry about architecting their code with
synchronization in mind when dealing with local or session variables. They would, however,
when performing tasks such as accessing external resources such as files.
a problem. The developer does not need to worry about architecting their code with
synchronization in mind when dealing with local or session variables. They would, however,
when performing tasks such as accessing external resources such as files.
Compiling Custom Java Components
Once a component is constructed in Java, the process for compiling and deploying these classes
is very simple. The VoiceXML Server
is very simple. The VoiceXML Server
lib
directory includes JAR files containing everything a
developer requires to compile custom components. The main JAR file of interest is
framework.jar
, which defines the entire Unified CVP Java API (including the VFCs). To create
custom components, all that is needed is to ensure that this JAR file appears in the compiler’s
CLASSPATH
or referred to in a Java IDE project file. Some Java IDEs may require additional JAR
files,
servlet.jar
and
xalan.jar
, to appear in the
CLASSPATH
since the classes within
framework.jar
refer to classes defined in those JAR files and these IDEs cannot compile
without definitions for these additional classes. The command-line Java compiler does not
require
require
servlet.jar
or
xalan.jar
to appear in the
CLASSPATH
. The developer is then
responsible for adding to the
CLASSPATH
any additional JAR files their custom code requires.
Deployment
Once compiled, component class files are deployed separately for Unified CVP VoiceXML
Studio and Unified CVP VoiceXML Server. Within these deployments, a developer can choose
to associate component classes with a specific application or with the system as a whole so that
the components can be shared across all applications. The deployment process for VoiceXML
Studio and the VoiceXML Server are described in the following sections. A third section
provides details on the specific deployment directories developers should use.
Studio and Unified CVP VoiceXML Server. Within these deployments, a developer can choose
to associate component classes with a specific application or with the system as a whole so that
the components can be shared across all applications. The deployment process for VoiceXML
Studio and the VoiceXML Server are described in the following sections. A third section
provides details on the specific deployment directories developers should use.