Managing Events 

Use

Voice Kit models include mechanisms for specifying behaviors of the run-time environment, including Events, Properties, Jumpwords, and Resource Targets. As opposed to other entities that are explicitly called, a Context Entity is activated by defined conditions in the context of the execution environment.

The Voice Kit lets you define some of the behaviors and capabilities of the environment in which the model is executed. These environmental entities include:

·        Event Handlers

These are sections of dialog that execute in response to a runtime event on the VoiceXML platform or Voice Dialog Server. For example, a common event handler nomatch might play Sorry I didn't get that, when the caller says something that was not recognized by the speech recognizer.

·        Properties

These are standard properties that effect various behaviors of the VoiceXML platform.

·        Jumpwords

These are words or DTMF (touchtone) key sequences that are listened for whenever the caller is speaking. They trigger an event and generally transition the caller to a different part of the dialog.

·        Resource Targets

These are locations where external resources, such as prompts or grammars, should be loaded from. One resource target is equivalent to one directory of prompts available on a Web server.

Scoping

All of these user-defined entities are scoped, that is, you can associate them with a particular group or Listen Element, or you can define them at the application level. Entities defined at higher levels are inherited by default, but each of the different types can be independently blocked if desired.

All Context Entities exist in a certain scope in the application (the application scope, one of many possible group level scopes, or a particular Listen element scope). At runtime, the dialog engine uses the definitions for these different entities that are defined most local to the current execution scope, along with all entities inherited from higher scopes. This means that the effective environment at any point in the model will be a combination of entities from the current scope and the application level plus entities from all intervening levels.

If you define a given entity at more than one scope, the runtime will use the definition that is most local to the current scope. When the runtime needs to locate a particular entity (such as an Event Handler or Resource Target), if it is not found in the current scope, it will continue to look it up through the levels of scope until it finds it or until it reaches the top level, where an error would be triggered. At compile time however, the compiler would detect that there was no corresponding entity and would issue a fatal error .

Eventing

The general mechanisms for eventing work as follows:

·        You define event handlers in two ways:

○       In the Event tab page of the Voice Application, Voice Component, Listen Element, Data Service element, or Data Component

Event handlers in this context have one fully-functional Speak Element embedded in them and have one continuation option selected from a set of six possibilities, one of which is to trigger a new event.

○       In a voice model, expressed as a Signal In Element

Event handlers in this context are called jump events and are used to allow control to jump to that point in the application. This is somewhat like a "goto", but it is actually an event-based jump that can cross scopes rather than a simple connection from point A to point B.

·         You trigger events in one of these ways:

○       Standard events, such as listen.nomatch or error.platform, are triggered automatically by the platform (either the VoiceXML gateway or the Voice Dialog Runtime).

○       Standard or Jump (user-defined) events can be triggered explicitly from within voice model using the Signal-out element. Typically, only jump events are triggered this way.

○       Standard or Jump events can be triggered explicitly from event handlers defined in the Events tab of applications, components, or elements, using the Event continuation action. Typically, only jump events are triggered this way.

○       Standard or Jump events can be triggered by JumpWord environmental entities, which define phrases or key presses that are listened for and then trigger a specified event. Typically, only jump events are triggered this way.

You can only define event handlers for a given event once in a scope. Duplicates will trigger a fatal compilation error. However, event handlers for the same event can be defined in different scopes simultaneously. In this case, the most-local event handler will take precedence. It is also possible (and frequently desirable) for events to be triggered in a lower scope that does not include a handler for that event. In this case, the event passes upward until it finds a handler. In practice, many applications will take advantage of this behavior by defining most error handlers only at the top (Application) scope, where they will apply equally to all elements in all child scopes, unless specifically overridden at the lower level.

It is important that Voice Applications provide event handlers for all standard events that the platform can throw. For this reason, the Voice Kit automatically inserts a default set of event handlers into each new Voice Application when it is created. You can delete or replace  this set if desired, although it is designed to provide suitable event handling behavior for most applications.

You can create user-defined events and can use them in a variety of ways:

·        At the simplest level, you can used them as a replacement for drawing lines between elements in a single model.

This can reduce clutter and improve readability. For example, a Signal-out called Jump to MAIN MENU that will take you to the Signal-in called MAIN MENU.

●      This same kind of jump behavior can be implemented across scopes.

For example, a model in a child scope might have the Signal-out Jump to MAIN MENU, but the handler for it would be somewhere in a parent scope. This way, sub-components could always transfer control back to the top-level main menu, as long as they all use the same event name.

●      You can define (user-defined) events in the events tab of a scope.

Here they can be triggered by either a Signal-out from a model or by a different event handler defined in an Events tab page at the current scope or below. For example, a standard event handler listen.nomatch may, after a number of attempts to understand the caller, trigger an event handler xfer_agent, which could transfer the caller to a live agent.

It would also be possible for a Signal-out to call that same xfer_agent event, if desired, from anywhere in the current or child scopes. This kind of approach makes it possible to define a particular behavior once in the model and make use of it from numerous locations. That way, if you want to change the behavior, you only need to change it in one place.

·        You can also define complex event handling behaviors by creating a string of elements starting with a Signal-in that need not be connected by lines to the rest of the model.

This means that standalone jump event handlers of arbitrary complexity can be implemented that make use of any of the normal voice elements.

This implementation of eventing gives you flexibility in structuring your voice application and makes it possible for reusable voice components to be smoothly integrated into new custom voice applications, as long as parent and child agree on consistent names for these events.