The Repository contains all the web pages used to set up the Virtual Users. It is also the place where the web page's settings, such as request definition and content assertion, may be configured. During a recording, all the recorded pages are created in a container, which is stored in the Repository. See the section called “Recording a Test Scenario” for further details.
The servers pane is used to declare and modify the web servers used in the scenario. The servers are automatically created when the scenario is recorded. The server settings are centralized, which means the target server for the test can be quickly changed. It is possible, for example, to quickly switch from the development to the pre-production server.
Select the server to bring up its settings pane:

Http server definition. Displays the server definition. Change hostname and port to switch physical server for all requests using the current server.
Authorizations. Settings for basic HTTP and NTLM-type authentications. The password-protected zones (realms and domains) are detected during the recording and automatically added. The accounts may be dynamic and changed for each user being simulated, using variables.
HTTP URL rewriting. Session tracking is automatically enabled when cookies are used. For servers that use URL rewriting to track a session, the session argument must be defined (e.g. SESSIONID or JSESSIONID for most servers). When detected during recording, the argument is automatically filled in.
The web pages is the page as it is composed in a web browser. It consists of the HTML page and its sub-components, such as image files and CSS style sheets.

Name - The name of the web page in NeoLoad.
URL - The URL of the first HTTP request forming the page is displayed here for information purposes.
Description - A description of the web page can be entered here if required.
Think time - The think time is the interval before a web page is accessed. This corresponds to the time a real user will spend reading the page displayed by the browser before clicking on a link. Use this box to set the think time for this page or click on the link to the Runtime Policy pane to set a global think time for all pages. The default policy is to use the think time defined for each page (to change this policy, click on the same link).
Web page screenshot - A screenshot of the browser content at the instant the web page was recorded.
Please note that this function is only available in Windows and is merely a reminder of what was displayed in the browser window when the web page was recorded. Screenshots are only available for web pages with an HTML content. If the screenshot does not mirror the actual web page, it may be deleted.
Automatic screenshots during recording may be turned off by
changing the value of the
recorder.screenshot.enabled key in the GUI section
of the /conf/controller.properties file to
false.
In NeoLoad, an HTTP request is the sending of a request over a network using the HTTP or HTTPS protocol. Normally the request is followed by a server response, which can be in the form of an HTML web page, image or CSS file among others.

