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) 

 

 

 

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.  

    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. 

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

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