2. Correlation - Dynamic Session Parameters (Var Handler)

Owned by Glenn Huang (Unlicensed)
Last updated: Mar 30, 2023 by Matt Wilkinson
18 min read

This page is not comprehensive, but an extended excerpt of the ZebraTester-Installed User PDF Manual called the ZebraTester Users Guide.

Dynamic Session Parameters

However, it is often desirable - or even required - that the recorded web surfing session must first be edited. Some possible use-cases are:

  • The web application contains HTML form-based authentication, and it is required that each user use a known username and password to login to the web application.

  • You wish to take a URL call variable and make it a parameter and set the parameter's value each time before starting the load test—for example, a booking date of a flight.

  • The recorded session contains dynamically-exchanged session parameters, which must be extracted at run-time from the web pages, and then assigned to succeeding URL calls to run the load test program successfully.

Variable Handler “Var Handler” Introduction

All of these tasks and many more can be performed using the "central variable handler menu" called Var Handler, which manages all dynamically- applied modifications to web surfing sessions. The process involves two steps:

  1. First, a variable must be defined or extracted.

  2. Then variable must be assigned.

In other words, a variable must first be extracted before it can be assigned; however, some of the most commonly-used dialogs also support making automatic and/or global assignments. Extracting variables is completely independent of the assignment; thus, many combinations are possible, providing maximum flexibility.

VAR Extraction

Variables can be extracted by using the Web Admin GUI from the following sources:

  • from Input Files, whose data are read at run-time during the load test

  • from HTML form parameters; for example, hidden form fields

  • from values of received XML and SOAP data

  • from values of received JSON data

  • from values of received Google Protobuf data

  • from CGI parameters contained in hyperlinks, form actions, or HTTP redirects

  • from any text fragments of received HTML and XML data

  • from User Input Fields - which are arbitrary configurable load test input parameters

  • from HTTP response header fields

  • from output parameters of Load Test Plugins

Additionally, it is also possible to define stand-alone variables that have constant or dynamic initial values.

VAR Assignment

