|Oracle® Real User Experience Insight User's Guide
Release 6.5.1 for Linux x86-64
Part Number E18053-01
This chapter describes how to manage the basic Web site configuration used within the monitored environment. This includes specifying the cookie technology, the scheme for identifying users, and the Web services. In addition, a number of advanced facilities are also described. These include modifying the rule ordering used to monitor network traffic, and facilities to fine tune the reporting of data.
In order to accurately monitor your Web environment, RUEI needs to know and understand the cookie technology your Web site is using. This will either be a standard technology (such as ASP or ColdFusion), or a custom implementation. In the case of the latter, you will need to provide the system with information about it. Note that you can define a maximum of five cookie technologies for use when monitoring.
To specify your cookie technology, do the following:
Select Configuration, then Applications, and then Session tracking. Note that this option is only available to Administrators. The currently defined cookie settings are displayed. An example is shown in Figure 7-1.
Click « Add new cookie » or an existing cookie definition. A dialog similar to the one shown in Figure 7-2 appears.
Select the cookie technology used in your Web environment from the Cookie type menu. If you are using a non-standard technology, select "(custom)".
If you selected "(custom)", you are required to specify the name of the cookie used by your organization. Note that you can specify wildcard characters (*) as part of the cookie name.
Note:Cookie names are case sensitive.
If you select "(URL argument)", you are required to specify the name of the URL argument used by your organization. The use of URL arguments in session tracking is fully explained in Appendix B, "Cookie Structures". When ready, click Save.
Any changes made to this setting are applied after a short interval (typically, 5 - 10 minutes), and are then visible within the Reporter system shortly after this.
As mentioned earlier, session tracking is based on cookies. However, in certain circumstances, a cookie may not be suitable or available. For example, consider the following situations:
The cookie changes with every hit (for instance, this is the case with ObSSOCookie).
The path set within the cookie only covers part of the application.
Do the following:
Add the following code to the appropriate login page:
Select Configuration, then Applications, and then Session tracking. Click Add new cookie. The dialog shown in Figure 7-3 appears.
To verify that your cookie configuration is being tracked correctly, do the following:
Clear all cookies in the browser.
(Re)login to the monitored application.
Perform a number of page views.
Logout out of the monitored application.
Wait for at least 10 minutes.
Open the RUEI Reporter environment, and select Browse data, open the All sessions group, select Session diagnostics, and locate the recorded session (by user ID or time). You can filter on applications.
Open the session and verify that there where more page views than just the login page. This verifies that the session ID is preserved after the login.
If you do not specify a cookie technology, then (by default) a combination of the client network and client browser is used to track sessions. However, in the event that this is not suitable for your environment, the client IP address can be used as an alternative tracking mechanism.
To specify the fallback session tracking mechanism, do the following:
Select Configuration, then Applications, and then Session tracking. The currently defined cookie settings are displayed. Click the currently defined session tracking fallback mechanism. The dialog shown in Figure 7-4 appears.
Use the Tracking mechanism menu to specify if a client network and browser combination should be used (the default), or the client IP address.
When ready, click Save. Any change you make takes effect immediately.
When considering which fallback mechanism to use, a general rule is that external-facing applications should use the default network/browser combination, while internal-facing applications should use client IP address. In the case of multiple users behind the same proxy server, the use of the default fallback mechanism is recommended. However, be aware this will result in all such users being recorded in one single session. The use of the client IP address mechanism is generally recommended in the following circumstances:
All users have a unique IP address. Note that for each application, you can specify if the client IP address should be retrieved from the TCP packet or a specific HTTP request header. This is described in Appendix O, "Monitoring NATed Traffic".
The organization enforces the use of a normalized browser. That is, a standard browser (such as Internet Explorer or Mozilla Firefox), with a standard version and plug-ins.
Some (or all) of the monitored applications are partially implemented in Java. Oracle E-Business Suite (EBS) is an example of such an application architecture. For these applications, the use of the client IP address mechanism prevents both Java and client requests appearing in the same reported session.
Important:The accurate specification of the cookie technologies used within your Web site is strongly recommended to ensure the accurate reporting of your network traffic.
In addition, you should that the cookie specified to track visitor sessions is not blinded. If it is, session creation based on the cookie will fail.
Optionally, you can use the Named servers facility to obtain more detailed insight into the visitors to your monitored Web sites. This facility allows you to assign ranges of server IP addresses (specified in the netmask) to a Web server group, and to individual Web servers. For example, a server group could be a department or data center, and the server name refers to specific Web servers within that group. In this way, you can easily identify the location of specific Web servers when problems (such as failed pages) occurred.
To use this facility, do the following:
Select Configuration, then General, and then Named servers. This option is only available to users with IT Analytical level access. The currently defined named servers are displayed. Click « Add new server ». The dialog shown in Figure 7-5 appears:
Use the fields within the dialog to specify a range of IP addresses or a specific IP address within a netmask, and the associated Web server and its group. When ready, click Save.
Optionally, you can click « Upload list » to merge a list of named servers with those that are currently defined. The file must contain only one entry per line, and the information for each server (as shown in Figure 7-5) must be tab-separated. Note that any definition in the merged file for an already defined named server overwrites its existing definition.
Any changes made to the named server groups are applied after a short interval (typically, 5-10 minutes), and are then visible within the Reporter system shortly after this.
The Web server information collected during monitoring can be viewed in the Data Browser via the All pages, Key pages, All functions, Failed functions groups, Failed URLs, Failed pages, and Slow URLs groups. The server IP identifies the specified IP addresses, and the server group refers to the group name. By zooming into a server group, you can view the individual Web server names that comprise the group. Zoom in again, and you can view the individual IP addresses assigned to that Web server.
In some instances, you want to be able to enhance the information associated with visitor IP addresses. This is especially useful when monitoring Intranet traffic and you want to be able to use your own client classification.
To use this facility, do the following:
Select Configuration, then General, and then Named clients. The currently defined named servers are listed. Click « Add new client ». This option is only available to IT users with Analytical level access. The dialog shown in Figure 7-6 appears.
Use the fields within the dialog to specify a range of IP addresses or a specific IP address within a netmask, the client, and their associated group (for example, company department). When ready, click Save.
Optionally, you can click « Upload list » to merge a list of named clients with those that are currently defined. The file must contain only one entry per line, and the information for each client (shown in Figure 7-6) must be tab-separated. Note that any definition in the merged file for an already defined named client overwrites its existing definition.
Any changes made to your defined named client groups are applied after a short interval (typically, 5-10 minutes), and are then visible within the Reporter system shortly after this.
The settings you specify for monitored traffic may need to be fine-tuned in order for you to receive what you regard as the most reliable data. In order to do this, it is recommended that you periodically review the relevant report for these settings. In addition, you can view configuration details by selecting Show statistics from the Configuration menu. An example is shown in Figure 7-7.
The following information is reported:
The Hits section indicates the objects associated with a defined application (Defined page), those not part of a defined application (Undefined page), and those not part of a page (Spurious).
The Pages section indicates the detected pages associated with a defined application (Defined), and those not associated with a defined application (Undefined). Note that undefined pages are not recorded, and further information is not available about them.
The Page views section indicates the pages viewed within cookie-tracked sessions (With session), and those for which no cookie information was available (Without session).
In addition, there are a number of advanced settings that are available to refine the accuracy of the report data. These are described in the following sections.
Hit failures are recorded in the failed URL group. Because hit failures can occur for a wide variety of reasons, you can control what is recorded. For example, it is unlikely that you want incidents related to remote robot searches to be recorded. Do the following:
Select Configuration, then General, then Advanced settings, then Ignore failed URLs. Note that this option is only available to Administrators. The dialog shown in Figure 7-8 appears.
Specify any file names that should be ignored within the failed URL view. That is, they should not be seen as errors. For example,
favicon.ico. Note the specified objects are removed from the listed object URLs. When ready, Click Next.
The new setting is applied after 10 minutes. A short period after this time, the changes you have specified are visible in the Reporter interface.
You can control whether you want all, some, or no URL arguments recorded within the lowest level page URL dimension. Do the following:
Select Configuration, then General, then Advanced settings, and then Page URL argument filtering. Note that this option is only available to Administrators. The dialog shown in Figure 7-9 appears.
Use the menu to select the appropriate filter. The default is "allow-all". That is, record all arguments. When ready, click Next.
If you selected the "allow-some" filter, the next dialog requires you specify which arguments should be recorded. Separate multiple arguments with an ampersand (&) symbol. When ready, click Next.
The new setting is applied after 10 minutes. Shortly after this time, the changes you have specified are visible in the Reporter interface.
Note:It is recommended that you make use of this facility if session or other random arguments are included in your page URLs. Otherwise, the content of page-based views (such as all pages or failed URLs) can become very large.
Within RUEI, session information is reported within the All sessions group. Here, information about a visitor session is available appropriately five minutes after the start of a session. By default, a visitor session is considered terminated if the visitor has been inactive for longer than the defined session idle time (by default, 60 minutes).
In order to optimize the reporting of sessions, the Session idle time advanced setting is available to specify the period (in minutes) of inactivity after which a visitor session is regarded as terminated. The default is 60 minutes.
Important:Because of the impact this setting can have on the performance of your installation, as well as the accuracy of the reported data, it is strongly recommended that you only change it under guidance from Customer Support.
In order to specify the idle time that should used when reporting sessions, do the following:
Select Configuration, then General, then Advanced settings, then Session processing, and then Session idle time. The dialog shown in Figure 7-10 appears.
Specify, in minutes, the period of visitor inactivity after which the session should be regarded as terminated. The default is 60 minutes. When ready, click Save.
Any change you make to this setting takes effect within five minutes.
The emergence of Web services has become one of the most important advances in the technology industry. Organizations are increasingly integrating enterprise applications to exchange information such as purchase orders, inventory levels, shipment notices, and interbank transactions, to name but a few.
It is important to distinguish this new breed of Web services from traditional ones. Generally, a Web service was any service available over the Web (such as search engines, language translators, weather guides, maps, and so on). However, these types of Web services required some human intervention.
A Web service is defined by the W3CFoot 1 as "a software system designed to support interoperable machine-to-machine interaction over a network". It implements a clearly defined business function that operates independently of the state of any other service. It has a well-defined contract with the consumer of the service. Services are loosely coupled - a service does not need to know the technical details of another service in order to work with it - and all interaction takes place through the interfaces. Using this technology, the service provider simply exposes a service on the Web, publishes the interface and service naming specifications, and waits for a connection.
Services are made available through service descriptions. They describe how to call the service, and what information is required to request the service and get a response. The data exchange takes a request-response pattern. RUEI primarily supports the monitoring of XML-SOAP and similar messages.
To define a Web service, do the following:
Select Configuration, and then Services. The currently defined Web services are listed. Click New services. The dialog shown in Figure 7-11 appears.
Specify a name for the service. This is the name that will be used for the defined service within reports and the Data Browser. The name must be unique across services, SSO profiles, suites, and applications. Note that services cannot be renamed later.
Use the remaining fields to specify the scope of the service. This is defined in terms of partial service URLs. Note that 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. You can specify a partial URL instead of, or to refine, a domain. It is not possible to specify a service name and leave all the other fields blank. Note that a wildcard character (*) cannot specified within the Find Port field, and network traffic arriving on a non-standard port (that is, other than ports 80/443), is not associated with the service unless the port number is explicitly stated. You can only specify one port number within the Find Port field. If you want to specify additional ports, these should be specified as additional filters after the new service has been created.
Be aware that while the use of a wildcard character is supported, all other specified characters are interpreted as literals. Note it is not possible to specify the wildcard character and no other information for domain and URL argument combinations.
Note:It is recommended that filter definitions should be mutually exclusive across services, SSO profiles, applications, and suites. For example, do not define a service filtered on the domain "us.oracle.com" and then another service, suite, or application filtered on "us.oracle.com/application_servlet". The use of non-mutually exclusive filter definitions can lead to unpredictable results. See Section 7.6, "Controlling Rule Ordering Within RUEI" for information about how you can influence the order in which filters are applied.
You can also specify an argument within the partial URL that must be matched. Note that if you use this facility, both the argument and argument name must be complete in order for them to be matched to page URLs. That is, partial matching is not supported. When ready, click Next. The dialog shown in Figure 7-12 appears.
Use this dialog to specify how the service should be identified and reported. It is important to understand that while applications (see Section 6.2, "Defining Applications") have the structure application » group » page, services have the structure service name » function group » function name. Note that functions that do not belong to a defined group are regarded as belonging to the default group "generic". If you specify a group naming scheme, this must be found within the function call for it to be reported.
When ready, click Finish. An overview of the service definition you have specified is displayed. An example is shown in Figure 7-13.
Once you have defined your service, you can modify its associated function scheme. Within the Identification section, you can click « Add new filter » to specify additional filters for the functions that should be associated with the service. A function will be assigned to a service when one of the defined filters is matched. 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-11. The service overview is updated to reflect your additions or modifications.
The procedure for defining the client ID identification scheme is identical to that for applications and suites, and is described in Section 6.2.10, "Defining User Identification".
When reporting on user visits, the client IP address is, by default, fetched from the TCP 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 header. The Client IP source check box within the Advanced section (shown in Figure 7-13) allows you to specify the required scheme. This is explained in Appendix O, "Monitoring NATed Traffic".
By default, function calls that have been identified as belonging to a service through its URL definition, but for which no classified name has been found, are discarded and not reported. However, if you want these unclassified calls to be reported, use the Report unclassified calls check box within the Functions section.
Because hits not identified as belonging to the service are identified as unclassified calls, incorrect or insufficiently defined function calls will be identified as unclassified. Note that unclassified calls are reported in the relevant Data Browser group under the category "Other".
In order to assess a function's responsiveness, RUEI assigns a satisfaction level for each function. This specifies the end-to-end time (that is, the sum of all server and network times) for the selected function calls in the service. This represents the end-to-end time (in seconds) required to call the function. That is, the total server and network times. The default is four seconds, and can be specified to within three decimal places (for example, 2.567). This is equivalent to the page loading threshold described in Section 6.2.8, "Specifying Page Loading Satisfaction".
The procedure for detecting strings associated with functions is equivalent to that for applications, and is described Section 6.2.9, "Trapping Application Functional Errors".
In order to track the clients using functions, the client identification mechanism used within a service needs to be defined. It can be specified in terms of URLs, XPath expressions, cookies, and whether the server response or client request should be searched. The procedure to do so is equivalent to that for applications, and is described in Section 6.2.10, "Defining User Identification".
By default, the order in which application, SSO profile, suite, and service filters are matched within RUEI is determined by the level of detail specified in the definition. That is, the definitions with the most information specified for them are applied first. However, sometimes you may want to modify the order in which filters are applied.
For example, you want to monitor network traffic for the domain "shop.oracle.com". You have defined two applications: one for the domain "shop*", and one for the domain "*oracle*. Because the string "*oracle*" is longer than the string "shop*", it is applied first. However, you want page identification for the "shop*" domain to take priority. You can use the rule ordering facility to override the default rule matching order, and specify the order in which pages for the required domains should be applied.
Note:It is recommended you use the default rule ordering, and that you define your applications, SSO profiles, suites, and services with sufficient information for them to be mutually exclusive.
To use the rule ordering facility, do the following:
Click the Configuration tab, select the Configuration menu option, and then the option Edit ruling orders. Note this option is only available to users with Full IT access permissions. A dialog similar to the one shown in Figure 7-14 appears.
Use the Automatic rule ordering check box to specify whether the rule ordering is automatically derived from the currently defined applications, SSO profiles, suites, and services. As explained earlier, by default, the definitions with the most information specified for them are applied first. This is check box is automatically unchecked if you use the Up and Down controls to specify the order in which the rules should be applied. If you re-check it, the filter ordering is automatically reset to the default.
Note any changes you make are immediately put into effect. When ready, click Close.
Important:Be aware that if you modify the default rule ordering, and then define a new application, SSO profile, suite, or service, its associated filter is immediately placed at the bottom of the current rule ordering. Therefore, you should always review the rule ordering after the creation of new filters.
The URL diagnostics group (described in Section 3.2.4, "The URL Diagnostics Group"), the suite diagnostics groups (described in Section 3.2.5, "Suite Groups"), and Session diagnostics facility (described in Section 3.10, "Working With the Diagnostics Facility") support clickout from selected functional URLs and certain dimensions to external diagnostics utilities. The currently supported external utilities are shown in Table 7-1.
Oracle Application Diagnostics for Java (AD4J) is part of the Oracle diagnostics pack for Oracle middleware, and provides low-overhead monitoring and diagnostics functionality to improve Java application availability and performance.
The use of this facility requires AD4J 10g R4 to be installed within your organization.
Oracle Composite Application Monitor and Modeler (CAMM) is a utility that allows you to monitor highly distributed Java EE and SOA applications running within your organization.
The use of this facility requires CAMM 10g R4 to be installed within your organization.
Refers users to the server or user reports facility on your EBS deployment.
Depending on your installed Oracle Enterprise Manager middleware and application management packs, the following facilities are available:
My Oracle Support
Searches the Oracle Customer Services' Web site (My Oracle Support) for relevant information about specific reported errors. For example, ORA-12154 or SBL-UIF-00271.
Use of this facility requires a working My Oracle Support registration. Further information is available at
Refers users to the server overview or user search facility on your Siebel deployment.
Depending on your configuration settings you have specified, clickout functionality is potentially available to users in the following situations:
Functional URLs within the URL diagnostics group.
Functional URLs within suite diagnostics groups.
Content error dimensions. Note that clickout is only available for standard errors (such as ORA-06512), and not user-defined content errors (such as "Out of stock").
Application names, page URLs, Siebel suite names, and user IDs within the Siebel group. User IDs are directed to the user search facility, while all other items are directed to the server overview facility.
Applications names, page URLs, EBS suite names, and user IDs within the EBS group. User IDs are directed to the user reports facility, while all other items are directed to the server reports facility.
The above functionality is also available within the Session diagnostics facility (Section 3.10, "Working With the Diagnostics Facility").
To configure access from within RUEI to these utilities, do the following:
Click the Configuration tab, then General, then Advanced settings, and then Clickout settings. Note that this option is only available to Administrators. Click Add new item or an existing external utility definition. A dialog similar to the one shown in Figure 7-15 appears.
Use the Clickout tool menu to select the external utility whose interface you want to configure. The supported utilities are shown in Table 7-1. Note that the other fields available within the dialog depend on the selected utility.
Use the Host field to specify how the selected external utility should be reached. This should not include the protocol scheme (such as
http://). For example,
Use the Port field to specify the required port number. Only one port number can be specified. A wildcard character (*) cannot be specified.
Use the Extensions entry field to specify the object file extensions for which clickout should be available. Use the Add button to specify additional extensions. You can also use the Also allow no extension check box to specify whether hits with no associated file extensions should have clickout availability.
Click the Advanced tab, and use the Protocol field to specify whether HTTP or HTTPS is used for connection to the selected utility. By default, HTTP is used.
Use the Regular expression and Replace fields to specify the parts of the URL passed to the external application that should be replaced. Further information on the use of regular expressions is available from Knowledge Vase articles within the My Oracle Support Web site (
When ready, click Save. Any changes made to these settings are applied immediately.
For each required application, specify the functional URLs that support clickout. This is described in Section 6.2.16, "Controlling Reporting Within the URL Diagnostics Group".
For Oracle E-Business Suite (EBS) and Siebel suites, the Enterprise name must be specified as part of a suite's configuration in order for clickout functionality to be available within dimensions. This is described in Section 6.5, "Working With Suites".
Clickout functionality for Data Browser items is available via the item's context menu. The exact options available to you depend on the Data Browser group, the selected dimension, and the defined clickout settings. An example is shown in Figure 7-16.
Footnote LegendFootnote 1: The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web.