Business Task

Overview

The Business Task object is used to define a business view on top of the dialog definition of an application. Business tasks can structure an application in terms of tasks that a caller can accomplish, such as logging into an account or doing a transaction. Information on the processing of a task will automatically be logged to Infostore, the logging component of VoiceObjects Server, including success and failure rates, the time that a task was active, data that was gathered during the task, recognition rates, etc. Using VoiceObjects Analyzer, powerful reports can be generated to understand how successful callers are in using your applications. Since business tasks are mainly implemented for logging and reporting purposes, Infostore must be licensed to make use of this feature.
Business tasks have no influence on the dialog flow or the interaction with the caller.

The Object Definition below covers the configuration of the Business Task object with VoiceObjects Desktop. For information on how to define this object type using VoiceObjectsXML refer to the VoiceObjectsXML Definition paragraph.

The Business Task object belongs to the object category Business Tasks.

Dialog Flow Scenario

The following example shows how a business task Life insurance information is started and finished in a dialog flow using Expression objects.

Object - Caller	Dialog Flow
Start task Life insurance information	[ Starts business task Life insurance information ]
	What is your gender?
Caller	I am male.
	And what is your age?
Caller	Thirty-one.
	[ Calculates life insurance fee ]
	The fee for a thirty-one year old male starts at just 92 dollars.
Finish task Life insurance information	[ Finishes business task Life insurance information as complete ]

Object Definition

The Definition of the Business Task object provides the following sections:

· Declaration
To specify the task type, optionally change the reference ID and provide a short description.

· Parameter Sets
To define parameter sets to be logged to Infostore in case the task was finished either as complete or as incomplete.

For further details regarding additional object configuration refer to Properties in this Object Reference.

i8 Note: A Business Task object can be disabled. In this case, none of the processing described below will take place.

Declaration

In the Declaration section, the task type is specified that categorizes the business task. One of the following types can be selected from the drop-down list in the Task type field:

Task type	Description
Authentication	Any kind of authentication, identification or verification task, such as entering an account number and PIN at the beginning of a call
Information	Any kind of information that is presented to the caller, such as playing back the account balance in a phone banking application
Notification	Any kind of external notification sent to the caller, such as email, SMS, MMS, etc.
Routing	Any kind of routing task, such as transferring the caller to an agent
Transaction	Any kind of transaction task, such as booking a flight, transferring money, ordering a product, changing credit card details, etc.
Other	A task that does not fit in any of the other task types

Using the function TASKREFID() through an Expression object, the reference ID of the currently active task can be retrieved at call time. Since readable IDs are usually preferred, the reference ID of the Business Task object can be modified in the Reference ID field.

A brief description of the task can be entered in the Description field. This description corresponds to the short description for the Business Task object (for further information refer to Properties in this Object Reference).

Parameter Sets

Use the Parameter Sets section to associate data with the task, which will be logged to Infostore when the task is finished. Specifying parameter sets is optional. Possible parameter types are Variable, Collection, Expression, Layer, Resource Locator, or Script objects, and constants. When using a Resource Locator object as a parameter, its URL definition is used.

The Alias field may be used to define the name under which the parameter will be logged to Infostore. Using the Alias field is optional. If left empty, the reference ID of the object in the Parameter field will be used. This means in particular that for constant values, an alias needs to be defined (as they do not have a reference ID). Constant parameters without a defined alias are ignored.

A distinction is made between tasks that are finished as complete and those that are finished as incomplete (this is described in the paragraph on Processing). All parameters defined in the Parameter Set – Complete subsection are used in case the task is finished as complete. All parameters defined in the Parameter Set – Incomplete subsection are used in case the task is finished as incomplete. For your convenience, select the option Use parameter set “complete” for both sets to re-use the parameters defined in the complete set also for the incomplete case. If parameters are defined in the incomplete set and this option is selected, these parameters will be ignored and the ones from the complete set will be used instead.

Processing

This section explains how business tasks are processed in a call, introduces some terminology and describes the type of data that will be logged to Infostore.

Start business tasks

A business task can be started (and finished) any number of times during a call.

Business tasks are added to the dialog flow by placing an Expression object with the STARTTASK function and the Business Task object as its argument at the desired position. When the caller passes this object at call time, the task is started.

Note that this is the only way to start a business task; you cannot add a Business Task object itself to the dialog flow.

Finish business tasks

