Identifying and Reporting Web Pages

7 Identifying and Reporting Web Pages

This chapter describes how to identify the web pages to be monitored. In particular, how to define the web pages for which you want additional information to be available, and those pages that should be monitored for the occurrence of specific text strings. The use of the ruling and other advanced facilities is also explained. Finally, the monitoring of traffic within a SSO-based environment is described.

URL Arguments

URL arguments configured for applications, suites, and services, as well as for user and client ID identification, must be specified without encoding (except for %, &, and = characters).

Naming Pages

Page identification within RUEI is based on applications. Essentially, an application is a collection of web pages. This is because pages on a web site are typically bound to a particular application. Each page within an application has an assigned name, and belongs to a group. For example, MyShop » Contact » About us refers to the About us page in the Contact group, within the MyShop application.

Each application has a page-naming scheme associated with it, which defines its scope. This can be specified in terms of a partial domain name, URL structure, or a combination of both of these. A page-naming scheme (such as page tagging or the title part of the HTML page) can also be specified to refine the application definition.

For each page that RUEI detects, it uses the available application definitions to assign a name to it. Information about any pages that could not be identified using these definitions is discarded and, therefore, not available through reports and the Data Browser.

In addition to automatic detection, application pages can also be defined manually. This is particularly useful in the case of an inconsistent URL structure, or where identified pages contain sub pages, or when you want to assign a different name to the one assigned automatically to it by the application. These manually defined pages take precedence over pages identified automatically through application definitions.

The structure of the currently defined applications, their groups and pages, are visible by selecting Configuration, then Applications, and then Applications. An example is shown in Figure 7-1.

Figure 7-1 Example Application Overview

Description of "Figure 7-1 Example Application Overview"

To edit an application identification filter, click on the associated value, for example to edit the cookie filter, click aCookie=22.

Tag Based Applications

Defining Applications describes how to monitor an application using either a tag based or network based data collector.

For tag based applications, where a tag data collector is used, but a network data collector is not used, collection of data from header, XPath and content sources is not applicable for application configuration, user id and content messages. For example, user id and content messages are not applicable to a tag based application. To identify users for a tag based application, use the oraInfo.user tag. To configure browser exceptions, use the specific "Browser exception" source within content messages and set the session tracking configuration to 'Oracle' to use the cookie being sent by the Javascript library.

However, with tag based applications, several metrics (for example, hits, application language, application territory, detail timings, and sizes) and replay functionality are not available.

To overcome these limitations you can install a network data collector in addition to the tag based collector. Create Framework Exceptions as described in Refining Application Definitions Through Framework Exceptions to create a hybrid configuration where both tag and network based traffic are combined.

For information on setting up tag and network based monitoring see the Installing the RUEI Software chapter of the RUEI Installation Guide.

Defining Applications

To define applications, do the following:

Select Configuration, then Applications, and click New application. The dialog shown in Figure 7-2 appears.

Figure 7-2 Configure New Application

Description of "Figure 7-2 Configure New Application"
Specify a name for the application. This should be unique across suites, services, SSO profiles, and applications. Because application names are appended to reported pages, it is recommended that you keep defined application names as short as possible. Applications cannot be renamed later.
Use the remaining fields to specify the scope of the application. This is defined in terms of page URLs. As you enter this information, you can see the effect of your definition through the Filter preview column.
The highest level filter is the domain. It is not possible to specify an application name and leave all the other fields blank. That is, a blank filter. A wildcard character (*) cannot be specified within the Find Port field, and only one port number can be specified. If you need to specify additional ports, these should be specified as additional filters after the new application has been created.

Be aware that while the use of a wildcard character is supported within certain fields, all other specified characters are interpreted as literals. Finally, it is not possible to specify the wildcard character and no other information for domain and URL argument combinations.

Note:

It is advised that filter definitions be mutually exclusive across applications, suites, SSO profiles, and services. For example, an application filtered on the domain oracle.com and then a second application filtered on oracle.com/application_servlet, can lead to unpredictable results. See Controlling Rule Ordering Within RUEI for information about how you can influence the order in which matching rules are applied.

Note:

URL arguments configured for applications, suites, and services, as well as for user and client ID identification, must be specified without encoding (except for %, &, and = characters).

You can also specify a URL GET argument that must be matched. If you want to use this facility, both the argument name and argument value must be complete in order for them to be matched to detected page URLs. This is, partial matching is not supported. When ready, click Next. The dialog shown in Figure 7-3 appears (HTML Title is default selection).

You can also specify a cookie using the Find cookie and Cookie value fields.

Figure 7-3 New Application Dialog
Note:

If the Tag based application checkbox is ticked, the following page naming schemes are listed,
- HTML Title (Browser JS Library)
- Oracle (Browser JS Library)
- URL based options
If you are creating a tag based application, select that option and click Finish. For more information on the tag and network data collectors, see Tag Based Applications.
If you are creating a network data collector based application, this dialog allows you to specify the automatic page-naming scheme used for pages within the application. Only one scheme can be specified per application. The following option groups are available:
- Page tagging: specifies that a either a standard scheme (such as Coremetrics) or a custom scheme is being used. In the case of a custom scheme, you are required to specify the name of the tag. The HTML title option specifies that the text found within the page's <title> tag should be used to identify the page. See Using Advanced Settings to Control the Handling of Pages and Objects for more information about the use of this option. The structure and processing of the generic page tagging schemes supported by RUEI are described in Tagging Conventions.
- Client request: specifies that pages are identified on the basis of their URL structure. The following options specify which portion of the URL is used:
  - URL argument: page naming is based on a specified argument within the URL. Only ASCII characters are allowed, and special characters (such as "&" and "|") must be URL-encoded.
  - URL: page naming is based on the complete domain and URL as it appears in the visitor browser location bar. This scheme is particularly useful when using ruling.
  - URL directory: uses only the directory part of the URL. The various parts of the URL are highlighted in Figure 7-4.
  - URL base: uses the main directory and file name (without the file extension) parts of the URL.
  - URL full: uses the main directory, the file name (without the file extension), and the configured arguments within the URL. If you select this option, you are prompted for the arguments that you want included in the page name. Within the dialog box, multiple arguments should be separated with an ampersand (&) character. For example, if the frmAction parameter has been defined, the URL shown in Figure 7-4 will result in the page name myshop » shop » NL index frmAction=buy.
  - Header in request: specifies that page naming uses a specified header within the client request. Not that only ASCII characters are allowed in the header name (and not special characters such as ":").
  - XPath in request: specifies that pages are identified on the basis of an XPath expression applied to the client request. For more information on the use of XPath expressions, see Working with XPath Queries.
  - XPath in JSON request: specifies that pages are identified on the basis of an XPath expression applied to the JSON client request. For more information on the use of XPath expressions for JSON requests, see XPath on JSON Content.
  - Custom Pattern in request: specifies a start string and (optionally) an end string to delimit the searched content. The use of wildcard characters is not supported, and all specified characters are treated as literals. In addition, besides any specified end string, the search will never extend beyond a new line.
  - HTTP Method and URL: page naming is based on the HTTP Method and the complete domain and URL as it appears in the visitor browser location bar. This enables support for REST (REpresentational State Transfer) style applications.This naming scheme option will report the HTTP Method and complete URL space separated. After creating your application definiton, select the naming scheme in the application overview to define URL ruling and use Translation lists.
  If you select any of the above options, see Using Advanced Settings to Control the Handling of Pages and Objects for further information about their use.
  
  Figure 7-4 URL Structure
  
  Description of "Figure 7-4 URL Structure"
- Server response: specifies that pages are identified on the basis of the server response. The following options are available:
  - Header in response: specifies that pages are identified on the basis of a specified header within the server response.
  - XPath in response: specifies that pages are identified on the basis of an XPath expression applied to the server response. For more information on the use of XPath expressions, see Working with XPath Queries.
  - XPath in JSON response: specifies that pages are identified on the basis of an XPath expression applied to the JSON server response. For more information on the use of XPath expressions, see XPath on JSON Content.
  - Custom Pattern in response: specifies a a start string and (optionally) an end string to delimit the searched content. The use of wildcard characters is not supported, and all specified characters are treated as literals. In addition, besides any specified end string, the search will never extend beyond a new line.
- Manual: specifies that the application pages will be manually defined rather than through automatic detection. If you select this option, all pages associated with the application that you want monitored must be manually defined. See Manually Identifying Pages for information on manual page definition. This is the default option.
When ready, click Finish. The application definition you have specified is displayed. An example is shown in Figure 7-5.

