UPDATED: See a HOWTO for OBIEE and LoadRunner here
LoadRunner is a tool from HP (bought from Mercury) that can be used to simulate user activity. It supports a whole host of protocols but for OBIEE I’m obviously using the Web one.
There are two flavours, “Web (Click and Script)” and “Web (HTTP/HTML)”. The latter simply shoves HTTP requests at the server, whereas “Click and Script” simulates mouse and keyboard entry and thus is more appropriate for this user-based application. I’m not sure if this is actually the case[/edit]
You can write the script from scratch if you’ve more time than sense, or you can “record” a session where LoadRunner scrapes all activity from a session and then generates a script based on it. From this you can then refine your script. A script is called a VUser (Virtual User).
It’s a good idea to have mapped out what you are trying to test and how, rather than just randomly clicking through the application. Doing this has two disadvantages:
- Your script will be a pig to debug & customise
- Your script will be little use other than replicating multiple instances of randomly clicking.
Much better to do something simple like this:
- Login (record it under the “vuser_init” action)
- Navigate to a dashboard
- Logout (record it under the “vuser_end” action)
Once you’ve got your simple script you can then get funky. Parametrise the username and password, and then the dashboard that you select. Suddenly what looked like a simple script can be set to go and open all your dashboards!
Validating VUser script
Now you have a simple script that you should be able to replay. Using the Verify Replay option you can test what you’ve recorded. On replay I got “No Errors Detected” :
but the screenshots thumbnails showed an difference :
Going to View -> Test Results and examining the full-size screenshots showed the error ! Error : Response from server contained an error
Doc ID 735158.1 on Metalink details this problem, but doesn’t have a solution. The error message is apparently not from OBI but the webserver. I don’t know enough about the web technology to trace this through to source. In the HTML there is always a placeholder for a message :
I did a detailed examination of the sawserver log (using detailed logging level) but couldn’t find any errors. I checked the analytics web app log too, and the oc4j and apache logs. All turned up nothing. Using Fiddler2 I set up a trace of the network traffic from LoadRunner to OBIEE (define Fiddler2 as a proxy in LoadRunner) - and the blasted thing worked! No error! So then I removed the proxy setting and again it worked, no problem. How frustrating.
Taking a step back, I restarted sawserver, ran the Replay and got the error again. Changed to go via Fiddler2, no error. Bounced sawserver again, ran the Replay through Fiddler2 first this time - and got the error. Phew. So it looks like it’s maybe cache-based, and at least it’s repeatable.
Analysing the Fiddler2 output revealed:
- DashboardErrorDiv is populated in res/b_mozilla/dashboards/portalscript.js saw.dashboard.showError, which is an error handler
- The error itself is thrown in res/b_mozilla/common/ajax.js (header indicates that it is for Server Calls - used to retrieve XML from server)
FireBug was also useful for backing up the analysis in capturing known-good sessions.