NeoLoad supports the following authentication mechanisms: Basic, Digest, NTLM and Negotiate.

SPNEGO is at the heart of the HTTP Negotiate authentication mechanism. When using SPNEGO, the browser and server negotiate as to which underlying mechanism to use, Kerberos or NTLM. If Kerberos -the default protocol- fails, Negotiate will try NTLM.

Note that Integrated Windows Authentication on Microsoft IIS uses both Kerberos v5 and NTLM authentication.

For performance reasons however, NeoLoad uses NTLM in place of SPNEGO as the default underlying mechanism for Negotiate, since SPNEGO+Kerberos has a major impact on Load Generator performance. When SPNEGO+Kerberos is used, a Load Generator cannot generate as many Virtual Users.

Enabling SPNEGO therefore, is not recommended. If it is absolutely required however, follow this procedure:

Some servers support multiple schemes for authenticating users. NeoLoad prioritizes them in the order Negotiate, NTLM, Digest, Basic to reflect the order used by regular browsers.

In certain cases, you may wish to change this default order:

The request type can be defined in three ways:

Parameters can be defined for the submission of forms by all methods (POST, GET, HEAD, PUT...). 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.

Whatever the type, POST-type requests may have parameters contained within the URL. The POST and URL parameters may be processed separately using the tabs provided.

In the above example, the URL obtained during the test will be: http://ServerHostName:80/loadtest/form/doit.jsp?firstname=john&lastname=smith&email=john.smith@company.com.

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.

Fields specific to the file part

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:

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.

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.

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.

You can use shortcuts from the repository tree to quickly and easily access the requests and pages in the current test results or in a Virtual User validation pane.

Note that the shortcut will only work if a Virtual User validation or scenario containing the request or page has been previously played in the project.

NeoLoad allows the user to search for requests in the repository according to various criteria and to modify them. This feature, which includes a find/replace wizard, can be accessed either via the Edit menu or from the repository tree context-sensitive menu.

The search can be carried out in the parameters, URLs or headers.

For parameters and headers, the search can take one of three forms:

The wizard then prompts you to enter the string to be searched for and the replacement string. A regular expression may be used for both of these strings, in which case the "Search regular expression" box must be ticked (for further information on regular expressions, please see the Regular Expressions Guide).

Once the required information is entered, the wizard prompts you for final confirmation. You may then check the parameters and modify them if necessary by clicking on Back.

Click on finish to close the wizard and begin the search.

If no matches are found, a pop-up window prompts you to modify the search parameters.

Otherwise, a pop-up window is displayed, which allows you to browse the results. The results are flagged in the repository tree and the cursor is immediately positioned on the first occurrence of the search result.

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:

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}".

Example

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://ServerHostname/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:

<a href="http://ServerHostname/search.php?searchID=<mygoodsearchid>&page=2">page2</a>
<a href="http://ServerHostname/search.php?searchID=<mygoodsearchid>&page=3">page3</a>
<a href="http://ServerHostname/search.php?searchID=<mygoodsearchid>&page=4">page4</a>

they will all match the definition. In this case, NeoLoad selects one of the links at random.

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}".

Example

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.

In NeoLoad, "dynamic parameters" refers to parameters that are dynamically generated by the server and used in several requests within a scenario. For example, this type of parameter may be used to manage user sessions, or preserve the browsing status at any given time. These parameters, calculated by the server, can be inserted into a hidden form field, or into a URL parameter, without any input from the user.

During a load test on the application, NeoLoad simulates the traffic of hundreds of users, and each of these users must be able to use the value of the parameter generated by the server as opposed to the value of the parameter recorded during the scenario's creation. Normally, to manage these dynamic parameters, we need to extract the value generated by the server using a variable extractor, and reinject it into the subsequent requests in place of the recorded value. This is not a problem when dealing with a single, isolated dynamic parameter, but it can become tedious when the dynamic parameter occurs in many requests (numerous replacements in the request definitions), or its value changes regularly (numerous variable extractors need to be created).

NeoLoad includes two processes that allow you to easily configure your application's dynamic parameters, thereby simplifying their management.

The dynamic parameter search is a process that may be launched after recording (Post-recording Wizard), or for each Virtual User.

To start a dynamic parameter search on a Virtual user:

This brings up the Dynamic Parameter Search Wizard, which gives you the two dynamic parameter search type options available in NeoLoad:

Within a framework specific to an application's development, the dynamic parameters generated by the server are often the same, and are used in numerous requests. To avoid having to define variable extractors for a large number of requests, and then having to define the use of those variables in the request definitions, NeoLoad offers to search for these parameters and to configure the variable extractors/replacements within the scenario.

In NeoLoad, the search process for generic dynamic parameters is entirely automated. It allows NeoLoad to search for the dynamic parameters in your application and modify your scenario accordingly.

Example

Let's take the example of an application containing the dynamic parameter id computed by the server and added as a parameter to a page's links. The links in the server response look like this:

<a href="viewCategory.shtml?categoryId=BIRDS&id=1181639214472">BIRDS</a>
<a href="viewCategory.shtml?categoryId=FISH&id=1181639214472">FISH</a>
<a href="viewCategory.shtml?categoryId=DOGS&id=1181639214472">DOGS</a>
<a href="viewCategory.shtml?categoryId=REPTILES&id=1181639214472">REPTILES</a>
<a href="viewCategory.shtml?categoryId=CATS&id=1181639214472">CATS</a>

As parameter id is dynamic, it will have a different value when run by each Virtual user. After recording this page, NeoLoad creates a request that includes the parameter's value at the time of recording:

During a dynamic parameter search, NeoLoad will fail to find this exact link in the server response. However, it will find an identical link with a new value for parameter id. Consequently, NeoLoad will offer to manage this dynamic parameter in your scenario:

Once the suggested changes have been applied to the scenario, the amended definition of the request handling this dynamic parameter will be:

In this amended definition, NeoLoad has changed the request's manual definition into a link extractor, by setting the parameter id as a dynamic parameter (value .*). Furthermore, NeoLoad will place the value of this dynamic parameter into the variable id when the scenario is run, so the variable can be used later on in the scenario.

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

This section describes how to record the interaction between an existing SOAP client and the web services server.

Description of the SOAP request editing pane:

	Note
	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.

Editing the parameters extracted from the WSDL

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.

Parameters

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 "Children" 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".

	Note
	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.

The attributes section allows the user to edit the parameter's attributes. The permitted attributes are listed in the table. The first column, "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.

Headers

This tab is used to configure the SOAP headers declared in the WSDL.

Its use is similar to that of the Parameters tab.

The specific SOAP Headers section allows the user to define the SOAP protocol's "Actor" attribute.

Advanced

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.

XML preview

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.

Editing the XML content

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.

XML text

This tab allows the user to edit the XML text.

	Tip
	Right click or use 'Ctrl-F' to search.

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.

Preview

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).

	Tip
	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.

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 checking button.

The Details section provides details of the request sent and of the server's response, and access to the assertion messages.

	Tip
	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 "Find..." or use Ctrl-F to search.