Figure 7-5 Example Application Overview
This overview provides a summary of the defined application. This includes the application's name, the number of unique pages that have so far been matched to it, and the date of the most recent page identified for it. If no page has been identified for the application in the last three days, a warning icon is displayed to indicate that the application is not currently functioning.

If you created a tag based application, you must define an Browser JS Library as described in Defining Browser JS Library Settings.

An application is enabled as soon as it is created. This means any traffic matching the setup criteria is recorded. Whenever the Data collection enabled box is unchecked, traffic rules are applied as if this application is not present. Existing data remains present, and the application can be re-enabled at any time.

The tabs in the lower part of the screen provides information about specific aspects of the application. For example, The Identification section summarizes the filter criteria currently defined for the application, while the Pages section specifies the the page-naming scheme to be used, the report unclassified pages setting, the page-loading satisfaction threshold, and the pages so far identified as belonging to the application. Each of these sections are described in more detail in the following sections.

Note:

When an application is deleted, both the configuration and all previously measured data is discarded. This action is irreversible.

Note:

If you create a tag based application using a page naming schemed that is not URL based and later edit that application to make it non-tag based (unticking the Tag based application checkbox), it is converted to an equivalent page naming scheme. For example, a HTML Title (Browser JS Library) scheme becomes HTML Title.

If you tick the Tag based application checkbox for an application that was previously non-tag based and used a page naming scheme that was not URL based, the naming scheme is converted to Oracle (Browser JS Library) and all ruling is removed.

Defining Browser JS Library Settings

If you created a tag based application, you must define a Browser JS Library, that is a URL served by the application that acts as the tag that is monitored.

To specify the Browser JS Library used by your applications or suites, do the following:

Select Configuration, and then Applications or Suites. Select the required application or suite to view its overview. An example is shown in Figure 7-1. Click the Pages tab and then the Configuration tab.
Click the Browser JS Library setting. The dialog shown in Figure 7-6 appears.

Figure 7-6 Edit Browser JS Library Dialog

Description of "Figure 7-6 Edit Browser JS Library Dialog"
RUEI creates a library API key that is unique for the application. If you need to modify that key, refer to the Maintaining the System chapter of the RUEI Administrator's Guide.
Specify the URL of the requested object and optionally enable options to record the number of objects on your page and/or screen resolution. To browse data relating to screen resolution, select Browse data, then select User flow completion or All sessions. You can then browse data relating to Client Screen Resolution. If you select the Browser Exception option, all javascript errors are sent to RUEI. To later check on those errors, select Browse data, then select Browser Exceptions. To check browser hits, select All pages, then Application Hits and Browser Hits. Specify an absolute path in the URL field without wildcards. If the application you are monitoring is hosted on a separate domain, specify a full URI including scheme, for example http://myhost.com/images/marker.gif.

Note:

If you are defining a tag based application, the Browser JS Library URL must refer to a file with an extension that is defined as a forced object as described in Controlling the Reporting of Objects as Pages.

Select the Navigation Timing option if you require reporting on timing relating to browser navigation. See Optimizing Page Download and Browser Time Reporting for more information on how navigation timing is reported.
Click Generate JavaScript and download the JavaScript code, and include it in the required application pages by making the following changes to your application pages:
- Add the following line between the <head> and </head> tags:
```
<script type="text/javascript" src="ruei_library.js"></script> 
```
  The above example assumes that the JavaScript library is in the same webserver path as the page itself.
- Add the following to the <body onLoad> tag or suitable location where the page has finished rendering:
```
<body onLoad="oraInfo.sendPageLoad();"> 
```
  In previous releases of RUEI, the following HTML was recommended. This code continues to be supported:
```
<body onLoad="oraInfo.sendData();"> 
```

If you selected "Oracle (Browser JS Library)" as the Page Naming scheme for the application as described in Defining Applications, you must also set the oraInfo.page property as described below.

The use of wildcard characters is not supported for security reasons.

For applications and suites using network data monitoring, the default is that no Browser JS Library is configured and if you do not define one, page browser times will be reported as zero. In addition, page loading/reading time analysis will also be less accurate because the reported page load times will not include page browser times. If pages are being requested from a CDN server (such as Akamai), use of the OnLoad event includes the render time of objects served through the CDN.

Example 7-1 Tag Library Properties

If you created a tag based application, RUEI automatically reports the page title using the reserved tag library property, oraInfo.title.

In addition, the following properties that can be specified using javascript code:

Table 7-1 Tag Properties

Name	Default	Explanation
oraInfo.url	document.location.href	The value RUEI reports as page url.
oraInfo.page		The value RUEI reports as page name.
oraInfo.pagegroup		The value RUEI reports as page group.
oraInfo.action		The value RUEI reports as action.
oraInfo.user		The value RUEI reports as user.

For example:

<script type="text/javascript" src="ruei_library.js"></script>
<script type="text/javascript">
 oraInfo.page = 'homepage';
 oraInfo.action = 'view';
</script>

Example 7-2 Monitoring Page Clicks Using the Tag Library

If you created a tag based application, you can monitor page clicks using the onclick oraInfo.sendAction property. For example, the following code reports an when a user clicks on the "Click here" link:

<a href="#" onclick="oraInfo.sendAction('clickAction');"> Click here</a>

Example 7-3 Manual deployment of Browser JS Library link

As alternative to step 4 in Defining Browser JS Library Settings, you can also create a request to the specified marker object yourself. When enabled, RUEI will detect this request and records the start time of this request as being the browser time. Specified URL search pattern must correspond to that in the triggered request.

For example:

onLoad="m=new Image(); m.src='http://myhost.com/marker.gif?apikey=yourAPIkey&' + new Date().getTime();"

where yourAPIkey is the API key for the Browser JS Library and a timestamp is included as an argument to prevent browser caching. The event can be included in the BODY part of the HTML page, or any other required location (such as within a Flash program).

The above example does not include browser exceptions, navigation timing, object count, and screen resolution. You should use the JavaScript library if you want to include those.

Example 7-4 Using Custom Dimensions with the Browser JS Library

If you create a Custom tag (Browser JS Library) dimension as described in Working With Custom Dimensions, you can set properties relating to those dimensions. For example, if you created a three level dimension, consisting of levels product, group and vendor, then you could include the following code to set properties for a page:

<script type="text/javascript" src="ruei_library.js"></script>
<script type="text/javascript">
 oraInfo.product = 'x9991';
 oraInfo.group = 'Servers';
 oraInfo.vendor = 'Oracle';
</script>

After creating this three level dimension, RUEI collects data that you can later browse and use in reports as described in Working With Custom Dimensions.

Example 7-5 Supported Browsers

The Browser JS Library works on modern browsers that support W3C timings, for example IE9+, Firefox 34+, Chrome 31+, Safari 8+, Opera 26+. However, Internet Explorer 8 is not supported.

Applying Page Naming Translations

In addition to the defined page-naming scheme described in Naming Pages, the reporting of application pages can also be modified through the use of page translations. These allow you to specify transformations that should be made to a page's reported page-group » page-name specification.

Defining Page Translations

To define page translations, do the following:

Select Configuration, then Applications, then Applications, and select the required application. The application overview (similar to the one shown in Figure 7-5) appears.
Click the Pages tab, and then the Page translations tab. The currently defined page translations are displayed. Click Add new translation to define a new translation, or click an existing one to modify it. The dialog shown in Figure 7-7 appears.

Figure 7-7 Add Page Translation Dialog

Description of "Figure 7-7 Add Page Translation Dialog"
Specify the original page identification, and group and name that should be reported for it. The original value must be specified in the format group|name. When ready, click Save.

Moving Page Translations Between Environments

It is recommended that page translations are developed at the same time as the application itself. This is best achieved by having RUEI monitor the application under development, and refining its defined page translations based on the obtained results.

Once ready for deployment, the application is then moved to a production environment. If that new environment is monitored by a different RUEI installation, you do not need to manually re-create the application's page translations. Instead, you can use the download facility to obtain a copy of its latest definitions, and then upload the generated file for use by the new RUEI installation.

To upload a file containing a list of predefined page translations, do the following:

After selecting the required application, click the Pages tab. Click Upload list. The dialog shown in Figure 7-8 appears.

Figure 7-8 Upload Page Transactions

Description of "Figure 7-8 Upload Page Transactions"
Use the Browse button to locate and specify the name of the page translation file. The uploaded file must have the extension .txt. Optionally, use the File encoding menu to specify the file's character encoding. For more information on international character set support, see Working with National Language Support. In case of duplicate page translations, the latest translation is used. The file may only contain one translation per line, with page group and page name tab separated. When ready, click Merge.

