Cisco Cisco Unified Customer Voice Portal 10.0(1) Release Note
C
HAPTER
2:
U
NIFIED
CVP
API
I
NTRODUCTION
P
ROGRAMMING
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
R
ELEASE
7.0(1)
5
•
An application is loaded into memory when VXML 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, VXML 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, VXML 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.
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, VXML 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, VXML 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.
•
VXML 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.
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.
Compiling Custom Java Components
Once a component is constructed in Java, the process for compiling and deploying these classes
is very simple. The VXML Server
is very simple. The VXML 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 Call Studio and VXML
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 Call Studio and VXML Server are described in the
following sections. A third section provides details on the specific deployment directories
developers should use.
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 Call Studio and VXML Server are described in the
following sections. A third section provides details on the specific deployment directories
developers should use.