Create / Edit Service Test - Web Transaction (Request Simulation Mode)

Specify the frequency at which the beacon will replay the transaction and collect metrics.

Select the playback engine that should be used to play back the recorded transaction. This can be:

• Request Simulation : In this mode, the beacon will play back the Web transaction by constructing a series of HTTP requests executed sequentially, which simulates the recorded transaction.

This mode is recommended as it is more scalable and platform independent. But transactions recorded in this mode are not suitable for applications with AJAX requests. In this mode, only the server response time is measured; browser rendering time is not measured.

• Browser Simulation: In this mode, the beacon will play back the Web transaction using a browser based engine, simulating each keyboard and mouse action such as data entry in a text field, or a mouse click. This mode is suitable for applications with extensive AJAX like interactions. In this mode, the complete end user time is captured, which includes the server response time, as well as any browser side rendering time.

This mode works only with Internet Explorer 6.0 or above and requires a beacon that is 10.2.0.4 or later running on Windows to play back the transaction. Setting up the recorder in this mode requires additional steps. For a detailed description of these steps, refer to the Advanced Configuration Guide.

Note: At the end of the recording, a suitable playback mode is automatically selected based on the content of your transaction. You can manually change the mode to that which is suitable for your deployment. Refer to the Advanced Configuration Guide for details.

The amount of data collected by the beacon. This can be:

• Transaction: Data is collected for the overall transaction only. If you select this option, data will not collected for the step groups and steps in the transaction.

• Step Group: Data is collected for the overall transaction and the step groups in the transaction.

• Step: Data is collected for the overall transaction, step groups and each individual step in the transaction.

Session Parameters

Specify the URL parameters in the transaction that will vary between sessions. This will help the beacon play back the correct URLs each time the transaction is played. Multiple session parameters must be delimited using commas.

For example if a Web application uses the parameter transactionid in each URL, and if the value of transactionid changes each time a user logs into the application, then you should specify transactionid in the Session Parameters text box. The beacon will use this hint to substitute the correct value each time it plays the transaction.

You can specify additional HTTP headers in each HTTP request in the following format:

name1[nm-val-sep]val1[hdr-sep]name2[nm-val-sep]val2[hdr-sep]name3[nm-val-sep]val3

where:

• [nm-val-sep] (which is the name-value separator for a header) is a ":" (colon)

• [hdr-sep] (which is the separator between headers) is either be a "#" (hash) or a newline carriage return.

Authentication Realm

The Authentication Realm is used to verify the login credentials and is found in the top of the Basic Authentication dialog box. If basic authentication is required for the Web transaction, specify the Authentication Realm.

Before a HTTPS URL can be monitored over a Secure Sockets Layer (SSL), the beacon must be configured to recognize the Certificate Authority that has been used by the Web site where the URL resides.

You can set this flag to Yes if the beacon has been pre configured to recognize the Certificate Authority. You can then successfully monitor the availability and performance of the secure URL.

Success and Failure Strings are used to validate the content of the pages downloaded by the beacon. A Success / Failure String can be one of the following:

• Regular Text: The literal string is compared against the content of a page.

• Regular Expression: The string is treated as a regular expression that is matched against the content of a page.

Each Success String must appear at least once within a transaction. Failure Strings should not appear within a transaction or a step. If a Failure String appears within a transaction, or a Success String does not appear within a transaction, it is considered to be unsuccessful. Click the symbol to add more Success and Failure Strings.

Note: Only beacons that are 10.2.0.4 and above support Regular Expression mode.

Transaction Timeout

The timeout period for the entire transaction.

Connection Timeout

The maximum amount of time that the beacon will wait before connecting to a Web server.

Read Timeout

The maximum amount of time that the beacon will wait while trying to read data from a connection.

The amount of time that the beacon will wait between attempts to play a transaction.

You can use Regular Expression Variables to adapt the dynamic content of a transaction depending on the content of the pages downloaded by the beacon. For example, you can specify that the beacon should always click on the first link in a table, even if that link changes regularly.

When the beacon downloads a page, it will attempt to match each regular expression to the text of the page. If a match is found, then the value parsed for the last sub-expression in parentheses will be assigned to the variable. Each variable consists of a name, value, and a mode, as follows:

paramFor_Link <a [^>]*href="\S*/OA_HTML/OA\.jsp\?(\S*)"[^>]*>ABM Supervisor</a> Raw Text

where

• paramFor_Link is the Name

• <a [^>]*href="\S*/OA_HTML/OA\.jsp\?(\S*)"[^>]*>ABM Supervisor</a> is the Value

• Raw Text is the Mode.

For example, suppose you specify the variable as above, and in a subsequent step you specify that the URL is http://www.mysite.com/OA_HTML/OA.jsp?[paramFor_Link]. When the beacon plays the transaction, it will apply the regular expression to each page.