To download the currently defined page translations, click Download list. Depending on how your browser is configured, you are either prompted to specify the location to which the file should be saved, or it is immediately saved to the defined default location.

Applying Action Translations

If you are using an action-naming scheme as described in Defining Action-Naming Schemes for example HTTP Method and URL, you can associate that scheme, for example a specified HTTP Method and URL, with an action translation.

Defining Action Translations

To define action translations, do the following:

Select Configuration, then Applications, then Applications, and select the required application. The application overview (similar to the one shown in Figure 7-5) appears.
Click the Pages tab, and then the Action translations tab. The currently defined action translations are displayed. Click Add new translation to define a new translation, or click an existing one to modify it. The dialog shown in Figure 7-7 appears.

Figure 7-9 Add Action Translation Dialog

Description of "Figure 7-9 Add Action Translation Dialog"
Specify the original value and the action you would like to associate with that value. When ready, click Save.

Using Advanced Settings to Control the Handling of Pages and Objects

If you selected the HTML title or any of the client request page-naming schemes (such as URL base), the Advanced tab within the page naming scheme allows you to refine the operation of these schemes. In the case of the HTML title scheme, the dialog shown in Figure 7-10 appears.

Figure 7-10 Edit Application Page-Naming Scheme Dialog

Description of "Figure 7-10 Edit Application Page-Naming Scheme Dialog"

Time Recognition

You can use the Time recognition menu to control whether non-forced objects are used to identify the page. Consider the example shown in Figure 7-11.

Figure 7-11 Time-Based Recognition

Description of "Figure 7-11 Time-Based Recognition"

In this case, there are three non-forced objects (home.jsp, sub.jsp, and down.jsp) that could potentially be used for page identification.

If the enabled option (the default) is specified for the Time recognition menu, only the first object (home.jsp) would be identified as a page, and all hits after it will be considered objects until no more hits are detected within one second after the last object hit. However, if disabled, each of the three non-forced objects (such as jsp) would be identified as separate pages, regardless of detection time. For further information on forced objects, see Controlling the Reporting of Objects as Pages.

Controlling Case Sensitivity

The Lowercasing menu within the Advanced tab allows you to specify whether page names should be converted to lowercase. The available options are shown in Table 7-2.

Table 7-2 Case Controlling Options

Option	Explanation
No	Specifies that the original casing of page names is preserved. This is the default.
Before ruling	Specifies that reported page names for the selected application, suite, or service are converted to lowercase before applying all rules defined under the Ruling tab. The test input and search expressions should be supplied in lower case
After ruling	Specifies that reported page names for the selected application, suite, or service are converted to lowercase after applying all rules defined under the Ruling tab.

Sub-Header Fallback

If you selected the HTML title page-naming scheme, the text found within the page's <title> tag is used to identify the page. Potentially, if not found, you may want the sub-headings <H1>, <H2>, and <H3> to be used. Therefore, you can use the sub-header fallback menu to control this facility. By default, the sub-headers are not used (Disabled).

Redirect handling

If you selected any of the client request-based schemes (such as URL base), and click the Advanced tab, the dialog shown in Figure 7-12 appears.

Figure 7-12 Edit Application Page-Naming Scheme

Description of "Figure 7-12 Edit Application Page-Naming Scheme"

You can use the Page handling menu to specify how redirects within a URL should be handled. The options shown in Table 7-3 are available.

Table 7-3 Page-Handling Options

Setting	Description
Final page	Specifies that only the final page URL should be used to determine the page name. This is the default.
Redirect naming	Specifies that the page should be identified using the information available from the redirect in front of the final page. If not available, the final page's information is used.
Redirect becomes page	Specifies that the redirect will become the actual identified page. Note that the first redirect is used for page creation, and all subsequent redirects become objects on the created page. It is strongly recommended that you only select this option if you clearly understand its consequences for application reporting.

Note:

Be aware that the Full session replay facility (described in Introduction to Session Diagnostics) and error reporting may not function correctly if page names have been derived from redirects.

Using the Ruling Facility

Each application definition requires you to specify the page-naming and user identification schemes to be used. Optionally, you can also specify content messages that should be reported when they appear within specific application pages. Each of these definitions can be extended through the use of the ruling facility. This allows you to specify additional matching rules that should be used to refine the selected page-naming scheme, user identification scheme, or message specification.

When using the ruling facility for page-naming, be aware that only matching URLs are reported upon. When a URL does not match, it is disregarded altogether. The ruling facility is only available for automatic (not manual) page-naming schemes and XPath-based (not literal) content messages.

Recommended Usage

Because of the complex nature of ruling, it is recommended this facility is only used by users with a sound understanding of the selected application's appropriate scheme or message structure. For example, in the case of a URL-based page-naming scheme, the selected application's underlying URL structure should be clearly understood.

Note:

When the "Before ruling" setting is applied in the lowercasing option, the test input and search expressions should be supplied in lower case.

Defining Rules

To specify the use of ruling for an application, do the following:

Select Configuration, and then either Applications . Click the required application to view its overview. Examples are shown in Figure 7-1 and Figure 10-4.
Depending on the required use for the ruling, click the page-naming scheme (within the Pages tab), the appropriate user-identification scheme (within the Users tab), or the appropriate content message specification (within the Content messages tab). A dialog similar to the one shown in Figure 7-13 appears.

Figure 7-13 Edit Application Page-Naming Scheme Dialog

Description of "Figure 7-13 Edit Application Page-Naming Scheme Dialog"
Click the Ruling tab to specify the rules to be used, and the order in which they should be evaluated. The dialog shown in Figure 7-14 appears.

Figure 7-14 Ruling Tab

Description of "Figure 7-14 Ruling Tab"
Use this dialog to define new rules or delete existing ones. You can also use the context menu under each rule to modify the order in which they are applied. Click the Add new matching rule item to define new matching rules. A dialog similar to the one shown in Figure 7-15 appears.

Figure 7-15 Add Matching Rule

Description of "Figure 7-15 Add Matching Rule"
Specify the following components for the rule:
- Input value: specifies the structure of the expected scheme (such as URL or page tagging) or message specification. Essentially, it provides a template for interpreting the received scheme or specification.
- Search expression: specifies a definition of the scheme or specification that should be matched. Typically, this is expressed in terms of required parameters or components, and the sequences that should comprise them.
- Page group: specifies how the page group is identified from the received page-naming scheme. Note if this is not specified, the page group is left empty. This field is only available for page-naming rules.
- User ID/Page Name/Content message: specifies how the page name, user ID, or content message is identified from the received scheme or specification.
- Client browser / Client browser version: specifies how the client browser/browser version is identified from the received user agent string.
- Client device/ Client device brand/ Client device model: specifies how the client device/device brand/device model is identified from the received user agent string.
After specifying the rule's components, you can click the Check rule button to verify that the defined rule is consistent with the specified validation value. Note that the result window can be expanded in order to view a summary of the matched placeholders. An example is shown in Figure 7-16.

Figure 7-16 Example Rule Check Dialog

Description of "Figure 7-16 Example Rule Check Dialog"

When ready, click Save. You are returned to the dialog shown in Figure 7-14.
After defining all required rules, you can click Check rules to verify all defined rules against their validation values. Each validation value should be relevant to its corresponding rule. After verification, the icon shown beside each rule indicates its status. For rules that were not successfully verified, additional information is available via a mouseover or hover box. Consider the example shown in Figure 7-17.

Figure 7-17 Example Ruling Verification

Description of "Figure 7-17 Example Ruling Verification"

The first rule is consistent with its defined validation value, and is successfully verified. However, the second rule is extremely generic, and you are warned that multiple validation rules could match this rule. In fact, it is so generic that no subsequent rule could be applied because its associated validation value has already been successfully applied. That is, the third rule will never be reached. That is why an error is reported on the third rule, and not the second. However, if the second rule was moved down to become the last rule, then the three rules would be successfully verified.

Although it is possible to save ruling definitions with reported errors, it is recommended that you resolve any issues before saving a ruling definition. When ready, click Save. Any changes you make to a ruling definition take effect within five minutes.

Example 7-6 Ruling for URL Matching

Be aware that URL matching is case sensitive, and URLs (after matching) are converted to lower case. Matched slashes are replaced by spaces in the page name after ruling.

In addition, it is recommended that only the "URL" page-naming scheme is used when performing ruling based on URL structures. This is because other URL-based naming schemes perform some form of initial formatting.

Example 7-7 Ruling for User Identification

The use of ruling for user identification is equivalent to that for page naming, except that you specify how the user ID is identified from the selected scheme, and page group identification is not supported. Consider the following case. The specified user-identification scheme is based on cookies, and each cookie has the following structure:

