Handle an application dynamic parameter

The HTML pages generated by the applications usually contain dynamic elements, that is to say elements whose values vary from one call to the next. Typically, these include unique identifiers that cannot be replayed "as is", and which must be handled individually.

When a dynamic parameter is not handled correctly:

  • requests may return an error (typically, Error 500) when validating the Virtual User;
  • the Virtual User displays an unexpected behavior (entries not created in the database for example).

NeoLoad automatically handles the most common parameters, such as the Framework .Net __VIEWSTATE parameter. However, NeoLoad cannot automatically handle some parameters that are specific to an application. These needs to be handled individually, that is to say by placing an extractor on the value returned by the server and injecting the extracted value into the appropriate requests.

This tutorial will show how search for, and handle, a dynamic parameter. The steps are as follows:

  1. Identify the request returning the error

  2. Identify the parameter to be handled

  3. Search for the request whose response contains the value to be extracted.

  4. Place the Variable Extractor.

  5. Inject the variable in the appropriate requests.

  6. Validate the changes.

The example used throughout this tutorial is taken from an e-commerce demo application. The recorded scenario concerns the purchasing of an animal on the website.

Run the Virtual User validation

Validation allows you to check a Virtual User behavior. In the event of a problem, the information required to correct the problem, namely details of all the requests sent to the server and their responses, are displayed in the validation window.

To validate a Virtual User, follow these steps:

  1. Select the Run > Start checking command.

  2. Select the appropriate Virtual User in the list.

  3. Click on the Start checking button.

Identify the request containing the error

Depending on the application tested, requests return the HTTP 500 Internal Error code. In this case, NeoLoad automatically flags the request as containing an error.

In many cases however, the error is handled at the application level and the page returned by the server shows a 200 OK error code. In this case, NeoLoad cannot detect the error automatically, and the error must be searched for manually.

To search for an error manually, follow these steps:

  1. Run the Virtual User validation.

  2. Scan all the requests with HTML responses. Typically, these will be the first or second response in each page.

  3. Check the response content for each HTML request:

    • Click on the request

    • Make sure the Response option box is checked in the Details section.

    • Examine the server response displayed in the text area for any error message or inappropriate content. Click Open in browser to display the response in a more readable format, then click Compare with recording to highlight the discrepancies between the replayed request and the response received during the recording.

In the example, the 500 Internal Error code clearly identifies the request containing the error.

Note: When an error occurs, it usually triggers a cascade of subsequent errors. To correct the problem therefore, it is important to work on the first request containing an error. Once this has been fixed, run the Virtual User validation again and correct any other errors that may be flagged.

Identify the parameter to be handled

To identify the parameter to be handled, follow these steps:

  1. Click the request /jpetstore/shop/viewCategory.shml link in the validation window to be taken automatically to the definition of the request containing the error in the scenario User Paths.

  2. You can see that the request contains two parameters:

    • categoryID: This parameter provides the category of animal selected during the scenario recording (in this case a dog). The categoryId field is not generated by the server, but is a direct result of the user's choice. Consequently, it can be safely assumed that this parameter is not the source of the error.

    • id: The id parameter is a suspect, however, due both to its name and its value. You can assume that the value is generated by the server and that this parameter is the source of the error reported during validation.

  3. If in doubt over a parameter, continue the process for each parameter. The next step will allow you to check whether the parameter should be processed, or whether the recorded value can be submitted unaltered.

Make the parameter dynamic

NeoLoad includes a search engine that allows it to configure automatically the extractor to be used. The search is based on regular expressions that take into account the all the various methods applications use to allocate values.

To make the parameter dynamic automatically, follow these steps:

  1. Select the /jpetstore/shop/viewcategory.shtml request.

  2. Double-click on the value of the id parameter.

  3. Select the Use an extracted value option.

  4. Click on the Automatic Configuration button (NeoLoad will then configure the extractor to be used for you).

  5. If you get the message "NeoLoad could not find the parameter", you will have to configure the extractor manually. For more information, see Make the parameter dynamic manually.

Globally replace a parameter in a recording

Once the extraction has been configured, the request should work correctly. However, it is a good idea to check to see if this same value is used in other requests in the scenario and to replace the static value with the new variable.

Note: This section describes replacing parameters that you made dynamic automatically. For information on what to do when you make the parameter dynamic manually, see Make the parameter dynamic manually.

To globally replace a parameter in a recording, follow these steps:

  1. Start the wizard with the Edit > Search and replace command.

  2. The wizard allows you to automate the replacement of the "id" parameter value with the "nl_extracted_param" variable. Select the first option Search request parameters, then click Next to go to the next step.

  3. Select Search names and values and replace, then click Next to enter the search criteria.

  4. In the first field, you will enter the value for the "id" parameter, that is to say "1241078526424", which was previously non-editable. In the second field, you will enter the replacement value "${nl_extracted_param}". If necessary, you can use the variable picker.

  5. Once the variable has been selected, click Next, then Finish. A dialog box allows you to replace each occurrence of the value "1241078526424". When all of the replacements have been made in the scenario, the dynamic parameter management is finished.

Re-check the Virtual User

To successfully conclude the procedure, you need to check the validity of the newly-modified Virtual User. Click the green tick button to display the validation window. Run the validation.

The request that was previously flagged as containing an error is now correctly handled. The HTTP code returned is 200, proof that the client-server transaction has been successfully completed.

Additional links

For more information, see Use framework parameters to automatically search for dynamic parameters.

For more information about extracting dynamic values from an HTML page, see Create a variable extractor.