Cisco Cisco Unified Customer Voice Portal 11.0(1) Developer's Guide
C
HAPTER
3:
S
ESSION
API
C
ISCO
CVP V
OICE
XML 3.1
Programmer
Guide
•
Setting the maintainer, default audio path, main document language and encoding, as well as
the call’s session timeout. At any point in the application, these settings can be changed.
the call’s session timeout. At any point in the application, these settings can be changed.
The following lists the API classes that extend
APIBase
(also found in the
com.audium.server.session
package). A detailed description of what each class provides is
given in the individual section for that component.
•
CallStartAPI
. This class is sent as an argument to the start of call class.
•
CallEndAPI
. This class is sent as an argument to the end of call class.
•
ElementAPI
. This class is used by all standard and configurable element classes as well as
dynamic configuration classes. The following classes extend
ElementAPI
to provide
additional functionality required for different kinds of elements.
o
ActionAPI / ActionElementData
. The
ActionAPI
class is used by generic action element
classes and is extended by
ActionElementData
which is used by configurable action
element classes.
o
DecisionElementData
. This class is used by configurable decision element classes.
o
VoiceElementData
. This class is used by configurable voice element classes.
XML API
When a component uses the Java API, the Session API is accessed via an object passed to the
execution method. A similar setup exist when a component uses the XML API. The entire
contents of the Session API is made available via a set of XML documents passed to the
component in the HTTP request. Each component will receive this information whether they
need it or not, since the Server does not know in advance what information the component could
require. The component can choose to ignore these documents if the information contained
within are not required, or use a fast, event-based parser to extract only the desired information
from the documents.
execution method. A similar setup exist when a component uses the XML API. The entire
contents of the Session API is made available via a set of XML documents passed to the
component in the HTTP request. Each component will receive this information whether they
need it or not, since the Server does not know in advance what information the component could
require. The component can choose to ignore these documents if the information contained
within are not required, or use a fast, event-based parser to extract only the desired information
from the documents.
Each component receives two POST arguments containing complete XML documents
representing the Session API. The first, named “inputs”, lists the session information
representing the state of the application up to the point when the component was reached. The
second argument, named “settings”, lists the current value for the application settings.
representing the Session API. The first, named “inputs”, lists the session information
representing the state of the application up to the point when the component was reached. The
second argument, named “settings”, lists the current value for the application settings.
XML Document Sent in “inputs”
Figure 3-1 shows the DTD diagram for the XML document sent to all components in the
“inputs” argument. Its DTD is defined in the file
Figure 3-1 shows the DTD diagram for the XML document sent to all components in the
“inputs” argument. Its DTD is defined in the file
ElementRequest.dtd
in the Server
dtds
folder.
Copyright 2001 - 2005 Audium Corporation. All Rights Reserved. 10/05
20