| Oracle® Real User Experience Insight User's Guide Release 6.0.1 for Linux x86-64 Part Number E16359-02 |
|
|
View PDF |
| Oracle® Real User Experience Insight User's Guide Release 6.0.1 for Linux x86-64 Part Number E16359-02 |
|
|
View PDF |
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.
The currently defined cookie settings are displayed. 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.
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.
The privacy policies configured on the Web server disable the use of cookies.
If no suitable cookie is available for session tracking, it is recommended that you implement a client-side cookie mechanism using JavaScript.
Configuring a Client-Side Cookie Mechanism
Do the following:
Add the following code to the appropriate login page:
<SCRIPT
LANGUAGE="JavaScript">if(document.cookie.indexOf('track=')==-1){document.cookie
='track='+parseInt(Math.random()*2147418112)+new
Date().getTime()+';path=/;domain='+document.location.host.substring(
document.location.host.lastIndexOf('.',
document.location.host.lastIndexOf('.') - 1)) ;}</SCRIPT>
Select Configuration, then Applications, and then Session tracking. Click Add new cookie. The dialog shown in Figure 7-3 appears.
Select the cookie technology (custom) from the Cookie type menu, and specify the appropriate cookie name. In the above JavaScript code, this is track. Note that the name should match that specified in the login page JavaScript code, and should only contain alphanumeric characters. In addition, it is recommended that the cookie name is restricted to no more than 10 characters in order to minimize header sizes. When ready, click Save.
Verifying the Cookie Configuration
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 pageviews.
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 pageviews 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.
Figure 7-4 Set Session Tracking Fallback Dialog
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.
Which Fallback Session Tracking Mechanism Should be Selected?
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 B, "Cookie Structures".
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 Applications, 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.
Uploading a List of Named Servers
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 Applications, 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.
Uploading a List of Named Clients
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 Pageviews 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, robots.txt, or 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.
Figure 7-9 Page URL Argument Filtering Dialog
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, 15 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 15 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.Specifying Session Settings
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.
Figure 7-10 Change Session Reporting Dialog
Specify, in minutes, the period of visitor inactivity after which the session should be regarded as terminated. The default is 15 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.
Understanding Web services
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.
Defining Web services
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 if a wildcard character (*) is not specified within the Domain field, network traffic arriving on a non-standard port (that is, 80/443), is not associated with the service unless the port number is explicitly stated. In addition, 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 name 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.
Figure 7-12 Function Naming Scheme Dialog
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.
Refining Your Service Definitions
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.
For reporting purposes, if the user/client ID is not found, client identification falls back to the SSL certificate (if there is one). The common name (CN) portion of it is used. If this is not found, the client ID is reported as Anonymous.
Specifying the IP Address Source
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 (shown in Figure 7-13) allows you to specify the required scheme. This is explained in Appendix B.
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 shown in Figure 7-13.
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.7, "Specifying Page Loading Satisfaction".
Sometimes you want to detect strings associated with functions and have them reported as errors. For example, if a function responds with the message "Requested item is out of stock". Note the following:
All functions within the selected service are searched for the specified error string. It is not possible to limit the search to specific functions.
Functional errors can be specified in terms of a literal search string or an XPath expression, and whether the server response or client request should be searched. More information about using XPath queries is available in Appendix B, "Cookie Structures".
Displayed page texts that match your specified error text strings are reported with the page content result "error string: error search string".
To define a functional error in a service function that you want monitored, do the following:
Select Configuration, then Services, and then select the required service. The service overview (similar to the one shown in Figure 7-13) appears. Click the Functional Errors tab. The currently defined functional errors are displayed. Click « Add new functional error » to define a new error, or click an existing one to modify it. A dialog similar to the one shown in Figure 7-14 appears.
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. More information about using XPath queries is available in Appendix B, "Cookie Structures". When ready, click Save.
Alternatively, you can click Upload list to upload a file of functional errors you want detected. This is the same procedure as for uploading a list of application errors described in Section 6.2.8, "Trapping Application Functional Errors". The file must contain only one error string per line. Be aware that these messages will be regarded as literal strings to be searched for in the response content.
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. Do the following:
Select Configuration, then Services, and then select the required service. The service overview (similar to the one shown in Figure 7-13) appears. Click the Client ID tab. The currently defined client ID sources are displayed. Click « Add new source » to define a new source, or click an existing one to modify it. The dialog shown in Figure 7-15 appears:
Specify whether the search should use a literal search string or an XPath expression, and whether the page URL, cookie, server response, or client request should be searched. More information about using XPath queries is available in Appendix B, "Cookie Structures". When ready, click Save.
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-16 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") and Session Diagnostics facility support clickout from selected functional URLs to external diagnostics utilities (such as CAMM and AD4J).
To configure access from within RUEI to these utilities, do the following:
Click the Configuration tab, then click General, then Advanced settings, and then the 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 Example 7-0 appears.
Select the external utility whose interface you want to configure. Currently, CAMM and AD4J are supported. The use of these utilities is described in Section 3.2.4, "The URL Diagnostics Group".
Specify the full URL to be used when a clickout to the selected external utility is requested.
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 that hits with no associated file extensions should have clickout availability.
Click the Advanced tab, and use the Regular expression and Replace fields to specify the parts of the URL passed to the external application that should be replaced. This is useful if the external application requires the URL in a somewhat different format. For example, that the query part of the URL should be stripped off.
When ready, click Save. Any changes made to these settings are applied immediately.
Footnote Legend
Footnote 1: The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web.
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
