This section outlines a replay cookbook of preliminary steps that you can follow to diagnose common issues with replaying sessions through Tealeaf CX RealiTea Viewer.
Overview of Replay
During replay, RTV loads a version of the target web page into an instance of Internet Explorer over which it has control. When objects required by the target page are requested, RTV intercepts the request in the IE instance and decides if it has the requested object in the loaded session or if it must get it from the original server, the web application.
If RTV can locate the object in the session data, it creates a version of it and requests it through a proxy server that it uses to deliver the requested object as if it came from an external web server.
When you look at the headers of the request, these proxied requests typically originate from localhost:<some_port_number>
.
Images, JavaScript™, and CSS are typically not captured and stored in the session data, as these items do not change often and require significant storage overhead. During replay, these items are commonly requested from the origin server. Other items such HTML, scripts that are created based on customer data, JSON, and binary data are usually captured in session data; if they were to be requested live at replay time, they may have changed or are unavailable.
Check 1. Verify everything you need is in the session
In the Page Load Details page in RTV, you can see each object that the web page is requesting from the session and the origin server.
- If any item is, Page Load Details may give insight into the elements that are not replaying correctly.
- To access Page Load Details, select View > Page Load Details.
Many seemingly complex replay issues can be rectified by verifying that all required data is in the session data or accessible from the server. Often, a UI element that is missing or fails to replay is corrected as soon as a POST or JSON request missing from the session became available.
Examples
- If JavaScript or CSS is not retrieved successfully during replay, the site may not replay correctly or may render poorly. These types of errors are easily corrected.
- Some files are created based on user credentials, like cookies or login accounts. If these files are not captured in the session data and are requested during replay, they usually do not complete successfully. In most cases, a generic version of the file is returned from the origin server, or a redirect occurs during the request, returning another unassociated page, such as the home page. This issue results in erratic replay.
- If POST data are required to dynamically affect UI elements of the web page, this data must be captured in the session data.
- Common examples include drop-down lists that auto-populate based on previous choices or radio button groups toggled based on user input.
- Usually during replay, a request is issued when a UI element is changed. This request is usually a POST request that instructs the server to send the data that is required for the page. This request and the returned data must be in the session for replay to accurately portray what happened during capture.
- UI Capture may need to be implemented in order to capture these data.
- There are certain cases where JavaScript must be captured in the session data for replay to work correctly.
- Good examples are ashx files for .NET websites, as these contain script code that is needed to control UI elements of the page.
- If these data are being dynamically created on the server during the user's interaction with the web page, replay must reference versions identical to the version used during capture. In this instance, the custom-built JavaScript must be captured in the session data to replay correctly.
- When in doubt, check Page Load Details.
Replay for sites requiring sign-In
If you have most of your static content, such as images, script, or objects, blocked from users who are not logged in, RTV is likely to have issues retrieving this content during replay.
Options
- You can acquire the content and place it on a proxy server, such as the Portal server, which can store the content so it may be served during replay. This scenario requires a host/port remap rule to map the URLs for static content to your proxy.
- You can enable Business IT Mode in the PCA so that all images and static content are captured.
- You must remove blacklisted extensions and MIME types and add the file name extensions to the whitelist (like
gif
,jpg
, etc.). - You must also verify that the Processing Servers have
DelImages
disabled in the DataDrop pipeline agent so that the content is not dropped.Note: This functionality can be enabled in the PCA pipeline, which limits the volume of data that is processed and transmitted to the Processing Servers.Note: This configuration captures all content in the session. Operating in this mode dramatically increases the storage requirement and should only be used during POC or other temporary situations where Replay must be demonstrated. This solution is for temporary use only.
- You must remove blacklisted extensions and MIME types and add the file name extensions to the whitelist (like
Check 2. Verify needed data are not being blocked by Privacy
Privacy is used to obscure sensitive customer data. While privacy secures customer data, it can result in some data needed for replay being blocked.
A common rule that causes replay issues is BlockURLFields
. This rule blocks all the parameters that are appended to the end of URLs following a ?
character. If during replay you notice many of the URLs in the Navigation list (upper left pane) have lists of X
characters following them, you may have privacy settings issues. If the URLs in the Navigation list have any repeated character following them, privacy is usually the culprit.
The obscured URL parameters are needed by RTV to match the requests with the data in the session. If the requests cannot be matched, then they are requested from the origin server. The returned hits are not identical to the originally captured hits, which results in poor replay.
Examples
- When the main page request for the session has URL parameters, obscuring them can force RTV to request them from the origin server, which results in poor replay and artificially inflation of the hit count for the page.
- If
.axd
pages in .NET server sessions are blocked by privacy, crucial parts of the web page that is required for reacting to JavaScript events are not available.- Because these pages commonly have the same name with different content (such as
WebResource.axd?xxxxxxx
) for each request, the URL parameters are required by RTV to decide which version ofWebResource.axd
in the session is needed for the page. - There are several types of files where this can happen. Any file containing specific JavaScript for UI controls must be available during replay through the session data.
- Because these pages commonly have the same name with different content (such as
- If POST data are blocked by privacy or the POST request has URL parameters that are blocked by privacy, those POST requests are not matched correctly, and UI elements fail to replay.
- Replay is impeded for any URL if the parameters used to make that page unique were blocked by privacy. At one customer site, dynamically generated GIF images of application forms were requested using a
document
andpage
parameter. When blocked, these parameters caused RTV to fail to find the image. The image failed to display, even if it existed in the session.
Check 3. Client UI Capture for Ajax is in use and its events are captured
Tealeaf offers the CX UI Capture for AJAX to be deployed to the customer website and served to the visitors' browsers when they navigate the website.
This JavaScript hooks in to the UI elements on the client's web page and sends events back to the Tealeaf system when the visitor interacts with the UI elements. The events are converted to XML data and are POSTed back to the website using Ajax.
After the UI events are captured, they are saved in the session to be used by RTV during replay. The events come in bundles of XML and can be seen in the REQ view of the session in RTV. Using timestamps and other parameters, RTV sorts these events and associates them with the pages in the session.
Because the events were captured while the user interacted with the web application, they can replay how the user interacted with each UI element on the web page and in the order of interaction. For replay of this type to work correctly, however, events must be correctly matched with the parent page, and the UI elements to which they pertain must be available at replay time in the UI of the page.
Examples
- A web page contains a form and is referencing the CX UI Capture for AJAX. The form is either shown or hidden based on the values of a set of radio buttons. If replay of the radio button event fails, the form is not displayed during replay.
In this case, all replay events to fill the form fields following that radio button click fail to replay as well, since the form does not exist in the UI. This common situation has many different variations.
- A web page has a set of drop-down lists. The choice from list 1 affects the content of list 2. If the request from list 1 fails due to privacy blocking needed data, the request resulting in an HTTP 404 error, or the event for list 1 failing to fire, then list 2 fails to replay. For example, if there is a list 3 dependent on list 2, events should fail for it as well. In this case, follow Checks 1 and 2 to verify the UI event data are captured in the session and that the requests are being matched up correctly (for example, no privacy blocking).
- There are several events that say
xpath
in front of them, and they have a long list of members and may have no "value" data. These events do not do anything during replay, and all subsequent UI events don't do anything.In this case, the
XPATH
event is missing a crucial piece of information that most likely cannot be matched to the content on the page, and RTV cannot send the event to the UI element.Note: This situation is complicated. Contact Support for assistance.
Check 4. Verify only one main page is requested for each page in the navigation list
A common issue regarding replay occurs when the RTV user clicks a page in the navigation list. The page displays and then disappears, replaced by an HTTP 404 or another, incorrect page.
In this scenario, RTV runs JavaScript or HTML when it highlights the elements of the UI during replay. RTV can be configured to highlight fields and UI elements during replay to denote the element clicked by the visitor during their visit to the web application.
In RTV the replay highlighting option allows scripts associated with the currently highlighted UI element to run and to carry out all actions that are specified in the script that is intended for the origin website. This option is not always needed if the origin site is simple and does not toggle elements through UI controls. However, if the site uses complex JavaScript behaviors to control UI elements, these script actions must be run during replay.
In RTV, select Tools > Options > Replay tab. The options is labeled, Invoke JavaScript while highlighting.
Examples
- If the parent site has a Next button to navigate away from the current page, this button most likely causes a navigation when RTV highlights it. You must remove this anchor tag or JavaScript so that it cannot cause navigation.
- There is an overlay page that makes the rest of the screen inactive and displays a form with which you can interact.
Check 5. Verify frame content is configured correctly
In websites that use frames, replay can require some work to display the pages properly. A page in the session is likely to be the parent frame and subsequent pages after it in the Navigation list (upper left list) are the child frames that must be placed within the parent.
To allow proper replay of frames, you must enable the following RTV features:
- Tools > Options > Replay > Replay Frames (required)
- Tools > Options > Advanced > Replay Remote Frames (optional)
- Tools > Options > Advanced > Aggressive Frame Placement (optional)
Then, you must tell RTV the hierarchy of the frameset:
- Find the page that you expect to be the parent page. Click this page in the Navigation list and click the RSP button to examine the HTML code of the response, which should contain a
<FRAME>
tag. Inside this tag, the URLs of the subsequent pages in the Navigation list should appear.After they are found, you can right-click the parent page in the Navigation list and select Replay Rules > Place this page in a frame > _top. The parent page is configured to hold all subsequent child pages.
- Locate each page that must be placed in the parent page from the Nav list. Right-click each page and select Replay Rules > place this page in a frame and then select the frame ID that pertains to this element.
Usually, the
src
parameter that is located in theFRAME
element of the parent page contains the URL of the child element to be assigned. Then, use thename
orID
parameter of theFRAME
element in the parent page to assign the child.