Show TOC Start of Content Area

Background documentation Voice Component  Locate the document in its SAP Library structure

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

This graphic is explained in the accompanying text

This graphic is explained in the accompanying text

This graphic is explained in the accompanying text

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.

Note

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.

 

End of Content Area