Replay of sessions that use Ajax typically requires capturing UI events that occur in the visitor's browser.
UI Events are captured by including a set of JavaScript™ files on each page. This JavaScript hooks all UI input, captures it, and periodically sends it back to the web server. This post gets captured along with all other session data and is available at replay time, where it is used to duplicate the actions that are undertaken by the visitor when the session was captured.
If your web application makes Ajax calls only at page load time to populate elements on the page and does not have any dynamic content that changes based on user input, then you do not need UI Event capture. Otherwise, you do.
Where to start
Suppose that you have installed and implemented UI Event capture in your pages and you begin capturing sessions with UI events and Ajax pages. The list of pages is displayed in the left pane of RTV. This list must contain only full HTML pages and UI events. No Ajax pages are displayed.
The following are types of Ajax pages:
- Any dynamically requested content that is going to be processed by client script to update the display
- Some data that the user may or may not immediately see
These pages can be XML, a chunk of HTML, a bit of JavaScript, JSON, or other client-side scripting format.
Since they cannot be properly displayed, Ajax pages must be removed from the Viewable Pages List:
- Step through the session several times to determine which pages must be removed.
Any entry that is not displayed to be a full HTML page must be removed.
- To remove a page, right-click it in the left pane and select Replay Rules > Remove this page from replay.
A dialog is displayed in which you can create a replay rule to remove the URL from any replay.
- You can edit the URL with wildcards to remove similar pages with a single rule.
- For example, to match an individual page that requires query parameters, you can delete the query string part of the URL (the part after the
?
) and replace the listed content with a*
. All instances of the URL are removed from replay, regardless of the query parameters in them. - You can use any Request name-value pair that positively differentiates the Ajax calls from normal pages.
- For example, to match an individual page that requires query parameters, you can delete the query string part of the URL (the part after the
- To create the replay rule, click OK.
When you create a rule, it is placed in the profile, which is in XML format. The rule is displayed in a HostProfile
node with the matching host name of the page.
If you accidentally create a rule that hides pages that you did not want to hide:
- You can delete the rule by editing the profile on the Profile tab of options.
- You can delete the rule from the Request or Response views. Pages that are listed in the Request and Response views that have profile rules that hide them are displayed with a different icon than other pages. Right-clicking on them gives you the option to remove the rule that hides them.
Sometimes, a simple URL pattern matching does not uniquely identify Ajax pages without also removing non-AJAX pages. You can also remove pages from the Viewable Pages List by finding values in the Request that uniquely identify them. For example, if all pages use the same base URL, you can have some Ajax pages that can be filtered based on the query string part of the URL.
Suppose that all Ajax pages all have REQUEST_METHOD=POST
, whereas the non-AJAX pages have REQUEST_METHOD=GET
. To find these pages, go to the Request view of an Ajax page and locate the REQUEST_METHOD
entry. Right-click it, and select Remove page with this Request value from replay. You can edit the URL pattern, variable name, and value, as needed.
- The Microsoft™ Ajax toolkit generates URLs of normal pages that are the same as that URLs for Ajax hits. You can use the following Request variable to create rules for these hits:
HTTP_X_MICROSOFTAJAX=Delta=true
- In the absence of the UI Events capture, you can also choose to treat this page as a Highlight Only page through the context menu.
Getting the replay right
After you remove Ajax pages from the Viewable Pages List, you can attempt to replay the session. The list of pages must show normal pages with UI events listed between them.
After a page load, you can step through the UI events in the list, and RTV populates fields on the page, presses buttons, and triggers the other types of user actions that are captured by UI events. Some of these actions may cause the page content to change. Some may cause AJAX requests to be made, which in turn causes page content to change. Ajax replays rarely work properly the first time they are run.
When replay fails to work, verify the following items:
- An invaluable tool is the window, which shows all the images, JavaScript, CSS, and other pages that are requested as the page loads. It also shows Ajax requests as they are made. You can display it through the View menu.
- The Source column in the Page Load Details window shows how a request was satisfied:
- If the URL that was requested was found in the session, the Source column contains,
Session
. - If Source contains
Remote
, then the URL was not in the session, and it was sent back to the original site, which is normal for static content such images, JavaScript pages, and CSS pages. However, if AJAX requests are indicated asRemote
, they were not found in the session. This situation usually results in the replay failing to work properly.
- If the URL that was requested was found in the session, the Source column contains,
- RTV matches the URL, and also posted data, if any is present. There are several reasons why RTV might not be able to match up a request with a page that was captured in the session, and the Page Load Details window can help to find them.
If you find a
POST
entry in Page Load Details whose source isRemote
, right-click it. The menu lists all pages in the session whose URL matches the post, and under each URL entry, the menu indicates the matching and non-matching parameters. Some URLs may have wildly different parameters. Locate the page with the most matching parameters, which is closest to your current location in the session. You may be able to resolve the parameters that are causing the problem. - The most likely cause is that one or more parameters in the query string or in the posted data do not match what was captured. For example, some sites use a timestamp parameter on each Ajax request. Since the current time is never the same in replay as it was during the original capture, the time stamp never matches.
Ignoring request variables for URL matching
You can use a profile rule to tell RTV to ignore a parameter when it tries to match requests that are generated during replay to captured responses. By ignoring request variables, you can improve matching of captured URLs to the server pages they represent.
To create a rule:
- In the RTV window, click Request View.
- Right-click the parameter in the
[urlfield]
section and select Ignore this value for URL and Post data matching. - In the spaces that are provided, you can enter the request variable in the
[urlfield]
to ignore for purposes of matching URLs. These parameters can be specific[urlfield]
fields, query parameters, or other variables that are passed with the request to the server.- Enter the name of the
[urlfield]
variable to ignore. If this variable is found in the section, it is ignored for purposes of matching the URL. - If the request variable name corresponds to a regular expression, click the check box. In the Test string text box, enter the
[urlfield]
string that the regular expression must match. Click Test. If the regular expression finds a match in the test string, a success message is displayed. - In the bottom textbox, you can enter the URL pattern against which the ignore rule must be applied. To apply the ignore variable rule against all URLs, leave this field blank.
- Enter the name of the
- To create the rule, click OK.
The rule is saved to your local profile.
Hard-coded host names
Using hard-coded host names in Ajax requests can cause problems for replay in RTV. In these cases, blank entries are displayed on Ajax requests in the Source column of the Page Load Details window. When a hard-coded host name is used, RTV is unable to see the requests in a context in which requests can be found in the session data.
Using a hard-coded host name is seldom necessary because omitting the host name causes the request to be relative to the host name of the page from which the request is being made. To work around this issue, you can create ResponseModify
or ExternalFileModify
rules to remove the host name from the code that is building the request's URL. Using a ResponseModify rule, you can replace strings in the URL (for example, http://www.host.com/
with /
).