| 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 identify the Web pages to be monitored. In particular, how to define the Web pages for which you want additional information to be available, the logical sequence of pages in transactions to be monitored, and those pages that should be monitored for the occurrence of specific text strings. In addition, the definition of Single Sign On (SSO) profiles and suites are also described. This can only be performed by users with Analytical level access.
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. Note that 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. Note that 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 6-1.
To define applications, do the following:
Select Configuration, then Applications, then Applications, and click New application. The dialog shown in Figure 6-2 appears.
Specify a name for the application. This must be unique across suites, services, SSO profiles, and applications. Note that applications cannot be renamed later.
Use the remaining fields to specify the scope of the application. This is defined in terms of page 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. It is not possible to specify an application name and leave all the other fields blank. That is, a blank filter. Note that if a wildcard character (*) is not specified within the Domain field, network traffic arriving on a non-standard port (that is, other than ports 80/443), is not associated with the application unless the port number is explicitly stated. In addition, be aware that while the use of a wildcard character is supported within 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 name 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
us.oracle.com and then a second application filtered on us.oracle.com/application_servlet, 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 matching rules are applied.You can also specify a URL GET or POST argument that must be matched. Note that 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 found page URLs. This is, partial matching is not supported. When ready, click Next. The dialog shown in Figure 6-3 appears.
Figure 6-3 Application Page-Naming Scheme
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 Section 6.2.1, "Controlling the Handling of Pages and Objects" for information about the use of this option. The structure and processing of the generic page tagging schemes supported by RUEI are described in Appendix A, "Tagging Conventions."
Page URL: specifies that pages are identified on the basis of their URL structure. The following options specify which portion of the URL is used:
URL advanced: page naming is based on advanced URL matching rules. The use of this facility is described in Section 6.2.2, "Using Advanced URL Matching Rules".
URL-directory: uses only the directory part of the URL. The various parts of the URL are highlighted in Figure 6-4.
Base-URL: uses the main directory and file name (without the file extension) parts of the URL.
Full-URL: 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 6-4 will result in the page name myshop » shop » NL index buy.
If you are using any of the above options (other than URL advanced), see Section 6.2.1, "Controlling the Handling of Pages and Objects" for important information.
Be aware that URL argument names are processed in their raw (original) format, while argument values are transcoded. For further information on encoding support and handling, see Appendix B, "Cookie Structures".
Server 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 Appendix B, "Cookie Structures".
Manual: specifies that the application pages will be manually defined rather than through automatic detection. Note that if you select this option, all pages associated with the application that you want monitored must be manually defined. See Section 6.2.14, "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 6-5.
This overview provides a summary of the defined application. This includes the application's name, the page-naming scheme it uses, the report unclassified pages setting, the page-loading satisfaction assigned to each of the application's associated pages, the source from which the client IP address is fetched, the number of unique pages that have so far been matched to it, and the date of the most recent page identified for it. The Identification section summarizes the match criteria currently defined for the application. This is described in more detail in the following section.
When using the HTML title option, 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 Include sub-headers check box within the Advanced tab to control this facility. By default, the sub-headers are not used.
This check box is also available when using any of the Page URL options (other than URL advanced). In addition, you can use the Disable time recognition check box to control whether non-forced objects are used to identify the page. Consider the example shown in Figure 6-6.
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 Disable time recognition check box is unchecked (the default), only the first (home.jsp) object would be identified as a page if detected within one second of the last hit. However, if checked, each of the three objects would be identified as separate pages, regardless of detection time considerations. For further information on forced objects, see Section D.1.2, "Forced Objects".
Each application definition requires you to specify the automatic page-naming scheme used for pages within the application. The URL advanced option specifies that pages are identified on the basis of their URL structure using advanced matching rules.
Note:
Because of the complex nature of URL matching rules, it is recommended this facility is only used by users with a sound understanding of URL structures. In addition, the selected application's underlying URL structure should be clearly understood.To specify the use of advanced URL matching rules for a selected application, do the following:
After you have initially defined your application (as described earlier), click the page-naming scheme setting shown in Figure 6-5. The dialog shown in Figure 6-7 appears.
Figure 6-7 Edit Application Page-Naming Scheme
Use this dialog to either change the specified page-naming scheme, or click the Advanced tab to specify the URL matching rules, and the order in which they should be evaluated. The dialog shown in Figure 6-8 appears.
Click the Add new URL matching rule item to define new matching rules. The dialog shown in Figure 6-9 appears. Use this dialog to define new rules or delete existing ones. You can also right click a rule and use the menu to modify the order in which they are applied, as well as edit and delete them. When ready, click Save.
Each URL matching rule is expressed in terms of the following components:
Search value: specifies the structure of the expected URL. Essentially, it provides a template for interpreting the received URL.
Page group: specifies how the page group is identified from the received URL. Note if this is not specified, the page group is assigned the page name.
Page name: specifies how the page name is identified from the received URL.
URL (for checking): specifies a definition of the URL that should be matched. Typically, this is expressed in terms of required parameters, and the sequences that should comprise them.
If you do not specify anything in the advanced rules, the page is discarded and not reported. The rules are matched in the order specified for them.
Search Constructions
In addition to the use of parameters, the elements shown in Table 6-1 can also be used in URL matching rules.
Table 6-1 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. |
Note the special characters specified in Table 6-1 must be preceded with a backslash if they should be interpreted literally. For example, \% specifies a literal % character, rather than a parameter. Also, be aware that a maximum of nine placeholders can be specified.
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
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 shown in Figure 6-5.
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".
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 request header. This is explained in Appendix B, "Cookie Structures".
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.
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 6-2. The application overview is updated to reflect your additions or modifications.
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:
Satisfied: the page loads in the user browser within a specified threshold. This threshold is the page loading satisfaction threshold. For example, the page should load within five seconds.
Tolerable: the page takes longer to load than the specified threshold.
Frustrated: the page takes more than four times the specified threshold to load.
An example page load satisfaction report is shown in Figure 6-10:
Figure 6-10 Page Loading Satisfaction Report
As stated above, this assessment is based on a threshold within which pages would normally be expected to load. This threshold can be modified to fine tune the reported page load satisfaction within the Data Browser. Do the following:
Select the required application, and click the setting defined for the Page-loading satisfaction item. The dialog shown in Figure 6-11 appears.
Figure 6-11 Page Load Satisfaction Time Dialog
Specify the duration (in seconds) within which page loads would normally be expected to be completed. The default is 4 seconds. When ready, click Save. Any change you specify takes effect immediately.
Sometimes you want to detect strings that appear on pages and have them reported as errors. For example, if a user receives the message "Your credit card has expired". Note the following:
All pages within the selected application are searched for the specified error string. It is not possible to limit the search to specific pages (as it is with page content checks).
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".
An example of a functional error report is shown in Figure 6-12.
Defining Functional Errors
To define a functional error string, do the following:
Select Configuration, then Applications, and select the required application. The Application overview (similar to the one shown in Figure 6-5) 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. The dialog shown in Figure 6-13 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 F, "Working with XPath Queries". When ready, click Save. Any changes you make will take effect within 5 minutes.
Importing Lists of Functional Errors
Instead of separately defining each site error that you want to be monitored, you can click Upload list to import a file containing a list of error messages. This could, for example, be a list of predefined application errors. The dialog shown in Figure 6-14 appears.
Figure 6-14 Upload Functional Errors 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 Appendix B, "Cookie Structures". If an unsupported encoding is encountered, or the transcoding fails, an error is reported. The file must contain one error 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.
Defining Translations for Functional Errors
Optionally, you can also define a set of translations for each unique error string. For example, you could define the translations for Oracle database errors shown in Table 6-2.
Table 6-2 Example Error String Translations
| Error 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 |
Transactions 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 an error translation, do the following:
Select Configuration, then Applications, and select the required application. The Application overview (similar to the one shown in Figure 6-5) appears. Click the Error translations tab. The currently defined error 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 6-15 appears:
Specify the required source value and its translation. When ready, click Save.
Importing Lists of Translations
Instead of separately defining each translation, you can click the « Upload list » item to import a file containing a list of translations. The dialog shown in Figure 6-16 appears.
Specify the name of the translation file. Optionally, use the File encoding menu to specify the file's character encoding. For more information on international character set support, see Appendix B, "Cookie Structures". 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. When ready, click Merge.
Within RUEI, user identification is first based on the HTTP Authorization field. If this is not found, the application's user identification scheme is used. This can be specified in terms of URLs, cookies, request or response headers, or XPath expressions. When it is not configured, RUEI will use the SSL client certificate (when available). The common name (CN) portion of it is used. If this is not found, the client ID is reported as Anonymous. To configure user identification, do the following:
Select the required application, and click the User ID tab.
Click the « Add new source » item. The dialog shown in Figure 6-17 appears.
Use the Search type menu to specify the user identification mechanism. This can be specified in terms of a literal search string, an XPath expression, or a cookie, and whether the server response or client request should be searched. More information about using XPath queries XPath queries is available in Appendix B, "Cookie Structures". Use the Search value field to specify the required parameter. When ready, click Save.
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 Chapter 2, "Working With Reports".National Language Support
See Appendix B, "Cookie Structures" for a detailed discussion of the implications for identification when working with international character sets.
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 6-18.
Figure 6-18 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 6-18. 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 or transaction, is defined as a key page, is manually named, or is part of a monitored KPI. The View menu shown in Figure 6-19 allows you to control which type of pages are displayed in the structure overview.
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, and click the Search button above the application overview (see Figure 6-5). A screen similar to the one shown in Figure 6-20 appears.
Figure 6-20 Page Search and Results Dialog
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.
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.
Note:
The scope of the search includes both pages that have already been detected, and undetected pages that appear in reports and transactions.Information about each page detected for an application is available through the page Analysis window. An example is shown in Figure 6-21.
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 Section 6.2.13, "Specifying Page Content Checks".
Reporting: lists the reports in which this page appears. Reports are described in Chapter 2, "Working With Reports."
Transactions: lists the transactions in which this page is defined. See Section 6.5, "Building Transactions" for more information on defining transactions.
Monitoring: list the KPIs in which this page appears. See Section 5.2, "Defining KPIs and SLAs" for more information about the procedure for defining KPIs.
Defining Keypages
Use the Keypage check box in Figure 6-21 to define a page as a key page.
Keypages 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 transaction 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).
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" appears 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 content check returns "configured string not found".
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 6-21) appears.
Click the Content check tab, and click Add check. The dialog shown in Figure 6-22 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. 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 Appendix F, "Working with XPath Queries". When ready, click Save.
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 in the application overview, 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 6-23 appears.
Note:
If the required page is not visible in the application overview for you to select, locate it using the Search button (described in Part , "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 6-24 appears.
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 6-18. You can use this window to track the page's detection, and modify its definition.
The URL diagnostics group (described in Section 3.2.4, "The URL Diagnostics Group") 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 facility (see Section 3.9, "Working With the Session Diagnostics Facility"), 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 6-5) appears. 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 6-25 appears.
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 the « Add URL argument/component » item. A dialog similar to the one shown in Figure 6-26 appears.
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 6-27.
Figure 6-27 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 6-25.
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.
Excluded URL Information
Note that forced objects (described in Section D.1.2, "Forced Objects") 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.
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 Section 3.9, "Working With the Session Diagnostics Facility"). 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, then Applications, then Applications, and then select the required application. The Application overview (similar to the one shown in Figure 6-5) appears. Click the JavaScript replay tab. The currently defined execution rules are displayed. A dialog similar to one shown in Figure 6-28 appears.
Use the Disable all JavaScript execution check box to specify whether all JavaScript code within the selected application's pages should be disabled when replayed within the Replay facility. Note that if checked, any existing execution rules are ignored, and it is not possible to define new ones. By default, it is checked.
Click « Add new rule » to define a new execution rule, or click an existing one to modify it. Note that this facility is only available if the Disable All JavaScript execution check box is unchecked. A dialog similar to the one shown in Figure 6-29 appears.
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.
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.
Single sign-on (SSO) is a method of access control that enables a user to log in once and gain access to the resources of multiple software systems without being prompted to log in again. Because different applications and resources support different authentication mechanisms, SSO has to internally translate and store different credentials compared to what is used for initial authentication. SSO offers the following benefits:
Reduces password fatigue from different user name and password combinations.
Reduces time spent re-entering passwords for the same identity.
Reduces IT costs by lowering the number of IT help desk password-related calls.
SSO uses centralized authentication servers that all other applications and systems utilize for authentication purposes, and combines this with techniques to ensure that users are not actively required to enter their credentials more than once.
In order to facilitate the correct monitoring of SSO-enabled applications, you need to configure the authentication server(s) used within your environment. This is done through the creation of an SSO profile.
SSO servers manage user profiles and provide a login page to authenticated users. Applications then interact with SSO servers to validate temporary tokens. Figure 6-30 illustrates how application authentication works when enabled by an SSO server.
Figure 6-30 Authentication Flow Within SSO-Enabled Application Traffic
The authentication flow shown in Figure 6-30 takes the following sequence:
The user attempts to access a protected URL. The application server checks for the existence of an authentication cookie for the requested application. If found, it means that the user is already logged on, and no further authentication is required.
The user is re-directed by the application server to the SSO server. The application server also provides an application URL to the SSO server so that it knows where to go after user logon. Note the SSO server also checks whether the user is already authenticated (by another application) by validating any existing authentication cookie.
In the event the user is not recognized based on an existing authentication cookie, the SSO server requests credentials from the user via the login page, and these are specified by the user in a user name and password combination.
The user's credentials are verified against their entry in the SSO server database. Once validated, the authentication is preserved by an SSO cookie. The name of this cookie must be specified when creating a SSO profile.
The SSO server fetches the user's attributes. The attributes that are actually fetched are implementation-specific, and are not relevant to RUEI.
The SSO server passes the fetched attributes to the partner application server, using the URL provided to it in step 2. Note that a token argument is added to this URL. The name of this token argument must be specified when creating SSO profiles. The application server will probably also issue its own cookie to the user. This is configured as part of the application or suite definition.
Finally, note the network lines over which steps 1, 2, and 5 pass must be within the scope of RUEI monitored traffic.
SSO Profiles and Applications
It is important to understand that SSO profiles and applications, although closely related, are reported as separate entities within RUEI. For this reason, SSO profile and application definitions should be mutually exclusive. That is, each should be based on separate domains and cookies. Otherwise, the monitored traffic is reported as application-related traffic, and the potential benefits to enhanced reporting are not realized.
To define a SSO profile, do the following:
Select Configuration, the Applications, then Single Sign-On, and Click New SSO profile. The dialog shown in Figure 6-31 appears.
Specify a name for the SSO profile. This must be unique across suites, services, applications, and SSO profiles. Note that SSO profiles cannot be renamed later.
Use the remaining fields to specify the scope of the SSO profile. This is defined in terms of partial page URLs. Note that as you enter this information, you can see the effect of your definition through the Filter preview column.
Note:
It is advised that filter definitions be mutually exclusive across SSO profiles, applications, suites, and services. Otherwise, this 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 matching rules are applied.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 profile name and leave all other fields blank. That is, a blank filter. Note that if a wildcard character (*) is not specified within the Domain field, network traffic arriving on a non-standard port (that is, other than ports 80/443), is not associated with the SSO profile 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 combinations. See Section 7.6, "Controlling Rule Ordering Within RUEI" for information about how you can control the order in which filters are applied.
When ready, click Next. The dialog shown in Figure 6-32 appears.
Figure 6-32 Single Sign-On Server Information Dialog
Use this dialog to specify information about the SSO authentication server you are using. You need to specify the session cookie name, the URL argument which contains the authentication token, and how users are identified in the monitored traffic. Normally, this is defined in terms of a URL argument and value. However, it can also be specified in terms of cookies, request or response headers, or XPath expressions.
When ready, click Finish. An overview of the SSO profile definition you have specified is displayed. An example is shown in Figure 6-33.
This overview provides a summary of the defined SSO profile and allows you, if necessary, to modify its definition. The Identification section summarizes the match criteria currently defined for the SSO application. The User ID section summarizes how users are identified. This can be specified in terms of URLs, cookies, request or response headers, or XPath expressions.
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 Chapter 2, "Working With Reports".
After defining an SSO profile, you can modify it via its overview. The following tabs are available:
Identification: Specifies the scope of the SSO server in terms of one or more partial page URL matches. Pages are assigned to the SSO server when a defined filter matches a page's URL. To add a new filter, click Add new filter. Click an existing filter to modify it. A dialog similar to the one shown in Figure 6-34 appears.
Figure 6-34 Edit SSO Profile Filter Dialog
The note at the bottom of the dialog indicates the current rule ordering scheme. This is explained in Section 7.6, "Controlling Rule Ordering Within RUEI".
User ID: Specifies how user IDs are identified within the application. When not defined, the SSL client certificate is used (when available).
When verifying the correct operation and reporting of your SSO-enabled applications, the important aspect to inspect is the correct identification of users. It is recommended that you regularly review the reporting of within the Data Browser (All sessions > User Id > Sessions and pageviews). For example, an unexpectedly high level of unidentified (anonymous) users.
Also, you should verify that URLs within SSO-enabled applications are not reported within application-related data. This can indicate that there is a problem.
As explained earlier, page identification within RUEI is based on applications. However, if these applications are based on certain Oracle Enterprise architectures (such as Oracle E-Business Suite, Siebel, and WebLogic Portal), then a fourth level, suite, is introduced. A suite is essentially a collection of applications, and Web pages associated with these suites have the structure suite » application » group » page.
Why Use Suites?
If you are using any of the any of the currently supported Oracle Enterprise architectures within your monitored environment, it is strongly recommended that you make use of this facility. It not only saves you time in defining your applications, and makes applications within suites more compatible, but also ensures that these architectures are monitored correctly.
Creating Suites
To define a suite instance, do the following:
Select Configuration, then Applications, and then Suites from the menu structure shown in Figure 6-35.
Important:
For information about package availability, please contact Customer Support or visit the Web site
http://www.oracle.com/enterprise_manager/user-experience-management.html.Click New suite. The dialog shown in Figure 6-36 appears.
Specify a name for the suite. The name must be unique across suites, services, SSO profiles, and applications, and is restricted to a maximum of six characters. Note that suite instances cannot be renamed later.
Use the remaining fields to specify the scope of the suite. This is defined in terms of partial page URLs. The use of these filter criteria is the same as described in Section 6.2, "Defining Applications". Note that as you enter this information, you can see the effect of your definition through the Filter preview column. The use of blank filters is not permitted. Note that if a wildcard character (*) is not specified within the Domain field, network traffic arriving on a non-standard port (that is, ports 80/443), is not associated with the suite instance 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. When ready, click Next. The dialog shown in Figure 6-37 appears.
Note:
It is advised that filter definitions should be mutually exclusive across suites, SSO profiles, applications, and services. The use of non-mutually exclusive filter definitions can lead to unpredictable results. See Section 7.6, "Controlling Rule Ordering Within RUEI" for more information about how you can control the order in which filters are applied.This dialog allows you to specify the Oracle Enterprise architecture upon which the suite is basedFoot 1 . When ready, click Finish. The suite definition you have specified is displayed. An example is shown in Figure 6-38.
This overview provides a summary of the defined suite. This includes the defined page identification filter(s), the number of pages that have so far been matched to the suite, the functional errors (if any) that should be detected and recorded, and the user identification mechanism used within the suite to track visitor sessions. Each of these can be modified as required. The procedure is equivalent to that described in Section 6.2, "Defining Applications".
It is strongly recommended that you run the appropriate script supplied with the package within your Oracle architecture production environment. For example, create_EBS_info.pl script. This is in order determine how these architectures have been implemented within your environment. In particular, the page-naming scheme. Do the following:
Download the script supplied with the accelerator package. See the documentation supplied with the appropriate package for further information on the use of this facility.
Run the script within our deployment environment. This script assigns an identification to the page IDs within your environment. It creates a number of .txt files.
Create a .zip file from the generated .txt files.
Select Configuration, then Applications, then Suites, select the appropriate suite, and click Upload configuration. The dialog shown in Figure 6-39 appears.
Specify the name of the file generated by the script. A Browse button is available to help you locate the required file. This must be a .zip file. When ready, click Upload.
Note:
This configuration file must be uploaded for each required suite instance. It may only contain known (and non-empty) .
txt files. All these files must be in the root directory. That is, subdirectories are not permitted. It is important you upload the correct configuration file for the required suite instance, and that it is based on the actual production environment. The result of importing an erroneous configuration file is incorrect reporting.Modifying Suite Definitions
As explained earlier, a suite is essentially a collection of applications. Once you have defined your suites, you can modify its associated properties in the same way as described for applications in Section 6.2, "Defining Applications".
You should pay particular to the following points:
A number of default suite-specific functional errors are defined. You should review these to reflect the requirements of your environment. The procedure is the same as described in Section 6.2.8, "Trapping Application Functional Errors".
By default, unclassified pages are not reported. You can modify this through the Report unclassified pages check box. The procedure is the same as described in Section 6.2.3, "Reporting Unclassified Pages".
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. This is fully explained in Appendix B, "Cookie Structures".
A default user identification scheme is defined for each suite. You should review this to reflect the requirements of your environment. The procedure is the same as described in Section 6.2.9, "Defining User Identification".
In addition to identifying pages through suites, you can also define pages manually. The procedure is the same as described in Section 6.2.14, "Manually Identifying Pages". However, you cannot define a new page from scratch. You must use an existing page as the basis for a new page.
A transaction is a collection of pages that define a logical task. For example, a ferry booking application might have the following pages defined for the transaction booking:
Route and date details.
Passengers and vehicle details.
Payment details.
Confirmation.
This facility provides you with far greater insight into how visitors experience your Web pages. For example, you might notice that 80% of visitors who start the above transaction fail to complete it while on the last page. This might indicate that there is something visitors find confusing or annoying about that page.
In order to facilitate administration, transactions are classified into categories. For example, you could define separate categories for bookings, requests for brochures, or job applications.
To define a new transaction, do the following:
Select Configuration, then Applications, and then Transactions. The currently defined transaction categories are displayed. Click New transaction. The dialog shown in Figure 6-40 appears:
Specify a name for the transaction, and the category in which it will be stored. Note that you can click the Add category button to create a new transaction category. In addition, specify the first step in the transaction. Each step in a transaction must have a unique name. Use the Page name field to specify the page used in step. Note that you can click the Search icon to the right of the Page name field to search for a required page. For information about applications, see Section 6.2, "Defining Applications". When ready, click Save. The new transaction, and its first step, are listed. An example is shown in Figure 6-41.
Note:
Within the Page name field, although it is possible to enter the page name directly, it is strongly recommended that you select it from the list. This prevents the risk of entering a non-existent page name. However, for performance reasons, a maximum of 500 pages are listed. If the required page is not listed, you can enter it manually in the format application » group » page. The separator character (») can be produced with the key sequence Alt 0187. If you enter the page name directly into the field, it is strongly recommended that you review the application overview (shown in Figure 6-1) to ensure that it is correctly specified.Use this window to define the remaining steps in the transaction. Note that an individual step can be made up of several pages. For example, in a payment method step, you may have a separate page for each available payment method (such as credit card, bank transfer, and so on). Click Add step/page to define additional transaction steps or pages. The dialog shown in Figure 6-42 appears.
Use this dialog to create transaction steps or specify additional pages for existing steps. Note that you can click the Search icon to the right of the Page name field to search for a required page. When ready, click Save. You are returned to the transaction definition shown in Figure 6-41.
Repeat the above procedure for each required transaction step. Note that a maximum of 15 steps can be defined for a transaction.
To modify an existing transaction, do the following:
Select Configuration, then Applications, then Transactions, and click the required category and transaction. The transaction definition appears similar to the one shown in Figure 6-43.
Use the context menu available under transaction steps to change their order in the transaction, or to rename or delete them. You can also use the Add step/page button to extend the existing definition with additional steps or pages.
Note:
Information about the transactions you have defined is available through the Transaction category of reports. For more information on reports, see Chapter 2, "Working With Reports."Transaction reporting is based upon the session within which a visitor started the transaction. A transaction is considered terminated if the visitor has been inactive for longer than the defined session idle time (by default, 15 minutes). The use of this setting is described in Section 7.4.3, "Controlling Session Reporting". In addition, a transaction is considered terminated if the transaction lasts longer than the defined transaction flush time. By default, this is 60 minutes. After this time, the transaction's details are written to the Data Browser.
For example, consider the transaction activity shown in Figure 6-44.
The user's transaction activity from 08:00 until logging off at a little before 10:00 would be recorded as two transactions. The first transaction would be recorded as starting at 08:00, and would report one step (step 1). The second transaction would be reported as starting at 09:00, and would show three steps (1, 2, and 3). If you need to modify the transaction reporting, you should consider modifying the transaction flush time.
In order to control the transaction flush time, do the following:
Select Configuration, then General, the Advanced settings, then Session processing, and then Transaction flush time. The dialog shown in Figure 6-45 appears.
Figure 6-45 Change Transaction Reporting Dialog
Specify, in minutes, the period after which transaction information is written to the Data Browser. When ready, click Save.
Any change you make to this setting takes effect within five minutes.
Transaction steps are correlated within their defined sequence. Hence, it is possible for RUEI to detect when visitors go back and forth between transaction steps, and ensure that the page visit is only recorded once. However, if visitors view pages out of the defined sequence, this can lead to inaccurate information.
Transaction completion is calculated by comparing the number of page visits within a session to the first transaction step to the number of page visits to the last transaction step. A sample transaction funnel is shown in Figure 6-46.
Therefore, in order to obtain accurate transaction information, it strongly recommended that you carefully review the design of all transaction pages within your Web environment. In particular, you should ensure that:
All transactions are designed in such a way as to ensure complete execution of all the defined steps. That is, visitors are required to visit all steps to complete the transaction. Furthermore, it should not be possible for visitors to enter or leave the transaction funnel through any means other than the designated path.
It is not possible for visitors to skip transaction steps. For example, through the use of bookmarks or hyperlinks on marketing material. In addition, avoid the use of your Home page in transaction definitions because, typically, visitors can easily skip it.
Reporting Transaction Information
Be aware that when a user starts a transaction, if the user is inactive for longer than the session idle time (by default, 15 minutes) without completing it, the transaction is regarded as having timed out, and is reported as failed. If the user then continues with the transaction and completes it in the same session, this is not recorded as a completed transaction. For this reason, if you have a back-office system tracking transaction completions, you may notice that the number of completed transactions it reports is higher than that reported by RUEI.
It is recommended that you design your transactions to be short as possible in order to minimize the chance that users time out during transactions.
Footnote Legend
Footnote 1: The options available for selection depend on the accelerator packages you have installed.
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