ORA_UCM_INFO=5~DVJ88287~John~Doe~john.doe@myshop.com~USA~en~33~44~5~~1;

You want user identification to be based only on the E-mail address portion of the cookie. In this case, you could specify the following:

Search expression: %\~%\~%\~%\~%\~%

User ID: %5

The validation value could be specified using the example cookie shown above, or some other example cookie with the same structure.

Example 7-8 Ruling for Client Browser

The use of ruling for client browser allows you to separate mobile App based traffic from browser traffic. For example, a mobile application may access your web pages using the user agent 'MyApp/Shopping/v1.3', you can use rules to allow that mobile application to be reported as 'Shopping' and client version as 'Shopping 1.3'.

Input value: MyApp/Shopping/v1.3

Search expression: %/%/v%

Client browser: %2

Client browser version: %2~%3

Example 7-9 Ruling for Client Device

The use of ruling for client device allows you to separate mobile App based on traffic from device traffic. For example, a mobile application may access your web pages using the user agent 'Mozilla/CFNetwork/Darwin/15.0.0', you can use rules to allow that mobile application to be reported as 'mobile' and client device brand as 'CFNetwork ' and client device model as 'Darwin'.

Input value: Mozilla/CFNetwork/Darwin/15.0.0

Search expression:%/CFNetwork/%/%

Client device: mobile

Client device brand: CFNetwork

Client device model:%2

Example 7-10 Identifying Page Groups Within Rules

When using the ruling facility with a page-naming scheme whose source includes a page group, you should ensure that the group value is correctly identified. In the case of a URL page-naming scheme (except for "URL") whose source is myhost.com/myshop/menswear/catalog/basket.jsp, it is internally converted to the structure myshop\%7Cmenswear/catalog. This then needs to be transformed for correct reporting as follows:

Input value: myshop|menswear/catalog

Search expression: %|%/%

Page group: %1

Page name: %2

In the search expression, the pipe character (|) separator between group and page name does not need to be encoded. Note that the slash characters within URL structures can be used in ruling. Matched slashes are replaced by spaces in the reported groups and names after ruling.

Example 7-11 Search Constructions

In addition to the use of parameters, the elements shown in Table 7-4 can also be used in URL matching rules.

Table 7-4 Advanced Search Constructions

Usage	Description
`%`	Match zero or more characters and fill one placeholder. Allowed placeholders are %1 - %9.
`%[!...]`	Find one value corresponding to any of the supplied name(s) in the URL argument, and fill one each for the original and matched placeholders.
`%[&...]`	Find all values corresponding to the supplied name(s) in the URL argument, and fill one parameter placeholder for the original and specified number of placeholders.
`%[\|...]`	Find zero or more values corresponding to the supplied name(s) in the URL argument, and fill one placeholder for the original and specified number of placeholders.
`%[c#]`	Find the specified number of characters.
`%[d]`	Find directory path of the URL, and fill one placeholder.
`%[f]`	Find file name path of the URL without the file extension, and fill one placeholder.
`%[h]`	Find domain part of URL, and fill three placeholders (for example, `a.b.name.co.uk` would be matched as `%1=a.b`, `%2=name`, and `%3=co.uk`).
`%[t...]`	Match until one of the following characters is matched, and fill one placeholder.
`%[t^...]`	Match until a character is found that does not match the specified list of characters.
`%[^name=value]`	Match if the supplied `name` and `value` pair are found in the URL argument. Fills one parameter placeholder.

Note that special characters (%, \, |, !, and ~) must be preceded with a backslash if they should be interpreted literally. For example, \% specifies a literal % character, rather than a parameter. In addition, special characters after the % character (^, &, [, and ]) also need to be escaped. Be aware that a maximum of nine placeholders can be specified.

Example 7-12 Matching Multiple URL Parameters

If you want to match multiple URL parameters, it is strongly recommended that they are defined within one set of square brackets. For example, %[!parm1!parm2]. Note that while it is possible to specify %[!parm1]%[!parm2], be aware that it will only match the specified arguments if they appear in the same order in which they are defined. Consider the string /example/path/file.html. The possible matching schemes are shown in Table 7-5.

Table 7-5 Matching Multiple URL Parameters

Definition	Matched Results
`%[f]%`	`%1` = `/example/path/file` `%2` = `.html`
`%[d]%[f]%`	`%1` = `/example/path/` `%2` = `file` `%3` = `.html`

Example 7-13 Examples

Search value: %[h]/%/%/%/%?%

Page group: %6 (electronics)

Page name: %7 (tv821)

URL (for checking): www.mydomain.co.uk/shop/catalog/electronics/tv821?params=all

Search value: %[h]/%[&shop_cat]

Page group: %2 (pcShop)

page name: %5 (Cables)

URL (for checking): www.pcShop.com/home/applications/catalog?cust_id=123&shop_cat=Cables

Search value: %[h]/cart:%[c9]/articleid:%[c9]/%

Page group: %4 (00000ABCD)

Page name: %5 (000018201)

URL (for checking): www.myshop.com/cart:00000ABCD/articleid:000018201/shop.jsp?params=all

Reporting Unclassified Pages

By default, pages that have been identified as belonging to an application through its URL definition, but for which no classified name has been found, are discarded and not reported. However, if you want these unclassified pages to be reported in Data Browser groups, use the Report unclassified pages check box within the Pages section of the application overview shown in Figure 7-18.

Figure 7-18 Application Page Configuration Section

Description of "Figure 7-18 Application Page Configuration Section"

Because page identification is a time-based activity, it is possible that references to objects not booked as objects are incorrectly identified as unclassified pages. For this reason, it is recommended that you only enable the reporting of unclassified pages for testing purposes. Thereafter, you can disable it again, and define the identified problems pages manually. Note unclassified pages are reported in the appropriate Data Browser group under the category "other".

Reporting Service Test Beacon Traffic

Note that monitored service tests can also be converted into RUEI user flows. This is fully described in Converting Service Test Sessions into User Flows.

You can use the Report service test traffic check box within the Advanced section to specify whether service test traffic configured within Oracle Enterprise Manager for a selected application should be reported within RUEI. By default, reporting is disabled. For further information on the use of this facility, see Reporting Service Test Traffic.

When enabled, the Service tests group provides information about monitored service test beacon traffic. Its structure is described in Table W-1.

Obtaining the Client IP Address

When reporting on user visits, the client IP address is, by default, fetched from the IP packet. However, when the RUEI system is placed in front of a NAT device, it may be more useful for the client IP address to be obtained from a specific HTTP request header. This is fully explained in Monitoring NATed Traffic.

Automatic Page Naming Assignment

As explained earlier, each page within RUEI has the form application » group » name. Automatically detected pages are assigned their group and page names based on the directory structure within the URL. The first directory in the URL is assigned to the group name, and the remaining sub-directories are assigned to the page name. Note that the domain part is not used in the assigned name. Note this only applies to applications defined with the URL base, directory, or full page-naming schemes.

For example, the page URL http://MyShop.nl/catalog/menswear/sale.html for the application "Clothing" would generate the RUEI page name Clothing » catalog » menswear sale. Note that slashes within the directory structure are converted to spaces.

If there are no sub-directories in the URL, then the default group "home" is assigned to the page. For example, the URL http://MyShop.nl/sale.html in the application Clothing is assigned the page name clothing » home » sale.

Refining Your Application Definitions

Once you have defined your application, you can modify its associated page-naming scheme by clicking it and selecting a new scheme, as described earlier in this section.

Within the Identification section, you can click Add new filter to specify additional filters for the pages that should be associated with the application. You can also modify an existing filter definition by clicking it. In each case, you can select from the same filters as shown in Figure 7-2. The application overview is updated to reflect your additions or modifications.

Specifying Page Loading Satisfaction

In order to assess the user's experience when viewing application pages in a session, RUEI assigns a satisfaction level for each page. These are shown in Table 7-6.

Table 7-6 Page Loading Satisfaction Levels

Level	Description
Good	The page loads in the user browser within the satisfied page loading threshold period. By default, this is four seconds.
OK	The page loads in the user browser within the OK threshold period. By default, this is 16 seconds.
Poor	The page takes longer than the poor threshold to load.

An example page load satisfaction report is shown in Figure 7-19.

Figure 7-19 Page-Load Satisifaction Report

Description of "Figure 7-19 Page-Load Satisifaction Report"

As stated above, this assessment is based on thresholds within which pages would normally be expected to load. These thresholds can be modified to fine tune the reported page load satisfaction. Do the following:

Select the required application, click the Pages section, and click the Default setting. The dialog shown in Figure 7-20 appears.

Figure 7-20 Edit Page-Load Satisfaction Thresholds Dialog

