Cisco Cisco Unified Customer Voice Portal 10.5(1) Guida Dello Sviluppatore

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) 

 

 

4 

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 VXML 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 VXML Server uses to access the component. This method can be seen as the “main” 
method for that component; it is where VXML 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 VXML Server. Two components, custom 
configurable elements and Say It Smart plugins, require integration with Builder for Call 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), 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 contain detailed descriptions for each of the classes in the Java API, including 
the Session API and the VFCs.  

A few notes on VXML Server and how it interacts with custom components written in Java is 
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 VXML 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 VXML Server’s 

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 

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