A task can be finished in two different ways, either manually or automatically. When a task is finished, data on the processing of the task is logged to Infostore by the server.

Finish a task manually

The end of a task is marked manually by placing an Expression object with the FINISHTASK function at the desired position in the dialog flow. As first argument of the function, link the Business Task object to be finished. The second argument controls the status you want to assign to the task when finishing it. Leave it empty or define it as complete to mark the status as complete when the caller passes the Expression object at call time, which should be the default when finishing a task with the FINISHTASK function. See Completion and status of a task below for more information on the status.

Instead of linking a Business Task object as first argument, you can also enter active to finish the currently active task, or all to finish all tasks. See Handle more than one active task below for more details on processing several tasks simultaneously.

Expression objects with the functions STARTTASK and FINISHTASK are displayed in the dialog flow with a start icon and a stop icon respectively, to highlight the use of business tasks in a dialog flow. The following example is taken from the Check existing claim sub module within the Prime Insurance sample application. It shows the start and end points of a business task to authenticate the caller and a task to manage claims, respectively:

i8 Note: When the FINISHTASK function is processed for a business task that is not started yet, or already finished, the function will be ignored.

Finish a task automatically

Instead of finishing a task manually through Expression objects, the server can finish a task automatically depending on certain conditions at call time. This reduces workload for the developer, as the server can handle certain scenarios related to business task processing itself, without requiring explicit definitions by the developer.

When the server finishes a task automatically, it will be marked as incomplete by default. For a definition of this term, see Completion and status of a task below.

A task is finished automatically

· when the call ends (dialog timeout, no further objects to process, uncaught runtime errors) before the task has been finished manually through the FINISHTASK function. In this case, any dialog end processing objects defined in modules are processed first, and the task is finished at the very end of the call, with the values the parameter sets have at that point in time.

· when an Expression object with the STARTTASK function is processed again for a business task that has not been finished yet. The current instance of the task first gets finished, and a new instance of the same task will then be started again.

· when an event handler, hyperlink or Goto object is used that has the Finish Tasks option set to Active or All.

In an event handling item, a custom navigation item, a Hyperlink object, and a Goto object, the Finish Tasks option can be set to Active, if you want to finish the currently active task, or to All, if you want to finish all tasks when the respective object or item is processed. The default is None, which means that no task is finished.

The following screenshots show the option in an event handling item, custom navigation item and Goto object, respectively:

i8 Note: The Finish Tasks option will only be processed on a hyperlink if the mode is set to Process object. On an event handling item, the option will only be processed if the target is an Exit or Goto object, i.e. it will not be processed if the event handler merely plays a prompt through an Output object.

@8 Tip: It is best practice to set Finish Tasks to All for a hyperlink that returns to the main menu, as well as for event handlers that exit the call. In general, make sure to consider the Finish Tasks option carefully when designing an application.

While the task will always be marked as incomplete when finished automatically, the status depends on the processing context.

Completion and status of a task

When a task is finished, either manually or automatically, it will be assigned a completion value and a status. Completion can be either complete or incomplete. A task can only be marked as complete when finished manually through the FINISHTASK function. The second argument must be left empty or set to complete in this case. The status of a completed task is also complete.

If a task is finished automatically, or using the FINISHTASK function with a value other than the empty string or complete, it will be marked incomplete. The status then further specifies why the task was incomplete. In case of the FINISHTASK function, the status can be set by the developer. In case of the server finishing a task automatically, the context in which the task was finished determines the status.

The following table lists each possible status a task can get in case of incomplete.

Status	Description	Set automatically…
Back-end error (backEndError)	The task was finished due to an error in a back-end system.	with event handler Error – Connector
Business logic (businessLogic)	The task was finished due to requirements or specifications of the business logic.	n/a
Caller abort (callerAbort)	The task was finished by means of caller interaction.	with event handlers Caller - Exit, Caller - Cancel, Caller – Help with all custom event handlers (custom event type) with the Goto object with the Hyperlink object
Recognition failure (recognitionFailure)	The task was finished due to speech recognition problems.	with event handlers ASR – Invalid Answer Limit, ASR – Max Processing Time, ASR – Max Speech Duration, ASR – No Input, ASR – No Match, ASR – No Match (Voice), ASR – No Match (DTMF)
Task restart (taskRestart)	The task needed to be finished since the same task was started again. i8 Note: This status cannot be set manually. Trying to do so using FINISHTASK will result in an error.	when an unfinished task is started again
Session termination (sessionTermination)	The task was finished since the dialog session terminated. i8 Note: This status cannot be set manually. Trying to do so using FINISHTASK will result in an error.	when a call ends due to dialog timeout or end of call (no more objects to process) with event handlers Disconnect, Disconnect – Hangup, Disconnect – Transfer and with uncaught errors that end the call
Technical error (technicalError)	The task was finished due to a technical error.	with event handlers Error – Internal, Error – Media Platform, Error – Script