Suppose the beacon downloads a page that contains the string

<a href="http://www.mysite.com/OA_HTML/OA.jsp?transactionid=1829345234&oas=ABCDEFG”>ABM Supervisor</a>

In this case, the beacon will apply the expression to the page and assign the value transactionid=1829345234&oas=ABCDEFG to the variable named paramFor_Link. When the beacon gets to the step with the variable reference it will lookup the last known value of paramFor_Link, and it will play the URL "http://www.mysite.com/OA_HTML/OA.jsp?transactionid=1829345234&oas=ABCDEFG"

For each variable, three forms of encoding modes are available.

• URL Encode: The value obtained when the regular expression is applied should be URL encoded before it is substituted into the URL or the Post Data fields. Suppose the HTML fragment <a onclick="submitForm('personId','John{!!1234')"></a> is found, the encoded string John%7B!!1234 must be added.

• Raw Text: The value obtained from applying the regular expression should be substituted directly into the URL or the Post Data fields.

• Character Reference Decode: The value obtained from applying the regular expression should be dereferenced, before it is substituted into the URL or the POST Data fields. For example: <a onclick="document.location='OA.jsp?transactionid=123456&amp;oas=ABCDEFG'">Create</a>

Constant Variables

Constant Variables are variables for which you will specify an initial value. You can refer to Constant Variables in the URL or Post Data of a step (just like you would refer to Regular Expression Variables).

You can use Constant Variables in order to assign initial values to variables that are also Regular Expression Variables. Because Constant Variables may vary per beacon, you can also use Constant Variables in order to direct each beacon to play a slightly different transaction. For example, you may use Constant Variables in order to direct each beacon to play the same transaction against identical Web servers behind a load balancer.

The beacon downloads images one-at-a-time. Perceived timing metrics are estimates of how much time a page would take to download if the several images were also downloaded at the same time. This is the maximum number of simultaneous downloads that an beacon will simulate for a transaction.

If this flag is set to Yes, Success / Failure strings will be validated in HTML components, .jss, and .css files.

Indicates the version of the Recorder by which a transaction has been recorded.

The amount of time that it would take a Web browser to play the transaction. This is a good metric for setting thresholds because it is the closest active measurement of what the user-experience is likely to be.

Enterprise Manager breaks down each transaction into individual phases. Performance metrics for each phase of the transaction can help you pinpoint the cause of a slow response time alert. Connect Time is the total time spent in the transaction connecting to the server. There may be multiple connections made during a transaction. Time spent waiting for requests that result in redirects count as Redirect Time rather than Connect Time.

User Action
Significant time taken to redirect the HTTP request. If the redirect is causing the performance problems, consider alternative solutions to sending the user to another HTML page.

User Action
As with the Connect Time and Redirect Time, this metric can help you pinpoint whether or not the page content or Web application software is causing the slow response time, as opposed to the actual time it takes to transfer one byte of information to the browser. A high First Byte Time suggests that there may be high network latency between the beacon and the service. Some applications generate an entire page before sending the first byte of that page. For such applications, a high First Byte Time could also indicate that the servers are taking a long time to generate each page.

Enterprise Manager breaks down each transaction into individual phases. Performance metrics for each phase of the transaction can help you pinpoint the cause of a slow response time alert. This metric measures the HTML Time, which is the amount of time it takes to transfer the HTML coding of the page to the beacon. This metric does not include the time spent transferring images or other page content.

User Action
Slow HTML time could indicate that the application is taking a long time to finish generating each page. Alternatively, slow HTML time could indicate that network bandwidth between the beacon and the service is low.

This is the amount of time it takes to transfer the non-HTML content such as images to the beacon.

User Action
Slow Non-HTML time could indicate that the application is taking a long time to generate images. Alternatively, slow HTML time could indicate that network bandwidth between the beacon and the service is low. Consider reducing the number of distinct images in the application.

User Action
Use the Total Time Metric to identify problem transactions. After you identify a transaction that is slow to respond to user requests, you can drill down and analyze each phase of the transaction to isolate and repair the problem.

The transfer rate indicates how quickly data is being transferred from the Web server to the client browser. This is computed as: Total Kilobytes Received / Total Transaction Time.

User Action
Slow transfer rate can be caused by network congestion or other connectivity issues.

The average amount of time that it would take the beacon to play each page in the transaction. This is a good metric for setting thresholds because it is the closest active measurement of what the user-experience is likely to be. Because it is normalized on a per-page basis, Perceived Time per Page is also a good metric for comparing the relative performance of different transactions.

The amount of time that it would take the beacon to play the slowest page in the transaction. This is a good metric for setting thresholds because it is the closest active measurement of what the user-experience is likely to be.

This is the Connect Time divided by the number of connections made while playing a transaction.

This is the First Byte Time divided by the number of pages in the transaction.