Description of "Figure 7-20 Edit Page-Load Satisfaction Thresholds Dialog"
Click the Default item. The dialog shown in Figure 7-21 appears.

Figure 7-21 Edit Default Page-Load Satisfaction Thresholds Dialog

Description of "Figure 7-21 Edit Default Page-Load Satisfaction Thresholds Dialog"
Specify the thresholds (in seconds) that should be used when assessing page-loading satisfaction. These thresholds are explained in Table 7-3. The defaults are 4 and 16 seconds. Note that defined thresholds must be in the range 0.001 - 86400 (that is, a day). When ready, click Save. You are returned to the dialog shown in Figure 7-20.
Optionally, click Add exception to specify a situation in which different (from the default) page-loading thresholds should be used to assess the user's experience. This facility is extremely useful when particular user actions would normally be expected to take significantly longer to perform than other application actions. For example, in the case of downloads or complex database queries. The dialog shown in Figure 7-22 appears.

Figure 7-22 Add Satisfaction Exception Dialog

Description of "Figure 7-22 Add Satisfaction Exception Dialog"
Specify the page-load thresholds that should be used to assess the pages and user actions within the defined exception.
Specify the events that must be met for the exception to be considered reached. Note that all defined events must be met for the exception to be considered fired. For each event, use the Dimension level and Value menus to select the dimension that should be checked, and the value that it must hold. Note that if the required value is not available within the Value menu, you can click the Search icon beside it to locate it.

Optionally, you can use the Exclude check box to specify that the defined dimension level=value pair should be negatively applied. That is, the event should be regarded as achieved if the defined event is not met. When ready, click Add. The new event is added to the exception's definition. Note that a maximum of 10 events can be defined for an exception. When ready, click Save. You are returned to the dialog shown in Figure 7-20.
Be aware that exceptions are resolved from top to bottom. If necessary, you can use the Move up and Move down options within an exception's context menu to change its position. Note that a maximum of 100 exceptions can be defined.

When ready, click Save. Any change you specify takes effect immediately.

Example 7-14 Understanding how Page and Object-Loading Satisfaction are Reported

It is important to understand that while page-loading satisfaction is based on the time required for a page to load in the user's browser, object-loading satisfaction is based on an object's total end-to-end time. Note that object-loading satisfaction uses the default application page-loading thresholds, and ignores any defined exceptions.

As explained in Problem Analysis Groups, any object with an end-to-end time of less than two seconds is not considered a slow URL. If greater than two seconds, its URL-loading satisfaction is based on the default application page-loading thresholds, and ignores any defined exceptions.

Defining Logout Events

It is important to understand that RUEI does not automatically regard a user logging out of an application as the end of a session. Instead, the end of a user session is determined when the session idle timeout (by default, 60 minutes) is reached. This means that if an application does not terminate a user's session when they logout, and the user logs on again to the application, RUEI is unable to detect the application logout, and reports the two application sessions as part of the same user session.

If this does not meet your reporting requirements, you can define the application events that, if reached, will automatically be regarded as the end of the current user session. Typically, these will be logout pages and events. Any subsequent user actions will then be regarded and reported as part of a new user session.

To define application logout events:

Select Configuration, Applications, Applications or Suites, and select the required application. The application overview (similar to the one shown in Figure 7-5) appears.
Click the Pages tab, and then the Logout Events tab. The currently defined logout events are listed. Click Add new event. Alternatively, click an existing definition to edit it. The dialog shown in Figure 7-23 appears.

Figure 7-23 Specify Application Logout Event(s) Dialog

Description of "Figure 7-23 Specify Application Logout Event(s) Dialog"
Specify a dimension level=value pair for each required event condition. Optionally, you can use the Exclude check box to specify that the pair should be negatively applied. That is, the event should be regarded as achieved if the defined condition is not met. When ready, click Add. Note that while only one defined event needs to be achieved in order for the session to be regarded as terminated, all conditions within with an event must be met for it to be considered achieved. When ready, click Save.

Trapping Application Content Messages

Sometimes you want to detect strings that appear within pages, and have them reported as either application notifications (such as "Order processed successfully") or as application errors (such as "Network connection to server failed").

Content Messages vs System Errors and Page Content Checks

These content messages differ from system errors (such as web server or network errors) in that they are based on page content, rather than a return code, and are specific to a selected application.

Note that all pages within the selected application are searched for the specified message string. It is not possible to limit the search to specific pages, as it is with page content checks (described in Specifying Page Content Checks).

Application content and page content messages are page-based. In the case of services, they are call (that is, hit) specific. Therefore, they are only reported in page-based groups, and not diagnostics groups (which are URL-based).

Reporting of Content Messages

Individual content messages can be specified as notifications or errors. In either case, they are reported via the Page delivery dimension.

Displayed page texts that match your specified notification strings are reported with the page content result "notification string: notification search string", while errors are reported as "error string: error search string". An example of a content error report is shown in Figure 7-24.

Figure 7-24 Functional Error Analysis

Description of "Figure 7-24 Functional Error Analysis"

Defining Content Messages

To define a content message string, do the following:

Select Configuration, then Applications, Suites, or Services, and select the required application. The Application overview (similar to the one shown in Figure 7-5) appears.
Click the Content messages tab, and then the Content messages tab. The currently defined content messages are displayed. Click Add new content message to define a new message, or click an existing one to modify it. The dialog shown in Figure 7-25 appears.

Figure 7-25 Add Content Message

Description of "Figure 7-25 Add Content Message"
Use the Search type menu to specify the scope of the search. The search location can be one of request header, reply header, request content, reply content, or URL. The search type is either XPath or literal. For more information about the use of XPath queries, see Working with XPath Queries.

If you specify a request or response header, you can choose to specify the header that should be searched. If you choose to leave this field blank, it will be filled automatically with the full header content.

If you specify a URL, you can choose to specify a URL argument, which will be reported additionally to the URL part.

Note that the use of wildcards is not supported and all specified characters are treated as literals.

When ready, click Save. Any changes you make will take effect within five minutes. Note that after creating an XPath-based or header content message, you can use the ruling facility to refine the message's specification. This is fully described in Using the Ruling Facility.

Importing Lists of Content Messages

Instead of separately defining each message that you want to be monitored, you can import a file containing a list of predefined application messages. Do the following:

After selecting the required application or suite, click the Message specifications tab. Click Upload list. The dialog shown in Figure 7-26 appears.

Figure 7-26 Upload Content Messages Dialog

Description of "Figure 7-26 Upload Content Messages Dialog"
Use the Browse button to locate and select the required file. Optionally, use the File encoding menu to specify the file's character encoding. For more information on international character set support, see Working with National Language Support. If an unsupported encoding is encountered, or the transcoding fails, an error is reported.

The uploaded file must contain one message per line, and there should be no blank lines in the file. Be aware that these messages will be regarded as literal strings to be searched for in the response content. When ready, click Merge.

Defining Translations for Content Messages

Optionally, you can also define a set of translations for each unique message string. For example, you could define the translations for the Oracle database messages shown in Table 7-7.

Table 7-7 Example Message String Translations

String	Translation
`ORA-00056`	An attempt was made to acquire a DDL lock that is already locked.
`ORA-00057`	The number of temporary tables equals or exceeds the number of temporary table locks.
`ORA-00058`	DB_BLOCK_SIZE initialization parameter is wrong for the database being mounted.
`ORA-00059`	The value of the DB_FILES initialization parameter was exceeded.
`ORA-00060`	User flows deadlocked one another while waiting for resources.
`ORA-00061`	The shared instance being started is using DML locks, and the running instances are not, or vice-versa.
`ORA-00062`	The instance was started with DML_LOCKS = 0, and the statement being executed needs a full-table lock (S, X, or SSX).
`ORA-00063`	The number of log files specified exceeded the maximum number of log files supported in this release.

To define a message translation, do the following:

After selecting the appropriate application or suite, click the Content messages tab, and then the Message specifications tab. The currently defined message translations are displayed. Click Add new specification to define a new translation, or click an existing one to modify it. The dialog shown in Figure 7-27 appears.

Figure 7-27 Add Message Specification Dialog

Description of "Figure 7-27 Add Message Specification Dialog"
Specify the required source value and, optionally, a translation. When ready, click Save.
Use the Message type menu to specify whether the message should be reported as an error (default) or a notification. When ready, click Save.

In the example above, this would be reported as:

error code ORA-00056: An attempt was made to acquire a DDL lock that is already locked.

Note that when working with a large number of translations, you can use the Search field to quickly locate a required translation. The search facility uses partial matching. The use of wildcards is not supported, and all characters are treated as literals. When ready, click Go.

