Cisco Cisco Unified Customer Voice Portal 11.0(1) Developer's Guide

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 

4.1(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.  

•

 

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. 

Once a component is constructed in Java, the process for compiling and deploying these classes 
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 

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. 

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.