CCXML 1.0-W3C Development Guide

<goto> element

The <goto> element, used in conjunction with the <fetch> element, is used to transfer execution to a separate CCXML document. The <fetch> element allows for a pre-emptive fetch and parse of the target document to ensure that it is well formed and can execute before the <goto> ever executes. Execution returns from this element immediately, and the CCXML interpreter is free to continue while the execution context parses and prepares the target document for execution. If the target is fetchable, and parseable, an event 'ccxml.fetch.done' is sent, and the <goto> may now execute normally. However, if there is a problem with the target page, the event of 'error.fetch' is thrown to the invoking document.

usage

attributes

fetchid	Data Type: (ECMAScript Expression)	Default: none - attribute is required
	This attribute indicates the ID of any document referenced in a fetch operation, which is gathered with the fetchid. A sucessful fetch completion additionally provides a property whose value is the fetch ID of the document being fetched.

parents

none

children

none

code samples

<1.0 goto -fetchid> sample

<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">

<eventprocessor>

<transition event="connection.alerting">
<accept/>
<log expr="'*** CALL ACCEPTED ***'"/>
</transition>

<transition event="connection.connected">
<log expr="'*** CALL CONNECTED, STARTING FETCH ***'"/>
<fetch next="'docToFetch.xml'" fetchid="'myFetchID'"/>
</transition>

<transition event="fetch.done">
<goto fetchid="event$.fetchid"/>
</transition>

<transition event="error.fetch">
<log expr="'*** AN ERROR OCCURRED DURING THE FETCH ***'"/>
</transition>

<transition event="error.*">
<log expr="'ERROR OCCURRED: '+ event$.name"/>
<exit/>
</transition>

</eventprocessor>
</ccxml>

<docToFetch.xml>

<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">

<eventprocessor>

<transition event="ccxml.loaded">
<log expr="'*** OUR NEW CCXML DOCUMENT HAS BEEN FETCHED! ***'"/>
<exit/>
</transition>

<transition event="error.*" name="event$">
<log expr="'ERROR OCCURRED: '+ event$.name"/>
<exit/>
</transition>

</eventprocessor>

</ccxml>

additional links

W3C Specification

ANNOTATIONS: EXISTING POSTS

bpcamac

12/15/2008 9:10 PM (EST)

I'm looking for a way to pass parameters from a fetching document to a fetched document. Both documents are statically defined (as in the Voxeo hosted environment) so the use of dynamic substitutions in a JSP or ASP page to produce the fetched document isn't an option.

I noticed that the fetch ccxml statement allows for parameters to be supplied in the call (via the namelist attribute). Is there a way for the CCXML environment of the fetched document to gain access to parameters mentioned in that namelist?

thx,
Brenton

voxeoJeffK

12/15/2008 11:06 PM (EST)

Hi Brenton,

Normally a CCXML document has access to query string variables via session.values.foo. The difficulty here is that fetch/goto brings a new CCXML document into the same session space, and the session variables are read-only after initialization. fetch/goto was really intended to be used with dynamically generated server-side code that can read the query string. We may be able to offer better insight on how to accomplish your goals. What functionality were you seeking by incorporating a fetch/goto?

Regards,
Jeff K.
Voxeo Support

bpcamac

12/16/2008 11:47 AM (EST)

Hi Jeff,

Yes, I tried the session.value namespace and observed it wasn't a solution. Your explanation makes sense.

My situation is that a subordinate CCXML document has behavior that is parameterized, hence the need for passing it parameters. However, I didn't want to have it fetched from a webserver since all the other CCXML docs for this app are statically defined and thus reside on the voxeo hosting platform, and I would prefer to keep them all together for maintainability.

As a workaround, I'm going to have the platform load the document (via goto). Then when the doc receives its ccxml.loaded I'll have it contact the app-server (via a send) to obtain the parameters it should use.

I just thought I would check first with Support to see if there was a more direct way to propagate values from doc to doc.

Thanks for you quick reply, as always.

- Brenton

voxeojeff

12/16/2008 11:56 AM (EST)

Hi Brenton,

In order to accomplish this task, the use of application scoped variables will help greatly. Below is an example which illustrates how this can be done.

<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">

<var name="myFetchID" expr="'some_fetch_ID'"/>
<var name="testvar"/>

<eventprocessor>

<transition event="connection.alerting">

<assign name="application.testvar" expr="event$.connectionid"/>
<accept/>
<log expr="'*** CALL ACCEPTED ***'"/>
</transition>

