| Oracle® Real User Experience Insight User's Guide Release 5.1 for Linux x86-64 Part Number E15344-01 |
|
|
View PDF |
| Oracle® Real User Experience Insight User's Guide Release 5.1 for Linux x86-64 Part Number E15344-01 |
|
|
View PDF |
This chapter describes how to identify the 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. 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 the system 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 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 Configure new application 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. 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 advised that filter definitions should are 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 argument that must be matched (the use of POST arguments is not supported). 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 Application page-naming wizard 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. Note if this is not defined on the page, the <H1>, <H2>, and <H3> heading tags are used. 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 fully described in Section 6.2.1, "Using Advanced URL Matching Rules".
URL-directory: uses only the directory. 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).
Full-URL: uses the main directory, the file name (without the file extension), and the configured arguments. If you select this option, you are prompted for 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.
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.13, "Manually Identifying Pages" for information on manually 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 settings, 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.
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-6 appears.
Figure 6-6 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-7 appears.
Click the Add new URL matching rule item to define new matching rules. The dialog shown in Figure 6-8 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 fully explained in Appendix B.
As explained earlier, each page within the system 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 thr 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 system 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-9:
Figure 6-9 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. To do so:
Select the required application, and click the setting defined for the Page-loading satisfaction item. The Page load satisfaction dialog shown in Figure 6-10 appears.
Figure 6-10 Page Load Satisfaction Time Dialog
Specify the duration (in seconds) in which page loads would normally be expected to 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 that:
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-11:
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-12 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.
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-13 appears.
Figure 6-13 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. 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 specificied 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-14 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-15 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-16 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 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-17:
Figure 6-17 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-17. 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 list shown in Figure 6-18 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). The Page search and results dialog shown in Figure 6-19 appears.
Figure 6-19 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-20.
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 fully described in Section 6.2.12, "Specifying Page Content Checks".
Reporting: lists the reports in which this page appears. Reports are fully 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 Key Pages
Use the Key page check box in Figure 6-20 to define a page as a key page.
Key pages are monitored Web pages that receive special attention. Typically, these are pages in which you have particular interest. For example, your organization's home page, or a series of pages in a transaction such as placing an order. For these pages, additional information is recorded. This includes client information (such as ISP, the country of origin, and so on), and the user 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-20) appears.
Click the Content check tab, and click Add check. The Add page content check dialog shown in Figure 6-21 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 Manual page naming wizard shown in Figure 6-22 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, Find in domain (oracle.com) and Find exact URL (/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-23 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-17. You can use this window to track page detection and modify its definition.
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-24 illustrates how application authentication works when enabled by an SSO server.
Figure 6-24 Authentication Flow Within SSO-Enabled Application Traffic
The authentication flow shown in Figure 6-24 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 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 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 domain and cookies. Otherwise, the monitored traffic is reported as application-related traffic, and 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-25 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.
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. The specified domain name cannot already be used in another SSO profile. 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-26 appears.
Figure 6-26 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. The SSO profile definition you have specified is displayed. An example is shown in Figure 6-27.
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. The dialog shown in Figure 6-28 appears.
Figure 6-28 Edit SSO Profile Filter Dialog
The note at the bottom of the dialog indicates the current rule ordering scheme. This is fully 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 above Oracle Enterprise architectures, 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 suites, do the following:
Select Configuration, then Applications, and then Suites from the menu structure shown in Figure 6-29.
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-30 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 suites 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. 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-31 appears.
Note:
It is advised that filter definitions should be mutually exclusive across suites, SSO profiles, applications, and services. For example, do not define a suite filtered on the domain "us.oracle.com" and then another suite, application, or service 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 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 displayed in Figure 6-32.
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".
Uploading Configuration Files
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.sh 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 your deployment environment. This script assigns an identification to the assigned 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-33 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. 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, 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:
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.7, "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.2, "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.
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.8, "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.13, "Manually Identifying Pages". However, you cannot define the new page from scratch. You must use an existing page as the basis for the 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 gives you 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 groups. For example, you could define separate groups 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 groups are displayed. Click New transaction. The dialog shown in Figure 6-34 appears:
Specify a name for the transaction, and the group in which it will be stored. Note that you can click the Add group button to create a new transaction group. 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, as shown in Figure 6-35.
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 page, 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-36 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-35.
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 group and transaction. The transaction definition appears similar to the one shown in Figure 6-37.
Use the 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 group of reports. For more information on reports, see Chapter 2, "Working With Reports."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-38.
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 idle 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 transaction.
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 |
|
