Table of Contents |
---|
...
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:
First, a variable must be defined or extracted.
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.
...
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.
...
Step | Screenshot |
---|---|
Review the recorded valuesTry 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 parametersThis 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. |
ErrorOn 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. |
...
Manual Extraction of Dynamically-Exchanged Session Parameters
Note |
---|
Beyond the scope of this online documentation. |
...
Use the text pattern-based variable extractor.
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.
...
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:
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.
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.
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 | ||
---|---|---|---|
| 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. |
...