Answer: There are a few application variables that BusinessObjects provides for use when a user logs into InfoView, one of which is BOUSER.  BOUser is the variable for the userId that is logged in and can be used when Xcelsius is aware of the user session.  The user session is passed to Xcelsius via a flash variable that has been made available in XI for this purpose.  It is called, CELogonToken.

BOUSER contains the value of the userId of the user logged in.  It can be used to provide user-specific row-level security through the universe design by adding a self join to a field containing the userIds in your data.  With XI3.1 Designer, this can be applied at the class level (across all objects in a class), or through the traditional method of being applied just when objects from that specific table are used in the query.

Here is an example of how this variable is applied:
Note that the self join is applied against the Manager field.

The Manager field for eFashion contains usernames like “Queen” and “Tuttle”.  For this example, we have added these as users into our CMC.

In QAAWS, I have created a web service to return Manager and their corresponding Store.  This query automatically prompts for the BOUSER since the SQL contains the @Variable(‘BOUSER’) restriction.

In Xcelsius, I have referenced this QAAWS with the appropriate connection defined and entering Name of Manager and Store name results into cells that are viewable through a spreadsheet component.

IMPORTANT: QAAWS will return a promptValue invalid error message if a valid value is not declared as a default for bouser.  Make sure you point bouser to a cell in the Excel spreadsheet of your Xcelsius design and input a valid userId as a default.

In order for Xcelsius to know the BOUSER userId of the user logged into BO, Xcelsius needs to be aware of the session.  If you enter a login and password to the QAAWS connection, that username will be used all the time.  Instead, these entries should be left blank.

If they are left blank, then the users will be prompted to log into QAAWS when they attempt to refresh the QAAWS query from the dashboard. 

For both performance and ease of use, it is usually desired that the users continue using their existing session for a single-sign on method.  To do this, a flash variable connection should be added which includes the range name CELogonToken.  This hands the existing session token over to Xcelsius seamlessly.

The BOUSER or userId is not viewable in the token value as displayed.  The token, however, makes this application variable available for use as the Login value passed to the QAAWS connector upon refresh.

In the end, my excel spreadsheet design looks like this:

I export the Xcelsius dashboard to the SAP BusinessObjects Platform (note that an Enterprise license is required for this functionality).

Then, I log into InfoView as Tuttle and view the dashboard. When I click the refresh button, the Manager Tuttle and his/her store gets returned.

Incidentally, the default value of Queen is never used.  The default is only to allow the bouser variable to load with the QAAWS definition, but only the actual user logged in ever gets passed to the query.

In this blog I will discuss 2 methods, both of which are valid and are useful ways to organize dashboard data.  Deciding as an organization which approach you adopt can help with the process of taking up someone else’s project. 

 Some Xcelsius developers like to use a method of having all the data that is being used in the dashboard on one (or more) tab/s of the Excel spreadsheet, and then as you need to use data for display, using a series of vlookups or match & index functions for displaying data on charts, which they layout on other tabs of the spreadsheet.

My preferred method is to spread the layout in such a way that the names of the Excel tabs generally correspond to the functional area on the Xcelsius dashboard, perhaps even the same name of the Xcelsius  tab (Either the Tab Set Container or the Label based menu, is what I’m thinking of), so that all the data being expressed on that “page” of the dashboard is on one tab in the Excel spreadsheet behind the scenes. 

I like to have the data insert & any manipulations I have to do for expressing that data nearby the loaded data, so that it is all in one place & I can find it easily.  The only difficulty with this is when you have many components on one “page” or you have to create several aggregate levels to display.  Spreading it out & spacing it can become an issue, and this is where again, labeling the spreadsheet is so important.  (But aren’t we glad that if we move data around on the spreadsheet that the links follow, for those of you who have been using Xcelsius since the 4.5 days!). 

This approach, of course, assumes you have the aggregated data to work with!  Which leads back to my previous blog regarding data connectivity options.   If I have to use QaaWS, I end up having to do a lot of manipulation in the universe to get the data to look or be ordered the way I want to use it in Xcelsius.  I usually have to end up making many of what I call, “dimensionalized measures” when I want to end up with a crosstab result.  So I have a measure for Jan Sales, Feb Sales, etc.  Very tedious.  Sorting is another  issue that is often easier addressed in the universe, but also can be labor intensive.  

Live Office gives me the option to create crosstabs and sort the data in any way I wish and I can also have multiple tabs to aggregate the data at different levels (YTD, MTD,  past 30 days, etc).  The problem that I so often bump into with this approach is the amount of data when we get down to the detail level.  We have all experienced poor performance any time we go over the 512 row default and horrible performance when we approach 1000 rows. 

All of these are reasons why I enjoy using the InfoBurst XDS or XDM option, as it addresses all these issues, plus gives me many more options.  The Intelligent Cache syntax of this tool is by far the most exciting feature, in my opinion.  Using their syntax, I can pass parameters to the XML url call and only return the rows of data I wish to display.  For example, within my xml url call, I can add syntax that returns …. YEAR=2009;DIVISION=HPD;DEPT=23.  This ability to extract just the rows of data I want to display helps keep my dashboards very responsive, since I am not loading it down with too much data.  It also gives me the ability to go to a much more detailed level than I would have been able to with QaaWS or LiveOffice.

XDS or XDM also has syntax to return unique values of a particular column from an xml data set which I can use for  my selector.  My selector will always have accurate values, as it is loaded from the current xml cache, rather than from a hard-coded list in my Excel spreadsheet which may not be up-to-date.

And, I have the flexibility to create these large XML data sets from a Web Intelligence document or by writing a query, directly to the database, or even from an Excel spreadsheet, and any combination of all three!

This is a brief summary of the differences between these 3 options which may be helpful.

QaaWS is a BusinessObjects web service that access BusinessObjects universes (and only universes) to pull back data.  Each time a dashboard is opened and selections are made, a real-time query is launched against production data, which, depending on the amount of data requested, can take many long seconds or minutes.  I have not found it to be very effective, and the few companies that do use it, have highly summarized tables in their data warehouse to use for this purpose (i.e. lots of preparation work).  The only upside I see to this method is that security is already in place based on BO user ids, and, real-time data retrieval (if that is the requirement). Large amounts of data (i.e., more than 500 rows of data) returned by the web service will significantly slow down the performance of the dashboard.  

With Live Office you can access Web Intelligence or Crystal reports as your data source and use the functionality of these reporting tools to summarize, crosstab and format your data.  The advantage is that you can schedule these reports to refresh in BO (InfoView) and then use the latest instance of that report for your Xcelsius data source, without waiting for it to refresh.  The disadvantage is that it requires users to log into BusinessObjects every time they access the dashboard.  (Supposedly you can use single-sign-on with this, but I have not seen it working anywhere).  Obviously, if you want to deploy this solution outside of BusinessObjects, like hosting the SWF file on SharePoint or an Intranet, most companies do not like having to sign on again.  Also, it would not work if you want to deploy outside the network (outside a firewall).  There have been many posts on the forums about the “flakiness” of LiveOffice, often losing connections and unable to refresh reports.  Since Live Office has to hold the data in the Xcelsius spreadsheet, the amount of data returned will have a negative impact on dashboard performance.  This last item has been the biggest barrier to our customers, who often wish to show granular data in their dashboards, or a significant amount of historical data.

InfoBurst XDS and XDM were designed to overcome these obstacles.  XDS can use Web Intelligence or Desktop Intelligence reports as data sources for pulling data, which it can refresh overnight (based on a schedule) and convert this data to xml.  XML is the fastest way to load data into Xcelsius.  XDS does not require a BusinessObjects login.  XDS also has the option of accessing a database directly (any database that can be accessed via an ODBC connection) through SQL queries, which can also be scheduled and converted to XML.  XDS also provides options for distributing the dashboard (putting on a network share, an intranet site, or as an email attachment or embedded in an in-line html email).  The biggest advantage, though, is the Intelligent Cache feature which allows dashboard developers to “cache” a very large set of data (I am currently working on a data set of over 18,000 rows of data), and then pass parameters through the xml code, based on selections the user makes on the dashboard, which then returns the small data set needed for that particular chart.  (On the above example I am passing parameters, based on drop-down menus, for Division, Plant, Department, Day and Shift, which returns the 6 rows of data I need to display – shift hours per day per Department.)  Since the dashboard is only loading these 6 rows of data, obviously the performance is very fast.    We recently converted a QaaWS dashboard where the data loading time when changing customers went from 2 minutes or so to less than 10 seconds, using Intelligent Cache filtering.