OATS: Tie All Processes Together — from OpenScript to Scenario

We have been blogging different topics on OATS since 2013.  In this article, we'll tie all processes together.

In [1], we have demonstrated how to create an open script for load testing using CRM FUSE (i.e. a Fusion application).  Assume you have done that, the next step will be testing by clicking on the  Playback button:

If the test succeeds, you should see Passed status in the Results.  Since we have hard coded user name (i.e., SALESREPUSER00001) in the Post Data step, the next step will be setting up databanks in OpenScript and then configuring scripts to use databanks.  See [2] for details.

But, before we do that,  I usually clean up steps a bit by removing steps that loaded cookies or images (i.e., png files).  In my experience, they were not useful.  Since we will migrate OpenScript file from Windows to Linux, the cookie recorded might be useless.  Also, we would like the whole zip file self-contained.  By removing image files, we don't need to worry about the dependency of script to the images (i.e., where to load them from).  Anyway, before you remove anything from the project.  Save the project and make a backup first.

After deleting steps involving either cookie or images, you need to playback steps to make sure everything still works OK.  You then proceed to iterate the test using multiple unique users.  To create databanks needed for the test, we have copied it from a previous project.  Noted there is a new folder named databanks in our new project folder (i.e., FUSE_Saleopty_oct01_wrk).

Inside the databanks folder, there are two files:

• UserName.csv
• UserName.csv.index3

You may delete the index file (i.e., UserName.csv.index3) because it will be re-generated by OpenScript later.  Inside UserName.csv, you will find the following entries:

UserName
SALESREPUSER00002
SALESREPUSER00003
SALESREPUSER00004
SALESREPUSER00005
SALESREPUSER00006

Then you follow [2] to substitute a variable for the hard coded user name (i.e., SALESREPUSER00001).  Make sure you have selected the correct csv file (i.e., the one under your new project folder).   Note that we have set up all users to share the same password in WebLogic Server. 

Now, we can test the script with multiple virtual users by clicking on "Iterate (Alt+I)" button:

Let's iterate the test for no more than 3 times:

After the testing, you then export a self-contained zip file (note that we have excluded some unnecessary data from the export):

Read [3] for more details on how to export and import scripts from Windows to Linux.  To import OpenScript into Oracle Load Testing (OLT which is run on Linux in our case), you start up OLT and select Tools > Import...

Note that when you migrate OpenScript zip file from Windows to Linux, copy it somewhere outside the $installDir/OFT folder. On the Import File dialog, open it and specify Default Repository as  your destination which is the OFT folder.

After import the OpenScript, you can find it from the Default folder (highlighted on the diagram).  If not, exit OLT and restart it.  Clicking on the script named FUSE_Saleopty_oct01_wrk, this will allow you start building a new scenario.  However, with the default setup, you can submit the scenario and start a test immediately:

Let the test run for a while and then click the same button to stop it.  Note that it will take a while before the test fully stops.  If you don't see any Failed transaction, it means your script is OK.  Then the next step is to configure parameters by selecting "Build Scenarios" tab.  This will bring you back to the window before you started the test.  For advanced editing, you can click on the "Configure all parameters" icon.  This allows you to edit scenario details.

For our tests, we have set the following:

• # VUs: 200
• VU Pacing (Think Time): Recorded/Random
• Lower: 15 (percent)
• Upper: 185 (percent)

which mean OLT will generate 200 virtual users using recorded delays, but with some variations (i.e., randomly ranged from 15% to 185% of the original delay time).  The next step is to "Set up Autopilot".  After clicking on the tab, this will allow you to control the timing and other advanced features:

In our tests, we only need to set up stop time (i.e., after 3 hours and 20 minutes).  Note that our benchmark utilizes this new scenario in a refworkload framework, which is composed of a few Linux shell scripts that drive the whole process.  For this reason, we didn't use other advanced features such as ServerStats or Scenario Profiles as shown above.

Finally, to save your new scenario, select Scenario > Save as.  Be warned that this writing is based on an old installation (i.e., OATS 12.3.0.1 Build 376) and might be a bit different from newer versions.^[4]

