Building A Complex Application

Having covered the basics of Fuse, now it's time to focus on more complex applications. This means, for example, an application that collects caller account data, queries a webservice for authentication, presents the caller with a menu of options, and provides the caller with details about their account.

Create a new application in the manner detailed above. In the new application workspace, add a Prompt () module, name the module, type a welcome message, and connect the 'Start' () module to the new welcome prompt.

Collecting Caller Input

Caller input refers to either Speech or Touch-Tone (DTMF) input provided by the caller. Only the modules listed in the Input section of the Modules menu actively listen for caller input.

Most input modules allow users to control the type of caller input to be collected. However, not all types of input are compatible with DTMF input. These include the modules Name (), Address (), and Record ().

Conversely, the Language () module, which allows callers to switch to a different language, is DTMF only because it is not possible to recognize speech input in multiple languages at the same time.

Continuing with the sample complex application, it is necessary to collect the caller's account ID. To facilitate this need, add a Digits () input module to the workspace and connect it to the welcome prompt. Because this module collects the caller's account ID, change the title to “accountID” and then type prompt text that asks the caller to enter their account ID.

Variables

It is important to understand that modules automatically create variables in Fuse based on the name of the module. In the screenshot above, the module asks the caller to provide their account ID and Fuse stores the resulting input in a variable named accountID.

Options

Each Fuse module has a unique set of options that controls how that module behaves. To customize module behavior, click on the gear () icon to open the options menu for that module.

Returning to the sample complex application, the Digits () input module has the following editable options:

1. Barge-In: Allows the caller interrupt the prompt with input, advancing the call-flow before the prompt finishes. Note: When barge-in is enabled the top line of the text box changes from a solid line to a dashed line.

2. Enabled Speech Input: By default, this module only allows DTMF tones. Toggling this option enable speech input.

3. Min / Max Digits: This determines the rules for acceptable input length. For example, if account numbers are 7 digits long, setting both the Min and Max to 7 forces users to enter 7 digits. Any input that contains additional or fewer digits will trigger a 'No Match' error.

4. Private: This setting controls whether Fuse logs caller interactions with this module. By default, logging is turned on.

5. Show Custom Errors: This allows users to provide custom No Match/No Input paths for the module. If this option is disabled, then the application uses the default No Match/No Input rules defined on the Settings tab for the application.

Try adjusting each of these settings. Notice that each change causes a small visible change to the module. This is done so users can quickly identify which options are enabled without opening the options menu. For the current sample application, leave all of the module options on their default settings, i.e. barge-in enabled and all other settings disabled.

Error Handling

Input modules have the ability to trigger No Match and No Input errors based on the caller's behavior.

By default, input modules utilize the global settings which play a generic prompt (e.g., “I'm sorry I didn't get that”) and then repeats the current module. If the caller produces three errors, in any combination of No Match or No Input, Fuse's default setting is to then disconnect the call.

To override these behaviors, enable the 'Show Custom Errors' option. This adds two new transmitters at the bottom of the module as well as icons that allow users to add or remove additional No Match/No Input transmitters.

For example, the default global settings produce the following behavior for all input modules.

Variables & Branching

When adding a module to the workspace, users will notice that the default title of the module is “varX”, where X is a number. The module title functions as a variable within Fuse. This occurs automatically and Fuse stores the results from that module, under that variable name, for later use.

Users can create and define new variables using the Set Variables () and Evaluate JS () modules, too.

Users can add any variable to any field that has abutton. This functionality is available in individual modules as well as global application settings.

All prompt fields have abutton in the bottom right corner. This allows users to insert dynamic variable values and mix those with static prompt text.

Modules and fields that require data value(s) also have abutton. This is most evident when branching based on a value or when passing data to a webservice or application.

Fuse automatically globally scopes all variables within an application and variables are accessible from any page. Jumping to a new application creates a new scope with a new set of variables.

WYSIWYG Prompts

When creating prompts in a Fuse module, the text entered into a text box is presented to end-users exactly as written, so what users see if what they get. Fuse allows users to combine static text with dynamic values by inserting variables into the prompt field using thebutton.

To add a variable, place the cursor at the appropriate place in the text box and click thebutton. This generates a new window that allows users to define a variable name. Some modules allow users to define specific variable types as well. Available variable types include:

• Acronym

• Address

• Currency

• Date

• Time

