HTTP request details

General tab

Version

Indicates the HTTP version.

Method

Indicates the HTTP request method that was used during recording. Typically, you do not change this value unless you are adding a new request to a test. GET, POST, PUT, HEAD, PATCH, and DELETE are supported.

Primary request for page

Displayed for the primary request, and cannot be modified. A page can contain only one primary request.

Click to set as primary

Displayed for all secondary requests. Because each page can have only one primary request, if you select this option, the Primary request for page option is moved to this request, and the Click to set as primary option is moved to the original primary request. To undo your change, select Click to set as primary on the original primary request.

Connection

Specifies the connection to the web server. The connection includes the host name, which is typically the fully qualified domain name, and the listener port on the web server. Click the name of the connection to navigate to the server access configuration where the connection is defined. Click Change to change the connection used for this request.

Total number of requests

Applies to HTTP Secondary Request Generator. Specify the number of requests to send to the server. If there is an array variable assigned to the request, the number of requests set in the Test editor takes precedence.

URL

Specifies the path to a resource (such as a page, graphics file, or stylesheet file). When the method is GET, the URL field typically includes query strings that are designated as dataset candidates.

Data

Specifies additional content data that might be needed to clarify the request. When the method is POST, the data frequently includes values that are designated as dataset candidates.

Request Headers

Lists each request header and its value. To change the value of a header, click the row, and then click Modify. To add a new header, click Add. To delete a header, click Remove.

Enable response time breakdown

Select to enable the collection of response time breakdown data. You can enable response time breakdown collection at the parent or page level. Not all test elements support response time breakdown data collection.

Use the Advanced page to configure performance requirements, error handling, and delay behavior for the request.

Advanced tab

Always log details

To ensure that the details about the request is always logged, select this check box.

Use substituted URL in performance reports

Use this option to view the substitutions in Page Elements report.

Requirement

All performance and functional requirements are displayed in the table. Shaded requirements indicate that they are undefined. To define a requirement, provide details in Operator and Value. To apply the defined requirement to multiple requests, select the requests in the test, right-click the requirement row in the table, and click Copy Requirements.

Enable Requirements

Select to enable the use of performance and functional requirements for this test.

Name

Specifies the name of this set of defined requirements. By default, the name is the URL of the request. Although you can change the name to improve readability, only the Requirements report uses this name. Other reports use the default name. Click Use Defaults to reset Name to the default value.

Operator

Click this field to display a list of mathematical operators. Select an operator for the performance requirement.

Value

Click this field to set a value for the requirement.

Standard

Select to enable this requirement to be processed by the report as a standard requirement. Standard requirements can cause a test to fail. Requirements that are not listed as standard do not cause the test to fail.

Hide Undefined Requirements

Select to prevent the table from including undefined requirement candidates. Selecting this check box hides all shaded rows.

Clear

Select one or more requirements, and click to remove the definition. The requirement is still available and can be redefined.

Error Handling

Click to open the error condition table. You can use error handling to specify an action to take and a message to log when a specific condition occurs. Error conditions include verification point failures, server timeouts, custom code alerts, and data correlation problems. All error conditions are displayed in the table, beside the action to take and the message to log when the error occurs. To define an error handler, select a Condition, and then click Edit. The Errors report lists the number of errors and the corresponding actions that occurred in the test or schedule. You can also specify whether an error contributes to the health of the page. To set the health parameter, select a Condition and select the Override contribution to health status check box. The Page Health report shows the health of each page.

Hide unselected conditions

Click to display only the selected error handlers. Hiding a condition does not deactivate the condition.

Applied Transform

Indicates the data transformation that is applied to the request. Click Change to select a data transformation to apply to the request.

Character set

Indicates the character set to be used for the page request. Click Change to see the valid character sets.

Pre / Postprocessing

To modify and inspect certain aspects of the action before and after it is executed, specify pre and post processors. Click Create to create the Java file that will contain the skeleton of the Java file needed. Click Browse to navigate to a Java processor that has already been created.

Client Processing Delay

Previous versions of tests support only waiting for primary requests. Wait for and Release when are not available. The additional delay in previous versions of tests is measured from the first character received of the primary request.

Wait for

Indicates the associated request that must start or finish before this request is issued. Click Request to select a different request. Click the Clear request association icon to remove the association.

Release when

Select Last Character Received or First Character Received to indicate when this request is issued in relation to the associated request.

Additional delay (ms)

Indicates the additional delay, in milliseconds, to wait before this request is issued. Delays are statistical emulations of user behavior. You can scale this delay at the test level to make a test play back faster (or slower) than it was recorded.

Delay Between Requests

Applies to HTTP Secondary Request Generator. Use the delays to control the flow of the requests to the server. In Release When, select when exactly to release the request. For instance, First Character Sent indicates to release the second request after the first character in the first request is sent.

In Additional delay, specify a value in milliseconds to indicate additional delay to send the request.

Digital Certificates

Lists details about the certificate stores that the test uses. Click Add to add a certificate store for the test to use. HTTP and SOA support digital certificates. Other protocols do not support digital certificates.

Enable response time breakdown

Enables collection of response time breakdown data. With response time breakdown, you can see statistics on any page element. The statistics show how much time was spent in each part of the system under test. You can use response time breakdown to identify code problems. You can see which application on which server is the performance bottleneck, and then drill down further to determine exactly which package, class, or method is causing the problem.

This option is displayed in multiple test elements. Enabling this option in an element also enables it in the element’s children. For example, enabling monitoring at the test level also enables monitoring at the page and request levels. You can enable monitoring for a specific page; doing so enables monitoring for the requests of that page, but not for other pages or their requests.

HTTP and SOA support response time breakdown. Other protocols do not support response time breakdown.