The strings in parentheses in the Status column denote the values to be used in the FINISHTASK function as second argument. They are the same as the ones used in VoiceObjectsXML, as well as the values returned by the TASKSTATUS function.

The TASKSTATUS function returns the status of the business task provided in the first argument. If a task has never been started in a call, the function returns notStarted. If a task has not been finished when calling the function, the string active or inactive is returned, depending on whether the task is currently active or inactive (for a definition of these terms, see Handle more than one active task below). If a task was started more than once during a call, the status of the last processed task instance is returned.

The function TASKREFID can be used to retrieve the reference ID of the currently active task. If no task is currently active, the function returns an empty string.

Handle more than one active task

In most cases it should be sufficient to have one task active at a time. A task is started, some objects are processed, and the task is finished before another task is started. In some cases, it might be desirable to start another task while one task is still active. This is possible by processing two or more STARTTASK functions before finishing a task.

The tasks are then managed on a stack. Only one task can be active at a time. If a task B is started while task A is still active, task B will become active (i.e. pushed to the stack) and task A will become inactive. Task B is considered a child task of task A, so they should be conceptually related. Usually, task B should be finished (i.e. removed from the stack) prior to task A. In that case, task A becomes active again. If task A is finished before task B (by calling FINISHTASK on task A), then task B will be implicitly finished by the server as incomplete, with the same status that has been assigned to task A. In other words, finishing an inactive task will implicitly finish all tasks above the task in the stack. A special column IMPLICIT_FINISH in Infostore marks the implicitly finished tasks.

Task data logging in Infostore

Once a task has been finished, information on the processing of the task is automatically logged to Infostore. This requires Infostore to be licensed and System DB logging to be enabled at call time. If System DB logging is turned on, information on business tasks will be logged. The coverage filter, which can control the amount of information logged to Infostore, thus also applies to business task logging, if the filter scope includes System DB logging.

The following tables are used in Infostore to store business task-related information.

Lookup tables

Table	Description
VOLDTASK	Stores information on the Business Task objects defined in your application, such as their names, creation and modification timestamps, task types etc. This table will be filled whenever the server loads an application into its cache, i.e. on redeploy and restore operations.
VOLDTASKTYPE	Holds the IDs and localized descriptions of the six available task types: Authentication, Routing, Information, Notification, Transaction, Other.
VOLDTASKCMPL	Holds the IDs and localized descriptions of the two available completion values: complete and incomplete.
VOLDTASKSTATUS	Holds the IDs and localized descriptions of the eight available task statuses: Complete, Back-end error, Business logic, Caller abort, Recognition failure, Task restart, Session termination, Technical error.

Fact tables

Table	Description
VOLDTASKSTATS	Stores information on the processing of a task at call time. Including: Start and end timestamp, duration and number of active and inactive phases, task status, recognition rates (No Match, No Input events, average confidence values etc.), number of errors, etc.
VOLDTASKDATA	Stores information on the data associated with a task in the object definition, i.e. parameters gathered during the call. Examples are account numbers, selected menu or list items, answers provided in Input objects, etc. The values will be logged to two columns, one with an alphanumerical, and the other one with a numerical data type. This allows you to do calculations such as building a sum or an average on the data, in case they are numerical.

In addition, the tables VOLDDSSEQ and VOLDRECLOG, which store input state-related data, are enhanced to store the active business task for a given input state, if there is any. The table VOLDDLGSTS holds aggregated business task information for the entire dialog session.

To be able to associate the logs written to Infostore with custom logging implemented in your application, the placeholders @TASK_SID@ and @TASK_COUNTER@ can be used inside a Log object. They will be replaced with the surrogate ID (unique ID used in the VOLDTASK table) and the counter of the currently active business task.

i8 Note: Even if System DB logging is disabled, business tasks are still processed.

Business tasks and standard navigation

