Loadrunner Correlation Part - 1

Loadrunner Correlation:

Introduction:

VuGen, when recording a script, simply listens to the client (browser) talking to the server (Web server) and writes it all down. The complete transcript of everything that was said, the dates and time, content, requests, and replies can be found in the Recording Log (for Single Protocol) or Generation Log (for Multiple Protocol). The script is an easier to read version of this. The main difference is that the script only contains the client’s communication.

If you imagine that VuGen is an impersonator pretending to be the client (browser), the script tells VuGen what to say to the server to successfully fool it. You want the server to believe that VuGen is a real client, and thus send it the requested information.

This script has the hard-coded information of the original conversation (Browser session) that occurred between the client and server. This hard coded information may not be enough to fool the server during replay however; it may have to be correlated.

What is correlation:

Correlation is where the script is modified so that some of the hard-coded values in the script are no longer hard-coded. Rather then sending the original value to the server, we may need to send different values.

For example, the original recorded script may have included the server sending the client a session identification number, something to identify the client during that particular session. This Session ID was hard-coded into the script during recording.

During replay, the server will send the client a new Session ID. You need to capture this value, and incorporate it into the script so you can send it back to the server to correctly identify yourself for this new session. If you leave the script unmodified, you will send the old hard-coded Session ID to the server. The server will look at it and think it invalid or unknown, and so will not send the pages that have been requested. Replaying a script with an old Session ID will not successfully fool the server into believing it is a client.

Correlation is the capturing of dynamic values passed from the server to the client and back. You save this captured value into a parameter, and then use this parameter in the script in place of the original value. During replay, the replay engine will now listen to what the server sends to it, and when it makes requests of the server, send this new, valid value back to the server; thus fooling the server into believing it is talking to a real client.

Why do I have to correlate?

If you try to replay a script without correlating first, the script will most likely fail. The server will not reply to the requests it sends. Either the Session ID is invalid so the server will not allow you into the site, or it will not allow you to create new records because they are the same as existing ones, or the server will not understand your request because it is not what it is expecting.

The following diagram illustrates a typical example where correlation is required. While recording, the client request for page A with the ID “123.” This information (123) will be intercepted by the Web recorder and placed as a hard-coded value in the script. During replay, even though the ID is supposed to be “456,” the Web Vuser sends “123” to the server causing a replay failure. You will need to correlate this value so that the correct data is sent to the server.

What errors mean I have to correlate?

There are no specific errors that are associated with correlation, but there are errors that could occur because a value has not been correlated. For example, if an invalid Session ID is sent to a Web server, how that server responds depends on the implementation of that server. It might send a page specifically stating the Session ID is invalid and ask you to log in again. It might send an HTTP 404 Page not found error because the requesting user did not have permissions for the specified page, and so the server could not find the page.

In general, any error message returned from the server after the script makes a request that complains about permissions can point to a hard-coded value that needs to be correlated.

Functions for correlation:

web_reg_save_param: This is the latest function with some extra features for a more powerful usage.

The syntax is as following: web_reg_save_param ( “Parameter Name” , , LAST );

Each of these parameters is a pointer to a string. That means that if they are entered as literal text, they need to be enclosed in quotes, with each parameter separated by a comma. The supported attributes include LB (Left boundary), RB (Right boundary), RelFrameID, ORD, Search, SaveOffset, SaveLen, and Convert. These attributes can appear in any order because they contain within them what they are. Detail information about each attribute can be found on the function reference online.

Web_create_html_param,Web_create_html_param_ex : Both of these functions are for backward compatibility only. It is recommended that you use the web_reg_save_param function. If you need to use this function for some reason, please refer to the function help reference.

Document Ref: HP loadrunner correlation

This post explains... what is correlation,why do we have to do correlation,what errors mean we have to correlate :)

Future posts :

1.how to do find unique/session value

2.correlation studio

3.Correlation rules

4.manual & auto correlation

5.Tips & Tricks