CCXML 1.0 Session and Application Variables

Session Variables

The CCXML 1.0 platform has a number of system-defined variables that are created upon application execution which persist throughout the duration of the call session. These variable values are read-only, and may not be modified at the application scope, (however, it is entirely possible to declare a user variable that contains the value of the session variable, and then modify the value, of course). Neither can the application developer create and declare new session variables, (or any variables that contain a 'session.' prefix). Session variables are dependent upon the context of the state that they are in: for instance, if there is no conference in the current session, then we should not expect the "session.conferences" variable to have a value of anything other than 'undefined'. Of course, this also implies that certain session variable values will change upon each change of state in the application. The below listing defines the available session variables, and what values one can expect to see when referencing them:

session.startupmode: This session variable allows the developer to log the mode that the CCXML 1.0 script started as. The possible values are:
* newcall - Indicates that the session was started via a new inbound call
* external - Indicates that the session was started via an external launch request, (ie, via an http token request).
* createccxml - Indicates that the session was started via the invocation of a <createcall>

session.id: This session variable contains the unique alphanumeric identifier that is associated with any CCXML 1.0 session. Developers are strongly encouraged to both log, and store this data in any production deployments, as it allows the developer to easily locate the details of any given call session by searching in the persistent voxeo logs.

session.uri: Contains the value of the URI that was used during the creation of the current CCXML 1.0 session, including any querystring parameters that might be in the request. If multiple document fetches were performed when creating the session, (as could occur when redirects are involved), then the value defined will be the URI of the final target document.

session.parentid: This session variable contains a string value that equates to the parent CCXML 1.0 session that created the current session, (if applicable).

session.connections: This session variable contains an Associative Array which lists all Connection Objects that the current session has active. Each key in this Array evaluates to the connection identifier of the Connection itself.

session.conferences: This session variable contains an Associative Array which lists all Conference Objects that the current session has active. Each key in this Array evaluates to the Conference identifier of the Connection itself.

session.dialogs: This session variable contains an Associative Array which lists all Dialog Objects that the current session has active. Each key in this Array evaluates to the Dialog identifier of the Connection itself.

session.ioprocessors: Contains an Associative Array which lists any external event I/O access URI's that are available to the current session, with each key in the array being the type of the event I/O processor.

session.values: This session variable is an Associative Array containing a list of session parameters that are passed upon the creation of the session.

Application Variables

The CCXML 1.0 platform also allows developers to define application scoped variables which, similar to Session Variables, will persist throughout the entire session. Unlike Session Variables, Application-scoped variables are entirely under developer control, and may be created, and modified at any point in the application execution. Be aware that Application variables that are properties of the application object do not need to be explicitly declared, but any Application variables that are not properties, (ie, Objects), must be declared explicitly. Also note that Application Variables are freely accessible within any CCXML 1.0 document in the application execution. An example of creating application variables is illustrated in this code snippet:


     <!-- declaring a user variable -->
       <var name="author" expr="'matthew henry'"/>
       <log expr="'***** AUTHOR = ' + author"/>


      <!-- assigning the user variable Application scope -->
       <assign name="application.author" expr="'steve sax'"/>
       <log expr="'***** AUTHOR = ' + author"/>
       <log expr="'***** APPLICATION.AUTHOR = ' + application.author"/>


      <!-- declaring a new Object -->
        <var name="application.myObject" expr="new Object()"/>


      <!-- assigning application scoped properties to the Object -->
        <assign name="application.myObject.prop1" expr="'rob green'"/>
        <assign name="application.myObject.prop2" expr="'eric simpson'"/>

       <log expr="'***** APPLICATION.MYOBJECT.PROP1 = ' + application.myObject.prop1"/>
       <log expr="'***** APPLICATION.MYOBJECT.PROP2 = ' + application.myObject.prop2"/>

ANNOTATIONS: EXISTING POSTS

rqualis

3/14/2008 3:23 PM (EDT)

I am pretty new to CCXML. As I learn it, I found it, at times, helpful to relate it back to the various programming languages I am very familiar with. In this case, JavaScript:

For those that are familiar with JavaScript, the creating, assigning and accessing of application scope properties as in <assign name="application.myObject.prop1" expr="'rob green'"/> is pretty much the same:

The above in JavaScript would be:

this.myObject = new Object();
this.myObject.firstname="rich";
document.write(this.myObject.firstname);

As you know, the this is the instance of the object at hand (object in the application).

For session variable, seems the same behavior as in a J2EE application running in a container.

I: CCXML 1.0 Objects

| TOC