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.
Application Transfers
There may be instances where a caller in one application wants to visit or transfer to another standalone application. This is accomplished with an application transfer.
Application transfers 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 caller’s choice.
An application 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.
Subdialogs
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 subdialog.
Unlike application transfers that are separate but independent applications, subdialogs are sub-applications 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 Subdialog Invoke element.
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 Subdialog Start and the Subdialog Return elements.
-
Subdialog Start—An element used by a VXML Server subdialog application at the start of the call flow to import all variables passed by the
source application.
-
Subdialog Return—An 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 subdialog.