Cisco Cisco Customer Voice Portal Downloads Release Note
C
HAPTER
2:
U
NIFIED
CVP
API
I
NTRODUCTION
P
ROGRAMMING
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
R
ELEASE
7.0(1)
8
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 API works in a similar fashion as the Java API. VXML 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
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 VXML 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.
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 VXML
Server whenever needed. The XML API, since it is executed over HTTP in a request / response
fashion does not have that luxury. VXML 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, VXML 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.
Server whenever needed. The XML API, since it is executed over HTTP in a request / response
fashion does not have that luxury. VXML 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, VXML 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
VXML 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
VXML 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.