Skip to main content

Advanced Web Script Generation Options

When you use the Generate Script from Recording wizard in Eggplant Performance Studio to generate a script from a recording, there are some advanced options you can configure. The last pane you encounter before you click Generate (to generate your script) contains configuration tabs you can select to navigate to the following advanced configuration areas:

note

If you choose to generate another script from the same recording, the Generate Script from Recording wizard uses any options you configured earlier to generate the new script. You might want to generate another script using different advanced configuration options. To change these options, navigate through the configuration areas described here, change the options to the desired values, then generate a new script.

Web Forms​

The Web Forms tab includes selections that let you choose whether to automatically or manually correlate forms data (POST or query data).

Web Forms tab in the Advanced web script generation options in the Generate Script from Recording wizard

Data can be passed in following ways:

  • Using HTTP, data can be sent to web servers either as POST or Query data.
  • POST data is sent using an HTTP POST request and is passed to the web server within the body of the request.
  • Query data can be sent using either an HTTP POST or GET request. Query data is clearly visible as it forms part of the actual URL being requested. The string of characters following the '?' character at the end of some URLs is Query data.

Click the Web Forms tab to make your selections. The following selections let you choose whether to automatically or manually correlate forms data (POST or query data).

When selected, name=value pairs sent as POST or Query data is matched to a form on a previous web page and auto-correlated. At runtime the extractForm() statement extracts the form data and places it into a RequestData object. The RequestData object is then used as a parameter in a later navigate statement. This is powerful functionality that greatly reduces manual correlation and handles forms that alter dynamically in both content and length. Checking this option also selects the Format Post and Query options on this tab.

Use the table located beneath this selection to view real-time form matches to make it easier to adjust the percentage thresholds for the matching algorithm.

Do not correlate forms​

By selecting this option, you can set or clear the following checkboxes:

  • Format HTTP POST data as name, value pairs: If the data is in the form of name=value pairs then it makes more sense to manage it as such using a RequestData object to store the pairs. When unchecked, POST data is formatted as a single string of characters that can be difficult to both read and parameterize. Although POST data is often sent as name=value pairs this is not always the case; in such circumstances this option should be unchecked.

  • Format query data as name, value pairs: Selecting this option will manage the query data using a RequestData object to store the pairs.

Mode​

The Mode tab includes selections that let you choose which script mode, Page or URL, to use when processing downloaded content during script generation.

Advanced web script generation options in the Generate Script from Recording wizard

