Q-01. Have you checked page load details to see if the page is being requested correctly?

NO:

• Go to RTV > View > Page Load Details.
• Look at all the requests and see if the main page you are expecting to see is resulting in a 404 or a status code other than 200. Verify that the page is being returned from the session and NOT the remote site. In the event it is coming from the remote site, it was not properly caught in the session data. Verify that the PCA is set up to capture pages of the type you are attempting to replay. In the event it is returning some code other than 200, it is almost certain it was not captured correctly. If the page results in another page being served, often times it is a redirect after the remote server could not serve the page. This once again points to the session not being captured correctly.

Q-01. Do any of the pages in the Navigation list (upper left pane) have lists of a single character after them (such as XXXXX or @@@@)

Yes:

Privacy is blocking URL field data that may be needed to match the requests with the UI elements. Alter the privacy settings to allow URL fields to come through. Usually the culprit is the rule BlockURLFields in the Windows™ pipeline on the canister server.

Q-02. Are there any requests resulting in 404 status code OTHER than images and CSS?

Yes:

If the missing files have an extension like AXD, ASHX, ASPX or otherwise, they contain JavaScript™ needed to display elements on the page. They were not captured in the session and RTV is making a request to the origin server for them and failing. On the PCA, make sure the extension of the pages that show 404 are white-listed. Also verify they are not in the "Block" list.

Note: In the event the page has NO extension, the PCA decides to keep or throw away pages based on the MIME type contained in Content-Type in the header. Verify that the MIME type for this missing page is white-listed and not blocked as well.

Q-03. Are there multiple requests to the home page or multiple redirects in page load details?

Yes:

Most likely, pages that are needed for replay were not captured and are being requested from the origin server during replay. Because the server needs cookies or a valid session id to serve these pages, it is simply returning a redirect to the home page or other generic page. On the PCA, verify that the page originally requested has an extension that is white-listed and not blocked.

Note: In the event the page has NO extension, the PCA decides to keep or throw away pages that are based on the MIME type that is contained in Content-Type in the header. Verify that the MIME type for this missing page is white-listed and not blocked as well.

Q-04.Are there loading graphics or a large section of the page is blank?

Yes:

See S-05.

Q-01. In page load details, are there any 404 requests OTHER than images and CSS?

Yes:

See S-02, Q-02.

Q-02. In page load details, are there any requests being redirected or returning empty data?

Yes:

See S-02, Q-02.

Q-03. In page load details, are there any requests completing with a 200 that are of type POST AND are being requested form origin server?

Yes:

Save the session (TLS) as a TLA, and do a text search inside the session to see if the missing URL is in the session file.

Q-03.NO. Is the URL present in the TLA?

NO:

The POST request was not captured in the session data. This can happen because the MIME type or the extension is not white-listed or is blocked in the POST section of the PCA. Add this extension or unblock it if blocked. Go ahead and add or unblock it from the MIME type section as well.

Yes:

Most likely there is some issue with matching the captured POST request in the session during replay. If the URL has URL encoded values (like _, or %36) in it, go to RTV > Tools > Options > Advanced and clear Strict Post Data Matching. This does not do a simple string comparison when matching POST requests.