<transition event="connection.connected">
<log expr="'*** 1st Connection ID: ' + event$.connectionid"/>
<log expr="'*** CALL CONNECTED, STARTING FETCH ***'"/>
<fetch next="'docToFetch.xml'" fetchid="myFetchID"/>
</transition>

<transition event="fetch.done">
<goto fetchid="event$.fetchid"/>
</transition>

<transition event="error.fetch">
<log expr="'*** AN ERROR OCCURRED DURING THE FETCH ***'"/>
</transition>

<transition event="error.*">
<log expr="'ERROR OCCURRED: '+ event$.name"/>
<exit/>
</transition>

</eventprocessor>
</ccxml>

Fetched document:

<?xml version="1.0" encoding="UTF-8"?>
<ccxml version="1.0" xmlns="http://www.w3.org/2002/09/ccxml">

<eventprocessor>

<transition event="ccxml.loaded">
<log expr="'*** OUR NEW CCXML DOCUMENT HAS BEEN FETCHED! ***'"/>
<log expr="'*** testvar = ' + application.testvar"/>
</transition>

<transition event="error.*" name="event$">
<log expr="'ERROR OCCURRED: '+ event$.name"/>
<exit/>
</transition>

</eventprocessor>
</ccxml>

This will allow you to reference the connectionid from the first document, in the second document. We're not really passing variables, per se, but rather making them readily available to all documents. Please let me know if you have any further questions. :-)

Hope this helps!

Jeff Menkel
Voxeo Corporation

bpcamac

12/17/2008 3:40 AM (EST)

That makes sense. And this might be related to the discussion as well.

I see the following fatal error whenever the fetched ccxml document attempts to start a dialog: connectionid not found for <dialogstart>.

The dialogstart element in this case is simply:
<dialogstart src="'onHold.wav'" type="'audio/wav'" dialogid="clientDialog"/>

I can start this dialog fine in the parent ccxml document. So it seems that the fetched document doesn't completely inherit the parent doc's environment. Is this correct? If so, what can be done to resolve it?

thx,
Brenton

voxeoJeffK

12/17/2008 4:10 AM (EST)

Hi,

This error is usually seen when trying to start a dialog while not in a connection event, like in a dialog.exit event. If this is the case you can use the "connectionid" attribute:

<dialogstart src="'onHold.wav'" type="'audio/wav'" dialogid="clientDialog"
connectionid="connid"/>

where you have filled connid with the connection ID. If I am off base on where you're calling the dialogstart please let us know some of the details, and we'll do our best to help further.

Regards,
Jeff Kustermann
Voxeo Support

bpcamac

12/17/2008 1:07 PM (EST)

I'm invoking the dialogstart method within the ccxml.loaded transition of the fetched document.

Its parent (fetching) document has previously accepted a call, successfully started a dialog on that connection, received the dialog's exit event, and then fetched the subordinate doc.

It seems to me that each time a ccxml document is fetched, it is given its own session. This would explain why we needed to use application-scoped variables to bridge the documents. Likewise, if connections are associated with sessions, then this information will be lost to the new document (unless carried over via the application-scoped variables). Is this correct?

- Brenton

voxeojeff

12/17/2008 1:39 PM (EST)

Hi Brenton,

You're on the right track. :-) When CCXML executes a fetch and goto, the session ID will not change (unlike <createccxml>), however you will need application scoped variables to carry-over information such as the connectionid, as you stated. So going back to the code sample I provided, if you wanted to launch a dialog in the ccxml.loaded event for the fetched document, you could theoretically set the connectionid attribute to the application scoped variable.

Hope this helps,
Jeff

bpcamac

12/23/2008 12:45 AM (EST)

A footnote to the above discussion. I observed the following.

In the CCXML environment, Application-scoped variables seem to span more than one session. When I use the application namespace to save session specific information (such as a connectionID) for use later by a fetched CCXML document in the same session, weird things happen. For instance, one dialog interrupts another one, and many times a connection just hangs around until its garbage collected. These seem to arise because a session is picking up on connections that predated it, having gained access to the connection from the application namespace.

So, it seems like using the application-scoped namespace may not be the best way to transfer variable information from one CCXML doc to another when those docs are all scoped within a session.

- Brenton

voxeoJeffK

12/23/2008 3:22 AM (EST)

Hi Brenton,

We would be happy to investigate the situation deeper for you. If you could run the capture the debugger output of a session that displays these properties, and create a Support Ticket with us we will be happy to review the situation.

Regards,
Jeff K.
Voxeo Support