Session data captured by Tealeaf is composed of the requests submitted by the visitor's browser to a web application and the responses served by the web server. These messages are usually in the form of HTTP GET
requests or HTTP
POST
requests to the server and the response returned to the requestor.
Historically, the request data in the POST
requests has been in name=value
pairs and is URL-encoded; the POST
data resembles a URL query string. This type of data is also referred to as form data and is by far the most common mechanism for submitting HTML forms.
With the emergence of rich internet applications, requests and responses have become more complicated, using a wider range of optional technologies. In addition to the form data, rich internet applications are now using hierarchical forms of data, such as XML and JSON, and even binary forms to communicate between client and server.
RIAs can also make use of plug-in platforms. Such applications have the option to use proprietary data formats offered by the respective plug-in vendors.
These data forms can be captured by the PCA and forwarded into the Tealeaf system. During replay, the RTV and Browser-Based Replay clients need to know how to manage these data forms. In particular, for a given request happening at replay time, the captured request/response pair with which to associate the request may not be immediately identifiable.
For example, some requests may include a timestamp or a client-generated GUID parameter. The timestamp (or GUID) that is stored in a Tealeaf session corresponds to the time when the session was captured. During replay, a different timestamp (or GUID) corresponding to the time of the replay is generated as part of the request, which results in a replay request that does not exactly match any captured request.
Depending on the data format in use, this variable parameter could also be in the form of a name/value pair, such as timestamp=14325453
, or an XML node, such as the following:
<timestamp>14325453</timestamp>
JSON properties may also be used:
{"timestamp": 14325453}
Ignoring a specific subset of variables in order to get the best matching request requires detailed knowledge about the underlying data format in which the content is represented.
Through the POST Data Matching Plugin framework, the RTV and BBR clients can access a set of plugins that help to identify the appropriate response with which to match the request. Using the content type indicated in the request, the replay client can locate the appropriate plugin to use to match requests of these content types to their responses in the session.
As the area of rich internet applications continues to expand, new plugin types can be developed and deployed to your Tealeaf environment, enabling replay to keep pace with emerging technologies. Additionally, you can configure priorities for applying the plugins, so that hybrid technologies can be managed by a suite of plugins.
Adding and removing plugins
As needed, plugins can be added and removed from the replay clients to support accurate replay of your web applications. This operation can be viewed as a configuration step and does not require full re-installation of RTV or the Replay Server.
RTV
For RTV users, plug-ins are enabled and disabled through the Plug-ins Options tab. Plug-ins must be provided to individual RTV users for deploying and enabling through the application.
Replay Server and BBR
When the Replay Server is started, a discovery is performed on the Tealeaf install directory on the Replay Server for the plug-ins, which are stored as DLL
files.
During the render phase for a session, the Replay Server utilizes these DLL
files to perform POST data matching of responses to requests before delivering the session data to the BBR client. The POST data matching plug-in framework is transparent for BBR end users.
Default plugins
Tealeaf provides a set of POST Data Matching plugins for the following content types.
Plugin Name | Supported Content Types | DLL |
---|---|---|
Form Data | application/x-www-form-urlencoded |
TLReplayPluginForm.dll |
JSON |
|
TLReplayPluginJSON.dll |
formdata/jsonp |
text/html |
TLReplayPluginJSONP.dll |
XML |
|
TLReplayPluginXML.dll |
Google Web Toolkit | text/x-gwt-rpc |
TLReplayPluginGWT.dll |
To perform accurate POST data matching during replay, no additional installation is required for the above formats.
.DLL
files to the RTV and Replay Server locations.Updating replay profiles for DWR POST data matching
You must manually configure the FormData matching plug-in to recognize DWR POSTs and to apply the proper plug-in to match the content.
- BBR: This configuration is applied through the Replay Server Profile.
- RTV: Individual users of RTV must apply this change to their local profiles.
Note: This configuration information is not shared between RTV and BBR (Replay Server) profiles, so changes must be applied on each Replay Server and each instance of RTV.
Custom plugins
POST data matching is a unique requirement for replay and isn't needed in other areas of the Tealeaf product suite. The matching itself can range in complexity from simple to one involving complex rules, heuristics and response adaptation.
Plugins can be designed to:
- Perform decoding tasks of binary responses during replay (Base64)
- Perform data matching for the specified format (XML, JSON)
- Both (AMF, binary XML, JSONP)