Xcelsius CEWebServiceURL and Life Cycle Management

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.

Xcelsius Single Sign on with CELogonToken

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.

Xcelsius Flash Object Basics

by Ryan Goodman

The first and most obvious observation that you make when reviewing this example code is the presence of all attributes twice; one set within the <OBJECT> and one set within the <EMBED>. <OBJECT> is used for Internet Explorer to support the Flash player, which is an Active X control. <EMBED> is for other browsers that support other Flash Player installs. There is a wealth of content on the internet about these methods and using attributes, but I will move on to the 2 most important one to us: SWF source file path and Variables.
Below is the code I will be elaborating on…


SWF Source Path
In this case I am referring to the physical location where your SWF file reside, relative to the HTML page that it is loaded inside. In this scenario where we are using of BOE XIR2, they use a relative path using “opendoc/documentdownload” which uses the same syntax as opendoc.jsp. The document download syntax declares an iDocID to identify the SWF source file. You can re-use this code when loading Multi-Layer (Parent/Child)dashboards inside of BOE.


Variables
An Xcelsius generated file is capable of consuming variables from HTML using the Flash Variables feature. When loading flash variables you want to separate each variable with an “&” symbol, and individual values should be comma separated. If you look at the code below the syntax is slightly different in the <OBJECT> from the <EMBED>. The next tow blog articles will discuss not only how the SWF leverages these variables, but how you can take this new knowledge further when you plan your dashboard project.