Chat now with support
Chat with Support

Foglight Experience Monitor 5.8.1 - Installation and Administration Guide

Installing and configuring Multi-appliance clusters Configuring the appliance Specifying monitored web traffic Transforming monitored URLs Managing applications Foglight components and the appliance Using the console program Troubleshooting the appliance Appendix: Third party software Appendix: Dell PowerEdge system appliance

Transforming form variables

Form variables are HTML constructs that appear in HTTP POST requests. These are typically tied to HTML elements that allow the user to enter data in boxes and pick lists, and are posted to the application server when the user clicks a Submit button or preforms a similar action that transmits user-supplied data to the application. If desired, you can have the appliance monitor the values of form variables and append them to the URLs that appear in the database by creating the appropriate variable rule.

For example, consider an HTML form that uses a hidden variable named step, which is assigned a number identifying the current stage of a purchasing transaction.

If no form variable has been defined, any instance of this page appears in the database as:

Without a defined form variable, you are not able to evaluate each step of the transaction, since all steps are aggregated into a single data set. However, if the step form variable is defined, the appliance records web pages for all steps:

Transforming session identification variables

Transformations can also be performed on user session identification variables that have already been defined in the appliance, see Identifying user sessions. Typically, session identifiers are cookies, although they may also be query, form or parameter variables.

With most monitored applications, the session identifier remains constant for the entire length of the user's session. However, if some portion of the session identifier changes during a user’s session (for example, an application appends extra information such as a server name or IP address to the session identifier) the appliance interprets this change as the start of a new user session. The end result is truncated user sessions, which are displayed in the User Sessions Log, reflecting only a subset of the user’s actual activity.

To configure the appliance to accurately track a user session whose identifier changes during the course of the session, define a variable rule that ignores the changing portion of the session identifier.

The variable you change should already have been defined in the Session Identification Variables section of the User Sessions page. For more information about User Sessions, see Identifying user sessions.

Performing actions on variable names and values

All variable rule definitions and modifications are made on the Variable Rules > Edit Variable Rule page.

Configuration of a variable rule requires that you specify actions on both parts of the name-value pair. For example, consider the URL www.store.com?catalog=pet. This URL consists of a single variable whose name is catalog, that may have many values such as pet.

By defining a variable rule, you can control how both the name and value are transformed when the appliance adds the URL to the database. You could choose to ignore catalog altogether, to mask its values as XX, or to expose all of its values in the database. The operations that can be performed on each half of the pair are respectively found in the Name Action and Value Action sections.

The Name Action section allows you to identify the variable name and type, as well as apply transformations to it.

The Variable name box and Evaluate as regular expression box allow you to specify which variables are affected by the rule.

The name that is entered must precisely match that which you wish to find in monitored URLs. For example, if you enter catalog as the variable name, this sample URL:
www.store.com?catalog=pet
will be affected by this rule, but this URL:
www.store.co.uk?catalogue=pet
will not be transformed.

By selecting the Evaluate as regular expression check box, the value that you entered in the Variable Name box is treated as a regular expression. With this setting selected and the string catalog.* specified in the Variable Name box, this rule would affect both of the URLs:
www.store.com?catalog=pet
www.store.co.uk?catalogue=pet

The Variable type list allows you to specify the variable type:

Query Variable–these are query strings that appear after the question mark in a URL, and are the most common type of variable to which you can apply transformations.
Form Variable–these are variables that appear in HTTP POST requests, and are typically tied to HTML elements that allow the user to enter data, such as text entry boxes.
XML Variable–these are variables that appear in HTTP POST requests, but are encoded as XML.
For example, if a POST is submitted to this URL:
http://www.store.com/entryform.asp
and the following XML structure is passed in that HTTP POST on submission:
<Screen Action=“Save” Panel=”Address” >
the URL will appear in the system as:
http://www.store.com/entryform.asp
However, if Screen.Action is declared as an XML variable, then the URL would appear as:
http://www.store.com/entryform.asp [ Screen.Action=”Save” ]
Cookie Variable–these are variables that appear in cookies contained in the HTTP header. From the perspective of end users, cookies are transparent, and are not visible in URLs.
Parameter Variable–these are values that appear after the path portion of a URL.
HTTP Variable–these are values that appear in the HTTP headers and contain information about the client, server and the web page. Some applications can create custom HTTP headers that contain useful state information relevant to the application itself. In these cases, you can configure these HTTP variables and expose their values in the user interface.

When you select the Show as is option button, the name portion of the name-value pair is not transformed, and only the operation performed on the value portion of pair changes the URL.

In the case of a Cookie variable, the name portion of the name-value pair is appended to the recorded URL.

If you are identifying an XML variable in the Variable type box, this is the only available option. You cannot transform the name portion of an XML variable.

If you are identifying a Query Variable, Form Variable, Cookie Variable, Parameter Variable, or HTTP Variable in the Variable type box, you can replace the name value of the variable with either a literal string, or a regular expression.

Selecting the Replace with option button requires that you enter a direct replacement string in the accompanying text entry box.

