Using the Words and Fields of an Index

Some applications do not conform to W3C standards for the names of input fields. Some sites use characters in the field names that are punctuation characters and are treated by the indexer as word separators. However, this poses a problem for searching, as the RTV user would expect to be able to type in the field name exactly as it is displayed in the Response and in the Request.

The drop-down that indicates <No Indexes Selected> can be used to select any of the cxImpact servers that host indexes: an All-in-One or any Processing Server.

After the server is selected, two buttons become available. You can select a view of the data that shows either the individual words or fields that are indexed with the help of these buttons.

The data that is shown in the text box is filtered by the Date Filter.

To acquire field values, click Get values for field. The following figure shows the results. After values are found, you can select one or more values and then construct a search term from the selected values.

To create the search term, click Enter selected values into search criteria. The following figure shows the search term that was created. You can see that the term includes the field name, the contains operator, and the parentheses-grouped list of field values, which are combined with the OR operator.

Regular expressions (regex)

Regular expressions (regex) are a way of specifying a string for pattern matching. By using meta characters, regular expressions are a flexible and powerful way of specifying patterns.

Some regular expressions are recognizable. For example, the command dir *.txt, where the asterisk is a meta character (or "wildcard") indicates to match any file name that has a .txt extension.

However, regular expressions can be cryptic, non-intuitive, and time-consuming to create and debug. The following links present regular expressions at a high level along with some important concepts as they relate to using regular expressions with Tealeaf data.

For some replay rules configuration fields, you can insert regular expressions to help pattern matching. Typically, these patterns are designed to match a range of URLs.

Greedy versus non-greedy searches

An important regular expression concept is "greedy" versus "non-greedy" searching.

For example, consider the following nursery rhyme.

Peter, Peter, pumpkin-eater,
had a wife and could not keep her.
He put her in a pumpkin shell,
and he kept her very well. 

If you wanted to look for the string Peter followed somewhere by the string her, such a search would be represented by the regular expression Peter.*her. This expression is saying to look for the string Peter followed by 0 or more characters (the .*) and then the string her.

But there are separate multiple occurrences of this pattern that match this regular expression:

Peter, Peter, pumpkin-eater,
had a wife and could not keep her.
He put her in a pumpkin shell,
and he kept her very well. 

and also

Peter, Peter, pumpkin-eater,
had a wife and could not keep her.
He put her in a pumpkin shell,
and he kept her very well. 

and also

Peter, Peter, pumpkin-eater,
had a wife and could not keep her.
He put her in a pumpkin shell,
and he kept her very well. 

The first occurrence is non-greedy; it is the shortest match string possible. The last instance is referred to as greedy, as it wants to match as much as possible.

For example, if the Peter nursery rhyme was a very long nursery rhyme (~100 kb) and even if there were no further occurrences of the phrase her, it would still have to scan the string to the end to determine that there were no matches.

Greedy regular expressions must be limited to "filtered" events or value parts of request buffer name-value pairs. They must never be used to do any searches in the response buffer, unless its contents are known.