For some applications, RTV must be provided with hints in the RTV profile. Each user has a profile file to which these hints can be added.
Hints can also be synchronized by a central profile server. The RTV power users and Tealeaf administrators can update the central profile when the web application changes. The updates are propagated to all RTV users.
You can edit the most common profile elements through the RTV application. Users who are comfortable with XML can edit all profile options in the XML file.
RTV ships with a default profile for providing hints that help RTV replay the session. The Profile consists of a RequestMapping node and zero or more HostProfile nodes.
The RequestMapping node rarely changes. It contains the standard mappings followed by the major web server technologies: Apache and IIS. Each RequestEntry node within the RequestMapping section gives RTV a list of entries for which to search in a Request and from which to retrieve values that are needed to replay the session. It is unlikely that you will require to modify the RequestMapping node.
In the HostProfile nodes, you can customize replay. The rules within each HostProfile node apply to all pages that come from a specified host. The host name is specified in the 'name' attribute. Do not include a protocol identifier, such as HTTP or HTTPS, or a port number in the host name.
If your Tealeaf cxImpact system is capturing many different web applications by using many different HTTP_HOST values, you need to create multiple HostProfile nodes. The host name can contain simple wildcards to allow a set of rules to apply to more than one host. For example, if your websites have one application that responds to www.mybiz.com, mybiz.com, and public.mybiz.com, and another application on www.internalmybiz.com, you would probably setup two HostProfile nodes,*mybiz.com, and *internalmybiz.com.
Be careful when you use wildcards to avoid creating conflicts between multiple HostProfile nodes that operate on the same domain. For example, if you had two HostProfile nodes: www.mycompany.com, and *.mycompany.com, sessions from www.mycompany.comwww.mycompany.comwould always pick up rules from the www.mycompany.com HostProfile node.
The Rules within the HostProfile node control how RTV replays the session. Most of these rules can be created or modified through dialogs and menus within RTV, so editing the raw XML is not necessary.
The specific Replay Mapping directives are as follows:
||Tells RTV that this is not a viewable page. If a matching page is displayed in the session, it is not inserted into the navigation list and cannot be opened during replay.
|Add Host/Port Remap (remap host)||
||Replaces the host name of the page with the specified host. There can be only one RemapHost node within a HostProfile node.|
|Add Host/Port Remap (remap port)||
||Changes any page by using the port in valueIn to the port number in valueOut. There can be multiple RemapPort nodes within a HostProfile node.|
|Add Host/Port Remap (protocol)||value=(auto, http, https)||Overrides the captured protocol of the all pages to specified type. There can be only one Protocol node within a HostProfile node.|
||Places any matching URLs into the named frame.|
||Used to do special processing to pages before replay, generally to nullify any page execution that is undesirable in replay.|
||Used to do special processing of external files, such as js files, before replay, generally to nullify any page execution that is undesirable in replay.|
||Used for Ajax replay. When matching requests generated during replay to captured hits in the session, some entries must be ignored, for example, a timestamp parameter.|
|Add PopupUrl||value="/popup.html"||All pages that match the pattern are treated as Pop-up pages. These items are displayed in the NavList, and when you browse to them, they are displayed in a pop-up window.|
||(AJAX pages) When UI Capture is not deployed, these rules mark the response of the specified URL as highlight only. In these cases, the response is treated as modifying the appearance of the preceding page, instead of replacing it.|
Note: The protocol identifier (
|Specify a rule to block specific URLs or URL patterns from reaching out to the origin server. If the matching response is not in the session, no request is made to the origin server for the content, and the response is not displayed in RTV.|
Ignore profiles stored in TLS
When you load a TLS, if a profile and options are stored within it, they are applied when the session is loaded and replayed. Any changes that you make to the profile or options apply only to the loaded session. Those changes are lost if you close the TLS without saving and are not applied to the global profile.
If this option is enabled, any profile or options that are stored within the TLS are ignored when the file is loaded and replayed. The global options and profile settings are used instead. You might choose to ignore the settings that are stored in the TLS if they are known to be incorrect and are sure of the global settings.
Enable and disable profile rules
As profiles become more sophisticated, you might find it useful to be able to disable individual rules for troubleshooting purposes.
In the Edit Profile dialog, you can enable or disable individual profile rules or groups of profile rules by selecting the appropriate check box.
Create a profile rule
To create a profile rule, select any displayed profile rule and then click New.
Select the type of rule from the displayed list:
||Add a host to monitor. The name of the host must be the full domain name of it (for example,
||Specify a URL for a page or pages that must not be included in replay. You can apply wildcards
||If needed, you can remap detected host names and port numbers in the captured session data to redirect to other host/port combinations. This type of rule is useful for forcing replay to not use a production server.|
||If IFRAMES are used for the web application, you can specify these rules to place URLs or patterns of URLs into specified frames.|
||These rules modify the response data based on detected patterns for one or more URLs.|
||For files that are referenced in session data, these rules modify the response data based on detected patterns so that unwanted effects are not applied to the session replay.|
||These rules can be used to specify
||Dynamic response modification rules are used to modify the response data by using parameterized event identifiers.|
||Dynamic external file modification rules are used to modify external files that are referenced in the session pages by using parameterized event identifiers.|