Cisco Cisco Customer Voice Portal Downloads Release Note
C
HAPTER
2:
Unified CVP
C
OMPONENTS IN
D
ETAIL
U
SER
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
37
decision elements within the framework of a voice application. The XML format is simple
enough for an application designer to enter within Builder for Call Studio without requiring
separate programming resources.
enough for an application designer to enter within Builder for Call 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 VXML 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.
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 VXML 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’”.
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
progressively looser since the first rule to be true will yield an exit state and no more rules are
tested.
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
progressively looser since the first rule to be true will yield an exit state and no more rules are
tested.