The final part on my dissection of the Xcelsius <OBJECT> is a variable called CEWebServiceURL. This Flash Variable is used specifically with the Live Office component and overwrites the “Live Office Web Services URL.”
Regardless of what you enter inside the input box shown above, when the SWF is loaded inside of Infoview, the Live Office connector component will dynamically consume a webservice URL originating from the CEWebServiceURL flash variable. In this case, you do not need to do any configuration of Flash Variables for this to work, similar to CELogonToken.

What does this mean for Life Cycle Management?
For quite some time, I have heard Xcelsius users complain about the inability to bind the Live Office component URL, and how that makes life difficult for migrating Xcelsius objects between BOE repositories. The good news, is with the CEWebServiceURL, the bindable URL is no longer needed. *Note, that this option is only available with BOE XIR2 SP2 and up.

What about QaaWS?
The bad news is a Web Service connector is not configured by Xcelsius to consume the CEWebServiceURL. The good news, is that since the URL for this component is bindable, you can easily leverage the CEWebServiceURL to provide the system name. I have mocked up a simple Excel sheet that evaluates the CEWebServiceURL, then matches it to the correct system name. For those of you not using SP2, you could just as easily use the CELogonToken, since it also contains the server name. All you need to do is declare and bind the Flash Variable inside of Xcelsius then use similar logic that you can download here.

Another Option for QaaWS
If you always plan on using your Xcelsius dashboard inside of BOE, you can drop the system name and port number from the URL. This will work, assuming you don’t use a reverse proxy or some non-standard application server configuration. I have used this method many times since it alleviates the need for any fancy logic or consumption of Flash Variables.

I hope that this 3 part series has helped you in gaining better understanding of how Xcelsius generated SWFs leverage basic Flash variables and BOE.

This week we are going to talk about a session token that an Xcelsius dashboard (SWF) consumes when it is loaded inside of Infoview or Dashboard Builder (Business Objects XIR2). The CELOGONTOKEN is the variable name that is assigned to a session token that BOE creates when you successfully login.

How does Xcelsius consume this token?
As you notice, inside of the <OBJECT> tag, there is a Flash Variable called CELOGONTOKEN. When BOE renders the HTML page, it dynamically inserts the current logon token as the CELOGONTOKEN. Any SWF that uses a Query as a Web Service or Live Office connection will automatically consume the CELOGONTOKEN Flash Variable.

How is the CELogonToken used during SWF runtime?
SWF files that contain a QaaWS or Live Office connectors will automatically search for the presence of a logon token when the connector is executed. With each transaction from the dashboard to BOE, this token is passed back to BOE. If the SWF does not detect a CELOGON token, (when it is loaded outside of Infoview or Dashboard Builder) it will display a login dialogue box.

So now that we have de-mystified the magic that is Xcelsius, let’s think about how we can leverage this knowledge. First, we use Flash Variables and the login token to solve the single sign on issue for multi-layer or nested SWF files within a dashboard. The second use is an Xcelsius dashboard using single sign with BOE outside of Infoview. While I have seen several implementations of this, unfortunately I do not have anything that I can share at this point. Hopefully those of you who are BOE SDK gurus run with this new understanding of how Xcelsius consumes the logon token. If anyone is interested in working together to put something together, I am more than interested to provide the Xcelsius knowledge…

Later this week, I will finish up this 3 part analysis of the Xcelsius <OBJECT> with the CEWebServiceURL and how it helps to improve life cycle management.