Configurable elements are built by extending an abstract Java class. This base class lays out the methods used to identify the element’s configuration, how it is executed, and any utility methods available to it. The developer simply implements the appropriate methods and uses the Java API provided to build the element. Within the execution method, the developer is then free to use Java in any way possible, such as creating a complex class hierarchy, accessing files or backend systems, utilizing third party libraries, even communicating with external systems via HTTP or RMI.
elements must extend
ActionElementBase, and decision
DecisionElementBase, all found in
com.audium.server.voiceElement package. These
three base classes all extend a common base class for configurable elements,
In order for Builder for
Call Studio to identify the Java class representing the actual element (as
opposed to another class lower in the class hierarchy or a standard element
that also extends that class), a marker Java interface
ElementInterface must be implemented. Only
those classes that implement this interface are shown in the Builder’s Element
Each configurable element contains a single execution method
in which the element performs its function. This method is called by VXML
Server when that element is visited in the call flow. One can equate this
method to the element’s
main() method, it begins and
One argument to the method is an instance of a Session API class. Aside from the standard functionality available in this class such as obtaining the ANI and setting element data, this API class can be used to obtain a Java object representing the element’s configuration. VXML Server automatically creates this configuration object with the data entered by the application developer in the Builder or made available through a dynamic configuration. The name of the execution method and the API class passed to it differ for each element type as do the classes encapsulating the element’s configuration. The execution method for decision and voice elements must return an exit state and the execution method for action elements do not return anything (since all action elements explicitly have a single exit state).
The execution method for action and decision elements can
AudiumException while voice elements can
ElementException. The developer would throw
this exception if an error was encountered within the execution method that the
developer wishes to end the call. A call that encountered this exception would
then visit the error element (or the application-specific error message if the
error element was not defined), and the error message is placed in the error
log including the exception’s full stack trace.
The base class also includes various methods used to define the element’s configuration. These methods define everything from the element’s name to its possible exit states. These methods are essential for Builder for Call Studio to visually render the element and its configuration correctly. Custom elements will be indistinguishable from Unified CVP Elements within the Builder. The developer can choose as simple or complex a configuration as desired (or even no configuration at all, though it wouldn’t be very reusable).
Element data generated by an element will be overwritten if that same element is visited again in the call flow. For example, a variable set by a voice element handling the main menu of an application will be reset the next time the main menu is visited. The activity log, however, is a historical account of the call, so would have all values of the element data. Should the developer wish to retain all data created by all visits to the element, they must build that into the element, such as creating new variables or appending the new value to an existing variable.