Cisco Cisco Unified Customer Voice Portal 11.0(1) Developer's Guide
C
HAPTER
2:
C
ISCO
U
NIFIED
CVP
API
I
NTRODUCTION
V
OICE
XML
P
ROGRAMMING
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
7
Apache Jakarta Tomcat application server, a library for connecting to a mainframe system
can be placed in
can be placed in
TOMCAT_HOME/common/lib
rather than any Unified CVP directory.
XML API
The philosophy behind the XML API is to provide as much of the functionality found in the Java
API as possible in a way that can be accessed by non-Java developers. This is managed by using
XML, which can be produced and parsed easily, and by using HTTP connections, which can be
handled by many different programming languages. Interpreted languages such as Perl or PHP
are just as effective in interfacing using this API as other languages such as ASP or CGI via
C++.
API as possible in a way that can be accessed by non-Java developers. This is managed by using
XML, which can be produced and parsed easily, and by using HTTP connections, which can be
handled by many different programming languages. Interpreted languages such as Perl or PHP
are just as effective in interfacing using this API as other languages such as ASP or CGI via
C++.
The XML API works in a similar fashion as the Java API. Unified CVP VoiceXML Server
creates one or more XML documents and places their contents in POST arguments in an HTTP
request. These documents contain the same environment information available through the Java
Session API classes. This request is sent to a developer-specified URL whose purpose is to
produce an XML document and return it as the HTTP response. As with the Java API, the XML
documents returned by various components differ to reflect the different functionality each
component possesses. All these XML documents comprise the XML API. The DTDs for the
XML API documents are found in the
creates one or more XML documents and places their contents in POST arguments in an HTTP
request. These documents contain the same environment information available through the Java
Session API classes. This request is sent to a developer-specified URL whose purpose is to
produce an XML document and return it as the HTTP response. As with the Java API, the XML
documents returned by various components differ to reflect the different functionality each
component possesses. All these XML documents comprise the XML API. The DTDs for the
XML API documents are found in the
dtds
directory in VoiceXML Server. The DTDs exist as a
reference, a DOCTYPE line is not required in either request or response XML documents. The
format of each XML document will be described in detail in each component’s section in this
document.
format of each XML document will be described in detail in each component’s section in this
document.
A component using the Java API has the ability to access methods that interface with Unified
CVP VoiceXML Server whenever needed. The XML API, since it is executed over HTTP in a
request / response fashion does not have that luxury. The VoiceXML Server does not know in
advance what session information the component will need. Providing a separate interface for
every piece of information desired would cause unnecessary overhead since a component could
potentially access this information dozens of times, each time requiring a new HTTP request and
response. To resolve this issue, the VoiceXML Server sends to the component all information in
several XML documents passed as a POST parameters. While this may seem like a lot to put into
a single document, especially if the component does not need more than a few pieces, a typical
application will not possess so much session information as to adversely affect the performance
of the XML API.
CVP VoiceXML Server whenever needed. The XML API, since it is executed over HTTP in a
request / response fashion does not have that luxury. The VoiceXML Server does not know in
advance what session information the component will need. Providing a separate interface for
every piece of information desired would cause unnecessary overhead since a component could
potentially access this information dozens of times, each time requiring a new HTTP request and
response. To resolve this issue, the VoiceXML Server sends to the component all information in
several XML documents passed as a POST parameters. While this may seem like a lot to put into
a single document, especially if the component does not need more than a few pieces, a typical
application will not possess so much session information as to adversely affect the performance
of the XML API.
Another consequence of the request/response mechanism for accessing the XML API is that
while the Java API can call a method to read information and set information, the XML API
must separate the read and write functionality. The HTTP request XML documents produced by
Unified CVP VoiceXML Server contains all desired information to read while the XML
response sent back from the component specifies how to manipulate the desired information.
Since the tasks each component can perform are different, the response XML document will
differ for each component type.
while the Java API can call a method to read information and set information, the XML API
must separate the read and write functionality. The HTTP request XML documents produced by
Unified CVP VoiceXML Server contains all desired information to read while the XML
response sent back from the component specifies how to manipulate the desired information.
Since the tasks each component can perform are different, the response XML document will
differ for each component type.