This section describes CCXML document structure and useful background information
on how to write CCXML documents for use with Blueworx Voice Response for AIX. It also includes some
examples of typical CCXML programming tasks:
CCXML document structure
CCXML documents are a type of XML document, so they all begin with an XML document header, followed by a <ccxml> element, an initial part (containing variable declarations and document control information), and an event processing part including one or more <transition> elements.
CCXML document processing The processing of CCXML documents is event driven. The execution of a CCXML document occurs in two phases that correspond to the two parts of the document. The first phase is the execution of the ‘initial' part of the document. This occurs only once.
CCXML variables and their scope In addition to global variables, declared at the start of a CCXML document and visible throughout its length, there are local variables, declared within a <transition> element and visible only within that transition, application variables (not supported by Blueworx Voice Response), which are visible to all documents within the CCXML application and can be changed by CCXML programs, and session variables, which are also visible to all documents within the CCXML application, but are read-only. Application variables allow information to be exchanged between different CCXML documents in a CCXML application. Session variables hold information on the state of the executing CCXML session. For an assign or reference in a transition, a scope-unspecified variable must be searched for in the following order of scope: transition, ccxml, application, session.
CCXML object identifiers CCXML operates with a number of objects such as connections and dialogs. The CCXML Browser assigns a unique identifier to each of these objects it creates and CCXML applications refer to the objects using the identifiers:
Connection states A connection can be in one of the following states:
Using Blueworx Voice Response call tags You can incorporate information associated with Blueworx Voice Response call tags, which convey information from a signaling process, to a CCXML document.
Answering a telephone call To answer a telephone call that is in the ALERTING state, your CCXML document must use an <accept> element within a <transition> element:
Rejecting a telephone call To reject a telephone call in the ALERTING state, your CCXML document must use a <reject> element within a <transition> element:
Updating a variable To update a variable, your CCXML document must use an <assign> element:
Invoking a VoiceXML application A VoiceXML Version 2.0 application is normally invoked on a connection that is in the CONNECTED state. If the underlying telephony connection allows it, a VoiceXML application can be invoked in the ALERTING state.
Transferring a telephone call Many voice applications give the caller the option of speaking to a real person. Blueworx Voice Response has a number of different transfer capabilities, and can use the facilities of the telephone switch, a computer telephony integration (CTI) link, or its own ability to join two calls together. These capabilities are not included in the CCXML standard, therefore they are made available by using the <send> element to send platform specific messages to Blueworx Voice Response.
Making an outbound telephone call To make an outbound telephone call, your CCXML document must use a <createcall> element within a <transition> element.
Disconnecting a telephone call To disconnect a telephone call, your CCXML document must use a <disconnect> element within a <transition> element.
Using an automated connection timeout To specify a connection timeout, you can either modify the default timeout value by editing the configuration file $DTJ_HOME/dtj.ini, or you can use a connection.ibm.timeout event within a <transition> element.
Transporting events to and from external components Blueworx Voice Response supports a basichttp event I/O processor that uses HTTP (as described in RFC2616) to transport events between a CCXML implementation and external components.
Logging events To log events during the execution of a CCXML application, your CCXML document must use <log> elements. To log information on specific events, include <log> elements within <transition> elements.
Error handling Generally, when an error occurs during the execution of a CCXML document, the corresponding error event is added to the front of the document’s event queue, causing the CCXML application to process the error immediately after the current event. Errors occurring during initialization of a CCXML document, or in eventprocessor elements are identified by the CCXML Browser and the execution of the CCXML document is terminated immediately.