Cisco Cisco Customer Voice Portal 8.0(1) Release Note

Page of 152
C
HAPTER 
1:
 
I
NTRODUCTION
 
 
U
SER 
G
UIDE FOR 
C
ISCO 
U
NIFIED 
CVP
 
VXML
 
S
ERVER 
 
 
 
AND 
C
ISCO 
U
NIFIED 
C
ALL 
S
TUDIO
 
 
 
 
11 
provided to allow seamless integration of VoiceXML insert elements with the rest of the call 
flow. 
The use of VoiceXML insert elements has its consequences such as the loss of being able to 
seamlessly switch between different voice browsers, some greater processing overhead involved 
with integration with the rest of the call flow, as well as the added complexity of dealing with 
VoiceXML itself rather than creating an application with easy to use configurable elements. 
VoiceXML insert elements can have as many exit states as the developer requires, with a 
minimum of one. 
Decision Elements 
Even the simplest voice applications require some level of decision making throughout the call 
flow. These “crossroads” are encapsulated in decision elements.  
Decision Element 
Encapsulates business logic that make decisions with at least two exit 
states. 
A decision element is like a traffic cop, redirecting the flow of callers according to built in 
business rules. Examples of business rules include decisions such as whether to play an ad to a 
caller, which of five different payment plans should be offered to the caller, or whether to 
transfer a caller to an agent or hang up. 
The results of a decision element are represented as exit states. Although many decisions are 
boolean in nature, (e.g. “has the caller registered?”, “is the caller new to the application?”), 
decision elements can have as many exit states as desired, as long as at least two are specified. 
The configuration for a configurable decision contains two components: settings and variables. 
Additionally, the Java class that defines the configurable decision sets the exit states it can return 
and the designer must map each exit state to another call flow component to handle all its 
consequences. 
Action Elements 
Many voice applications require actions to occur “behind the scenes” at some point in the call. In 
these cases, the action does not produce VoiceXML (and thus has no audible effect on the call) 
or perform some action that branches the call flow (like a decision).  Instead the action makes a 
calculation, interfaces with a backend system such as a database or legacy system, stores data to 
a file or notifies an outside system of a specific event. All of these processes are built into action 
elements
Action Element 
Encapsulates business logic that performs tasks not affecting the call 
flow (i.e., has only one exit state).