References

1. How to Create Load Testing Scripts Using OpenScript (Xml and More)
2. How to Configure Scripts to use Databanks in OATS (Xml and More)
3. OATS: How to Export and Import Scripts from Windows to Linux
4. Oracle Application Testing Suite
5. Auto-Correlating Session IDs in Oracle Application Test Suite (Xml and More)

How to Configure Scripts to use Databanks in OATS

This article is one of the Oracle Application Test Suite (OATS)^[1] series on Xml and More, which began with the following articles:

• Auto-Correlating Session IDs in Oracle Application Test Suite (OATS)
• Removing "Compatibility setting is not supported" Warning before You Do OpenScript Recording

In this article, we will show you:

• How to set up databanks in OpenScript^[4]
• How to configure scripts to use databanks

Databanks

Databanks are used to hold input data that can be automatically fed into your Web application during Load Testing^[5].  In this article, we have created a new script in OpenScript using ADF Load Test Module for the load testing of CRM FUSE (i.e., Fusion CRM with FUSE interface).

At the login step (i.e., step 2), we have used the following credentials:

• SALESREPUSER00001 /Welcome1

during script recording in OpenScript.  To do load testing, we need to use different users to drive our Web application .  In the following, we will show you how to achieve that.

Substitute Variables

After clicking the Post Data node, list of parameters used in HTTP Post is displayed.  As you can see that the value of userid was recorded as SALESREPUSER00001.  So, we need to configure it to use a databank.

After clicking on Edit..., it brings up the Parameter message box.  Let's click on the second Substitute button next to the Value field.

This brings up Substitue Variable window.  Next we need to add new databank before we can use it for variable substitution.

Note that before we started OpenScript, we have copied an existing databank named UserName.csv in the the subfolder of our workspace (i.e., FUSE_Saleopty_oct07_wrk).  Therefore, you have seen it appearing in the right panel.  For our script, we have chosen to store our databank "Relative to current script".

If you open the databank, you can see different user names are stored in it.  Note that all users will use the same password in our case.

After adding new databank, the value of userid has been updated to:

Finishing variable substitution, a new node (i.e., GetNextDatabankRecord) was shown next to "Run" node.

You can click on the new node to edit it.  But, the default (i..e, Next Record) works for us.

After we have configured our script to use databank, we can test it using "Iterate" playback.

Clicking on the Iterate button, this allows you to specify how many iterations you want to test.  In the following example, we have set it to be three times.

Next Steps

After testing our script running OK in the OpenScript (which runs on Windows only), we proceed with the following steps:

• Export script to a ZIP archive (i.e., FUSE_Saleopty_oct08_wrk.zip)
• Copy the ZIP archive file to the Oracle Load Testing (OLT) server (which runs on Linux)
• In OLT, we have imported the OpenScript ZIP to a scenario.
• After setting up Autopilot, we have run load testings using the databank to feed CRM FUSE with different users.

A new article describing the above steps will be posted in the future given time permitted.

References

1. Oracle Application Testing Suite
2. Auto-Correlating Session IDs in Oracle Application Test Suite (OATS) (Xml and More)
3. Removing "Compatibility setting is not supported" Warning before You Do OpenScript Recording
4. OpenScript for Load Testing Script Troubleshooting (Tutorial)
• OpenScript is a scripting platform for creating automated test scripts in Java.
• Version: 12.3.0.1 Build 376 was used in this discussion.
5. Oracle Load Testing
6. Oracle Application Testing Suite Downloads
7. OATS: Tie All Processes Together — from OpenScript to Scenario (Xml and More)

Auto-Correlating Session IDs in Oracle Application Test Suite (OATS)

Similar to HP LoadRunner, Oracle Application Test Suite (OATS)^[1] is an automated performance and test automation product from Oracle for monitoring system behavior and application performance. It's especially useful for Oracle Fusion Application's performance evaluation.

