This document attempts to address the issue of creating/updating so called scenarios for Xcelsius Dashboards. There are various approaches taken by previous implementations (see Introduction and References). We will offer our own implementation.
We thank Rajeep Bhaduri, who helped a lot by providing a fresh look and support when we got frustrated by s/w non-cooperation
(not to mention allowing us to use his own BOE server!)
When developing in Xcelsius there is often a need to have some kind of runtime customization. It can be a different color scheme, that a specific user prefers, or a set of selections which this particular user always makes and would like to always start with.
Xcelsius provides a "Local Scenario" button control. It is supposed to save the state of the entire user session - basically,
the entire underlying workbook. However, for some reason, it only works when there is a very small amount of data,
and after a certain data volume it breaks and doesn't save data anymore.
Even if it worked, SAP documentation states it saves the state on your local machine and it is specific to the deployed version of a dashboard.
This means if a new version of your Dashboard is deployed on a BOE server you lose whatever you saved.
With these restrictions this button has a very limited utilization.
David Gilbertson [1] mentioned several options from various sources. Ryan Goodman [2] also had a good article some time back.
Basically, there are two types of solutions:
We found David Gilbertson's approach more appealing. However, his solution saves information on BOE Web server in a specific subdirectory. We think this is inconvinient and taking us outide of InfoView paradigm. For big organizations this may also represent some security problems, as they have to deal with files, appearing on their web server.
We propose the solution where a rectangular area of an Xcelsius workbook is saved in the user's "Favorites" directory in InfoView. Let's call this rectangular area a "scenario". Our assumption is that a Dashboard developer will place the results of user selections into one worksheet. If we save a big enough rectangular piece of this worksheet, we, basically, are saving all the choices made during the workbook usage. Since this information is saved in InfoView, it is saved there permanently, regardless of the updates to the Dashboard. Obviously, if the dashboard changed significantly and the internal spreadsheet structure changed so much that it invalidates the saved scenarios then the scenarious saved have to be deleted via regular InfoView cleanup process.
The advantage of saving scenarios in Infoview is that the user can find data herself and (if necessary) modify/delete the file directly.
The obvious extension of this solution is to save the files in a public folder in InfoView if those scenarios are to be shared or maintained by a POC.
Reading the scenario into Xcelsius requires using an XML Connector which invokes a Jsp page which, in turn, finds the file in user's "Favorites" and transfers it back to Xcelsius.
Writing the scenario to the user's "Favorites" also requires using a different XML connector which invokes a Jsp page and creates a new file in one's "Favorites". Of course, here we will run into a situation where the file with this name may already exist. We need an override flag to allow replacing the existing file.
We also need an XML Connector which would retrieve a list of possible saved scenaros.
If this approach is used with several different dashboards there is a danger of mixing up scenarious from different applications. The proposed solution solves this by using a system of prefixes.
Can this appoach be modified to be used to save the real data? (Say, a user made all the selections and retrieved the data which
she wants to save in her "Favorites")
Yes! However, the format, in which XML data connector sends the information over, requires some (albeit, pretty rudimentary)
XML parsing to do to make it into a useful csv file.
This modification is beyond the scope of this web article. Our jsp pages preserve the original format transfered via jsp.
Let's assume your Tomcat directory location is D:\Apps\BusinessObjectsXIR3\Tomcat55. Under that directory one can find directory webapps\InfoViewApp\jsp directory.
Let's create a new folder dashboard_cust under it and place the following files there:
| This jsp page reads a scenario from the Myfavorites directory in user's Infoview and returns it to the caller (dashboard) | |
| This html page tests readscenario.jsp page without a dashboard | |
| This jsp page reads a list of scenario files from the Myfavorites directory in user's Infoview and returns it to the caller | |
| This html page tests readscenariodir.jsp without a dashboard | |
| This jsp page writes the file it received from the caller to your Myfavorites directory and returns a "happy" message | |
| This html page tests writescenario.jsp without a dashboard |
We are going to test Java code separately from Xcelius to make sure everything is done correctly, since Xcelsius is not going to help with a good error diagnostics.
Make appropriate changes in HTML files: Change 'myCMS' to your CMS server in all .html files.
Since at this point you don't have any files to work with we are going to start with the "write" part to create a file to be read in in the next step: Type "http://your-infoview-server/InfoViewApp/jsp/dashboard_cust/writescenario.html" in your browser and hit "Enter". You should get a screen which looks like this:
For now do not change the File Contents part of this screen. Just enter your user_id and your password, then hit "Save". The file with the name "MY_DASHBOARD_BORIS.txt will be created in your Myfavorites and its contents will be what you saw in File Contents area. The screen which will come back will be:
and will just inform you that file creation in your 'Favorites' was successful.
If you try to hit "Save" button again you will get this message:
If you are going to save scenarios with Xcelsius you are going to need this functionality - to prevent accidental user file overwriting.
Just click on "Yes" in an "Override" part of the screen and then click "Save". You will get a slightly modified message:
Now, let's create one more file in our Favorites: Change the file name to boris2, and in a File Contents textarea modify row1_col1 to row1_col1_boris and row2_col1 to row2_col1_boris like so:
and hit "Save". You will get something like this:
If you successfully performed these tests your "Save Scenario" functionality works.
Type "http://your-infoview-server/InfoViewApp/jsp/dashboard_cust/readscenariodir.html" in your browser and hit "Enter".
You will see this screen:
Enter your userid and password and click on "Retrieve". You will see something plain like this:
However, if you click on your web page "View Source" menu item you will see a an xml which looks like this (not sure why JSP generates so many empty lines):
If you successfully performed these tests your "List Scenarious" functionality works.
Type "http://your-infoview-server/InfoViewApp/jsp/dashboard_cust/readscenario.html" in your browser and hit "Enter".
Enter your userid and password and click on "Retrieve". You will get something like this:
Actually, as in case of Retrieve Scenario List if you look into a page source it will reveal some other markings:
you may also try to retrieve the file boris2.
If you successfully performed these tests your "Read Scenarious" functionality works.
If you go into Infoview you should be able to see text files "MY_DASHBOARD_BORIS.txt" and "MY_DASHBOARD_BORIS2.txt" in there. In fact, the main purpose of writing these jsp files is to place your scenarios in your own directory as "normal" files.
We are now ready to move on to testing this with Xcelsius:
But first, a couple of words of explanation:
Xcelsius can be run from your client machine or as a part of Infoview. While we assume your main modus operandi is calling it from the Infoview
we cannot ignore the fact that while developing you need to run it locally. When Xcelsius is called from Infoview it gets CELogonToken
(see Ryan Goodman[5]), but when you call it from your client machine it doesn't receive CELogonToken.
We couldn't find a good way to repeat the QaaWS effect when the first Connector is asking for a user_id and a password, and the rest of the calls
do not require entering your cridentials (suggestions are welcome!). So, we opted for passing your userid and password in clear text when you are
running Xcelsius from your local machine. Once you are ready to deploy you can remove the embedded password from the Xcelsius. If your security
personnel is panicing about this, you may remove the corresponding logic from your jsp files and debug your code by constantly deploying it to Infoview and running from there.
Download the Xcelsius dashboard here testsavescenarioboris.xlf
The dashboard imitates having 8 parameters which are displayed on it. The logic reads data into these 8 parameters, saves your values under the name provided for you, and warns you about the override. The parameters are actually saved/read as cells Parameters!A2:D3.
Open it up and modify the server name, username and a password:
Call Preview. Your screen will look similar to this:
Click on "Get Scenario List" buttom and when you click on a combobox control you should be able to see the list of scenarious you created during your jsp debugging:
Select 'BORIS' and hit "Load" button. You will see the content of your BORIS file loaded into the parameter area of your dashboard.
Now, type in BORIS4 into the combobox, change any values in Parameters and hit "Save" button. It will combe back with a little message at the bottom: "Created file "MY_DASHBOARD_BORIS4 in your Favorites".
If you try to save it again you will get a message that the file already exists. Check the "Override" checkbox and Xcelsius will save your parameters.
If you deploy this dashboard the inner behavor changes. In the Datamanager we defined a Flash Variables connection:
When we were running locally, it didn't return any values and as a result our dashboard was calling other three XML Data Connections with the cms/user_id/password. Now, that we are calling this dashboard from the InfoView, we are not passing userid parameters when calling jsp. Instaed we are passing CELogonToken parameter. When jsps see this parameter they are trying to connect to CMS using this token and don't require user id/password. You can see the CELogonToken displayed in the appropriate label.
However, you may get an infamous "Crossdomain security problem". In this case talk to your BOE administrator and create a crossdomain.xml file at this location: D:\Apps\Business Objects\Tomcat55\webapps\ROOT\crossdomain.xml with this content:
If you went through all these screens successfully, this means you deployed the appropriate jsp files and now have a sample dashboard to play with to implement your own logic when to save/load parameters.
What kind of improvements can we see?
Perhaps, a "delete" functionality, though it seems like an overkill, since we may delete/modify these files directly in infoview.
Personally, I would like to implement the functionality of QaaWS, which asks me for a userid/password once and then creates a CELogonToken. This would be a good way to learn some internals but it is not critical to the dashboard behavior, unless, of course, you are planning to deploy it as a stand alone application.