The request type can be defined in three ways:
Manual definition. A static definition of the request. Define the URL and the parameters.
HTTP redirect. Indicates that the current request is the target of an HTTP
redirect command contained in the server response to the previous
request. When a request is defined as an HTTP redirect, the Load
Generator plays the request ignoring the recorded URL and
parameters. It uses the result of the previous request dynamically.
(The previous request must be of the "302 Moved
Temporarily" type). This is very useful for pages which
include redirects containing dynamically-generated parameter values
(for example:
/searchresult.jsp?searchID=481825).
Link extractor. Extracts and follows a link matching a dynamic definition. It is also called a form extractor in the case of form POST-type requests. It should be used when a test scenario simulates a click on a dynamically-generated link. The Load Generator extracts the link dynamically from the results of the previous request (referrer) and follows it. The extraction is carried out using regular expressions (regexes).
One typical instance is where one or several parameters are
dynamic. Use the "Set as dynamic value" button to
create the regex by default.

".*" indicates a wildcard character. In the previous example,
the first link encountered, in the form
/petsore/search.screen?searchID=<anyvalue>,
matches the regular
expression and is extracted. Regular expressions enable
advanced extraction to be carried out.
Note that all the parameters, in addition to the URL, may
contain regular expressions. Consequently, the following special
characters reserved for regular expressions must be escaped using the
'\' character: [ ] ^ \ { } ( ) + ? . *
When extracting a link or form, NeoLoad variables may be automatically created, containing the parameter values of the link when run. The dynamic element of a link can thus be extracted and used in other requests. For example, if your application frequently uses a same dynamic parameter, you can define a link extractor for the first use of that parameter, then use the variable in all the other requests that use the parameter. This avoids multiple searches in server responses and thus enhances the efficiency of the Load Generators.
Refer to the sections on link and form extractors for further details and examples.
Parameters can be defined for the submission of forms by the POST or
GET methods. Some can have static values assigned to them and others
dynamic values, using variables. When the encode
checkboxes are checked, the specified values are converted to the
application/x-www-form-urlencoded MIME format before
being submitted (encode space as %20 for example). Clear the checkbox if
either the name or value is already encoded.
POST requests with an "application/octet-stream"
-type content or non-standard charset are processed by NeoLoad as if they
were binary content. This ensures that no URL or charset encoding is
carried out on the contents before playing.

POST requests with a "text/..." -type content.
The contents of these requests may contain NeoLoad variables for generating dynamic
content.
POST requests with a "multipart/form-data" -type
content have modifiable parameters and use a specific interface.

Each part is described by a name attribute and a value. It also features an optional specific content type, charset and transfer encoding. Refer to RFC1867 for more details. Each field may be replaced by a variable. The value may be a string or a file input.

The filename field describes the file name within the part. The part's content data is described by the source file field. The file may be identified using a set path or one related to the project. The files are automatically copied to all the Load Generators when the test is started.

The advanced parameters pane includes:
Request headers. HTTP request headers. Existing headers may be edited or deleted or new headers added. A variable may be used as a header value.
Advanced settings.
Request parameters. Specifies whether or not a sent request should include
an equals character after the parameter name if its value is
empty (e.g.: a request may be sent as
/page.jsp?myparam= rather than
/page.jsp?myparam).
Advanced definition. Enables the user to configure the referrer
of the current request. The referrer is the request
containing the link to the current request. By default, the
referrer is established during the recording phase. You may
alter the referrer by clicking on the Change
referrer button. When altering the referrer, make
sure that the new referrer's request call precedes the
current request's call in the Virtual User
definition.
The referrer is used when a request is:
a link or form extractor
In this case, NeoLoad fetches the link or form definition in the server response to the referrer.
a redirect
In this case, NeoLoad fetches the value of the
Location header in the server response
to the referrer.
Form charset. Denotes the charset used to encode the form parameters (UTF-8, ISO-8859-1, ...). By default, NeoLoad uses an algorithm similar to the one used by web browsers to determine which charset to use: NeoLoad uses the charset of the HTML page containing the form. If the charset is not found, "iso-8859-1" is used.
Do not confuse this charset, used to convert characters
into bytes, with plain URL Character
Encoding, which converts, for example, the space
character into %20. Specifically,
URL Character Encoding differs according
to the charset used.
Variable extractors. Extracts a string from the server response to this request and assigns the string to a variable. See the section called “The variable extractor”
Request content. The request content that was recorded when recording the scenario.
Response content. The response content that was returned by the server when recording the scenario.
The variable extractor extracts a string from the server's response to the request and assigns the string to a variable. The variable extractor features two operating modes, simple and advanced. In simple mode, the user defines the string to be extracted; in advanced mode, the user can define more complex extractions using regular expressions.
Definition (Simple mode). Used to define the extractor.

Variable name. The name of the variable automatically created to contain the value extracted.
Starting with. The phrase in the server response appearing immediately before the value to be extracted.
Followed by. The definition of the string's main body. The extracted string is the concatenation of all the parts selected for extraction.
Ending with. The phrase in the server response appearing immediately after the value to be extracted.
Occurrence to extract in the page. If the definition is matched more than once, select the occurrence to be used. The default value is 1. To use a random occurrence, enter 0. To use all occurrences (useful with loops) use a negative value such as -1.
When the occurrence number is negative, all the matched occurrences are processed. The following variables are automatically created:
<VariableName>_matchNr - the
number of occurrences found; can be 0.
<VariableName>_n, where n =
1,2,3 etc - the strings as generated by the value
template.
<VariableName>_n_gm, where
m=0,1,2 - the groups matching n
<VariableName> - always
attached to the default value
Note: When switching to advanced mode, the definition is automatically converted from simple to advanced.
Definition (Advanced mode). Extraction is carried out on the server response using a regular expression.

Variable name. The name of the variable automatically created to contain the value extracted.
Extract the value from. Extract the value from either the body of the server response, the headers of the server response or the content of a NeoLoad variable. Extracting a variable from the content of another variable, allows to extract a content with several steps. First extract a part of the response based on a regular expression, then use another regular expression to extract a part of it.
The extractors are ordered and executed in the definition order. You can reorder the extractors using the arrows buttons.
Regular expression to match. The regular expression used to extract the value. Within the expression, the parts to be extracted must be enclosed in brackets (valid: value="(.+?)", invalid: value=".+?"). Please refer to the Regular Expressions Guide for help on regular expressions.
Occurrence to extract in the page. If the definition is matched more than once, select the occurrence to be used. The default value is 1. To use a random occurrence, enter 0. To use all occurrences (useful with loops) use a negative value such as -1.
When the occurrence number is negative, all the matched occurrences are processed. The following variables are automatically created:
<VariableName>_matchNr - the
number of occurrences found; can be 0.
<VariableName>_n, where n =
1,2,3 etc - the strings as generated by the value
template.
<VariableName>_n_gm, where
m=0,1,2 - the groups matching n
<VariableName> - always
attached to the default value
Value template. The template used to construct the value. This is an
arbitrary string containing special elements that refer to
groups within the regular expression (a group is a dynamic
portion of the regular expression set within brackets): $0$
refers to the entire text matching the expression, $1$ refers to
group 1, $2$ refers to group 2, and so on. Using an illegal
group will return an error of the type
<NL-Illegal-groupIndex> during the
test. This typically arises when no brackets are specified in
the regular expression to be matched.
Note: When switching to simple mode, the last simple definition is used, since advanced-simple conversion is impossible.
Examples
Extracting from the server response body. Given the following content: Your order number Mr
Smith is:12345; and that the string to be extracted is
'12345', to be used in a subsequent request.
The variable extractor is defined thus:
Variable name: 'MyVariable' Extract from: 'Message body' Regular expression to be matched: 'Your order number(.+)? is:([0-9]+);' Occurrence within the page: '1' Value template: '$2$' as it's the order number that must be extracted and not the name of the person. Use $1$ to obtain the name. ($0$ would return the complete matched text: 'Your order number Mr Smith is:12345;') Default value: '-1' for example.
Extracting from the server response header:
Extract from: 'Header' Regular expression to be matched: 'MyHeader: (.*)' Occurrence within page: '1' Value template:'$1$'
Test. This tab allows you to test the variable extractor. Enter the text corresponding to the server response in the text box. The "value extracted from page" field value contains the value extracted from the page.

Error. This tab allows the user to define the default value to be used when the definition is not matched in the server response. By default, an assertion fails when the definition is not matched, allowing the request to be treated as an error in the test results.

Allows the user to add assertions to the server responses. The content returned by the server may be treated as an error using the following criteria: delay, page size or page content.

Defines the minimum and maximum sizes, or length, of the server response's body. HTTP header lengths are disregarded. The default length is the length of the server response's content at the time of recording. "Greater than" denotes greater than or equal to; "Smaller than" denotes smaller than or equal to.
Checks whether or not the server response contains a certain content. The server response is composed of the HTTP response's headers and content. The server response is considered valid if all the content conditions are satisfied.
The conditions available are:
contains: checks if the body
of the server response contains the specified text. (Example:
"<span
class="welcome">Welcome</span>")
contains regular expression:
checks if the body of the server response contains the specified
regular expression. (Example: "<span
class="welcome">Welcome \w+ \w+ </span>")
Note that the content assertion may contain variables.
Please refer to the Regular Expressions Guide for help on regular expressions.
To help find specific requests quickly and easily, NeoLoad can add a flag to the action's icon in the tree.
These may be requests that include a response validation, a variable extractor, or a link or form extractor. You may also flag all form POST requests, and all requests using parameters or containing a specific text.
When searching custom text in the request definition, NeoLoad looks in the path, the parameters, the headers, the name of the Variable Extractors, and the content validations.
Procedure 7.1. To configure request flagging policy
Click on the "Repository" node in the tree.
The pane to the right of the tree displays a "flag" box.
Select the type of requests to be flagged.

Link extractors and form extractors search for and extract a link or form from a preceding HTML request, for easy handling of server-generated dynamic parameters.
Please refer to the Regular Expressions Guide for further details on regular expressions .
In this mode, the HTTP request definition is interpreted as a regular expression, which is used to find the link within the page. Before playing the request, NeoLoad replaces the dynamic values in the definition with the values extracted from the corresponding link in the previous page (referrer). Perl-type regular expressions are used.
The HTTP request parameters interpreted as regular expressions are: path, URL parameters (name and value) and server. If the server name is dynamic, manually create a server in NeoLoad whose hostname is the regular expression to be matched in the page.
If several links match the definition, NeoLoad will select one at random.
Note:
The link parser searches for links whose form resembles
and
takes into account the base URL (<a
href="http://mydomain/mypath"></a><a
base="mybaseUrl"></a>).
The following special characters in the link extractor's
definition must be escaped using the '\' character: [ ] ^ \
{ } ( ) + ? . *
Once the link is found, the parameter values can be placed in a
NeoLoad variable. To do
this, simply enter the name of the variable in the Extract to
variable column in the parameters table (this column is only
displayed in link extractor mode). Note that only the variable name should
be used, not the syntax: use "varname" and not
"${varname}".
Let's consider the following example: the web application generates a searchID, and this number is transferred from page to page as a request parameter. The recorded HTTP request looks like:

If you launch the test, NeoLoad will play the request with the
recorded searchID. Therefore, the searchID must be replaced by the
appropriate value. The previous page contains the following link:
<a
href="http://myHost/search.php?searchID=<mygoodsearchid>&page=2">Page2</a>
Now let's convert this manual request into a link extractor:

In this example, the searchID value has been set as ".*", which means the searchID may contain any value.
The "page" parameter may also be set as ".*" or"\d" (for a single digit). So, if you have several different links such as:
they will all match the definition. In this case, NeoLoad selects one of the links at random.<a href="http://myHost/search.php?searchID=<mygoodsearchid>&page=2">page2</a><a href="http://myHost/search.php?searchID=<mygoodsearchid>&page=3">page3</a><a href="http://myHost/search.php?searchID=<mygoodsearchid>&page=4">page4</a>
The Form Extractor -type HTTP request is used to
retrieve a form in the previous HTML page and play it back.
The HTTP request parameters interpreted as regular expressions are: path, form parameters (name and value) and server. If the server name is dynamic, manually create a server in NeoLoad whose hostname is the regular expression to be matched in the page.
If several forms match the definition, NeoLoad will select one at random.
Note: The following special characters in the form extractor's
definition must be escaped using the '\' character: [] ^ \ { } (
) + ? . *
Once the form is found, the parameter values can be placed in a
NeoLoad variable. To do
this, simply enter the name of the variable in the Extract to
variable column in the parameters table (this column is only
displayed in form extractor mode). Note that only the variable name should
be used, not the syntax: use "varname" and not
"${varname}".
Let's consider an application containing the following search form:
<form name="searchform" method="POST" action="search.php"> <input type="text" name="name" size="30" value=""> <input type="text" name="city" size="30" value="NY"> <select name="country" id="country"> <option value="US">US</option> <option value="Canada">Canada</option> <option value="China">China</option> <option value="France">France</option> <option value="UK">UK</option> </select> <input type="radio" name="fastsearch" value="YES"> <input type="radio" name="fastsearch" value="NO"> <input type="hidden" name="computedValue" value="4235"> <input type="submit" name="Submit" value="Submit"> </form>
In this example, the "computedValue" hidden field is server-generated and differs with each request call.
The recorded HTTP request looks like this:

If you launch the test, NeoLoad will play the request using the recorded "computedValue" parameter value. This needs to be replaced by the appropriate value, so let's convert this manual request into a form extractor:

Using ".*" as the value for computedValue will extract the value generated by the server.
Furthermore, if ".*" is used as the country field value, a random value from the option list will be returned. In the same way, the "fastsearch" field will randomly return "YES" or "NO" upon running the test.
As can be seen, the form extractor not only extracts server-generated dynamic values, but also allows random choices to be made in the form's option-based elements.
NeoLoad's optional SOAP module can be used to load test Web services using the SOAP protocol.
There are two ways of using this NeoLoad module:
Declare, then enter, the SOAP request's call parameters (manually or using a WSDL description file)
Record a SOAP request played by an existing client application, then modify its parameters.
This section describes how to create a SOAP request from the ground up. To record a request using an existing client, see the next section
Procedure 7.2. Creating a SOAP request in the NeoLoad Repository
In the Design section, click on the
Repository tab.
Right-click on the Repository node, then
select Add/New SOAP request. You can also create a
SOAP request by clicking on the "New SOAP request"
button in the Repository node's pane
Follow the wizard to select the parameter editing mode:

Create a SOAP request using a WSDL description file:
Enter the URL containing the WSDL. Use the file browse
button to select a file on the hard drive, or enter a web
server URL, for example:
http://myserver/app/myservice?WSDL.
In the drop-down list, select the method (or operation) to be tested.
Choose a pertinent name for the SOAP request.
Enter the URL of the web service ("Endpoint"). The URL defined in the WSDL is displayed by default.
Create a SOAP request by manually editing an XML request.
Choose a pertinent name for the SOAP request.
Enter the URL of the web service ("Endpoint").
This section describes how to record the interaction between an existing SOAP client and the web services server.
Procedure 7.3. Recording a SOAP request.
Alter the SOAP client's settings so that it uses NeoLoad as a proxy:
hostname: name or IP address of the machine currently running the NeoLoad Controller.
port: the NeoLoad HTTP recorder's
port, 8090 by default. This setting can be
changed in the NeoLoad preferences.
Axis: Modify the http.proxyHost and
http.proxyPort system properties.
For example, place the following lines in your code:
System.setProperty("http.proxyHost", "localhost");
System.setProperty("http.proxyPort", "8090");or modify the command line as follows:
java -Dhttp.proxyHost=localhost -Dhttp.proxyPort=8090 ...
.Net. The configuration file may be modified as follows:
<configuration>
<system.net>
<defaultProxy>
<proxy
usesystemdefault = "false"
proxyaddress="http://localhost:8090"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
</configuration>For further information, please see http://support.microsoft.com/default.aspx?scid=kb;[LN];318140
Run NeoLoad
Start a recording (See the section called “Recording a Test Scenario”). Since the recording does not
require a browser, we recommend clearing the "Launch
browser" option .
Launch your SOAP client application. Since the application has been configured to use the NeoLoad recorder as a proxy, NeoLoad records the request.
Stop the recording.
Description of the SOAP request editing pane:

Name. Name of the request
Description. Optional comments or notes.
URL. Web service's URL, cannot be edited.
Server. Web service server.
Path. Path to the web service, depending on the selected server.
WSDL. URL for the WSDL. For a file on the hard drive, the URL will
take the form file:/C:/... Use the file browse
button to select the file. For an online file, use the standard
http://myserver/myapp/myservice?WSDL.
The Reload button allows the WSDL to be
reloaded and the request parameters reconfigured. After
confirmation, the request's original parameters are deleted.
Edit mode.
WSDL parameters mode
This mode is available if a WSDL file has been defined. It allows the call parameters to be entered based on the WSDL definition. See the section called “Editing the parameters extracted from the WSDL”.
XML mode
This mode allows the request to be edited directly in XML format. See the section called “Editing the XML content”.
Contents. Edit the WSDL parameters or XML content, depending on the mode selected.
Test. Provides a quick way to test the request. Clicking on the
"Validate" generates a temporary Virtual User
containing the edited request, then launches the validation of the
Virtual User.
The "Advanced..." and
"Validation..." buttons provide the same features
as for a standard HTTP request, allowing HTTP headers to be edited,
variable extractors to be created or contents to be validated.

When NeoLoad loads the WSDL file, it generates a default tree structure for the parameters and SOAP headers. Optional parameters may be deleted and other parameters added if the WSDL description permits.
The parameters tab allows the user to edit,
delete or add parameters.
Parameter editing is limited by the restrictions imposed by the WSDL description.
There are two types of parameters:
leaf elements, such as a text or
numeric value which can be edited.
This value may be an actual value or a variable. Encoding
allows special characters such as '>' and '<' to be
encoded. If the value is a variable, the "encode
value" option may be cleared if the variable's value
is already encoded
The value type displayed is the 'type'
in the WSDL sense of the term, for example:
{http://www.w3.org/2001/XMLSchema}string. The
user must ensure that the value type syntax is adhered
to.

containers that contain other
elements:
sequence elements contain other
elements in a specific order and follow the cardinality
described in the WSDL. For example, the S
sequence must contain between zero and
three A elements and at least one B element, in that
order;
All elements contain other
elements once, and only once, in an unspecified
order;
Choice elements contain a single
child element among the various child elements
allowed.
The container element's restrictions
are displayed for information purposes in the "Child
elements" section at the bottom of the container's
edit pane.

To add an element to a
container , either click on the
'+' button, or right-click on the element, then
select "Add". In either case, the list of elements
to be added is limited by the child elements allowed by the WSDL. The
element is automatically inserted in the appropriate place, among the
other child elements where an order constraint exists.
To delete an element from a
container , either click on the
'-' button, or right-click, then select
"Delete".
To move an element within a
container , use the appropriate direction button,
or right-click, then select "Move up" or
"Move down".
If a restriction imposed on the container
by the WSDL is not complied with, an error icon is added to the
container's icon. An error message also appears in the
"Child elements" section of the appropriate
container's edit panel.
Use", allows the attribute to be added to the
parameter. Entering a value in the value column
automatically adds the attribute to the parameter. It is not possible
to add attributes not intended by the WSDL.This tab is used to configure the SOAP headers declared in the WSDL.
Its use is similar to that of the Parameters
tab.

SOAP Headers section
allows the user to define the SOAP protocol's
"Actor" attribute.This tab is used to define the following two parameters:
message style. The styles
supported are: RPC/Encoded,
RPC/literal,
Document/literal and Wrapped
Document/literal. The style selected is the one
declared in the WSDL. Normally, this parameter should not be
changed, as the web service expects to be contacted using the
predetermined style (as set in the WSDL).
encapsulation format for
the binary attachments: MIME or
DIME. As with the message style, this
parameter is extracted from the WSDL and should not normally be
changed.
This allows the user to preview the XML body of the request exactly as it will be generated. The preview cannot be edited and only includes the XML body of the message (not the binary attachments, where present).
Carry out a request validation to obtain a preview of the complete HTTP request.
If the WSDL file is not defined, or if the WSDL parameters cannot be edited, the XML body of the message may be defined manually.
To do this, edit either the XML text or the XML tree.

This tab is used to edit the nodes of the XML tree using the open tree view. The variable picker in this view makes it especially useful when using variables.
If a node value contains a variable, and this variable is
already encoded, the option not to encode it XML-wise is available. In
this case, NeoLoad adds the attribute
NeoLoad-encode="false" to the corresponding node,
visible in the XML text tab view. This additional
attribute will be deleted during the XML encoding phase of the test
and will not be sent to the server.
This tab provides a read-only preview of the body of the request to be sent.
The variables are interpreted and the carriage returns deleted (see tip below).
The request has the carriage returns removed to make it more
compact for the test; right click and select "Indent
XML" to obtain a more readable presentation.
SOAP 1.1requires the presence of the SOAPAction
HTTP request header. This header is automatically added, with the
appropriate value, when the WSDL is loaded, or recorded if the request
is recorded.
Edit the request's HTTP headers to modify this value. To do this,
click on the "Advanced..." button and select the
"Request header" tab .
Click on the Validate button in the
Test section to test the current SOAP request.
NeoLoad generates a temporary Virtual User containing the single
request, then displays the validation window for that Virtual User. Click
on the Start validation button.
The Details section provides details of the
request sent and of the server's response, and access to the assertion
messages.
Right click and select "Indent XML" in the
text field to obtain a more easily-readable detail report for the sent
request. Right click and select
"" or useFind...
Ctrl-F to search.