Oracle Open Script (or Oracle Functional Testing) is one of the components in OATS, which is integrated with Oracle Load Testing and Oracle Test Manager. It is also a load testing script generator, which is integrated with Eclipse to support script development and debugging. In the current offering, it only runs on Windows.

Correlation

Correlation of dynamic session values is a major task for load test scripting^[2]. When a server in AUT (application under test) exchanges dynamic session values with the browser. OpenScript can auto-correlate dynamic session values—For example session IDs.

What's Session ID?

Session ID is used in session tracking.  Session tracking enables you to track a user's progress over multiple servlets or HTML pages, which, by nature, are stateless. A session is defined as a series of related browser requests that come from the same client during a certain time period. Session tracking ties together a series of browser requests—think of these requests as pages—that may have some meaning as a whole, such as a shopping cart application.

Session ID is a piece of data that is exchanged between the application's web server and the user agent (or browser). It is typically used to identify a specific user logged on to the application for a particular duration of his/her visit (or session).

Session ID is given per Session. It is often destroyed when the user logs off from the application. Next time you visit the same site, you will have a different session ID. The correlation task is to identify these dynamic values and substitute variables for them in the load testing scripts.

As you know, Oracle Fusion Applications maintain a rich set of dynamic session values. Correlation done manually requires in-depth knowledge of the application itself and can also be error prone. Fortunately, most correlations needed for successful playbacks can be done automatically by Oracle Open Script. For example, it auto-correlates Session IDs.

Different Ways of Storing Session IDs

There are multiple ways for a web page to pass session ID to a web server. Session ID can be stored in:

• Cookie^[6]
• URL
• HTML page

Storing Session ID in Cookies

Cookie is the text information that application places in the client's hard disk. Browser sends the cookie back to the application to keep the state. On WebLogic Server, use of session cookies is enabled by default and is recommended, but you can disable them by setting cookies-enabled property^[3] to false.
If cookie is enabled on the browser, you often find the following entry in the HTTP headers:

• JSESSIONID=HDe6IhnMFZFtKrVsNi0eUsZ0NWaaIaw_OT2vW7CDpZ8sfz9v4Hqf!-777642468!-553692576;

Note that JSESSIONID is the default session tracking cookie name used by WLS. You can configure WebLogic Server session tracking by defining properties in the WebLogic-specific deployment descriptor,weblogic.xml. For a complete list of session attributes, see session-descriptor^[3].

Storing Session ID in URL

Session ID can be sent back to the server as a string appended to URL following a question mark (i.e., "?")

• http://samplesite.com/xxx?session_id=7AD3...

On WLS, you can enable URL rewriting by setting url-rewriting-enabled property, which encodes the session ID into the URL and provides session tracking if cookies are disabled in the browser. However, storing Session ID in URLs is less secure than storing it in cookies^[5].

Storing Session ID in HTML Page

Finally, session ID can also be stored in the hidden field of a HTML page and submitted by the Post Command:

• <input type="hidden" name="sessionID" value="54321abcd">

Most user agents (or browsers) allow you to store information in a HiddenField control, which renders as a standard HTML hidden field. A hidden field does not render visibly in the browser, but you can set its properties just as you can with a standard control. When a page is submitted to the server, the content of a hidden field is sent in the HTTP form collection along with the values of other controls. A hidden field acts as a repository for any page-specific information (including Session ID) that you want to store directly in the page.

References

1. Oracle Application Testing Suite
2. OpenScript for Load Testing Script Troubleshooting (Tutorial)
3. weblogic.xml Deployment Descriptor Elements
4. Extended Session ID format in WebLogic Server (12.1.1)
• A server startup flag, -Dweblogic.servlet.useExtendedSessionFormat=true, retains the information that the load-balancing application needs for session stickiness. 
• The extended session ID format will be part of the URL if URL rewriting is activated, and the startup flag is set to true.
5. Why is passing the session id as url parameter insecure?
6. OAM 11g Single Sign-On and OAM 11g Cookies
• Note that the cookie model is different between 10g and 11g.
7. OATS: Tie All Processes Together — from OpenScript to Scenario (Xml and More)