Subdialog
Last updated
Last updated
This is an advanced module
This module allows users to jump to an externally hosted VoiceXML application. Fuse can pass data to the VoiceXML application and receive data in return that can be used as subvariables within the Fuse platform.
Enter the URL of the web server location where the VoiceXML application lives in the first field.
The ‘submit as’ drop-down menu has these options: POST, GET w/ <param>, or GET. All three settings allow users to enter an event name, which can include variables. POST and GET w/ <param> both allow users to define custom variables.
Users must define variables as POST variables. These variables are “hidden” in the request, behind the scenes, so to speak, and are passed directly to the backend scripting server. Once the server receives these requests, it can act upon them.
Users building PCI-compliant application(s) should use POST because it prevents data from being passed to the server in clear text in the URL.
GET requests pass variables directly in the URL request to a server. A tell-tale sign of a GET request is a URL with a question mark (?) in it followed by additional data. GET data is passed directly to the application server but this method is less secure that a POST request.
GET data is typically logged in web server logs, which is not a PCI-compliant.
A GET w/ <param> request is used when users need data in their application server, but want to pass that data directly to their VoiceXML script.
A GET w/ <param> request initiates a GET request to the web server but does not pass any data to the server. Instead, the data is stored inside Plum's VoiceXML browser.
A common use case for a GET w/ <param> request is when users want to pass data that will be used to dynamically prompt the end-user, but there is no need to have that data on the web server.
Another useful application of this method is when users are not using a dynamic scripting language on their web server and are serving static VoiceXML instead. Those static pages cannot receive data directly and instead need to receive all its data as <param> values.
To access the parameter variable passed in from Fuse in the VoiceXML application, just use it as if it is a regular VoiceXML subdialog param declared as <param name=“Variable” expr=“Value”/>.
To access variables returned from the subdialog, the VoiceXML has to declare which variables are to be returned with the following:
These variables can then be access with the subdialog_name.variable_name format in Fuse.
For example, suppose there is an external VoiceXML application that returns a market region name based on a zip input.
sample_subdialog.region can be used to access the return variable name after running the Subdialog module, as long as region is listed in the return namelist in the VoiceXML code.
<return namelist="region"/>
This allows users to set the maximum time, in seconds, that elapse before returning a timeout error. This applies modules that fetch outside scripts, like the SOAP, REST, or subdialog modules. The default value for Timeout Length is 30 seconds. Acceptable number values range from 1 to 120.
<return event="invalid_zip"/>
<return event="not_in_region"/>
The two most common errors that users see with this module occur when a server times out or an application returns invalid data.
To jump to an internal Fuse application, use the Goto App () module instead.
Enable this setting to play audio while an end-user is on hold. To upload a file for hold music, go to Application Settings > Connection Settings > > Webservice fetch audio.
This setting controls the logging function of a module. Enabling the 'Private' setting instructs the module to not record, report, or retain the information input to that module for reporting or any other purposes. When enabled any information entered into a module during a call will be lost immediately when the call terminates. The 'Private' setting is critical for businesses that need to maintain PCI-DSS or HIPAA compliance. The module icon, in the upper left-hand corner, becomes grayed-out when this setting is enabled. See more details .
Enabling it generates a field in the module that allows users to enter a custom event name for subdialogs.
To branch the call off an event, use the node to the side of the event ( )
In the VoiceXML subdialog, an event can be set by using:
<return event="event_name"/>
For example, for a VoiceXML that returns a region event based on a zip code entry, events can be used to return any invalid zip, or perhaps it is a valid zip, but one that does not belong to a specific market region. See the following: The above scenario would have a corresponding VoiceXML that would have the following events in the code.
This setting can be used to catch any server fetch errors that might occur when attempting to open the subdialog. It is recommended that a call flow to be set to this error so the call flow can continue in the scenario that the web service is not available. The two most common errors that users see with this module occur when a server times out or the subdialog application returns invalid data. Adding multiple errors () to a module functions behave the same way as a counter. The first error follows the path for the first error listed, if a second error occurs in the same module it follows the second listed error, and so on until all errors are exhausted or an error directs the end-user away from that module.