Use Case

Verifying end-user input presents a common use case for mixing static prompts with dynamic variables. One way to accomplish this is to use the Yes/No () module to add a variable to the confirmation prompt. Assuming that the end-user's account ID was collected earlier in the call-flow and is already an available variable, the 'Yes/No' () module allows end-users to verify that information. If there is an error, the 'Yes/No' () module can then re-route the end-user to the correct module to re-enter the correct information.

Branching

In Fuse, branching, also called jumping, refers to the routing options a module provides. Oftentimes, an end-user's input influences their path through a call-flow, and Fuse allows users to branch, or re-direct, a call based on a dynamic value. Fuse provides users with multiple ways to create branches within an application.

• Counter (): This module counts how many times an end-user loops through a given section of a call-flow and automatically increases its counter on each loop. Users can set rules for the call-flow based on the current value of the counter.
• Compare Variable (): This module allows users to reference a dynamic value and perform a comparison on it. Users can then re-route end-users to different areas within the application depending on whether that comparison is valid or invalid. For example, it is possible to authenticate an end-user with a REST service and then to route them through the application based on their current account status.

• Goto Page (): This module allows users to send callers to a new page within the application. Not only can users choose the specific page, they can also select a specific module within that page as the desired landing place. Fuse maintains the application's current application variable scope when making this type of jump.

  • This makes it easier for users to manage their Fuse apps because it is easy to break a call-flow into its component parts, place each section on its own page, and then connect the pages using modules. This approach is also useful if an application uses a specific section in multiple places within a call-flow; users can jump to that sections without the need to re-create it in multiple pages.

• Goto App (): This module allows users to send callers to a different Fuse application. This is useful for collaborative development where one user owns a small subset of the application's functionality. Jumping to a new application creates a new variable scope, but users can pass variables from the original application into the sub-application, and vice versa. When the new application finishes executing, Fuse assigns the variables from that scope to Goto App module in the original application. These variables are stored as a sub-variable of that module.
• Menu (): The 'Menu' () module allows users to create a menu of options that branch the call-flow based on the option an end-user selects. The 'Menu' () module automatically creates a dynamic list of prompts that asks end-users to select one of the menu options.
• Yes/No (): The 'Yes/No' () module restricts end-user inputs to a language specific version of “yes” and “no”.

See the Modules page for more information on these modules and how variables function.

Data Integration

Fuse provides users with several, powerful data integration options. As detailed above, the Goto App () module sends and receives values from other Fuse applications. Using the SOAP () and REST () modules users can access virtually any web service.

REST: The REST () module allows users to specify a dynamic URL that can accept variables in order to access RESTful URLs that require dynamic value(s) in order to reach a specific resource(s). The module also allows users to specify custom HTTP headers using a combination of static text and dynamic variable values. The REST () module also allows users to use any variable value when passing in POST values.

For example, users can use the REST () module to update an account using a REST webservice where an account ID is required in the URL, and POST values are required to update that value.

SOAP:The SOAP () module allows users to specify the WSDL and to access that WSDL's list of methods. After selecting a method, users can use any combination of static text and dynamic variable values to assign the values to be sent to the webservice.

Accessing Return Data

When performing data integration, the values returned to the Fuse application can be accessed as a complex object using Javascript dot notation.

For Goto App (), all the variables in the sub-application scope can be accessed as sub-variable of the variable defined by the Goto App () module. For example, assume a Goto App () module named “app_result” runs an application that collects an 'accountID' variable. Users can access the 'accountID' as app_result.accountID.

For REST and SOAP services, the value returned by the webservice determines the return structure. For example, assume a REST () module named “rest_result” calls a JSON REST service and returns a complex structure like:

{“id”:1234,“name”:“John Doe”,“status”:{“overdue”:false,“balance”:1234.56}

Users can access these values as result_result.id, rest_result.name, rest_result.status.overdue, and rest_result.status.balance. This provides users with easy, direct access to these Javascript variables.

Debugging

Sometimes it may not be obvious how the SOAP () and REST () modules will parse and present data. One way to quickly determine this is to call the application and to use either the SOAP or REST modules.

This generates a call log that users can then consult in order to view the full request and its response data. The call log also details the full Javascript object that Fuse created based on the response data.

This lets users see exactly how to access the resulting data structure. It also provides insight as to how to debug any request or response parsing issues in the module.