| Oracle® Real User Experience Insight User's Guide 12c Release 1 for Linux x86-64 Part Number E35689-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Real User Experience Insight User's Guide 12c Release 1 for Linux x86-64 Part Number E35689-02 |
|
|
PDF · Mobi · ePub |
This chapter describes how to identify the Web pages to be monitored. In particular, how to define the Web pages for which you want additional information to be available, and those pages that should be monitored for the occurrence of specific text strings. The use of the ruling and other advanced facilities is also explained. Finally, the monitoring of traffic within a SSO-based environment is described.
Note that URL arguments configured for applications, suites, and services, as well as for user and client ID identification, must be specified without encoding (except for %, &, and = characters).
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 8-1.
To define applications, do the following:
Select Configuration, then Applications, then Applications, and click New application. The dialog shown in Figure 8-2 appears.
Specify a name for the application. This should be unique across suites, services, SSO profiles, and applications. Because application names are appended to reported pages, it is recommended that you keep defined application names as should as possible. 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 a wildcard character (*) cannot be specified within the Find Port field, and only one port number can be specified. If you need to specify additional ports, these should be specified as additional filters after the new application has been created.
Be aware that while the use of a wildcard character is supported within certain fields, all other specified characters are interpreted as literals. Finally, it is not possible to specify the wildcard character and no other information for domain and URL argument combinations.
Note:
It is advised that filter definitions be mutually exclusive across applications, suites, SSO profiles, and services. For example, an application filtered on the domain
us.oracle.com and then a second application filtered on us.oracle.com/application_servlet, can lead to unpredictable results. See Section 12.9, "Controlling Rule Ordering Within RUEI" for information about how you can influence the order in which matching rules are applied.Note:
URL arguments configured for applications, suites, and services, as well as for user and client ID identification, must be specified without encoding (except for %, &, and = characters).You can also specify a URL GET argument that must be matched. 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 detected page URLs. This is, partial matching is not supported. When ready, click Next. The dialog shown in Figure 8-3 appears.
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 8.2.2, "Using Advanced Settings to Control the Handling of Pages and Objects" for more information about the use of this option. The structure and processing of the generic page tagging schemes supported by RUEI are described in Appendix A, "Tagging Conventions."
Client request: specifies that pages are identified on the basis of their URL structure. The following options specify which portion of the URL is used:
URL argument: page naming is based on a specified argument within the URL. Note that only ASCII characters are allowed, and special characters (such as "&" and "|") must be URL-encoded.
URL: page naming is based on the complete domain and URL as it appears in the visitor browser location bar. This scheme is particularly useful when using ruling.
URL directory: uses only the directory part of the URL. The various parts of the URL are highlighted in Figure 8-4.
URL base: uses the main directory and file name (without the file extension) parts of the URL.
URL full: uses the main directory, the file name (without the file extension), and the configured arguments within the URL. If you select this option, you are prompted for the arguments that you want included in the page name. Within the dialog box, multiple arguments should be separated with an ampersand (&) character. For example, if the frmAction parameter has been defined, the URL shown in Figure 8-4 will result in the page name myshop » shop » NL index frmAction=buy.
Header in request: specifies that page naming uses a specified header within the client request. Not that only ASCII characters are allowed in the header name (and not special characters such as ":").
XPath in request: specifies that pages are identified on the basis of an XPath expression applied to the client request. For more information on the use of XPath expressions, see Appendix F, "Working with XPath Queries".
If you select any of the above options, see Section 8.2.2, "Using Advanced Settings to Control the Handling of Pages and Objects" for further information about their use.
Server response: specifies that pages are identified on the basis of the server response. The following options are available:
Header in response: specifies that pages are identified on the basis of a specified header within the server response.
XPath in response: specifies that pages are identified on the basis of an XPath expression applied to the server response. For more information on the use of XPath expressions, see Appendix F, "Working with XPath Queries".
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 8.2.17, "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 8-5.
This overview provides a summary of the defined application. This includes the application's name, the number of unique pages that have so far been matched to it, and the date of the most recent page identified for it. Note that if no page has been identified for the application in the last three days, a warning icon is displayed to indicate that the application is not currently functioning.
The tabs in the lower part of the screen provides information about specific aspects of the application. For example, The Identification section summarizes the filter criteria currently defined for the application, while the Pages section specifies the the page-naming scheme to be used, the report unclassified pages setting, the page-loading satisfaction threshold, and the pages so far identified as belonging to the application. Each of these sections are described in more detail in the following sections.
In addition to the defined page-naming scheme described in Section 8.1, "Naming Pages", the reporting of application pages can also be modified through the use of page translations. These allow you to specify transformations that should be made to a page's reported page-group » page-name specification.
To define page translations, do the following:
Select Configuration, then Applications, then Applications, and select the required application. The application overview (similar to the one shown in Figure 8-5) appears.
Click the Pages tab, and then the Page translations tab. The currently defined page translations are displayed. Click Add new translation to define a new translation, or click an existing one to modify it. The dialog shown in Figure 8-6 appears.
Specify the original page identification, and group and name that should be reported for it. Note that the original value must be specified in the format group|name. When ready, click Save.
Moving Page Translations Between Environments
It is recommended that page translations are developed at the same time as the application itself. This is best achieved by having RUEI monitor the application under development, and refining its defined page translations based on the obtained results.
Once ready for deployment, the application is then moved to a production environment. If that new environment is monitored by a different RUEI installation, you do not need to manually re-create the application's page translations. Instead, you can use the download facility to obtain a copy of its latest definitions, and then upload the generated file for use by the new RUEI installation.
To upload a file containing a list of predefined page translations, do the following:
After selecting the required application, click the Pages tab. Click Upload list. The dialog shown in Figure 8-7 appears.
Use the Browse button to locate and specify the name of the page translation file. The uploaded file must have the extension .txt. Optionally, use the File encoding menu to specify the file's character encoding. For more information on international character set support, see Appendix G, "Working with National Language Support". Note that in the case of duplicate page translations, the latest translation is used. The file may only contain one translation per line, with page group and page name tab separated. When ready, click Merge.
To download the currently defined page translations, click Download list. Depending on how your browser is configured, you are either prompted to specify the location to which the file should be saved, or it is immediately saved to the defined default location.
If you selected the HTML title or any of the client request page-naming schemes (such as URL base), the Advanced tab within the application overview allows you to refine the operation of these schemes. In the case of the HTML title scheme, the dialog shown in Figure 8-8 appears.
Figure 8-8 Edit Application Page-Naming Scheme Dialog
You can use the Time recognition menu to control whether non-forced objects are used to identify the page. Consider the example shown in Figure 8-9.
In this case, there are three non-forced objects (home.jsp, sub.jsp, and down.jsp) that could potentially be used for page identification.
If the enabled option (the default) is specified for the Time recognition menu, only the first object (home.jsp) would be identified as a page, and all hits after it will be considered objects until no more hits are detected within one second after the last object hit. However, if disabled, each of the three non-forced objects (such as jsp) would be identified as separate pages, regardless of detection time. For further information on forced objects, see Section 12.15, "Controlling the Reporting of Objects as Pages".
The Lowercasing menu within the Advanced tab allows you to specify whether page names should be converted to lowercase. The available options are shown in Table 8-1.
Table 8-1 Case Controlling Options
| Option | Explanation |
|---|---|
|
No |
Specifies that the original casing of page names is preserved. This is the default. |
|
Before ruling |
Specifies that reported page names for the selected application, suite, or service are converted to lowercase before applying all rules defined under the Ruling tab. |
|
After ruling |
Specifies that reported page names for the selected application, suite, or service are converted to lowercase after applying all rules defined under the Ruling tab. |
If you selected the HTML title page-naming scheme, the text found within the page's <title> tag is used to identify the page. Potentially, if not found, you may want the sub-headings <H1>, <H2>, and <H3> to be used. Therefore, you can use the sub-header fallback menu to control this facility. By default, the sub-headers are not used (Disabled).
If you selected any of the client request-based schemes (such as URL base), and click the Advanced tab, the dialog shown in Figure 8-10 appears.
Figure 8-10 Edit Application Page-Naming Scheme
You can use the Page handling menu to specify how redirects within a URL should be handled. The options shown in Table 8-2 are available.
Table 8-2 Page-Handling Options
| Setting | Description |
|---|---|
|
Final page |
Specifies that only the final page URL should be used to determine the page name. This is the default. |
|
Redirect naming |
Specifies that the page should be identified using the information available from the redirect in front of the final page. If not available, the final page's information is used. |
|
Redirect becomes page |
Specifies that the redirect will become the actual identified page. Note that the first redirect is used for page creation, and all subsequent redirects become objects on the created page. It is strongly recommended that you only select this option if you clearly understand its consequences for application reporting. |
Note:
Be aware that the Full session replay facility (described in Section 4.1, "Introduction") and error reporting may not function correctly if page names have been derived from redirects.Each application definition requires you to specify the page-naming and user identification schemes to be used. Optionally, you can also specify content messages that should be reported when they appear within specific application pages. Each of these definitions can be extended through the use of the ruling facility. This allows you to specify additional matching rules that should be used to refine the selected page-naming scheme, user identification scheme, or message specification. Note that the ruling facility is only available for automatic (not manual) page-naming schemes and XPath-based (not literal) content messages.
Because of the complex nature of ruling, it is recommended this facility is only used by users with a sound understanding of the selected application's appropriate scheme or message structure. For example, in the case of a URL-based page-naming scheme, the selected application's underlying URL structure should be clearly understood.
To specify the use of ruling for an application or suite, do the following:
Select Configuration, and then either Applications or Suites. Click the required application or suite to view its overview. Examples are shown in Figure 8-1 and Figure 10-4.
Depending on the required use for the ruling, click the page-naming scheme (within the Pages tab), the appropriate user-identification scheme (within the Users tab), or the appropriate content message specification (within the Content messages tab). A dialog similar to the one shown in Figure 8-11 appears.
Figure 8-11 Edit Application Page-Naming Scheme Dialog
Click the Ruling tab to specify the rules to be used, and the order in which they should be evaluated. The dialog shown in Figure 8-12 appears.
Use this dialog to define new rules or delete existing ones. You can also use the context menu under each rule to modify the order in which they are applied. Click the Add new matching rule item to define new matching rules. A dialog similar to the one shown in Figure 8-13 appears.
Specify the following components for the rule:
Input value: specifies the structure of the expected scheme (such as URL or page tagging) or message specification. Essentially, it provides a template for interpreting the received scheme or specification.
Search expression: specifies a definition of the scheme or specification that should be matched. Typically, this is expressed in terms of required parameters or components, and the sequences that should comprise them.
Page group: specifies how the page group is identified from the received page-naming scheme. Note if this is not specified, the page group is assigned the page name. This field is only available for page-naming rules.
User ID/Page Name/Content message: specifies how the page name, user ID, or content message is identified from the received scheme or specification.
After specifying the rule's components, you can click the Check rule button to verify that the defined rule is consistent with the specified validation value. Note that the result window can be expanded in order to view a summary of the matched placeholders. An example is shown in Figure 8-14.
When ready, click Save. You are returned to the dialog shown in Figure 8-12.
After defining all required rules, you can click Check rules to verify all defined rules against their validation values. Each validation value should be relevant to its corresponding rule. After verification, the icon shown beside each rule indicates its status. For rules that were not successfully verified, additional information is available via a mouseover or hover box. Consider the example shown in Figure 8-15.
The first rule is consistent with its defined validation value, and is successfully verified. However, the second rule is extremely generic, and you are warned that multiple validation rules could match this rule. In fact, it is so generic that no subsequent rule could be applied because its associated validation value has already been successfully applied. That is, the third rule will never be reached. That is why an error is reported on the third rule, and not the second. However, if the second rule was moved down to become the last rule, then the three rules would be successfully verified.
Although it is possible to save ruling definitions with reported errors, it is strongly recommended that you resolve any issues before saving a ruling definition. When ready, click Save. Any changes you make to a ruling definition take effect within five minutes.
Be aware that URL matching is case sensitive, and URLs (after matching) are converted to lower case. Matched slashes are replaced by spaces in the page name after ruling.
In addition, it is recommended that only the "URL" page-naming scheme is used when performing ruling based on URL structures. This is because other URL-based naming schemes perform some form of initial formatting.
Ruling for User Identification
The use of ruling for user identification is equivalent to that for page naming, except that you specify how the user ID is identified from the selected scheme, and page group identification is not supported. Consider the following case. The specified user-identification scheme is based on cookies, and each cookie has the following structure:
ORA_UCM_INFO=5~DVJ88287~John~Doe~john.doe@myshop.com~USA~en~33~44~5~~1;
You want user identification to be based only on the E-mail address portion of the cookie. In this case, you could specify the following:
Search expression: %\~%\~%\~%\~%\~%User ID: %5
The validation value could be specified using the example cookie shown above, or some other example cookie with the same structure.
Identifying Page Groups Within Rules
When using the ruling facility with a page-naming scheme whose source includes a page group, you should ensure that the group value is correctly identified. In the case of a URL page-naming scheme (except for "URL") whose source is myhost.com/myshop/menswear/catalog/basket.jsp, it is internally converted to the structure myshop\%7Cmenswear/catalog. This then needs to be transformed for correct reporting as follows:
Input value: myshop|menswear/catalog
Search expression: %|%/%
Page group: %1
Page name: %2
In the search expression, the pipe character (|) separator between group and page name does not need to be encoded. Note that the slash characters within URL structures can be used in ruling. Matched slashes are replaced by spaces in the reported groups and names after ruling.
In addition to the use of parameters, the elements shown in Table 8-3 can also be used in URL matching rules.
Table 8-3 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. |
|
|
Find the specified number of characters. |
|
|
Find directory path of the URL, and fill one placeholder. |
|
|
Find file name path of the URL without the file extension, and fill one placeholder. |
|
|
Find domain part of URL, and fill three placeholders (for example, |
|
|
Match until one of the following characters is matched, and fill one placeholder. |
|
|
Match until a character is found that does not match the specified list of characters. |
|
|
Match if the supplied |
Note that special characters (%, \, |, !, and ~) must be preceded with a backslash if they should be interpreted literally. For example, \% specifies a literal % character, rather than a parameter. In addition, special characters after the % character (^, &, [, and ]) also need to be escaped. Be aware that a maximum of nine placeholders can be specified.
Matching Multiple URL Parameters
If you want to match multiple URL parameters, it is strongly recommended that they are defined within one set of square brackets. For example, %[!parm1!parm2]. Note that while it is possible to specify %[!parm1]%[!parm2], be aware that it will only match the specified arguments if they appear in the same order in which they are defined. Consider the string /example/path/file.html. The possible matching schemes are shown in Table 8-4.
Table 8-4 Matching Multiple URL Parameters
| Definition | Matched Results |
|---|---|
|
|
|
|
|
|
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 within the Pages section of the application overview shown in Figure 8-16.
Figure 8-16 Application Page Configuration Section
Because page identification is a time-based activity, it is possible that references to objects not booked as objects are incorrectly identified as unclassified pages. For this reason, it is recommended that you only enable the reporting of unclassified pages for testing purposes. Thereafter, you can disable it again, and define the identified problems pages manually. Note unclassified pages are reported in the appropriate Data Browser group under the category "other".
Note that monitored service tests can also be converted into RUEI user flows. This is fully described in Section 9.8, "Converting Service Test Sessions into User Flows".
You can use the Report service test traffic check box within the Advanced section to specify whether service test traffic configured within Oracle Enterprise Manager for a selected application should be reported within RUEI. By default, reporting is disabled. For further information on the use of this facility, see Section 8.5, "Reporting Service Test Traffic".
When enabled, the Service tests group provides information about monitored service test beacon traffic. Its structure is described in Table W-1.
When reporting on user visits, the client IP address is, by default, fetched from the IP packet. However, when the RUEI system is placed in front of a NAT device, it may be more useful for the client IP address to be obtained from a specific HTTP request header. This is fully explained in Appendix P, "Monitoring NATed Traffic".
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 8-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 shown in Table 8-5.
Table 8-5 Page Loading Satisfaction Levels
| Level | Description |
|---|---|
|
Good |
The page loads in the user browser within the satisfied page loading threshold period. By default, this is four seconds. |
|
OK |
The page loads in the user browser within the OK threshold period. By default, this is 16 seconds. |
|
Poor |
The page takes longer than the poor threshold to load. |
An example page load satisfaction report is shown in Figure 8-17.
Figure 8-17 Page-Load Satisifaction Report
As stated above, this assessment is based on thresholds within which pages would normally be expected to load. These thresholds can be modified to fine tune the reported page load satisfaction. Do the following:
Select the required application, click the Pages section, and click the Default setting. The dialog shown in Figure 8-18 appears.
Figure 8-18 Edit Page-Load Satisfaction Thresholds Dialog
Click the Default item. The dialog shown in Figure 8-19 appears.
Figure 8-19 Edit Default Page-Load Satisfaction Thresholds Dialog
Specify the thresholds (in seconds) that should be used when assessing page-loading satisfaction. These thresholds are explained in Table 8-2. The defaults are 4 and 16 seconds. Note that defined thresholds must be in the range 0.001 - 86400 (that is, a day). When ready, click Save. You are returned to the dialog shown in Figure 8-18.
Optionally, click Add exception to specify a situation in which different (from the default) page-loading thresholds should be used to assess the user's experience. This facility is extremely useful when particular user actions would normally be expected to take significantly longer to perform than other application actions. For example, in the case of downloads or complex database queries. The dialog shown in Figure 8-20 appears.
Figure 8-20 Add Satisfaction Exception Dialog
Specify the page-load thresholds that should be used to assess the pages and user actions within the defined exception.
Specify the events that must be met for the exception to be considered reached. Note that all defined events must be met for the exception to be considered fired. For each event, use the Dimension level and Value menus to select the dimension that should be checked, and the value that it must hold. Note that if the required value is not available within the Value menu, you can click the Search icon beside it to locate it.
Optionally, you can use the Exclude check box to specify that the defined dimension level=value pair should be negatively applied. That is, the event should be regarded as achieved if the defined event is not met. When ready, click Add. The new event is added to the exception's definition. Note that a maximum of 10 events can be defined for an exception. When ready, click Save. You are returned to the dialog shown in Figure 8-18.
Be aware that exceptions are resolved from top to bottom. If necessary, you can use the Move up and Move down options within an exception's context menu to change its position. Note that a maximum of 100 exceptions can be defined.
When ready, click Save. Any change you specify takes effect immediately.
Understanding how Page and Object-Loading Satisfaction are Reported
It is important to understand that while page-loading satisfaction is based on the time required for a page to load in the user's browser, object-loading satisfaction is based on an object's total end-to-end time. Note that object-loading satisfaction uses the default application page-loading thresholds, and ignores any defined exceptions.
As explained in Section 3.2.2, "Problem Analysis Groups", any object with an end-to-end time of less than two seconds is not considered a slow URL. If greater than two seconds, its URL-loading satisfaction is based on the default application page-loading thresholds, and ignores any defined exceptions.
It is important to understand that RUEI does not automatically regard a user logging out of an application as the end of a session. Instead, the end of a user session is determined when the session idle timeout (by default, 60 minutes) is reached. This means that if an application does not terminate a user's session when they logout, and the user logs on again to the application, RUEI is unable to detect the application logout, and reports the two application sessions as part of the same user session.
If this does not meet your reporting requirements, you can define the application events that, if reached, will automatically be regarded as the end of the current user session. Typically, these will be logout pages and events. Any subsequent user actions will then be regarded and reported as part of a new user session.
Defining Application Logout Events
Do the following:
Select Configuration, Applications, Applications or Suites, and select the required application. The application overview (similar to the one shown in Figure 8-5) appears.
Click the Pages tab, and then the Logout Events tab. The currently defined logout events are listed. Click Add new event. Alternatively, click an existing definition to edit it. The dialog shown in Figure 8-21 appears.
Figure 8-21 Specify Application Logout Event(s) Dialog
Specify a dimension level=value pair for each required event condition. Optionally, you can use the Exclude check box to specify that the pair should be negatively applied. That is, the event should be regarded as achieved if the defined condition is not met. When ready, click Add. Note that while only one defined event needs to be achieved in order for the session to be regarded as terminated, all conditions within with an event must be met for it to be considered achieved. When ready, click Save.
Sometimes you want to detect strings that appear within pages, and have them reported as either application notifications (such as "Order processed successfully") or as application errors (such as "Network connection to server failed").
Content Messages vs System Errors and Page Content Checks
These content messages differ from system errors (such as Web server or network errors) in that they are based on page content, rather than a return code, and are specific to a selected application.
Note that all pages within the selected application are searched for the specified message string. It is not possible to limit the search to specific pages, as it is with page content checks (described in Section 8.2.16, "Specifying Page Content Checks").
Application content and page content messages are page-based. In the case of services, they are call (that is, hit) specific. Therefore, they are only reported in page-based groups, and not diagnostics groups (which are URL-based).
Individual content messages can be specified as notifications or errors. In either case, they are reported via the Page delivery dimension.
Displayed page texts that match your specified notification strings are reported with the page content result "notification string: notification search string", while errors are reported as "error string: error search string". An example of a content error report is shown in Figure 8-22.
To define a content message string, do the following:
Select Configuration, then Applications, Suites, or Services, and select the required application. The Application overview (similar to the one shown in Figure 8-5) appears.
Click the Content messages tab, and then the Content messages tab. The currently defined content messages are displayed. Click Add new content message to define a new message, or click an existing one to modify it. The dialog shown in Figure 8-23 appears.
Use the Search type menu to specify the scope of the search. This can be the request or response header or content. The search can be based upon a literal search string, or an XPath expression. In the case of an XPath expression, only the request or response header can be searched. If you specify a request or response header, you are required to specify the HTTP header that should be searched.
Use the String field to specify the search string. Note that the use of wildcards is not supported, and all specified characters are treated as literals. Alternatively, use the XPath search field to specify the XPath expression that should be used. More information about the use of 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. Note that after creating an XPath-based content message, you can use the ruling facility to refine the message's specification. This is fully described in Section 8.2.3, "Using the Ruling Facility".
Importing Lists of Content Messages
Instead of separately defining each message that you want to be monitored, you can import a file containing a list of predefined application messages. Do the following:
After selecting the required application or suite, click the Message specifications tab. Click Upload list. The dialog shown in Figure 8-24 appears.
Figure 8-24 Upload Content Messages Dialog
Use the Browse button to locate and select the required file. Optionally, use the File encoding menu to specify the file's character encoding. For more information on international character set support, see Appendix G, "Working with National Language Support". If an unsupported encoding is encountered, or the transcoding fails, an error is reported.
The uploaded file must contain one message per line, and there should be no blank lines in the file. Be aware that these messages will be regarded as literal strings to be searched for in the response content. When ready, click Merge.
Optionally, you can also define a set of translations for each unique message string. For example, you could define the translations for the Oracle database messages shown in Table 8-6.
Table 8-6 Example Message String Translations
| String | Translation |
|---|---|
|
|
An attempt was made to acquire a DDL lock that is already locked. |
|
|
The number of temporary tables equals or exceeds the number of temporary table locks. |
|
|
DB_BLOCK_SIZE initialization parameter is wrong for the database being mounted. |
|
|
The value of the DB_FILES initialization parameter was exceeded. |
|
|
User flows deadlocked one another while waiting for resources. |
|
|
The shared instance being started is using DML locks, and the running instances are not, or vice-versa. |
|
|
The instance was started with DML_LOCKS = 0, and the statement being executed needs a full-table lock (S, X, or SSX). |
|
|
The number of log files specified exceeded the maximum number of log files supported in this release. |
To define a message translation, do the following:
After selecting the appropriate application or suite, click the Content messages tab, and then the Message specifications tab. The currently defined message translations are displayed. Click Add new specification to define a new translation, or click an existing one to modify it. The dialog shown in Figure 8-25 appears.
Figure 8-25 Add Message Specification Dialog
Specify the required source value and, optionally, a translation. When ready, click Save.
Use the Message type menu to specify whether the message should be reported as an error (default) or a notification. When ready, click Save.
In the example above, this would be reported as:
error code ORA-00056: An attempt was made to acquire a DDL lock that is already locked.
Note that when working with a large number of translations, you can use the Search field to quickly locate a required translation. The search facility uses partial matching. The use of wildcards is not supported, and all characters are treated as literals. When ready, click Go.
Importing Lists of Translations
Instead of separately defining each translation, you can import a file containing a list of translations. Do the following:
Click Upload list. The dialog shown in Figure 8-26 appears.
Figure 8-26 Upload Message Specifications Dialog
Use the Browse button to locate and specify the name of the translation file. Note that in the case of duplicate message definitions, the latest definition is used. Optionally, use the File encoding menu to specify the file's character encoding. For more information on international character set support, see Appendix G, "Working with National Language Support". If an unsupported encoding is encountered, or the transcoding fails, an error is reported. The file may only contain one translation per line, with source values and translations tab separated.
Use the Message type menu to specify whether the messages defined in the file should be reported as errors (default) or notifications. When ready, click Merge.
It can be extremely useful for content messages to be reported alongside non-content related errors (that is, Web site, network, or server errors). This enables you to provide additional information about the context of the error in order to facilitate troubleshooting. However, this is not default reporting behavior.
As explained in Section 3.2.3, "Page Delivery Dimension", if a page experienced several types of errors (for example, both a server error and a network error), the page error is not reported multiple times. Instead, it is reported based on the following prioritization: Web site, server, network, and content.
To specify that non-content related errors should be reported with additional explanations, do the following:
Select Configuration, then Applications, and select the required application. The Application overview (similar to the one shown in Figure 8-5) appears. Click the Content messages tab, and then the Advanced tab. The screen shown in Figure 8-27 appears.
Check the Append content messages check box to specify that if a defined content message is found on the page, this should be appended to the error when reported. By default, content messages are not appended. Note that if multiple content messages are found within the same page, the first message found on the page is used for reporting purposes.
An example of enhanced page delivery details is shown in Figure 8-28.
Figure 8-28 Example Additional Page Delivery Details
Within RUEI, newly created applications are automatically configured to have user identification based on the HTTP Authorization field and the Common Name (CN) portion of the SSL client certificate (when available). This is shown in Figure 8-29.
Figure 8-29 Application User Identification Scheme
However, you can also configure the application's user identification scheme in terms of URLs, cookies, request or response headers, XPath expressions, custom tag or responses, or OAM user tracking (see Section 11.1, "Monitoring OAM-Based Traffic"). Note that the HTTP Authorization field has priority over other configured values, and that the SSL certificate is the fallback scheme. When the configured user ID does not match that found in the monitored traffic, the user ID is reported as Anonymous.
Configuring an Application's User Identification Scheme
To configure an application's user identification scheme, do the following:
Select the required application, and click the Users section.
Click Add new source. The dialog shown in Figure 8-30 appears.
Figure 8-30 Add New User ID Source Dialog
Use the Source type and Source value fields to specify the user identification mechanism. This can be specified in terms of a literal search string or an XPath expression. Be aware of the following:
In the case of a literal search string, you can specify whether the request or response header should be searched.
In the case of an XPath expression, you can specify whether the request or response should be searched. More information about using XPath queries is available in Appendix F, "Working with XPath Queries".
In the case of a cookie, you need to specify the name of the cookie. Note that if hashing is specified for the selected cookie, or as the default cookie masking action, the cookie's uniqueness is preserved, but not its original value. This is fully explained in Section 13.6, "Masking User Information".
In the case of a URL argument, the name of the argument must be specified.
In the case of OAM-based traffic, see Section 11.1, "Monitoring OAM-Based Traffic" for more information.
In the case of a custom pattern, you must specify a start string and (optionally) an end string to delimit the searched content. Note that the use of wildcard characters is not supported, and all specified characters are treated as literals. In addition, besides any specified end string, the search will never extend beyond a new line.
In the case of a custom tag, you must specify the name in the name=value pair from which the user ID will be retrieved.
As explained earlier, if the HTTP-based authentication is specified, this takes priority over any other defined identification scheme. In addition, if the SSL client certificate is specified, this is the fallback scheme.
Click the Advanced tab. Use the Lowercasing menu to specify whether user names should be converted to lowercase and, if so, before or after applying the matching rules you can define after creation of the user identification definition.
When ready, click Save. Note that once your user identification scheme has been defined, you can use the ruling facility to refine their implementation. This is described in Section 8.2.3, "Using the Ruling Facility".
Note:
You can check the effect your user identification definition has by viewing the XLS User Information report in the Clients category. For more information on reports, see Chapter 2, "Working With Reports".See Appendix G, "Working with National Language Support" 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 8-31.
Figure 8-31 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 8-31. For this reason, the structure view is restricted to those pages that have some Point of Interest (POI) associated with them. This could include the fact that the page is featured in a report, is defined as a key page, is manually named, or is part of a monitored KPI. The View menu shown in Figure 8-32 allows you to control which type of pages are displayed in the structure overview.
The options shown in Table 8-7 are available.
| Options | Description |
|---|---|
|
All |
List all application pages. |
|
Report pages |
List only pages that have been specified as report filters (see Section 2.7, "Using Report Filters"). |
|
Checked pages |
List only pages for which content checks have been defined (see Section 8.2.16, "Specifying Page Content Checks"). |
|
Manually named pages |
List only pages that have been manually defined (see Section 8.2.17, "Manually Identifying Pages""). |
|
Key pages |
List only pages that have defined as key pages (see Section 8.2.15, "Tracking Page Usage"). |
By drilling down through the application page categories, you can locate specific pages. However, if you are working with an application with a large number of pages, it may be more convenient for you to use the page search facility. Do the following:
Select the application you want to search. Select the Pages section, and click the Identified pages tab.
Specify the search profile you want to use to locate the required page(s). Note that the search is restricted to the current application, and page names have the structure application » group » name. The search facility will try to match any search pattern you specify either as a full match or as a substring. Hence, the search pattern "home" would match occurrences of this string or any substring in the application, group, or page names. When ready, click Go. An example results listing is shown in Figure 8-33.
Figure 8-33 Page Search and Results Dialog
The search results are shown in the lower part of the dialog. Click a matched page to open it. Use the Backward and Forward buttons to scroll between multiple pages of results. In addition, you can use the View menu (described in Section 8.2.13, "Viewing the Application Page Structure") to limit the displayed list to a certain criteria, such as pages used in reports.
Note:
The scope of the search includes both pages that have already been detected, and undetected pages that appear in reports and user flows.Information about each page detected for an application is available through the page Analysis window. An example is shown in Figure 8-34.
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 8.2.16, "Specifying Page Content Checks".
Reporting: lists the reports in which this page appears. Reports are described in Chapter 2, "Working With Reports."
Monitoring: list the KPIs in which this page appears. See Section 7.2, "Defining KPIs and SLAs" for more information about the procedure for defining KPIs.
Use the Key page check box in Figure 8-34 to define a page as a key page.
Key pages are monitored Web pages that receive special attention. Typically, these are pages in which you have particular interest. For example, your organization's home page, or a series of pages in a user flow (such as placing an order). For these pages, additional information is recorded. This includes client information (such as the ISP, the country of origin, and so on), and the client browser information (such as operating system, browser version, and so on).
Sometimes you want to monitor a specific page for the occurrence of a specific text string. For example, your Web application has an Order page, and at the end of a successful sale, the text string "Thank you for shopping with us" should appear on the page. You can define a page content check that looks for this string on the required page. Note that if the specified text string is not found on the page, the page view is reported as failed.
Note that all specified strings for a page must be found within a page view for it to be reported as successful. Otherwise, it is reported as a failed page view. In addition, be aware that content messages (described in Section 8.2.11, "Trapping Application Content Messages") are matched before page content checks. Therefore, a page view could be reported as a notification (that is, successful), even though the page content checks would indicate that it should be reported as a failed page.
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 8-34) appears.
Click the Content check tab, and click Add check. The dialog shown in Figure 8-35 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, 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 8-36 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 Section 8.2.14, "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 8-37 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 8-31. 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 4.1, "Introduction"), 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 8-5) appears. Click the Advanced section, and click the URL diagnostics tab. The currently defined URL patterns used to specify the scope of the monitored URLs are displayed. Click Add new URL pattern to define a new pattern matching scheme, or click an existing one to modify it. A dialog similar to the one shown in Figure 8-38 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 Add URL argument/component. A dialog similar to the one shown in Figure 8-39 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 8-40.
Figure 8-40 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 8-38.
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.
Note that forced objects (described in Section 12.15, "Controlling the Reporting of Objects as Pages") are automatically stripped from reported URLs. In addition, it is recommended that you configure your application definitions to exclude the reporting of session parameters and static-based objects (such as images). This is in order to prevent diagnostics information becoming too long and its possible truncation.
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 4.1, "Introduction"). JavaScript execution can be completely disabled, or you can specify that specific functions or files should be replaced during page replay.
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 8-5) appears. Click the Advanced section, and then the JavaScript replay tab. The currently defined execution rules are displayed. A dialog similar to one shown in Figure 8-41 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 8-42 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.
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.
In the case of applications that make use of Rich frameworks (such as Ajax), you can specify an action-naming scheme. This is particularly useful when you want insight into the interactive user actions performed on specific pages. For example, consider the situation in which users are viewing your online catalog pages, and you want to know when they click the "Add to basket" action.
Information about actions is available through the Actions view for the All pages and Problem Analysis (such as Failed pages) groups. It is also viewable within the Session Diagnostics facility. An example is shown in Figure 8-43.
Figure 8-43 Action Incidence on Page Views
To define an action-naming scheme, do the following:
Select Configuration, then Applications, then Applications, and then click the appropriate application. The application overview (similar to the one shown in Figure 8-5) appears.
Click the Pages tab, and then the Action-naming scheme setting.
The same action-naming schemes are available as for page naming (except Manual), and are explained in Section 8.1, "Naming Pages".
Optionally, you can click the Advanced tab to specify whether action names should be converted to lowercase. By default, the original casing is preserved. When ready, click Save.
After selecting the required action-naming scheme, you can use the Ruling facility to refine its operation. This is explained in Section 8.2.3, "Using the Ruling Facility".
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 8-44 illustrates how application authentication works when enabled by an SSO server.
Figure 8-44 Authentication Flow Within SSO-Enabled Application Traffic
The authentication flow shown in Figure 8-44 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.
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 8-45 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 12.9, "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 a wildcard character (*) cannot be specified within the Find Port field, and network traffic arriving on a non-standard port (that is, other than ports 80/443), is not associated with the SSO profile unless the port number is explicitly stated. Only one port number can be specified. If you want to specify additional ports, these should be specified as additional filters after the new SSO profile has been created.
Be aware that while the use of a wildcard character is supported, all other specified characters are interpreted as literals. Note it is not possible to specify the wildcard character and no other information for domain and URL combinations. See Section 12.9, "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 8-46 appears.
Figure 8-46 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 8-47.
This overview provides a summary of the defined SSO profile and allows you, if necessary, to modify its definition. This is explained in the following section.
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 8-48 appears.
Figure 8-48 Edit SSO Profile Filter Dialog
The note at the bottom of the dialog indicates the current rule ordering scheme. This is explained in Section 12.9, "Controlling Rule Ordering Within RUEI".
Configuration: specifies the authentication token and cookie used.
Users: 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 page views). 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.
It is strongly recommended that you regularly review the tracking of monitored traffic within your RUEI deployment to ensure that it is being correctly identified. To do so, select Show statistics from the Configuration menu. The dialog shown in Figure 8-49 appears.
If the level of unidentified hits or pages appears to be unexpectedly high, you shown review your page identification definitions. This is described in Section 8.1, "Naming Pages". If the level of page views without session identification is unexpectedly high, you should review your user identification definitions. This is described in Section 8.2.12, "Defining User Identification".
Oracle Enterprise Manager can be configured to monitor service tests to ensure that the highest levels of availability and performance are maintained for your business-critical services. Oracle Enterprise Manager service tests are executed from beacons, and monitor services from the end-users' perspective, and their correlation to the underlying IT infrastructure. Typically, beacons are set to perform user flows that are representative of normal application usage, and then Oracle Enterprise Manager breaks down the response time of that user flow into its component pieces for analysis. The procedure for defining beacons and service tests is described in the Oracle Enterprise Manager Cloud Control Administrator's Guide.
The Service tests facility within RUEI complements Oracle Enterprise Manager service tests by allowing you to validate the results of this synthetic traffic against comparable real-user traffic. For instance, if a service test reports an issue with a specific aspect of an application, you can use this facility to determine whether this problem is also seen with real-user traffic during the same period. In this way, erroneous incidents can be quickly identified and ignored, while the impact of reported issues on real customers can be readily assessed.
Within RUEI, specific applications and suites can be monitored for service test traffic and, when detected, reported via the Service tests group. In addition, diagnostics information about monitored service tests is also available via the Service tests diagnostics facility. To configure an application or suite to detect service test traffic, do the following:
Select Configuration, and then either Applications or Suites. Click the required application or suite to view its overview. An example is shown in Figure 8-1.
Click the Advanced tab, then the Enterprise Manager tab, and use the Report service test traffic check box (shown in Figure 8-50) to specify whether service test traffic configured within Oracle Enterprise Manager for the selected application should be reported within RUEI. By default, it is disabled.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