Selecting the Transform with option button necessitates the entry of a regular expression in the accompanying text entry box.

Select the Hide option button if you would like to completely remove the name portion of the name-value pair from the recorded URL. This option can be performed only on a Query Variable, Cookie Variable, Parameter Variable, or HTTP Variable, as selected in the Variable type box.

When you hide the name portion of a name-value pair, all options in the Value Action section are disabled.

The Value Action section allows you indicate what type of operation you want to perform on the value portion of the name-value pair.

When you select the Show as is option button, the value portion in the URL is not modified before being recorded to the database.

Selecting the Transform option button requires that you enter two regular expressions in the accompanying text entry boxes: the first being the string to search for in the value portion of the name-value pair, and the second being the string that replaces the detected string, before the URL is recorded to the database.

Selecting the Mask with XX option button causes all values of the name-value pair to be replaced with XX in the transformed URL.

Selecting the Decode as XML option button indicates XML is embedded in the variable value, and needs to be expanded.

Consider the following example:
http://www.store.com/page.asp?xml=<Screen Action=”Save” Panel=”Address”>

In this URL, there are two XML variables in the XML string:
Screen.Action, and Screen.Panel.

By default, the appliance would detect and display the URL as:
http://www.store.com/page.asp?myxml=XX

In the Name Action section, if you identify xml as the variable name, and in the Value Action section, choose to Decode as XML, the URL would transform to:
http://www.store.com/page.asp?xml=<Screen Action=XX Panel=XX>

If you continued by defining another variable rule for Screen.Action, the URL would then be transformed to:
http://www.store.com/page.asp?xml=<Screen Action=”Read” Panel=XX>

Selecting the Decode as URL option button indicates the variable value is an embedded URL, and needs to be expanded.

Consider the following example:
http://www.store.com/page.asp?step=http://www.store.com/
actualstep.asp?action=save&session=12345

In this URL, you can create a variable rule that instructs the appliance to decode step as a URL. This allows you to further manipulate variables that are embedded in the step URL (that is, action, and session).

By default, the appliance would detect and display the URL as:
http://www.store.com/page.asp?step=XX

If you identify step as a variable name in the Name Action section, and in the Value Action section, choose Decode as URL, the URL would transform to:
http://www.store.com/page.asp?step=http://www.store.com/
actualstep.asp?action=XX&&session=XX

If you continued by adding an additional variable rule for action, the URL would then be transformed to:
http://www.store.com/page.asp?step=http://www.store.com/
actualstep.asp?action=save&&session=XX

The following section discusses how to add variable rules.

2
In the Name Action section, begin by entering a string in the Variable name box that identifies the variable that appears in monitored URLs.
3
Select, or leave the Evaluate as regular expression check box clear, depending on whether you want to use a regular expression to define multiple variable names, or use a literal string to find an exact match.
4
From the Variable type list, select whether the variable that you are looking for is a query, form, XML, cookie, parameter, or HTTP variable.
8
Click OK to save the variable rule definition.

Rather than entering variable names manually, you can choose the auto-discovery links and have the system generate lists of variables that currently appear in the monitored network traffic.

2
Click Stop at any point to cancel the search, and use the list that has been compiled up to that point.

Displays the names of the variables that are passed in the URL, POST data, cookies, HTTP request headers, and HTTP response headers.

You can select its check box and then click Add to include it in a new variable rule.

A high value (number) in this column means that there are many different values that appear for the variable. Ensure you do not select query variables that are unique for every user that connects through the monitored application.
Unique variables generate unique URLs, all of which are recorded to the database; an excessively large number can result in an overloaded appliance on which data loss may occur. Review
Transforming query variables, Transforming form variables and Transforming session identification variables for information on variable transformations.

The number of times that the variable was found in the traffic.

The number of unique values of the variable found in the traffic.

Displays up to three of the most utilized values for the variable. Each variable is no more than ten characters in length.

3
Clicking the details link for a variable opens a dialog box that displays a list of values detected for the variable.
5
Click Add.

If you are monitoring SharePoint® servers, you can automatically populate the list of variable and query rules by clicking Apply on the Configure > Applications > SharePoint page. After the SharePoint monitoring is enabled the list of default variables appears in the variable rules sections.

Using hints

Foglight Experience Monitor is typically able to identify which URLs represent the start of a new page download, and then from these URLs the appliance can correctly identify which URLs are hits that belong to the page. However, there may be cases where the appliance is unable to correctly distinguish a page from a hit. This can occur when a URL is not recognized as the starting point for a new page download, or when a URL is incorrectly recognized as a new page, when it is actually an element of the current page download. These situations typically arise with HTML frame-based applications.

You can use the URLs > Hints page to create hints, in the form of regular expressions, that are matched against incoming URLs to force URLs to either always be treated as the start of a new page, always be treated as a hit that is part of another page download, or treated as a component of a page.

Figure 68. Hints page

These page hints ensure the accuracy of the appliance page and hit metrics for highly complex web applications.

For more information, see these topics:

Related Documents