There are many
scenarios where a set of smaller applications works better than a single
monolithic application. The desire to split up applications into smaller parts
centers on reuse - encapsulating a single function in an application and then
using it in multiple applications can save time and effort. Additionally
updating a single application is much simpler than updating multiple
applications with the same change. VXML Server provides two different ways to
foster modular application, each with its own unique features.
There may be instances
where a caller in one application wants to visit or
another standalone application. This is accomplished with an
do not require telephony routing; they are a server-side simulation of a new
call to another application running on the same instance of VXML Server. The
caller is not aware that they are visiting a new application, but VXML Server
treats it as if it were a separate call with separate logging, administration,
and so on. Data captured in the source application can be sent to the
destination application (even Java objects) to avoid asking for the same
information multiple times in a phone call.
A situation that could
utilize application transfers would be a voice portal whose main menu
dispatches the caller to various independent applications depending on the
transfer is meant to satisfy the need for one independent, standalone
application wishes to move the call to another independent standalone
application that can also take calls directly. Since an application transfer is
used to progress a call from one application to another, it has no exit states.
There are instances
where an application is less independent and really encapsulates some function
that multiple applications wish to share. This can be achieved by using a
transfers that are separate but independent applications, subdialogs are
that an application can visit to handle some reusable functionality and then
return back to the source application. It can also take as input application
data (though not Java objects) and can also return data for use in the source
application. Subdialogs also do not have the restriction that they be deployed
on the same instance of VXML Server, they can be hosted anywhere accessible via
a URL and does not even need to be a VXML Server application at all.
The VXML Server
subdialog is similar to the VoiceXML Insert element but without the requirement
to understand VoiceXML. VoiceXML Insert elements are also much more integrated
with the rest of the application to be considered an element alternative where
a subdialog truly sends control to the subdialog application. For example,
hotlinks and hotevents in the source application do not work in the subdialog
application where they do in a VoiceXML Insert element.
A situation that could
utilize a subdialog would be a third party that develops a sophisticated
voice-based authentication system that other applications can use to validate
callers. That company exposes their service as a VoiceXML subdialog that takes
specific inputs and returns information on the identity of the caller. Any
application that wishes to use the service will then use the subdialog element
to visit this application.
To use a subdialog,
several special elements are needed in the source and subdialog applications.
Visiting a subdialog from a source application requires that it use a
The Subdialog Invoke
element will be treated by the application as an element but will be the
gateway to the subdialog. This element handles the inputs and outputs of the
subdialog application. While the subdialog application is handling the call,
the source application is dormant waiting for the subdialog to return. The
Subdialog Invoke element has a single exit state that is followed when the
subdialog application returns.
If a VXML Server
application is to act as the subdialog, it uses two different elements: the
element used by a VXML Server subdialog application at the start of the call
flow to import all variables passed by the source application.
element used by a VXML Server subdialog application when the subdialog is
complete to return data to the source application.
These elements must be
used as the
endpoints of a
subdialog application. The Subdialog Start must be the first element in the
application from which the rest of the call flow emerges. The Subdialog Return
must be the final element in the call flow (to be used instead of the Hang Up
element). An application that does not use these elements can only handle calls
made directly to it and cannot be visited by another application as a