Cisco Cisco Customer Voice Portal Downloads Guía Del Desarrollador
C
HAPTER
6:
D
YNAMIC
E
LEMENT
C
ONFIGURATIONS
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)
27
Chapter 6: Dynamic Element
Configurations
Configurable voice, action, and decision elements used in an application must have
configurations. Usually, the configuration will be fixed, i.e., it acts the same every time a caller
visits it. In this case, the configuration itself exists as an XML file stored on the system. Builder
for Call Studio creates this file when the application is deployed. Programming is required when
a dynamic element configuration is desired, i.e., one which is generated at runtime each time a
caller visits it.
configurations. Usually, the configuration will be fixed, i.e., it acts the same every time a caller
visits it. In this case, the configuration itself exists as an XML file stored on the system. Builder
for Call Studio creates this file when the application is deployed. Programming is required when
a dynamic element configuration is desired, i.e., one which is generated at runtime each time a
caller visits it.
The manner in which configurations are used warrant closer examination. Configurations are
used by pre-built elements in order to tell it how to function. Since configurable elements are
constructed with Java, the configuration for the element must be given to it in the form of a Java
class. The API provides a set of Java classes that encapsulate an entire element configuration,
which are nothing more than just Java expressions of the visual Builder for Call Studio’s
Configuration Pane: three tabs General, Settings, and Data for action and decision elements and
a fourth tab, Audio, for voice elements. When a static configuration is used, this information is
stored as an XML file generated by Builder for Call Studio. VXML Server converts this XML
file to one of the Java configuration classes and then passed it on to the element.
used by pre-built elements in order to tell it how to function. Since configurable elements are
constructed with Java, the configuration for the element must be given to it in the form of a Java
class. The API provides a set of Java classes that encapsulate an entire element configuration,
which are nothing more than just Java expressions of the visual Builder for Call Studio’s
Configuration Pane: three tabs General, Settings, and Data for action and decision elements and
a fourth tab, Audio, for voice elements. When a static configuration is used, this information is
stored as an XML file generated by Builder for Call Studio. VXML Server converts this XML
file to one of the Java configuration classes and then passed it on to the element.
A dynamic configuration is simply a way of adding an additional step in this process. Once
VXML Server loads the static representation of the configuration (known as the base
configuration), it will pass this to the dynamic configuration Java class or URI for modification
instead of passing it directly to the element. The class or URI adds to or changes the base
configuration depending on the application business logic and returns a complete configuration.
VXML Server then passes this new configuration to the element.
VXML Server loads the static representation of the configuration (known as the base
configuration), it will pass this to the dynamic configuration Java class or URI for modification
instead of passing it directly to the element. The class or URI adds to or changes the base
configuration depending on the application business logic and returns a complete configuration.
VXML Server then passes this new configuration to the element.
Using the Java API
Dynamic voice, action, and decision element configurations are constructed in the Java API by
implementing the Java interfaces
implementing the Java interfaces
VoiceElementInterface
,
ActionConfigInterface
and
DecisionConfigInterface
respectively, all found in the
com.audium.server.proxy
package.
Note that the name of the voice element interface is not consistent with the others due to
backwards compatibility concerns. Each of these interfaces contain a single method named
backwards compatibility concerns. Each of these interfaces contain a single method named
getConfig
that receives three arguments:
•
The name of the element as a
String
.
•
An instance of
ElementAPI
or
ActionAPI
(for dynamic action element configurations).
These classes belong to the Session API and are used to access session information (See
Chapter 3: Session API for more on this API).
Chapter 3: Session API for more on this API).