A variable can be assigned as follows, irrespective of how it was extracted:

  • to the value of an HTML form field -

  • to the value of a CGI Parameter of a URL call

  • to values of XML and SOAP data of a URL call

  • to values of Google Protobuf data of a URL call

  • to a text fragment of a URL call (within the HTTP request header or the HTTP request content.

  • to the protocol (HTTP/HTTPS), the hostname, or the TCP/IP port of one or all URL calls

  • to the user’s think time of a web page

  • The response verification algorithm of a URL call (searched text fragment or size of the received content.

  • to the number of iterations and/or the pacing delay of an inner loop F

  • to some HTTP request header fields (ZebraTester automatically handles most request header fields)

  • to an input parameter of a Load Test Plugin

Each variable also has a scope. Possible scopes are:

global

all users will see the same value of the variable during the load test.

user

although the variable has been defined only once, each user will see its own value during the load test. There are as many virtual instances of the variable as concurrent users during the load test.

loop

the variable is bound to the current loop (surf session repetition) of a user, and its value can change during each loop.

inner loop

the variable is bound to the user's inner loop and can change its value during each iteration of the inner loop.

Although seemingly complicated, the Var Handler is a powerful tool that is easy to use. It is possible to satisfy complex requirements quickly with a few mouse clicks, as described in the next sections. Programming knowledge is not required.

"WHAT ARE THOSE ICONS?" 

Icons and what they do.

There are many tiny icons (seemingly identical!) that are actually context-sensitive in the ZebraTester. Generally:

A Dot/Circle in front of a Box Assigns Values to a Variable.

 

A Box in front of a Dot/Circle Extracts Values from a Variable.

Icon

Meaning

Example/Dialog

Icon

Meaning

Example/Dialog

Var Assigner “Assign a Variable”

Dots in front Boxes ASSIGN a Var to something.

HTTP REQUEST HEADER: This first ASSIGN icon above the HTTP Request Header and it Assigns Var to an HTTP Header Field

Var Extractors “Extract a Variable”

Boxes in front of Dot EXTRACT a value to a Var.

HTTP RESPONSE HEADER: This first EXTRACT icon, Extracts the Var from the Header Field

 

Blue Left Arrow indicates that the value of the variable has been extracted.

Red Right Arrow inside the search result means that a (variable) string has been sent. 

 

 

 

The Magnifier icon will change depending on the function it’s next to

“Var Extract Details” next to Blue Left Arrow displays more details about how the variable was extracted.

“Var Assign Details” next to Red Right Arrow displays more details about how the variable was extracted.

“Modify Input File Properties” next to Input File.

“Modify User Input Field Properties” next to User Input Field.

 

The Verify Input File Parsing Button displays a preview of how the input file will be parsed during load test execution.

 

Replace HTTP Response Content: directly modify the recorded data.

 

Download Response Content to a File

 

Expand the view of the HTTP Response Content

 

 

Var Finder: Supports finding and handling dynamically-exchanged session parameters easily.

 

Enable dynamic URL rewriting button in the Var Handler

Described in the J2EE URL Rewriting Section.

 

Define New Stand-Alone Var

Variables are usually defined implicitly by creating Input Files, User Input Fields, using the Var Finder, or extracting values using the Var Handler.

However, it is also possible to define variables directly for special-purpose use. Depending on the scope, directly-defined variables can have special initial values set during the load test by the load test program itself.

Declare External Resources

This menu allows you to declare additional external resources needed when executing a load test. Typically such external resources are Java library files (*.jar files) used by self-developed plug-ins or JUnit load test plug-ins, or Google Protobuf FileDescriptorSets (*.desc files) used to parse G-PROTOBUF messages. However, also any other file types can be declared.

Note: Any declarations made in the Var Handler menu, such as Input Files and Main Classes of Plug-Ins, are not external resources in this context and don't need to be declared because ZebraTester knows already these declarations.

Other edits, search/detail, and feature icons, but these Extract and Assign icons will be the most prevalent.  The many use cases for these icons are beyond this demo's scope and this article. 

The Var Handler UI Summary

The variable handler can be invoked by clicking on any recorded URL call in the main menu. On the left side of the window, all details of the URL call, which changes from call to call, are displayed. On the right side of the window, the Variable Handler is displayed and summarizes all extracted and assigned variables. This right-hand side part of the window remains constant (static) for all URL calls:

Load Test Plugins

ZebraTester Load Test Plugins are Extension Modules to the ZebraTester product. Plugins are configured using the GUI and are executed during a Load Test. The following are a few of the Plugins that are already predefined and delivered as part of the ZebraTester installation:

Plugin Designation in the GUI

Plugin Functionality

Plugin Designation in the GUI

Plugin Functionality

Abort Failed Test

Aborts a running Load Test if too many errors occur within a configured time interval.

Assign File Data to Request Content

Read the data of a file from disk and assign it to a URL call (only useful for HTTP/S POST requests and some WebDAV methods).

Cookie Injector

Sets a Cookie before or during the execution of a Load Test.

Get Cookie Value

Extracts the value of a Cookie into a GUI Variable. The extracted value can be later assigned to a CGI parameter of a succeeding HTTP/S Request (among other targets).

Defer Load Test Start

Delays the start of a Load Test Program for a configured time, expressed in minutes.

Delay Full Load

Limits the load - respectively, the number of the simulated users - for a configurable time. After this time is elapsed, the load is increased to the original number of planned users.

DNS Round Robin Load Balancing

Deprecated: Replaced by integrated DNS options that can be configured per test run.

Supports web servers that are using DNS Round Robin for load balancing.

dynaTrace Integration

Creates additional data during a Load Test for analysis using dynaTrace Diagnostics. The dynaTrace Integration Handbook contains further information about how to integrate ZebraTester with dynaTrace.

Generic Output File

During a Load Test, writes the values of up to 6 GUIVariables line-by-line to a text file. The file scope is freely configurable - lines can be written per virtual test user, per loop execution, or URL call.

Input File List

Reads from a metafile a list of input files and assigns each simulated user a known input file. The simulated users read a new line from their input file each time before executing a new loop.

Large Input File

Reads data from a large input file which has an unlimited size ( 1 GB)

Large Response Content

Allows receiving response content data of a large size (up to 2 GB) for one or several URLs. Note that all response data are read as usual during load test execution but that only a part is stored internally.

Limit Response Content

Limit the receiving of response content data to a specified size. Further reading of data from the webserver during load test execution is aborted (skipped) for the configured URL when the maximum size is reached.

PKCS# 11 Security Device

Support for Smart Cards / PKCS# 11 Security Devices, which contain an SSL Client Certificate used for authentication against web servers.

Remove Cookie

Removes a cookie from the cookie store of a simulated user.

User Synchronization Point

Retains all active users at a configurable synchronization point until all of the users have reached this point. After that, the users are rereleased by applying a configurable deblock delay multiplied with the no. of the actual user (0, 1, 2 …).

The configuration of a Plugin, respectively adding a Plugin to a recorded web surfing session, can be done in the Var Handler:

Step

Screenshot

Step

Screenshot

Start Add Plug-in from Var Handler Main Menu

Select Plug-in from Drop-down.

Click Continue…

Add Input Parameters

Some Plugins require input parameters.

So, it may be necessary to define additional variables.

One option to define such variables is to create global visible stand-alone variables with constant initial values if constant values are required as Plugin input parameters.

Additional variables can also be extracted from other sources, for example, from Input Files, or User Input Fields, or responses of previous URL calls.

  • Add Plug-in when done.

  • Note the Var Handler UI will change to reflect the new Vars and the newly-added Load Test Plug-Ins.

Dynamically-Exchanged Session Parameters

The HTTP protocol by itself is stateless - there is no memory from URL call to URL call; however, most web applications require state information, such as the stage in a process that a user had reached - before login, after login, placed an order, and so on. Usually, cookies are used to keep state information. Cookies are set by the web server as additional HTTP response header fields and sent by the web browser back to the webserver and the HTTP requests of succeeding URL calls. This is normally not a problem because the load test program automatically does the correct handling of cookies.

However, some web applications use, as a special "session context" dynamically-generated CGI- or form-parameter values which are exchanged between the web application and the web browser in such a way that, if you repeat the same web surfing session, a more or less random algorithm changes the values of these parameters. If you use, during a load test, these "burned-in" values of dynamically-generated server-side CGI- or form-parameters, the load test will fail. A good example of this is the "__VIEWSTATE" parameter used by Microsoft web servers.

The solution to this problem is that the values of these dynamically-exchanged session parameters must be extracted at runtime (during the load test) and then assigned to the corresponding parameters of succeeding URL calls.

To make this task easier, ZebraTester provides the Var Finder menu. You can invoke the Var Finder either from the main menu or from the Var Handler:

Automated Handling of Dynamically-Exchanged Session Parameters (Var Finder)

The Var Finder menu provides an overview of all URL request parameters and their values used anywhere in the entire recorded web surfing session. In this view, a parameter "name-value" pair is shown only once, even if the same "name-value" pair is used by more than one URL call. If the same parameter(-name) is used with different values, it will be shown multiple times, once for each distinct value.

Process

Step

Screenshot

Step

Screenshot

Review the recorded values

Try to judge which values could be dynamically-exchanged session parameters. If the value contains a long number or a cryptic hexadecimal string, it has a good chance of being a dynamically-exchange session parameter.

In the example above, the various parameter names containing ViewState are dynamically-exchanged session parameters. But the one “ctl00$MainContent$TeamNamesDropDownList=AC Milan” is not because the value “AC Milan” had been entered manually into forms, via the drop-down list, during the recording of the web surfing session.

Auto-Extract the dynamically-exchanged session parameters

This succeeds in approximately 50% of all cases.

To do this, click the

“Click here to perform automatic handling for dynamically-exchanged session parameter” icon at the left of the parameter name.

Success

If you receive a success message, there is nothing more to do for this parameter. In this example, the levid var was successfully created with the auto-extraction. Note the 2 with the left blue arrow; a var extraction.

 

The corresponding definitions inside the Var Handler are automatically created.

Error

On the other hand, if you receive an error message, you must manually extract the dynamically-exchanged session parameter (see the next subchapter).

In this example, the parameter __VIEWSTATE could be handled automatically. The other parameters (d & t) must be extracted manually since these parameters are listed more than once (i.e., the same name with different values); the extraction must also be done more than once for each distinct value.

Hint: you can use this menu as a checklist of already dynamically handled parameters, irrespective of whether the extraction is done automatically or manually. The handling is already done if the line contains a Left (extract) arrow and a Right (assign) arrow.

Manual Extraction of Dynamically-Exchanged Session Parameters

 

Replacing Text Patterns

In rare cases, the name of an HTTP request parameter is variable instead of the parameter value being a variable. Even rarer are cases where a file path of a URL call contains variable parts.

You can handle such cases as follows:

Use the text pattern-based variable extractor.

  1. At the last step, use the checkbox Assign Var automatically to all HTTP requests containing the same text pattern (full binary replacement of recorded value overall requests) instead of Assign var automatically to all HTTP requests that contain form CGI parameters with the same recorded value.

There are also other rare cases in which a text pattern must be extracted from an HTTP response header because a variable HTTP redirection occurs. A part of the URL file path, or a part of a CGI parameter, is variable. This is also supported - if two extractor icons are present, you simply use the second one.

Extracting and Assigning Values of XML and SOAP Data

In case that XML or SOAP data have been recorded, ZebraTester parses such data automatically and displays an additional XML Icon within the title of the “HTTP response Content” and the “HTTP request content” box:

HTTP File Uploads

If a recorded web surfing sessions contain HTTP file uploads, you can also use a variable for each file upload which allows selecting the uploaded file dynamically during the load test. Such a variable is often extracted from an input file whose lines contain different file names (without file paths).

Overview of most commonly used Extract and Assign Options

The following illustration is not exhaustive.

Directly-Defined Variables (stand-alone Variables)

Variables are usually defined implicitly by creating Input Files, User Input Fields, using the Var Finder, or extracting values using the Var Handler.

However, it is also possible to define variables directly for special-purpose use. Depending on the scope, directly-defined variables can have special initial values set during the load test by the load test program itself.

 

 

 

 

 

 

 

 

Supported combinations of scope and initial values are:

Initial Value

global var

user var

loop var

inner loop var

Initial Value

global var

user var

loop var

inner loop var

constant value

x

x

x

x

null

x

x

x

x

current user counter

-

x

x

x

loop counter

x¹

x²

-

-

inner loop counter

-

-

-

x

system time milliseconds

x

x

x

x

load source IP hostname

x

x³

x³

-

load source IP address

x

x³

x³

-

 

¹ = (outer) loop counter overall users

² = (outer) loop counter of the user

³ = inclusive multi-homing support

Initial Values:

constant value

the variable is initialized with an arbitrary constant value.

null

the value of the variable is not valid/undefined at initialization time.

current user counter

the variable is initialized with the sequence number of the simulated user (0, 1, 2 ..).

loop counter

global var scope - the variable is initialized with the outer loop counter (0, 1, 2 ..) - counted over all simulated user/user var scope: the variable is initialized with the outer loop counter of the actual simulated user (0, 1, 2 ..).

inner loop counter

the variable is initialized with the iteration counter of the inner loop (0, 1, 2 ..) - of the actual simulated user.

system time milliseconds

the variable is initialized with the current operating system time, in milliseconds since 1970.

load source IP hostname

the variable is initialized with the Exec Agent hostname.

load source IP address

the variable is initialized with the Exec Agent IP address.

J2EE URL Rewriting

The web application developers can configure a Java (J2EE) application server. A procedure called "URL rewriting" is used to build the session context instead of using session cookies. In this case, the server will assign a special dynamic session parameter to every returned hyperlink at runtime and to every form, which contains the session context.

An example of a hyperlink with applied URL rewriting is as follows:

<a href="http://www.d-fischer.com:8080/prxtool/servlet/WebMainMenu;jsessionid=bu3fy0bbj1?currentDir=344">forward</a>

The URL rewriting parameter [jsessionid=bu3fy0bbj1] is appended to the URL file-path[http://www.d-fischer.com:8080/prxtool/servlet/WebMainMenu], separated by a semicolon, and appears before the normal CGI parameters [currentDir=344], which start with a question mark.

Usually, a Java application server supports both session cookies and URL rewriting; however, only one of these procedures is applied, on a per-user basis, to build the session context. The inner algorithm of the application server works as follows:

  1. When a web browser requests any page from the server for the first time, the server does not know if the web browser supports session cookies. For this reason, the server sends a session cookie to the web browser and performs additional URL rewriting for all hyperlinks and forms for the first web page.

  2. When the web browser requests a second page from the server and transmits the received session cookie back to the server, the server will know that it supports cookies. For the current and all succeeding web pages, URL rewriting will no longer be done.

  3. If on the second-page request, the web browser does not send back the cookie, or if the application server is configured to disable the use of session cookies (in which case an initial cookie will not have been sent anyway), the webserver notes the absence of the session cookie. It does URL rewriting for the current web page and all succeeding web pages.

You do not usually have to do anything special in this case because most Java application servers support session cookies. However, if session cookies are disabled, you must first enable URL rewriting support inside the Var Handler before the load test can be executed successfully. You will recognize the need for this when you review the recorded URLs in the main menu - if the URL rewriting parameter is found in all URL calls in most web pages, you will have to enable URL rewriting support in the Var Handler.

Proceed as follows:

Step

Screenshot

Step

Screenshot

  1. Choose any URL detail menu.

  2. Click the Enable Dynamic URL Rewriting button in the Var Handler.

  3. Enter the name of the URL rewriting parameter in the field Rewrite Parameter

  4. Enter an arbitrary variable name in the field Map to Var Name

  5. Use the option automatically for the field Dynamic Handling.

After URL rewriting has been enabled, the Var Handler shows only the first extraction of the URL rewriting parameter - but not its assignment. This is normal behavior because the assignment in succeeding URL calls will be done automatically later in the load test without additional configuration.

It's also possible that the URL rewriting parameter's value can change during the web surfing session, for example, after logging in to the web application or after logging out. In this case, you will see two or more extractors for the URL rewriting parameter inside the Var Handler.

 

 

 

Can't find what you're looking for? Send an E-mail to support@apica.io