Cisco Cisco Unified Customer Voice Portal 11.0(1) Guía Del Usuario

Descargar
Página de 107
C
HAPTER 
2:
 
V
OICE
XML
 
S
ERVER 
C
OMPONENTS IN 
D
ETAIL
 
 
V
OICE
XML
 
S
ERVER 
U
SER 
G
UIDE 
 
 
 
FOR 
C
ISCO 
U
NIFIED 
C
USTOMER 
V
OICE 
P
ORTAL 
R
ELEASE 
4.0(1) 
 
 
 
 
 
24
Note that this class is used for notification purposes; it does not allow the call to recover from the 
error. Note also that there is no XML API equivalent for the on error notification; if done at all, it 
must be written in Java. 
Unified CVP XML Decisions in Detail 
Many commercial applications with decisions driven by business logic utilize an external rules 
engine to codify the definition of rules. These rules engines help describe the definition of a rule 
and then manage the process of making decisions based on the criteria at hand. Unified CVP 
VoiceXML Server bundles a rule engine in the standard installation and provides an XML data 
format for defining decision elements within the framework of a voice application. The XML 
format is simple enough for an application designer to enter within Unified CVP VoiceXML 
Studio without requiring separate programming resources. 
A detailed description of the structure of the XML format is warranted. The centerpiece of a rule 
is one or more expressions. An expression is a statement that evaluates to a true or false. In most 
cases, there are two parts (called terms) to an expression with an operator in between. The terms 
are defined by Unified CVP VoiceXML Server to represent all of the most common items one 
would want to base decisions on in a voice application such as telephony data, element or session 
data, times and dates, caller activity, user information, etc. The operators depend on the data 
being compared. For example, numbers can be compared for equality or greater than or less than 
while strings can be compared for equality or if it “contains” something. One kind of expression 
breaks this format: an “exists” expression which itself evaluates to a true or false and does not 
need anything to compare it to. For example: “has this caller called before?” or “does the system 
have a social security number for the user?” Each of these checks for the existence of something 
which is itself a complete expression. 
One or more of these expressions are combined to yield one exit state of the decision element. 
Multiple expressions can be combined using “ands” or “ors”, though not a combination. For 
example: “if the ANI begins with 212 OR if the ANI begins with 646 then return the exit state 
‘Manhattan’”. If a combination of “ands” and “ors” is desired, multiple expressions that return 
the same exit state would be used. For example, “if the ANI begins with 212 and the user is a 
gold or platinum customer, then return the exit state ‘discount’” would not work as a single rule 
because the discount would be given to callers with a 212 area code who are gold customers and 
all platinum customers (there is no way to set precedence). This would have to be expressed as 
two rules with the same exit state: 1) “if the ANI begins with 212 AND the user is a gold 
customer, return the exit state ‘discount’” and 2) “if the ANI begins with 212 AND the user is a 
platinum customer, return the exit state ‘discount’”. 
It is possible to define an exit state that returns when all other exit states fail to apply, called the 
default exit state. When not specified, all possible cases must be caught by the defined rules. For 
example, if a rule checks if a number is greater than 5, there should be another rule checking if 
the number is less than or equal to 5, unless the default exit state is defined. One can even create 
a set of rules that start from being restrictive, looking for only very specific matches, to