Skip to main content

Portal search capabilities

Portal search capabilities

Configuration for text searches

Depending on the type of session you are searching, you can search for text strings that are contained in requests, responses, events, and other derived data.

In general, specify the minimum text that is required to produce meaningful search results; lengthy search terms with extraneous words in them take longer to return the same or marginally improved results.

You can choose to return results that include the search field or to exclude the search field by selecting the applicable radio button.

  • include - returns results with the search field. This is the default setting.
  • exclude - returns results without the search field.
Note: If merging of fragments is enabled, using the NOT option might cause returning improper results. If you search the session for the absence of a search field returns a true result and a related fragment of the session returns a false result (meaning that the field is present in the fragment), both the session and the fragment are listed in the results, even though the field is displayed in the fragment. Avoid using the NOT operator when sessions are fragmented.

You can configure the maximum word length that is permitted in newly created session indexes by changing the value of the Maximum Word Size setting in the Indexing Options tab of the Session Indexer configuration in TMS. Changing this setting can have immediate impacts on search results.

Note: To limit index size, which is indexed words are truncated to a maximum of 32 characters each, by default. Longer words are truncated at 32 characters to match search fields in the index and are submitted without prompting the user.
Note: If a search field must search for values that are longer than 32 characters, you can create an MD5-hashed search field in the search template. When a user enters the full plain text, it is converted to a 32-character MD5 value and submitted to the search engine for processing.

Text searches by session type

The way a text search functions varies depending on the session type in which the search is implemented.

The following table describes how each text search behaves for the different session types.

Table 1. Text searches by session type
Search Field In Active Sessions In Completed Sessions In All Sessions
All Text This field is not available for active sessions, due to the inefficiency of this type of un-indexed sessions. The entered string is searched against all session indexes for matches.

In the default configuration, the response is not indexed, so this search field cannot be used to search response data. See below.

 Search queries are applied only to completed sessions.
Text in Request The entered string is searched against the request text in all active sessions. The entered string is searched against the values in the name/value pairs of the request that have been stored in the search indexes.
Note: In standard indexing, only a selection of request fields is indexed for search.

In completed sessions, value information is stored as words in search indexes. Name fields are stored as fields, which can be searched using the Form Field search term.

 Search queries are executed against both active and completed sessions.
Note: Since the behaviors of this field vary depending on the type of search performed, single search term in this field cannot be applied to both active and completed sessions.
Text in Response Searches all response text for matching strings. In completed sessions, the response is not indexed by default, so this type of search does not apply.
  • To search for specific information in the response, you can create an event to identify specific patterns in the response and then perform a search for that event.
  • You can also create a privacy rule to insert the data into the [appdata] section of the request, which is always indexed. This method is more advanced.
 Search queries are executed against both active and completed sessions.
Note: Since the behaviors of this field vary depending on the type of search performed, single search term in this field cannot be applied to both active and completed sessions.

How to handle URLs in a search

URLs are split up by non-alphanumeric characters, typically the forward slash (\/). Then, each word is truncated to the maximum word limit, effectively becoming multi-word search terms.

Support for wildcards in text searches

You can use wildcards in text searches. The following wildcard patterns are supported:

Table 2. Supported wildcard patterns
Wildcard pattern Description
*

Matches any number of characters. For example, C* matches both CC and CAT.
?

Matches any single character

How the wildcards are supported depends on the type of search you are running.

Note: It is by design that completed session search is based on words and does not match any text within a word unless wildcards are specified.

In the table below, you can see how two different search strings, one with a wildcard and one without, result in different matches that are depending on the type of search.

Table 3. Wildcards in text searches
Search Type String: town String: town* Explanation
Active Sessions Matches town, towns and township. None. In Active search, matches are strict text matches. Since the text town exists in all 3 words, all are returned as matches.

In the second string, there is no such word as town*, so no results are returned.
Completed Sessions Matches town. Matches town, towns and township. In Completed search, matches are made based on the word as the fundamental unit of comparison.
  • The first string is treated as a word and thus returns the word town.
  • The second string includes a wildcard, which is supported in completed search. So all 3 words are returned.
All Sessions
  • Active: Matches town, towns and township.
  • Completed: Matches town.
  • Active: None.
  • Completed: Matches town, towns and township.
 An All Sessions search runs separate queries against the specified sets of active sessions and of completed sessions. Thus, the behavior of wildcards varies depending on the type of session that are queried.

Limitations on use of regular expressions

Search provides support for regular expressions, with the following limitations:

  • A regular expression must match a single whole word. You cannot use regular expressions to match multiple words.
  • Only letters are searchable by using regular expressions.
  • No information is stored about line breaks. Searches that include beginning-of-line or end-of-line regular expression criteria (^ and \$) do not work.
  • Wildcards that are closer to the start of a search expression impacts the speed of search more. For example, the search for appl.* is nearly as fast as searching for apple, while you search for .*pple is much slower.

Text queries in the All Text field

You can also use the All Text field to construct text-based queries of the database. When All Text queries are in the form that is expected by the underlying dtSearch engine, they run as if they are constructed through the Portal form.

Note: These queries are submitted to the dtSearch engine with minimal preprocessing. As a result, it is possible to submit invalid search queries that would otherwise be prevented by the user interface. Where possible, use the search criteria that are provided in the Portal Search screen.
Note: dtSearch does not support searching for empty string values. To search for an empty string value, you must create an event to identify patterns that are matching the empty string value.

One useful way to learn to construct text-based queries is to create form-based queries and then to examine the query that is displayed beneath the search results. When inserted back into the All Text field of a new search, the query repeats the same search query. You can use these displayed queries as the basis for constructing queries of your own.

You can use the dtSearch keyword contains and the parentheses (( and )) to demarcate dtSearches.

Time grades

You can search for time grades that are assigned by Tealeaf for network transit, round trip, and page generation times.

For example, add the following string to the All Text field:


RT_Grade contains ExcellentRT

The previous query returns all sessions in which the round-trip time was graded as ExcellentRT.

The three types of time grades that can be searched for are:

  • NT_Grade - network trip
  • RT_Grade - round trip
  • WS_Grade - web server page generation

For each type of time grade, there are four grade levels. For example, following are the RT time grades:

  • ExcellentRT
  • NormalRT
  • HighNormalRT
  • HighRT

The definitions of the grade levels are specified at the point of capture in the PCA.

If this search is frequently needed in your environment, you can configure the Portal and/or the CX RealiTea Viewer to include these options in search.

Client UI URLs

If Tealeaf UI Capture is implemented in your Tealeaf solution, you can search for client user interface URLs.

Note: UI Capture enables the capture of client user interface events that do not generate a request to the web server, which can be captured through default Tealeaf capture. Tealeaf UI Capture requires more installation and implementation.

The following client user interface data are inserted into the [appdata] section of the request. You can search for this data by using the Search Keywords that are listed in your All Text search query.

Table 4. Text queries in the All Text field

REQTEXT
Request Field Search Keyword Description
TLT_CUI_URL Client UI URL The URL on the web server where the event was triggered.
TLT_CUI_APPLICATION_NAME Client UI Application The name of the client UI application name, which can differ from the TLT_APPLICATION_NAME request variable value.

Related articles

community icon

Join the community

Ask questions, share best practices, and connect with fellow marketers.

Ask a question

Academy

Read how-to articles, guides, and more to help you on the path to success.

Learn more