Importing Lists of Translations

Instead of separately defining each translation, you can import a file containing a list of translations. Do the following:

Click Upload list. The dialog shown in Figure 7-28 appears.

Figure 7-28 Upload Message Specifications Dialog

Description of "Figure 7-28 Upload Message Specifications Dialog"
Use the Browse button to locate and specify the name of the translation file. Note that in the case of duplicate message definitions, the latest definition is used. Optionally, use the File encoding menu to specify the file's character encoding. For more information on international character set support, see Working with National Language Support. If an unsupported encoding is encountered, or the transcoding fails, an error is reported. The file may only contain one translation per line, with source values and translations tab separated.
Use the Message type menu to specify whether the messages defined in the file should be reported as errors (default) or notifications. When ready, click Merge.

Appending Content Messages to Errors

It can be extremely useful for content messages to be reported alongside non-content related errors (that is, web site, network, or server errors). This enables you to provide additional information about the context of the error in order to facilitate troubleshooting. However, this is not default reporting behavior.

As explained in Page Delivery Dimension, if a page experienced several types of errors (for example, both a server error and a network error), the page error is not reported multiple times. Instead, it is reported based on the following prioritization: web site, server, network, and content.

To specify that non-content related errors should be reported with additional explanations, do the following:

Select Configuration, then Applications, and select the required application. The Application overview (similar to the one shown in Figure 7-5) appears. Click the Content messages tab, and then the Advanced tab. The screen shown in Figure 7-29 appears.

Figure 7-29 Content Message Advanced Tab

Description of "Figure 7-29 Content Message Advanced Tab"
Check the Append content messages check box to specify that if a defined content message is found on the page, this should be appended to the error when reported. By default, content messages are not appended. Note that if multiple content messages are found within the same page, the first message found on the page is used for reporting purposes.

An example of enhanced page delivery details is shown in Figure 7-30.

Figure 7-30 Example Additional Page Delivery Details

Description of "Figure 7-30 Example Additional Page Delivery Details"

Defining User Identification

Within RUEI, newly created applications are automatically configured to have user identification based on the HTTP Authorization field and the Common Name (CN) portion of the SSL client certificate (when available). This is shown in Figure 7-31.

Figure 7-31 Application User Identification Scheme

Description of "Figure 7-31 Application User Identification Scheme"

However, you can also configure the application's user identification scheme in terms of URLs, cookies, request or response headers, XPath expressions, custom tag or responses, or OAM user tracking. Note that the HTTP Authorization field has priority over other configured values, and that the SSL certificate is the fallback scheme. When the configured user ID does not match that found in the monitored traffic, the user ID is reported as "(no value)". For more information on the reporting of items with no value in RUEI, see Summary of Data Items.

Configuring an Application's User Identification Scheme

To configure an application's user identification scheme, do the following:

Select the required application, and click the Users section.
Click Add new source. The dialog shown in Figure 7-32 appears.

Figure 7-32 Add New User ID Source Dialog

Description of "Figure 7-32 Add New User ID Source Dialog"
Use the Source type and Source value fields to specify the user identification mechanism. This can be specified in terms of a literal search string or an XPath expression. Be aware of the following:
- In the case of a literal search string, you can specify whether the request or response header should be searched.
- In the case of an XPath expression, you can specify whether the request or response should be searched. More information about using XPath queries is available in Working with XPath Queries.
- In the case of a cookie, you need to specify the name of the cookie. Note that if hashing is specified for the selected cookie, or as the default cookie masking action, the cookie's uniqueness is preserved, but not its original value. This is fully explained in Masking User Information.
- In the case of a URL argument, the name of the argument must be specified.
- In the case of a custom pattern, you must specify a start string and (optionally) an end string to delimit the searched content. Note that the use of wildcard characters is not supported, and all specified characters are treated as literals. In addition, besides any specified end string, the search will never extend beyond a new line.
- In the case of a custom tag, you must specify the name in the name=value pair from which the user ID will be retrieved.
- As explained earlier, if the HTTP-based authentication is specified, this takes priority over any other defined identification scheme. In addition, if the SSL client certificate is specified, this is the fallback scheme.
Click the Advanced tab. Use the Lowercasing menu to specify whether user names should be converted to lowercase and, if so, before or after applying the matching rules you can define after creation of the user identification definition.

When ready, click Save. Note that once your user identification scheme has been defined, you can use the ruling facility to refine their implementation. This is described in Using the Ruling Facility.

Note:

You can check the effect your user identification definition has by viewing the XLS User Information report in the Clients category. For more information on reports, see Working With Reports.

Example 7-15 National Language Support

See Working with National Language Support for a detailed discussion of the implications for identification when working with international character sets.

Defining Localization Sources

Newly created applications and services by default do not have localization sources configured. However, you can configure the application's localization (territory and language) sources in terms of URLs, cookies, request or response headers, XPath expressions, or custom tag or responses.

Configuring an Application's Localization Sources

To configure an application's localization sources, do the following:

Select the required application, and click the Advanced section.
Click the Localization section.
Select either the Application Territory or the Application Language section.

Figure 7-33 Localization Configuration
Click Add new source.
Use the Source type and Source value fields to specify the localization identification mechanism. Be aware of the following:
- In the case of a literal search string, you can specify whether the request or response header should be searched.
- In the case of an XPath expression, you can specify whether the request or response should be searched. More information about using XPath queries is available in Working with XPath Queries.
- In the case of a cookie, you need to specify the name of the cookie. Note that if hashing is specified for the selected cookie, or as the default cookie masking action, the cookie's uniqueness is preserved, but not its original value. This is fully explained in Masking User Information.
- In the case of a URL argument, the name of the argument must be specified.
- In the case of a custom pattern, you must specify a start string and (optionally) an end string to delimit the searched content. Note that the use of wildcard characters is not supported, and all specified characters are treated as literals.
- Unless you specify an end of line string, the search will not extend beyond a new line.
- In the case of a custom tag, you must specify the name in the name=value pair from which the user ID will be retrieved.
Click the Advanced tab. Use the Lowercasing menu to specify whether values should be converted to lowercase and, if so, before or after applying the matching rules you can define after creation of the localization sources. When ready, click Save. Note that once your localization source has been defined, you can use the ruling facility to refine their implementation. This is described in Using the Ruling Facility.

Viewing the Application Page Structure

The structure of the pages detected for an application are shown in the application overview on the left-hand side of the window. An example is shown in Figure 7-34.

Figure 7-34 Example Application Page Structure

Description of "Figure 7-34 Example Application Page Structure"

Potentially, an application could have a very large number of pages associated with it. Indeed, far too many to be easily readable in the structure shown in Figure 7-34. For this reason, the structure view is restricted to those pages that have some Point of Interest (POI) associated with them. This could include the fact that the page is featured in a report, is defined as a key page, is manually named, or is part of a monitored KPI. The View menu shown in Figure 7-35 allows you to control which type of pages are displayed in the structure overview.

Figure 7-35 View Menu

Description of "Figure 7-35 View Menu"

The options shown in Table 7-8 are available.

Table 7-8 View Menu Options

