Xcelsius dashboards developers who leverage the BI 4.0 BI Launchpad as the content portal for delivering their work, have long suffered from the sloppy interface between Xcelsius and the portal.
First (and foremost), when you publish an Xcelsius or dashboard object (the .swf) into the BI Launchpad (or InfoView for that matter), you lose control over the canvas size. This means that the dashboard will open in a window the size allowed by the user browser and preferences. The impact on the dashboard design can be devastating, rendeing completely unusable in some extreme situation, or at a minimum less then professional looking, as fonts get “squashed” components overlap, and graphics degrade as they stretch or slim down.
This is nothing new, and has been the same situation since XIR2, through 3.1, and now, with 4.0, the problems still remain.
To have complete control over your dashboard presentation, you really should consider hosting it in a different portal, but that is not always feasible. If you are “stuck” with the BI Launchpad, you can use the following technique to address the problem described above, as well as another, less common problem, related to flash crossdomain restrictions. If your dashboard has live data and is making connections to a web service or xml feed, the web service url will have to be fully qualified in the xlf file. The problem will hit you if any of your users use a variation on the host name you used in your web services url. For example, if you use http://myboserver:8080 and your users use a fully qualified name, or even an IP address to get to the server (http://myboserver.mycompany.com:8080), they will end up with a crossdomain error instead of a working dashboard. To overcome this problem, you need to use a dynamic host name, based on the client request.
To address both problems, you can do the following:
First, add a flash variable connection in your xlf. In my example, I called mine host. Use this host flash variable to create a formula in your model that will concatenate the flash variable value with the rest of your web service url. Flash variables are populated on the swf initialization, and the values will be passed to the model before the web service connections are made.
Next, create a directory on your BO web server (tomcat in most cases) and place a .jsp file in it with the following code:
<%
//Initialize var
String host = "";
//Get the host name from the http request
host = request.getServerName();
//Construct an openDoc URL and pass the host name to the swf. Use this url as the content src of the iframe, where you can set the specific height and width
String url = "http://"+host+"/BOE/OpenDocument/opendoc/openDocument.jsp?iDocID=Abvx6T2dOeZNiF8bWJ11Qfk&sIDType=CUID&lsShost="+host;
%>
<iframe src="<%=url%>" height=630 width=1030 marginheight=0 marginwidth=0 frameborder=0></iframe>
Now, create a hyperlink in the BI Launchpad to this file (for example, if your file is called link.jsp, which resides in a folder called links and you wanted to use a relative path, your url would look like this: ../../../../../../links/link.jsp)
That’s it! Your swf is still safely secured in the BO repository, openDoc will only work if the user has logged in properly (or prompt the user to logon if not), so any universe security built into your connection will remain intact, and your dashboard will open using the width and height specified, regardless of the host name the users end up using.