Click the Mode tab to make your selections:

  • Page (recommended): If you select this option, it results in the generation of script source code structured around top-level URL navigations; primarily resources of content-type text/*. In most cases, if the recorded web session contains user-invoked navigations to, say, three separate URLs then the resulting script will be structured around three methods; one per URL. Each method will in turn navigate to each URL and the associated resources (images, scripts etc.) referenced by the returned page will be requested automatically at run-time. Using this option inserts setGetEmbeddedUrls(true) into the script. See Downloading web page resources at runtime for a discussion on page resources. Click here to see an example structure of a script generated in Page mode.

    Selecting this option has some additional considerations:

    • Ignore page resources: If this option is selected, embedded resources (that are treated as subrequests) will not be downloaded. This option reduces the length and complexity of the generated script. However, it will almost certainly be less accurate when played back in a test run than the traffic that would actually be produced by the real application.

    • If the Ignore page resources: option is cleared, any added or ignored subrequests are added to an aptly named method at the bottom of the generated script. For example, for a request named request1 in the script, any subrequests would be processed by a method called request1_ProcessSubRequests().

          Url url1 = new Url(protocol1, bbc, "/");
          try (Request request1 = getWebBrowser().createRequest(HttpMethod.GET, url1))
          {
            request1_ProcessSubRequests(request1);

            try (Response response1 = request1.send())
            {
              response1.verifyResult(HttpStatus.OK, ActionType.ACT_WARNING);
            }
          }

          private void request1_ProcessSubRequests(Request request1) throws Exception
          {
            // Ignore these URL's when making subrequests. Either they do not appear in the recording, or they are fetched in a later request.
            request1.ignoreSubRequest(protocol1, static_, "/id/0.36.23/style/ie8.css");

            // References to the following page resources could not be found within the contents of the received web page.
            // This can occur because resources are fetched as a result of style sheets or the browser executing script code e.g. JavaScript.
            request1.addSubRequest(protocol1, static_, "/id/0.36.23/svg/icon-sprite.svg"); // Request: 3, 200 OK
            request1.addSubRequest(protocol1, mybbc, "/notification-ui/2.6.6-mvt/svg/bell_grey.svg"); // Request: 4, 200 OK
          }

  • URL: If you select this option, then for each resource (pages, images, scripts etc.) downloaded during recording a separate navigate statement is created in the script source code. The resulting script source code will be (much) longer than a script generated in Page mode. Any handling of dynamic HTML must be added manually. Selecting this option inserts setGetEmbeddedUrls(false) into the script

    Selecting this option has some additional considerations:

    • Follow HTTP redirects at runtime: If this option is selected redirects occur when a resource request is redirected to another location. A redirect is commonly associated with an HTTP 302 response although other response codes may also cause a redirect. Checking this option results in only a navigate statement for the first URL in the redirect chain. During replay the web runtime engine will automatically handle and follow redirects to the correct location. Unchecking this option will produce navigate statements for each URL in the redirect chain.
    • The setFollowRedirects() statement is inserted into the script.

Cookies​

The Cookies tab includes selections that let you choose how to process cookies during the script generation.

Cookies tab on the Advanced web script generation options panel in the Generate Script from Recording wizard

Click the Cookies tab to make your selections:

  • Include persistent and client generated cookies in generated script: This option ensures that pre-existing persistent or client-generated cookies detected in the recording are inserted into the script source code as parameters to saveCookie() methods. Attention should be paid to the initial cookie cache of the browser when using this option to ensure a realistic script is generated. It might be necessary to parameterize these cookies to vary them for each virtual user.
  • Automatically correlate cookie values: Use this option to ensure that cookie values passed as part of web URLs or other similar methods are read and included in the generated script.
  • Show recorded cookies: When selected, this option causes the script generator to insert comments about cookies sent and received into the generated script, which is helpful for debugging problems with cookies.
  • Ignore cookie values shorter than: Use this option to specify that you want to ignore cookies of a specified length.

For a more detailed discussion of operating with cookies see the section on Cookie handling.

General​

The General tab includes selections that let you choose how to process several different general considerations, such as string handling and transaction naming, during script generation.

General tab in the Advanced web script generation options panel of the Generate Script from Recording wizard

Click the General tab to make your selections:

  • String handling: Split string literals in script source after n characters: Long string literals within scripts can make the scripts more difficult to read. This option splits a string literal into multiple smaller strings based upon the number of characters set here. Note that any POST data that is longer than the length shown in the Maximum POST data string length field is placed into a file located in <project folder>\data\files\<recording name>. Note that the actual file name varies, as it is generated from the recorded data.
  • Auto Transaction Naming: Client inactivity threshold (seconds): The time threshold for detecting user actions. Set in fractions of a second. If no user transactions were entered during recording then the generator will auto generate a transaction name on each occasion that it detects a period of inactivity within the web recording.
  • It is best practice that transactions should be entered by the user during recording. Generated web scripts are sub-divide into smaller Action() methods based upon transactions. This ensures greater script readability as well as enabling the logical partitioning of a script into user actions.
  • Verbose comments: If checked, this option causes the script generator to insert extra comments into the script source code to aid understanding of the generated code.
  • Generate code for HTTP 404 Not Found response: When resources cannot be found on a web server the response code is an HTTP 404. Such responses have a content-type of text/html whether or not this is the actual content-type of the originally requested resource. If checked, navigate statements for these resources will be inserted into the script. At runtime, warnings will be generated for these resources if they are still not found on the server during replay. By clearing this option navigate statements are not generated and thus no warnings will be received during replay.
  • Generate code for all requests that have no response data: Occasionally requests can be recorded that have no response data. If this option is unchecked these requests will be inserted into the code as comments. If checked, navigate statements will be inserted.

Authentication​

The Authentication tab includes selections that, if desired, let you enable and configure server or proxy authentication.

note

Any credentials entered in the Proxy Recorder Settings Authentication tab are also entered here. If you change the credentials here, they are used in subsequent script regenerations. Subsequent script regenerations are affected by selecting or clearing the Server or Proxy Authentication Required checkbox, which is used to enable or disable this authentication feature.

Authentication tab on the Advanced web script generation options panel of the Generate Script from Recording wizard

Click the Authentication tab to make your selections:

If the credentials are changed, the most recent values entered here will be used in subsequent regenerations (including turning the option off).

  • Server or Proxy Authentication Required: Select this checkbox if the website, or the proxy that you go through to reach the website requires user authentication.

  • If one of the following types of authentication is used:

    • NTLM
    • Other Microsoft based server authentication

    then select the Use Microsoft WinInet libraries runtime property (see Web: Options).

  • User Name: The default name to use for authentication. This entry sets a default value for the user name that can be overridden by a Data Dictionary value with the name user (see data parameterization).

  • Domain: The default domain to use for authentication. This entry sets a default value for the domain that can be overridden by a Data Dictionary value with the name user (see data parameterization).

  • Password: The default password to use for authentication. This entry sets a default value for the password that can be overridden by a Data Dictionary value with the name "password" (see data parameterization). It also inserts a setUserPassword() statement into the script when authentication is required. See Setting User Name and Password Values for more information.

Proxy Settings​

The Proxy Settings tab includes selections that let you select and configure proxy server settings. You can also choose to not use a proxy server (call the server directly).

Proxy configuration tab on the Advanced web script generation options panel of the Generate Script from Recording wizard

Click the Proxy Settings tab to make your selections:

  • Do not use a proxy server: Check this option if you do NOT use a proxy server to connect to the websites you have recorded.

  • Use the following proxy server settings: Check this option if you do use a proxy server to connect to the websites you have recorded. The proxy server address and port number should be obtainable from your browser settings. In Microsoft Internet Explorer 7 select Tools > Internet Options > Connections > LAN Settings.

    Selecting this option has some additional selection considerations:

    • Address: The address of the proxy server.
    • Port: The port number of the proxy server.
    • Using this option inserts a setProxy() statement into the script when a proxy server is used.

Regions​

When developing web scripts, you may want to edit the script after it is generated to make adjustments that is otherwise not possible using generation rules.

To ensure any code you add is saved and is not overwritten or lost if your script is regenerated, you must add your changes in certain regions in the generated script. The code added to the regions is preserved by the script generator if the script is regenerated. You can see an example of regions in Sample Script with Regions Sections.

Click the Regions tab to make your selections. The regions are as follows:

  • General
    • Imports/Usings: This region can be used to give the script access to additional types located in external namespaces. For example, if you make a DLL/JAR file available to your scripts, you will likely want to add a using or import statement that references the library, which lets the code use the types directly without having to fully qualify them.
    • Global Variables: This region appears at the top of the script class, before any methods are defined, at the point where class member variables are declared. Use this region to define your own global variables and class member variables.
  • Script methods
    • Pre() method: This region appears at the end of the pre() method, which is called when the script starts for the first time.
    • Script() method: This region appears at the end of the script() method, after the generated action methods.
    • Script Actions: (Advanced) Generated web scripts are sub-divided into smaller Action() methods based upon transactions. If you select this checkbox, then the EPP_ACTIONS region retains all the script Action calls that occur during script generation.
  • Transactions
    • Before StartTransaction() call: This region appears before the beginning of every transaction, which is useful for setting and resetting data, or verifying a condition before the start of a transaction.
    • Before EndTransaction() call: This region appears before the end of every transaction, which is useful for verifying if the script is executed correctly or waiting for a task to finish before the end of a transaction.
  • Requests
    • Before Request Sent: These regions appear after each request has been created, in order to modify the requests before they are sent to the server.
    • After Response Received: These regions appear after each request has been sent and the response received from the server, in order to verify or interact with the response.
  • WebSockets
    • Before WebSocket Opened, After WebSocket Opened: These two regions let you execute custom code before and after the WebSocket itself is opened.
    • Before WebSocket SendMessage/SendMessageFromFile call, After WebSocket SendMessage/SendMessageFromFile call: These regions can be used to alter the message being sent (Before), as well as add code that should be executed immediately after a message has been sent (After).
    • WebSocket ReceivedMessage callback, WebSocket Error callback, Websocket Closed callback: These regions let you persist code that should be executed when the specified events (ReceivedMessage, Error, Closed) occur.
    • Before WebSocket Message Queue's GetNextMessage call, After WebSocket Message Queue's GetNextMessage call: These regions let you modify the code immediately before and after a message is expected from the server. These options let you, for example, insert timing code (Start/EndTransaction) to measure how long it takes for the server to respond to a given message.

In C# web scripts, #region is a keyword that enables an IDE to collapse and hide a region of code. Only the regions defined above will be kept; others will be discarded. In Java web scripts, the regions are defined using comments instead.

Important

Do not move the regions or edit their names. Doing so can cause the script generator to produce unexpected results (including deleting regions that are not recognized).

note

The Before Request Sent and After Response Received regions appear multiple times, and are closely linked to the requests and responses to which they refer. If you add code to a region associated with a particular request, and then on a subsequent regeneration of the script that request is no longer present, the region will be orphaned and moved to the bottom of the script so that the code is not lost. This situation can happen if a request filter changes in one or more of the generation rules, or if the recording has changed significantly since the last time the script was generated.

Last updated on