Options	Description
All	List all application pages.
Report pages	List only pages that have been specified as report filters (see Using Report Filters).
Checked pages	List only pages for which content checks have been defined (see Specifying Page Content Checks).
Manually named pages	List only pages that have been manually defined (see Manually Identifying Pages").
Key pages	List only pages that have defined as key pages (see Tracking Page Usage).

Locating Page Details

By drilling down through the application page categories, you can locate specific pages. However, if you are working with an application with a large number of pages, it may be more convenient for you to use the page search facility. Do the following:

Select the application you want to search. Select the Pages section, and click the Identified pages tab.
Specify the search profile you want to use to locate the required page(s). Note that the search is restricted to the current application, and page names have the structure application » group » name. The search facility will try to match any search pattern you specify either as a full match or as a substring. Hence, the search pattern "home" would match occurrences of this string or any substring in the application, group, or page names. When ready, click Go. An example results listing is shown in Figure 7-36.

Figure 7-36 Page Search and Results

Description of "Figure 7-36 Page Search and Results"
The search results are shown in the lower part of the dialog. Click a matched page to open it. Use the Backward and Forward buttons to scroll between multiple pages of results. In addition, you can use the View menu (described in Viewing the Application Page Structure) to limit the displayed list to a certain criteria, such as pages used in reports.

Note:

The scope of the search includes both pages that have already been detected, and undetected pages that appear in reports and user flows.
If you want to remove all identified pages, select Purge all identified pages at the bottom of the window. This will reset the identified pages counter and the result list will be cleared.

Tracking Page Usage

Information about each page detected for an application is available through the page Analysis window. An example is shown in Figure 7-37.

Figure 7-37 Page Analysis Window

Description of "Figure 7-37 Page Analysis Window"

The following tabs are available within this window:

Identification: specifies the page identification scheme (manual or automatic), and the conditions used to identify it.
Content check: specifies if content search strings have been defined for the page. This is described in Specifying Page Content Checks.
Reporting: lists the reports in which this page appears. Reports are described in Working With Reports.
Monitoring: list the KPIs in which this page appears. See for more information about the procedure for defining KPIs.

Defining Key pages

Use the Key page check box in Figure 7-37 to define a page as a key page.

Key pages are monitored web pages that receive special attention. Typically, these are pages in which you have particular interest. For example, your organization's home page, or a series of pages in a user flow (such as placing an order). For these pages, additional information is recorded. This includes client information (such as the ISP, the country of origin, and so on), and the client browser information (such as operating system, browser version, and so on).

Specifying Page Content Checks

Sometimes you want to monitor a specific page for the occurrence of a specific text string. For example, your web application has an Order page, and at the end of a successful sale, the text string "Thank you for shopping with us" should appear on the page. You can define a page content check that looks for this string on the required page. Note that if the specified text string is not found on the page, the page view is reported as failed.

Reporting Page Content Checks

Note that all specified strings for a page must be found within a page view for it to be reported as successful. Otherwise, it is reported as a failed page view. In addition, be aware that content messages (described in Trapping Application Content Messages) are matched before page content checks. Therefore, a page view could be reported as a notification (that is, successful), even though the page content checks would indicate that it should be reported as a failed page.

Defining Page Content Checks

To define a page content check, do the following:

Select Configuration, then Applications, then Applications, and then select the required application page. The Page analysis window (shown in Figure 7-37) appears.
Click the Content check tab, and click Add check. The dialog shown in Figure 7-38 appears.

Figure 7-38 Add Page Content Check

Description of "Figure 7-38 Add Page Content Check"
Specify whether the search should use a literal search string or an XPath expression, and whether the server response or client request should be searched. In the case of an XPath expression, you can also specify an exact value to search for in either the client and server response content. More information about using XPath queries is available in Working with XPath Queries. When ready, click Save.

Manually Identifying Pages

In addition to identifying pages through applications, you can also define pages manually. Note that manually identified pages take precedence over pages identified automatically through applications. This facility is very useful in the case of sub pages that cannot be identified automatically, and to which you want to assign a different name. Manually identified pages are created by selecting an existing page to be the basis for the new page.

To manually identify pages, you can either define the new page from scratch, or use an existing page (automatically detected or manually defined) as the basis for the new page.

To define a page, do the following:

To define the page from scratch, select the required application, and click the New page button. To use an existing page as a basis for the new page, select the required application page, and click the New page (based on current) button. In either case, the dialog shown in Figure 7-39 appears.

Figure 7-39 Manual Page Naming Wizard

Description of "Figure 7-39 Manual Page Naming Wizard"

Note:

If the required page is not visible in the application overview for you to select, locate it using the Search button (described in Locating Page Details).
Use this dialog to specify the conditions that must be met for the page to receive the assigned name. These conditions can be defined in terms of the page's partial or exact URL, content, domain, or arguments. An XPath expression can also be specified. Click Add condition for each required condition.

Note that when specifying an exact URL (for example, http://www.oracle.com/contact.html) the domain and remaining URL structure are automatically assigned to the page conditions. For example, within the "Find in domain" option (oracle.com) and the "Find exact URL" option (/contact.html).
As you specify additional conditions, these are shown in the dialog. All specified conditions must be met for a match to be made. Note that conditions shown in blue can be removed by clicking them, while conditions shown in black cannot be removed. You must specify at least one condition for page identification. When ready, click Next. The dialog shown in Figure 7-40 appears.

Figure 7-40 Save as Dialog

Description of "Figure 7-40 Save as Dialog"
Use this dialog to specify a group and name for the page. When ready, click Finish.
The new page's details are shown in a window similar to the one shown in Figure 7-34. You can use this window to track the page's detection, and modify its definition.

Controlling Reporting Within the Problem Analysis Group

The URL diagnostics group (described in URL Diagnostics for Problem Analysis) allows you to view the functional URLs reported for hits within applications. These can be customized on application level to meet your specific requirements.

The use of URL diagnostics can provide valuable insight into application issues. For example, if a certain application is experiencing unusually large load times, you can quickly identify the specific problem object or the server responsible. Moreover, when coupled with the Session Diagnostics feature (see Introduction to Session Diagnostics), this functionality provides extremely powerful root-cause analysis of application issues.

To specify the URL diagnostics reporting scheme that should be used for a selected application, do the following:

Select Configuration, then Applications, and select the required application. The Application overview (similar to the one shown in Figure 7-5) appears. Click the Advanced section, and click the URL diagnostics tab. The currently defined URL patterns used to specify the scope of the monitored URLs are displayed. Click Add new URL pattern to define a new pattern matching scheme, or click an existing one to modify it. A dialog similar to the one shown in Figure 7-41 appears.

Figure 7-41 Edit URL Diagnostics Dialog

Description of "Figure 7-41 Edit URL Diagnostics Dialog"
Use the URL match type menu to specify whether the schemes you are about to define should be applied to all application URLs, or only to specific URLs. In the case of the later, you need to specify the URL structures that should be reported for the application within the URL diagnostics group. These should be defined as URL patterns that, when matched to detected URLs, will be reported. While the use of a wildcard characters (*) is supported, all other specified characters are interpreted as literals. Note that if no URL structures are defined, the application's associated hits are not reported within the URL diagnostics group.
You can also specify the parts (or components) of the detected URL structures that should be reported. Alternatively, you can the restrict the reported URL to specific arguments. In either case, click Add URL argument/component. A dialog similar to the one shown in Figure 7-42 appears.
Figure 7-42 Add URL Argument/Component

Description of "Figure 7-42 Add URL Argument/Component "
Use the Scheme type menu to specify if a matched URL should be limited to a specific parameter or component when reported. In the case of a parameter, you must specify the parameter name to be reported. In the case of a component, you must specify the component of the matched URL to be isolated, and use the Part menu to specify the part of it that should be reported. The number of options available is equivalent to the number of wildcards (*) specified in the URL component field.

For example, consider the component definition shown in Figure 7-43.

Figure 7-43 Example URL Diagnostics Component Definition

Description of "Figure 7-43 Example URL Diagnostics Component Definition"

In this case, only the part after */MyShop/catalog/ would be reported. Note that part parameters are matched to the wildcards specified in the Value definition. For example, the specified value */session=*/* contains three wildcards, and so the matched URL is regarded as having three logical parts. Note that a maximum of nine wildcards can be specified within an URL diagnostics definition.

When ready, click Save. You are returned to the dialog shown in Figure 7-41.
Review the parameter and component definitions for the application. When ready, click Save. Any matched URL patterns are reported within the URL diagnostics group after 5 minutes.

Example 7-16 Excluded URL Information

Note that forced objects (described in Controlling the Reporting of Objects as Pages) are automatically stripped from reported URLs. In addition, it is recommended that you configure your application definitions to exclude the reporting of session parameters and static-based objects (such as images). This is in order to prevent diagnostics information becoming too long and its possible truncation.

Controlling JavaScript Replay Execution

Application pages viewed through the Session Diagnostics replay facility can contain inline JavaScript code. Typically, this code is used to perform checks. For example, by connection to a specified server to determine if a session has expired. These checks, as well as other JavaScript functionality, can present problems when viewing their associated pages through the Replay facility.

For this reason, the application configuration facility allows you to specify how execution of inline JavaScript code should be handled within the Replay viewer (described in Introduction to Session Diagnostics). JavaScript execution can be completely disabled, or you can specify that specific functions or files should be replaced during page replay.

Defining Execution Rules

To define the JavaScript execution rules that should be used when replaying an application's pages, do the following:

Select Configuration > Applications, and then select the required application. The Application overview (similar to the one shown in Figure 7-5) appears. Click the Advanced tab, then the Replay tab, and then the JavaScript replay tab. The currently defined execution rules are displayed as shown in Figure 7-44.

Figure 7-44 JavaScript Replay Rules
Use the Disable all JavaScript execution checkbox option to specify whether all JavaScript code within the selected application's pages should be disabled when replayed within the Replay facility. If selected, any existing execution rules are ignored, and it is not possible to define new rules. The Disable all JavaScript execution option is selected by default.
Click Add new rule to define a new execution rule, or click an existing rule to modify it. This facility is only available if the Disable All JavaScript execution checkbox is unchecked. The Add New Rule dialog appears, as shown in Figure 7-45 .

Figure 7-45 Add New Rule Dialog
Use the Rule type menu to specify the type of execution rule you want to define. You can select the following options:
- Replace function: specifies that a named JavaScript function should be removed and, optionally, substituted for a return code at execution. For example, a function that checks whether a cookie is still valid could be replaced during replay with the returned value "OK".
  
  The definition for the specified function must appear in the page's inline code. It is not possible to replace external functions. Note that the JavaScript code is only replaced in the rendered browser page, and not in the replayed page's contents (as reported within the HTTP content facility).
  
  Be aware that if the function definition contains any comment between the function syntax and the function name, replacement will fail. For example, the following construction would fail:
```
function 
/* some comment */
myfunction ( url ) {
.....}
```
  If your application pages include references to external functions, you can replace them by uploading files containing the modified function definitions. This is described below.
- Replace file: specifies that a named file containing JavaScript code should be replaced with an alternative file. For example, a file containing validation routines might be replaced with a simplified version for replay purposes. If this option is selected, the Source name field must specify the name and extension of the file to be replaced. These must be the same as those specified within the associated script element. For example, consider the following file reference:
```
<script type="text/javascript" src="public/scripts/checks.js"></script>
```
  Here, the file name checks.js must be specified.
  
  Use the Replacement file field to specify the substitute file. This must have the file extension .js, and the MIME type "text". The file is uploaded to the /opt/ruei/gui/upload/ directory on the Reporter system.
  
  When ready, click Save. Any changes you make to the defined application replay rules are applied immediately.

Example 7-17 Uploading Replacement Files

The replacement .js file is uploaded to the /opt/ruei/gui/upload directory on the Reporter system. Note that, if necessary, you can modify the contents of the replacement file by selecting the appropriate rule, and either uploading a modified version of the original file, or specifying a completely new file. In either case, the contents of the original file are overwritten with the newly uploaded file. When a rule is deleted, any file uploaded for it is automatically also deleted.

Be aware that, if an application contains multiple rules referring to the same file, only one version of the file is held on the Reporter file system, and this is always the latest version to be uploaded. The file is only removed from the file system when all rules that use it have also be been deleted.

Quite often the same JavaScript files are used across multiple applications. Be aware that each replacement file specified for an application represents a unique file. This is true even if the same file name is specified across multiple applications. For example, imagine that three applications, A, B, and C, all have the replacement file mychecks.js specified for them. In this case, three versions of the mychecks.js file are maintained by RUEI. Any changes made to one particular file only apply to its associated application, and not to any other applications.

Controlling Full Session Replay (FSR) URL Mapping

If there is a load balance server with a hostname www.load-balancer.com, and there are several real servers behind the load balance server with hostnames such as www.real-server-1.com, www.real-server-2.com, etc, in that case, requests first come into load balancers, and then they are distributed across real servers.

Assume that RUEI is deployed between load balance server and real servers, and you are not able to access real servers by its hostname. Also, there are no routes from real servers to public networks. In this scenario, all pages captured will have URLs like www.real-server-*.com/.

If you have deployed RUEI to monitor the traffic between load balancer and web servers, FSR page may not display all the objects from replay storage page. This is because you do not have access to original URL and objects of the page being replayed. To solve this issue, define a Replay URL mapping for a successful page replay to make sure that RUEI displays all the objects correctly in FSR window.

For example:

When you replay http://www.real-server-1.com/1.html page in FSR, there will be no route from public network to www.real-server-1.com. RUEI rewrites the URL of such pages. You can define a Replay URL mapping rule http://www.real-server-*.com into https://www.load-balance.com.

Now, you can see that the page is replayed successfully including all the objects on the page. This is because load-balance.com is visible in public network. This indicates a successful Replay URL mapping.

Such Replay URL mapping rules are based on applications. Each application has separate mapping rules.

To configure the replay URL mapping rules for an application, do the following:

Go to Configuration >Applications, and then select required application.
Click Advanced >Replay > Replay URL mapping tab.

Figure 7-46 Replay URL Mapping tab
To configure a new rule, Click Add new rule.

Figure 7-47 Add New Rule
Enter Source URL pattern and Target URL.
Click Save.

Note:

Source and destination URL must contain URL schemes like http, https, etc.
For the source URL, you can use wildcards in hostname string of the URL. However, you must not use wildcards in the target URL.

Defining Action-Naming Schemes

In the case of applications that make use of Rich frameworks (such as Ajax), you can specify an action-naming scheme. This is particularly useful when you want insight into the interactive user actions performed on specific pages. For example, consider the situation in which users are viewing your online catalog pages, and you want to know when they click the "Add to basket" action.

Information about actions is available through the Actions view for the All pages and Problem Analysis (such as Failed pages) groups. It is also viewable within the Session Diagnostics feature. An example is shown in Figure 7-48.

Figure 7-48 Action Incidence on Page Views

Description of "Figure 7-48 Action Incidence on Page Views"

To define an action-naming scheme, do the following:

Select Configuration, then Applications, then Applications, and then click the appropriate application. The application overview (similar to the one shown in Figure 7-5) appears.
Click the Pages tab, and then the Action-naming scheme setting.
The same action-naming schemes are available as for page naming (except Manual), and are explained in Naming Pages.
Optionally, you can click the Advanced tab to specify whether action names should be converted to lowercase. By default, the original casing is preserved. When ready, click Save.
After selecting the required action-naming scheme, you can use the Ruling facility to refine its operation. This is explained in Using the Ruling Facility.

Using Enriched Data Exchange

The Enriched data exchange facility enables you to combine the data gathered by RUEI with other data sources. See Enriched Data Export Facility for more information on using this feature.

Enriched data exchange can be enabled or disabled for individual applications by:

Select Configuration, then Applications, and select the application you want to modify.
Select the Advanced tab, and then the Enriched data exchange subtab.
Choose whether to enable or disable Enriched data exchange and KPI data exchange.

Checking Audit Data

The Audit data is kept for recording modifications made to every application. The audit data shows the User name, IP address and time of the modification event. An example is shown in Figure 7-49

Figure 7-49 Audit Data Sample

The audit data can be checked by:

Select Configuration, then Applications, and select the application you want to check.
Select the Advanced tab, and then the Audit sub tab.

Verifying Your Application and Session Tracking Definitions

It is strongly recommended that you regularly review the tracking of monitored traffic within your RUEI deployment to ensure that it is being correctly identified. To do so, select Show statistics from the Configuration menu. The dialog shown in Figure 7-50 appears.

Figure 7-50 Configuration Statistics

Description of "Figure 7-50 Configuration Statistics"

If the level of unidentified hits or pages appears to be unexpectedly high, you shown review your page identification definitions. This is described in Naming Pages. If the level of page views without session identification is unexpectedly high, you should review your user identification definitions. This is described in Defining User Identification.

Reporting Service Test Traffic

Oracle Enterprise Manager can be configured to monitor service tests to ensure that the highest levels of availability and performance are maintained for your business-critical services. Oracle Enterprise Manager service tests are executed from beacons, and monitor services from the end-users' perspective, and their correlation to the underlying IT infrastructure. Typically, beacons are set to perform user flows that are representative of normal application usage, and then Oracle Enterprise Manager breaks down the response time of that user flow into its component pieces for analysis. The procedure for defining beacons and service tests is described in the Oracle Enterprise Manager Cloud Control Administrator's Guide.

The Service tests facility within RUEI complements Oracle Enterprise Manager service tests by allowing you to validate the results of this synthetic traffic against comparable real-user traffic. For instance, if a service test reports an issue with a specific aspect of an application, you can use this facility to determine whether this problem is also seen with real-user traffic during the same period. In this way, erroneous incidents can be quickly identified and ignored, while the impact of reported issues on real customers can be readily assessed.

Configuring Service Test Monitoring Within RUEI

Within RUEI, specific applications and suites can be monitored for service test traffic and, when detected, reported via the Service tests group. In addition, diagnostics information about monitored service tests is also available via the Service tests diagnostics feature. To configure an application or suite to detect service test traffic, do the following:

Select Configuration, and then either Applications or Suites. Click the required application or suite to view its overview. An example is shown in Figure 7-1.
Click the Advanced tab, then the Enterprise Manager tab, and use the Report service test traffic check box (shown in Figure 7-51) to specify whether service test traffic configured within Oracle Enterprise Manager for the selected application should be reported within RUEI. By default, it is disabled.

Figure 7-51 Enterprise Manager Tab

Description of "Figure 7-51 Enterprise Manager Tab"