Voice Component
The Voice Component is an external component containing a description of how it is to be referenced in the Voice Data Runtime. It indicates how data elements in the calling parent's scope are mapped to the exposed data elements of the component being consumed.
Voice Component Icons
Compose Details |
Compose Icons |
Design Board |
|
|
|
Fields
Field |
Type |
Values |
Default |
Name |
Text entry field |
- |
- |
It is assumed that a Voice Component will be a child element at one or more levels under a Voice Application. Voice Components have a local scope for variables, and, in general, data is passed between child and parent only as formal parameters through the define data and in/out mapping process. These Components inherit resources from their parents by default. They include:
● Event Handlers
● Jumpwords
● Resource Targets
● VoiceXML properties
● Predefined set of application context variables, which are available globally
You can override these resources locally within the child component.
A Voice Component can be edited in place by double-clicking on it, which takes you inside the component and lets you to add or modify any of the contained voice element types.

When you are editing a Voice Component, you have moved into a different Visual Composer model, which has its own local scope for all variables. It also has a local scope for environmental entities, such as Event Handlers, Jumpwords, Resource Targets, and VoiceXML properties. By default modules will inherit all parent environmental entities, but you can override them with a local copy or block them from inheriting altogether on a per-type basis.
Data is passed in and out of modules through a parameter passing mechanism. The only other interaction a module has with its container is through events. A module can trigger an event for which no local handler is defined. In that case, the event will propagate upward through parent scopes until a handler is found. This allows a module to trigger a Main Menu event for example, which could be caught by the top level application. Thus a series of pre-existing modules could be assembled and integrated easily into a multipurpose portal without any need to customize the modules themselves.