Using the standard navigation commands backward and forward, the caller can step over a start and end point of a business task. A special handling will apply in these cases.

· The information that is maintained for tasks will not be modified by rollbacks (i.e. going backward will not roll back timestamps already memorized, or any of the counters that count the number of events per task, etc.)

· When a backward command is used that steps over a STARTTASK function, the task that has been started by this function will be automatically finished with status callerAbort. As for the parameter set to log (in case one is defined), the state of values that was active before the rollback will be used.

· If a backward command steps over a STARTTASK of a task that has already been finished before, nothing will happen, as the task cannot be finished again.
This could happen if the caller uses several backward commands after a task has been finished, which would take them over the FINISHTASK and the STARTTASK function.

· When a backward command is used that steps over a FINISHTASK function, no special handling will apply, i.e. the task that has been finished will not be restarted or modified in any way.
Note that this could mean that the caller might finish the task again with a different status or parameter set; this information would then not be logged.

@8 Tip: To avoid this scenario, use the CLEARNAVIGATIONHISTORY function after a task has been finished. This will make it impossible for the caller to step back over a FINISHTASK function and confuse the statistics on processing tasks. In addition, it will make it impossible to re-run a transaction performed on the back-end.

· When a forward command is used that steps over a STARTTASK function, the function will be processed as it is defined, i.e. the task will be started normally as a new task instance.

· When a forward command is used that steps over a FINISHTASK function again, the function will be processed as it is defined, i.e. the task will be finished with the status defined.

· For the skip and repeat commands, nothing special must be considered. The repeat command does not reprocess anything; the skip command just leaves the current object and goes on processing the next one.

Example

The following image shows an example dialog flow with several tasks being started and stopped.

· The tasks Identify Customer and Account Info had been started and successfully finished before any other task was started. Therefore they had 1 active phase, no inactive phase, and are logged with completion and status complete.

· The task BuyStock had been started, and while it was active the task MarketInfo was started. Therefore BuyStock became inactive. MarketInfo was finished successfully, so that BuyStock became active again. This task was then also finished successfully. In the end, BuyStock had 2 active and 1 inactive phases, MarketInfo had 1 active and no inactive phase, and both are logged with completion and status complete.

· The task MoneyTransfer was started, but an Error – Connector event was triggered. In the Connector object, the corresponding event handler was defined such that it should finish the active task. Therefore MoneyTransfer had 1 active phase and is logged with completion incomplete and status Back-end error.

VoiceObjectsXML Definition

The Business Task object is represented by the VoiceObjectsXML element <businessTask>. It has two attributes and two children.

In addition, the element has the standard attributes described in the XDK Guide.

The <businessTask> element uses the embedded <parameterSet> element.

BusinessTask

Attributes

· taskType
Defines the task type. Can be one of authentication, routing, information, transaction, notification, or other. If not specified, defaults to authentication.

· useComplete
Defines whether the parameters defined in the complete set will also be used for the incomplete case. Either true or false. If not specified, defaults to false.

Children

· <parameterSet usage=”complete”>
Defines the parameter set to be logged to Infostore in case the task was finished as complete.

· <parameterSet usage=”incomplete”>
Defines the parameter set to be logged to Infostore in case the task was finished as incomplete.

Example

</parameterSet>

</expression>

ParameterSet

Attributes

· usage
Defines the type of parameter set. Can be complete or incomplete.

Children

· +<item>
Defines the list of entries in the parameter set. The use of the alias attribute is optional when the object attribute is used, and required when the value attribute is used.

Example

</parameterSet>

Item

Attributes

· object
Defines a reference to an object. If this attribute is defined, the value attribute must not be defined.

· value
Defines a constant value. If this attribute is defined, the object attribute must not be defined.

· alias
Defines the parameter alias.

Example

Object Interoperability

The Business Task object can only be referenced by an Expression object, which can start and finish business tasks or provide information on the status of a task.

Object Naming Conventions

In order to leverage the capabilities of the integrated documentation of VoiceObjects it is important to provide intuitive and self-explanatory object names and descriptions.

The name of a Business Task object should indicate what the task is about. The short description should mention the task type and describe in more detail what kind of task the object represents. The table below lists three examples:

Name	Description
Authentication	Covers the task of authenticating the caller by asking for account number and PIN.
Market info	Plays information on selected stock. Task type is Information.
Transfer money	Covers the task of transferring money to another bank account. Task type is Transaction.