It has been a number of weeks since I last posted on Performance Testing in BI 4.1 ... I could make excuses but let me just apologize and move forward with the interesting concepts contained herein.
This last blog in the series will demonstrate how to customize a JMeter test plan for use with Analysis for OLAP. The workflow leveraged in the test plan (found here for those who haven't read the previous posts) creates an Analysis Workspace based on a HANA Calculation View, adds a dimension, and inserts a bar chart. The fact that it is based on HANA has no impact on the test plan and those of you using SQL Server Analysis Services or SAP BW can utilize this equally well.
Let's start by reviewing the state of the transaction controller that handles the Analysis for OLAP logic:
In order to work with A-OLAP we need to extract 3 values from different iterations of the mddesigner.jsf method. This is the java server face that implements the Multi-Dimensional (i.e. OLAP) designer in the browser. To begin, we need to pull a request token value out of the first request. We also need the java server face View State, which we saw previously in the BI 4.1 logon process. You can count on this parameter being present any time you see a request with a .jsf extension.
Let's jump in to the first regular expression extractor, which I've labelled requestToken:
This token value represents a user session on the Analysis APS. Specifically, the Multi-Dimensional Analysis Service or MDAS is the process that the requestToken corresponds to. The format of an MDAS request token would look something like this:
ghQbjqT3erhH9j71IBfbVw==
For ease of copying the regular expression that is used in this extractor is:
name="designerForm::requestToken" value="(.+?)"
This tells JMeter to look for a value in a hidden form called designerForm::requestToken and extract it for later use. You don't need to remember much about this method other than it is the first instance of mddesigner.jsf called and we need both the requestToken and ViewState to be returned from it. This first request is invoked with the bttoken we extracted from our initial logon and after that we solely use the 2 MDAS specific values.
Next we need to attach a 2nd regular expression extractor to the same instance of mddesigner.jsf and retrieve the JSF View State. I talked about this as part of the logon to BI 4.1 (you can find the write up here) but in short, the value helps the application server keep track of which requests are related to specific clients. It looks something like this:
j_id23
The regular expression extractor for ViewState is as follows:
and our regular expression is:
name="javax.faces.ViewState" id="javax.faces.ViewState" value="(.+?)"
You could probably get away with a shorter regular expression but for completeness I like to get the entire XML pair. Once this is complete, we can use the text replacement process I explain in this SCN Document to update the successive mddesigner.jsf calls to work with our distinct session.
After sorting out those details, we're left with one final piece of dynamic data to extract. I mentioned above that we will be inserting a chart into this workspace, and the last thing we need to extract are the images associated with the bar chart. The chart is comprised of 2 elements, [1] an overview, and [2] the main pane as shown below:
The result of this is that we need to retrieve 2 different images, and this is the first time I will cover extracting multiple values from the same response so pay attention :smile: !
We now attach our final regular expression extractor to the instance of mddesigner.jsf immediately preceding the MDAnalysis.chart requests. I mentioned the 2 elements of an A-OLAP chart, so we can expect to see 2 distinct calls to MDAnalysis.chart. A-OLAP refers to the image content as a payload, so that's what we'll name our regular expression extractor. First, we'll configure the extractor as follows:
There is one important caveat here, in that we must check the standard Body of the response, as opposed to the unescaped Body I normally use. The reason is that there are escaped URL characters in the payload string, such as:
MDAnalysis.chart?payload=6b9627b3&
If we use the unescaped version of the response body our regular expression will not match anything. An example of the payload is:
6b9627b3
As I noted above, this response is going to contain 2 payload values and we need to instruct JMeter to save both of them. In the past, we've always used Match No. 1, indicating that JMeter should save the first instance of the regular expression that matches (if we knew that we always needed the 2nd instance of a regular expression, for example, we would use 2 instead). Here we will use a value of -1 for Match No. instructing JMeter to save ALL occurrences of the matching regular expression. If the regular expression matched 100 times, JMeter would create 100 instances of the payload variable for us to refer to later.
Now that we have both instances of the payload, we need to tell JMeter where to use them. We will apply the payload to the 2 instances of MDAnalysis.chart in the proper order. I admit that this tripped me up the first time I tried it, so let me share some of the methodology with you as well. The 2 instances of payload will be stored by JMeter in the format:
${payload_1}
${payload_2}
The 2 chart values that these variables correspond to are:
designerForm:HorizontalBarChart1_main
designerForm:HorizontalBarChart1_overview
In the image above, I have labelled the overview as #1 and the main pane as #2 ... I did this for a reason. The requests are logged inversely, that is, the request for ${payload_2} / designerForm:HorizontalBarChart1_main actually comes first! I was able to determine that was the case by looking at a Fiddler capture of an interactive request I performed in my browser:
Here, the payload of the main pane is 6b9627b3 and the payload of the overview is 4265525a. By reviewing the response body of mddesigner.jsf I can see the order these 2 values are delivered in:
- MDAnalysis.chart?payload=4265525a&component=designerForm:HorizontalBarChart1_overview
- MDAnalysis.chart?payload=6b9627b3&component=designerForm:HorizontalBarChart1_main
I am therefore able to determine that the overview is ${payload_1} and the main pane is ${payload_2}. Thus, the 2 instances of MDAnalysis.chart end up looking like this:
Main Chart:
Overview Chart:
Once these steps are complete, you have a fully functional test plan that tests 3 different BI Clients! You can use the View Results Tree and Debug Sampler explained on the Performance Testing Wiki - Description of JMeter core components section to ensure your getting the desired results. Here is an example of what your View Results Tree might look like:
Note that I can see the actual image that was returned by the MDAnalysis.chart method to see that it matches what you would find in your browser. Similarly, you can do this to confirm report data is coming back as opposed to an error message.
I welcome your feedback on what BI Clients or Platform operations you would like to see documented next. I hope this blog series has given you an understanding of how powerful JMeter can be when used properly, and that performance testing is within your grasp regardless of how large or small your organization is. By leveraging performance testing in an appropriate manner we can all deliver better BI and do justice to this wonderful and expansive suite of tools.
- SAP Managed Tags:
