Developer's Guide

CHAPTER 9: CONFIGURABLE ELEMENTS VOICEXML PROGRAMMING GUIDE

FOR CISCO UNIFIED CUSTOMER VOICE PORTAL RELEASE 4.0(1)

that instance. This executes a sub-element within the super-element using the same context. The

sub-element executes normally, it reads from a configuration object and creates VFC classes.

The difference is that the super-element can take what the sub-element produced and modify it or

add to it.

The arguments to the createSubVoiceElement() method are required in order to provide the

correct context for the sub-element to execute within. A voice element requires the correct

context in order for it to be able to read from a configuration object, use the appropriate VFC

objects, and have access to the system. The first argument to the

createSubVoiceElement()

method must be an instance of the super-element (which will be “this”). The last three

arguments are simply the arguments the super-element receives in it’s addXmlBody() method.

The VoiceElementResult object returned is a small data structure class containing the exit state

of the sub-element (if any), and whether the sub-element produced any VoiceXML. This last

value is important because the only time a voice element is allowed to produce no VoiceXML is

when it is visited for the last time. It returns an exit state and no VoiceXML so Unified CVP

VoiceXML Server knows to visit the next voice element immediately rather than producing a

VoiceXML page first and visiting the element after the browser makes the next request. If the

sub-element does not return any VoiceXML, the super-element must either add its own

VoiceXML content directly, visit another sub-element, or exit with an appropriate exit state.

After the createSubVoiceElement() method executes, the VMain object will contain a

complete VoiceXML page. If the VoiceElementResult object indicates that the sub-element

returned no VoiceXML, VMain will contain an incomplete VoiceXML page.

Building super-elements in this manner is a tricky process. The developer must be aware of the

following:

Since the sub-element executes in the super-element’s context, it shares the same

configuration. The consequence of this is that the super-element must ensure that its

configuration contains all the settings and audio groups expected by the sub-element. If it

does not, the super-element must modify its configuration object before calling the

createSubVoiceElement() method or the sub-element may throw an exception. This issue

is compounded when the super-element encapsulates multiple sub-elements that have settings

or audio groups with the same real name. The super-element’s configuration would need to

define separate settings for each sub-element’s settings and then rename them appropriately

in order for the sub-element to understand it.

The scratch space for a super-element is shared with all sub-elements. The consequence for

this is that any scratch data stored by the super-element must not conflict with the scratch

data stored by the sub-element. Many times, though, voice elements do not publicize the

names of the scratch data used. A good bet would be to name the super-element scratch data

uniquely so there will not be any conflicts. Another consequence is that the super-element

must be responsible for clearing the scratch data when an sub-element is complete. The

VoiceXML Server automatically clears the scratch data, but only for the elements it is aware

of, which in this case is only the super-element.