Q-01. In the page load details, do you see a request for more than one MAIN page (page with an "asp, jsp, html, htm, php etc...extension)?

Q-01.YES Does the initial page have a submit button or other page transition button on it (like "next")?

Yes:

Most likely the highlighting used when replaying is causing the button to navigate. If you don't require RTV to run JavaScript when it highlights (like there are no dynamically shown/hidden elements) then you can turn off Invoke JavaScript when highlighting in RTV > Tools > Options > Replay.

If you need the JavaScript to run while highlighting for other elements to replay, then you can write a response mod rule to replace the JavaScript that fires that button. Running a subsearch for the URL that is being requested is usually sufficient. Then replace the URL with the '#' character (anchor).

NO:

It may be that there is a javascript that is attempting to load a new page. Searching for phrases like "window.location.href " or "window.navigate" or "document.location" or "window.location" can help you pinpoint what code is doing the navigation.

In the event you don't find these, it is possible that the code to do highlighting is simply an anchor tag <a href=. Because there will be tons of these, you need to search for the last "main" page URL you see in the page load details. Once you see the URL that is causing the problem (the one that is causing the 404 or is the wrong page), you can search for this URL and hopefully the anchor tag that is associated with it.

In either of the above cases, a response mod rule requires to replace the code or anchor tag so it does not fire when highlighted.

If this setting is available, verify that the following was selected: RTV > Tools > Options > Advanced > Two Phase Replay.

Q-01. Are there multiple subsequent pages in the navigation list (upper left list) that have unformatted HTML or weird looking data in them?

Q-01. YES Does the content in the following pages look like it should be the content in the area with the loading graphic or blank area?

Yes:

The content is not being matched correctly but is in the session. This usually means the URL in the parent page (the one with the blank area or loading graphic) is using URLs with a host included. This causes a cross site scripting issue where this content is not loaded. RTV loads its content through a proxy server located at localhost:190X, this is expected to be the host and when the replayed page requests something from a different host (the host of the original site) security in the browser blocks the request.

To fix this, you must search for URLs that have the host that is contained in them. An example would be URLs that look like "www.thecustomersite.com/interesting_content.asp."

The URL matches one of the subsequent pages that contain the unformatted HTML mentioned above.

A response mod rule should be added to change this URL to "/interesting_content.asp". This relative URL should allow RTV to place the content in the missing area.

Q-02. In page load details (see S-01) are there any requests of type POST that are returning 404?

Yes:

The content to fill the missing area is being requested by the page to the origin server because it may not be in the session or is not being matched correctly. See S-02, Q-02.

Q-04. Does a rectangular area (possibly blank or with a message) cover a portion of the page?

Yes:

This may be a frame placement problem. The problem may appear more frequently when navigating backward through the session.

In this case, to correct the problem, try clearing Aggressive Frame Placement in the Advanced Options tab in RTV.

Q-05. When you look at the RSP (hit the RSP button), does it look like there is a whole page there (meaning opening and closing html tags, body tags, and content) that looks like valid HTML?

Yes:

In some cases, the content of the page is hidden using CSS or JavaScript and when the "loading" portion is finished, the page is shown. However, in RTV, the page is already there (no Ajax request to complete) and so we want it to show. An example would be a session where there is a DIV that is shown on load of the page. You can write a response mod rule to replace the JS code to allow it to show. This requires some slogging through the customer JavaScript.

Customer example: The body tag looked like this:

<body
onLoad="javascript:onloadExpressICMS();
   javascript:setOnLoadFlag();
   javascript:hideProgres();
   javascript:validateAllForOnLoad('A');
   javascript:myFormLoad();
   javascript:setFocus('agentRecord1');
   javascript:releaseOnLoadFlag();
   javascript:controlInsuredInformationBlock
      ('F','false');
   javascript:handleIcmsCookie('1250291211465');
   javascript:displayLinks();">

This tag contained a call to "hideProgress()" that I then looked for (because there was only a progress bar displaying during replay of the page). I realized it might help to call that function so I wrote this replay rule:

<HostProfile name="eagent.farmersinsurance.com" id="31">
          <ResponseModify id="34"
              url="/PLA/eAgent/eAutoE/view/info/
                   premiumsummary/
                   premiumSummaryCancelAll"
              pattern="onLoad=&quot;"
              replacementString="onLoad=&quot;
                  hideProgres()&quot;
                  onLoaded=&quot;" occurrences="all"/>
     </HostProfile>

This rule converted the tag to the following:

<body onLoad="javascript:hideProgres();">

The page now shows by calling the hideProgress() function first.

Q-01. Do the popups ask if you want to debug?

Yes:

Try turning off the script debugger. RTV->Tools->Options->Advanced->Disable script debugger. This should block the popups that ask you to debug.

If this still does not block them, Open IE->Tools->internet options-> advanced and check "disable script debugging (Internet Explorer)" and "disable script debugging (other)"

If neither of these help, see the resolutions under S-06, Q-02.

Q-02. Do the popups ask if you want to continue running scripts?

Q-01. YES Does the popup mention "access denied" AND the current page is using HTTPS?

Yes:

This is often caused by javascript trying to set or change a variable that is on a secure page when RTV is using localhost over a non-secure connection to serve the files. You must find the offending line (usually in a separate file) and make sure the request cannot occur.

See the next topic as well even if HTTPS.

Q-02. YES Does the popup mention "access denied"?

YES:

This is often caused by javascript trying to set the domain through "document.domain = ". You should do a subsearch for this text to see if this is the issue. If it is not found, you should use RTV->Tools->Get Images and then do another subsearch. This gets dynamically requested/generated pages that are not in the session and search them. When you find it, write a response mod rule to replace this text with "//document.domain=", this comments out that line of javascript.

If this does not work, it is also possible there is some other javascript member that is domain-specific and is not allowing RTV to set it during replay. At this point, you must look for document., window. and investigate. You will must toy around with response mod rules to modify this offending line.

Example:

At one customer, they had a review partner named Bazaarvoice loading in an IFrame and getting content from reviews.epson.com. Because RTV was loading everything from localhost:1901 (our internal proxy), there was a cross site scripting issue. To fix it, I wrote this replay rule:

<ResponseModify id="159" url="" pattern=
    "reviews.epson.co.uk"
    replacementString="localhost:1901" occurrences="all"/>

This rule allowed the IFrame URL to be changed to the localhost:1901 that we use, eliminating the cross site scripting.

Q-03. YES Does the popup mention "'x' is undefined"?

YES:

This is often caused by javascript requiring an object that was not collected in the session, or cannot be collected from the origin server at replay time.

This can be because a javascript file did not load successfully. Check page load details and see if any JS files are returning a 404.

• If the file returning 404 is being requested from the origin server, then it means it is either password that is protected and cannot be retrieved without a session, or it is behind a firewall or some other blocking network condition. Either way, this file should be collected during capture. See S-02, Q-02.
• If there are no 404's, then it means something is different between the way the page runs during replay and the way if runs in the wild. It is possible that some javascript is being successfully retrieved from the origin server during replay (200 status) but that its content is different than when it was requested during capture. If there are any redirects or pages in the page load details with empty content length, this is most likely the reason. Make sure these pages are collected during capture See S-02, Q-02.
• If the object it complains about seems to be a Tealeaf related variable, it is likely the Tealeaf.js file was not included by the customer correctly. Verify that it was included in a static way that can be cached. Usually this means at the top of the main page and not in any subsequent included requests. If it is included in ANY dynamically generated page, this is a serious issue and must be resolved. Consult the UI Capture library installation manual for details as to how the script must be deployed.
• If none of the previous issues apply, it means that some javascript variable is causing the script to fail on replay. To track the issue down, do a subsearch for the variable the popup mentions, and investigate.

Q-01. Are you blocking any URL's by replacing part of them (that is, changing "my.site.com" to "blocked")?

Yes:

We have seen internal proxy servers have issues with requests going to unknown host names or URL's. Usually the issues manifest with very slow performance of all content. The way to fix this is to go to the "hosts file" of IIS and add the new verbiage to the file as the same entry as localhost. An example would be to add "blocked" as above into the hosts file as the same entry as localhost.

NO:

It is possible that the internal proxy or other software (anti-virus) does not recognize the RTV User Agent. This means that when RTV requests something, unknown User Agent strings (i.e. not Internet Explorer or Firefox, and so on) can be blocked from requesting content or experience poor performance. The customer must make sure that their internal infrastructure knows and allows RTV to request content for replay to be reliable. This issue can also result in images, CSS, and other portions of the site to be blocked when RTV requests them, resulting in poor replay.

Q-01. Do UI events replay up to a certain point?

Q-01. YES Do you see any UI events of type "Exception"?

Yes:

Validate that your target page is set up correctly. Hit the REQ button in RTV and inspect the REQ buffer of the Exception type event. If the event contains the "FailedUrl" parameter, and it contains TeaLeafTarget.aspincluded in the URL, it is misconfigured. This does not apply to Client Side Capture.

If the ResponseType=unknown, this is also an indication that the target page is misconfigured.

Q-02. YES As you click through, do events that look like they should do something fail to affect the page?

Yes:

If replay works up until a certain point and then subsequent events do not modify the page or highlight, it usually means some content is missing. Events are based on ID's associated with form elements on the page such as fields or buttons. If these UI elements do not exist or the IDs are not unique or do not exist, replay cannot use them.

Right click the UI element in the main window you believe should be replaying with the event and choose "view element source". This shows you the HTML for the UI element in the page. Obviously, if the element is missing on the main page, you must consult S-02.

Once you see the ID of the element, make sure that the event ID is the same as the UI element ID in the HTML. If it does not have an ID, or the ID is different in some way, this is why the element is not replaying. One missing UI element can cause all subsequent events to fail, if the event was supposed to trigger display of the UI elements for subsequent UI events.

Q-03. YES Does the page contain form fields but the events seem to be missing?

Yes:

In the event the main page contains a form with fields and there don't seem to be UI events to show the user interaction with the fields, UI events may be missing or not captured. This can happen because other javascript on the page is "unhooking" our listeners that help us capture user interaction on the page.

If you have verified Q-01 above and the target page is correctly configured, contact engineering if you believe UI events are missing that should be caught.

Q-04. YES Is the failing event of type "change" in the Nav List?

Yes:

If the event is of type "change", you must add this type of event to the list of events RTV is replaying. This event is needed in situations where other associated events are missing such as "KeyUp" in a form field. To enable this event, go to RTV->Tools->Options->UI Events and add the word "change" into the field next to the "Add New Type" button. Once the "Add New Type" button becomes active, click it to add this type. Then click the checkbox next to "change" in the list.

Q-05. YES Does the broken event begin with "xpath" in its entry in the Nav List?

Yes:

Events of type xpath are needed when UI elements on the replayed page do not contain IDs. The xpath denotes a walk of the HTML DOM to find the element and use it during replay.

The xpath events can be tricky, in that they sometimes require changes to the Tealeaf UI Capture library to handle special cases.

Contact engineering when xpath events fail during replay.

Q-01. Do the pages display as a bunch of (seemingly) nonsensical characters?

Q-01. YES Do the pages have a unique query string or URL that does not match pages you want to display?

Yes:

You can right click them and choose Replay Rules->Remove this page from replay. Remember, this causes all pages with this URL to be removed.

Q-02. Do the pages all have the same URL or query string that also matches pages you want to display?

Yes:

You need to remove them using a unique REQ value. Click the REQ button on one of the offending pages and search for a REQ name-value pair that is in the pages you do not want, but is not in the pages you do want. A good example of this is "HTTP_X_REQUESTED_WITH=XMLHttpRequest" which usually denotes AJAX requests you do not want to show. Highlight this in the REQ and right click choosing "Remove page with this request value from replay". This hides these pages from now on.

Q-03. Do the pages display portions of a webpage?

Q-01. YES Do the pages look like parts of a frameset?

Yes:

See. Q-02.