URL Arguments
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. 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. 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 7-1.
To edit an application identification filter, click on the associated value, for example to edit the cookie filter, click aCookie=22.
Defining Applications describes how to monitor an application using either a tag based or network based data collector.
For tag based applications, where a tag data collector is used, but a network data collector is not used, collection of data from header, XPath and content sources is not applicable for application configuration, user id and content messages. For example, user id and content messages are not applicable to a tag based application. To identify users for a tag based application, use the oraInfo.user
tag. To configure browser exceptions, use the specific "Browser exception" source within content messages and set the session tracking configuration to 'Oracle' to use the cookie being sent by the Javascript library.
However, with tag based applications, several metrics (for example, hits, application language, application territory, detail timings, and sizes) and replay functionality are not available.
To overcome these limitations you can install a network data collector in addition to the tag based collector. Create Framework Exceptions as described in Refining Application Definitions Through Framework Exceptions to create a hybrid configuration where both tag and network based traffic are combined.
For information on setting up tag and network based monitoring see the Installing the RUEI Software chapter of the RUEI Installation Guide.
To define applications, do the following:
Note:
When an application is deleted, both the configuration and all previously measured data is discarded. This action is irreversible.
Note:
If you create a tag based application using a page naming schemed that is not URL based and later edit that application to make it non-tag based (unticking the Tag based application checkbox), it is converted to an equivalent page naming scheme. For example, a HTML Title (Browser JS Library) scheme becomes HTML Title.
If you tick the Tag based application checkbox for an application that was previously non-tag based and used a page naming scheme that was not URL based, the naming scheme is converted to Oracle (Browser JS Library) and all ruling is removed.
If you created a tag based application, you must define a Browser JS Library, that is a URL served by the application that acts as the tag that is monitored.
To specify the Browser JS Library used by your applications or suites, do the following:
If you selected "Oracle (Browser JS Library)" as the Page Naming scheme for the application as described in Defining Applications, you must also set the oraInfo.page property as described below.
The use of wildcard characters is not supported for security reasons.
For applications and suites using network data monitoring, the default is that no Browser JS Library is configured and if you do not define one, page browser times will be reported as zero. In addition, page loading/reading time analysis will also be less accurate because the reported page load times will not include page browser times. If pages are being requested from a CDN server (such as Akamai), use of the OnLoad event includes the render time of objects served through the CDN.
Example 7-1 Tag Library Properties
If you created a tag based application, RUEI automatically reports the page title using the reserved tag library property, oraInfo.title
.
In addition, the following properties that can be specified using javascript code:
Table 7-1 Tag Properties
Name | Default | Explanation |
---|---|---|
oraInfo.url |
document.location.href |
The value RUEI reports as page url. |
oraInfo.page |
The value RUEI reports as page name. |
|
oraInfo.pagegroup |
The value RUEI reports as page group. |
|
oraInfo.action |
The value RUEI reports as action. |
|
oraInfo.user |
The value RUEI reports as user. |
For example:
<script type="text/javascript" src="ruei_library.js"></script> <script type="text/javascript"> oraInfo.page = 'homepage'; oraInfo.action = 'view'; </script>
Example 7-2 Monitoring Page Clicks Using the Tag Library
If you created a tag based application, you can monitor page clicks using the onclick oraInfo.sendAction property. For example, the following code reports an when a user clicks on the "Click here" link:
<a href="#" onclick="oraInfo.sendAction('clickAction');"> Click here</a>
Example 7-3 Manual deployment of Browser JS Library link
As alternative to step 4 in Defining Browser JS Library Settings, you can also create a request to the specified marker object yourself. When enabled, RUEI will detect this request and records the start time of this request as being the browser time. Specified URL search pattern must correspond to that in the triggered request.
For example:
onLoad="m=new Image(); m.src='http://myhost.com/marker.gif?apikey=yourAPIkey&' + new Date().getTime();"
where yourAPIkey
is the API key for the Browser JS Library and a timestamp is included as an argument to prevent browser caching. The event can be included in the BODY part of the HTML page, or any other required location (such as within a Flash program).
The above example does not include browser exceptions, navigation timing, object count, and screen resolution. You should use the JavaScript library if you want to include those.
Example 7-4 Using Custom Dimensions with the Browser JS Library
If you create a Custom tag (Browser JS Library) dimension as described in Working With Custom Dimensions, you can set properties relating to those dimensions. For example, if you created a three level dimension, consisting of levels product, group and vendor, then you could include the following code to set properties for a page:
<script type="text/javascript" src="ruei_library.js"></script> <script type="text/javascript"> oraInfo.product = 'x9991'; oraInfo.group = 'Servers'; oraInfo.vendor = 'Oracle'; </script>
After creating this three level dimension, RUEI collects data that you can later browse and use in reports as described in Working With Custom Dimensions.
Example 7-5 Supported Browsers
The Browser JS Library works on modern browsers that support W3C timings, for example IE9+, Firefox 34+, Chrome 31+, Safari 8+, Opera 26+. However, Internet Explorer 8 is not supported.
In addition to the defined page-naming scheme described in 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.
Defining Page Translations
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 7-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 7-7 appears.
Specify the original page identification, and group and name that should be reported for it. 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:
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 are using an action-naming scheme as described in Defining Action-Naming Schemes for example HTTP Method and URL, you can associate that scheme, for example a specified HTTP Method and URL, with an action translation.
Defining Action Translations
To define action translations, do the following:
If you selected the HTML title or any of the client request page-naming schemes (such as URL base), the Advanced tab within the page naming scheme allows you to refine the operation of these schemes. In the case of the HTML title scheme, the dialog shown in Figure 7-10 appears.
Figure 7-10 Edit Application Page-Naming Scheme Dialog
Time Recognition
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 7-11.
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 Controlling the Reporting of Objects as Pages.
Controlling Case Sensitivity
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 7-2.
Table 7-2 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. The test input and search expressions should be supplied in lower case |
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. |
Sub-Header Fallback
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).
Redirect handling
If you selected any of the client request-based schemes (such as URL base), and click the Advanced tab, the dialog shown in Figure 7-12 appears.
Figure 7-12 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 7-3 are available.
Table 7-3 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 Introduction to Session Diagnostics) 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.
When using the ruling facility for page-naming, be aware that only matching URLs are reported upon. When a URL does not match, it is disregarded altogether. The ruling facility is only available for automatic (not manual) page-naming schemes and XPath-based (not literal) content messages.
Recommended Usage
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.
Note:
When the "Before ruling" setting is applied in the lowercasing option, the test input and search expressions should be supplied in lower case.
Defining Rules
To specify the use of ruling for an application, do the following:
Example 7-6 Ruling for URL Matching
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.
Example 7-7 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.
Example 7-8 Ruling for Client Browser
The use of ruling for client browser allows you to separate mobile App based traffic from browser traffic. For example, a mobile application may access your web pages using the user agent 'MyApp/Shopping/v1.3', you can use rules to allow that mobile application to be reported as 'Shopping' and client version as 'Shopping 1.3'.
Input value: MyApp/Shopping/v1.3
Search expression: %/%/v%
Client browser: %2
Client browser version: %2~%3
Example 7-9 Ruling for Client Device
The use of ruling for client device allows you to separate mobile App based on traffic from device traffic. For example, a mobile application may access your web pages using the user agent 'Mozilla/CFNetwork/Darwin/15.0.0', you can use rules to allow that mobile application to be reported as 'mobile' and client device brand as 'CFNetwork ' and client device model as 'Darwin'.
Input value: Mozilla/CFNetwork/Darwin/15.0.0
Search expression:%/CFNetwork/%/%
Client device: mobile
Client device brand: CFNetwork
Client device model:%2
Example 7-10 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.
Example 7-11 Search Constructions
In addition to the use of parameters, the elements shown in Table 7-4 can also be used in URL matching rules.
Table 7-4 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.
Example 7-12 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 7-5.
Table 7-5 Matching Multiple URL Parameters
Definition | Matched Results |
---|---|
|
|
|
|
Example 7-13 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 within the Pages section of the application overview shown in Figure 7-18.
Figure 7-18 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 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 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 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 7-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 7-6.
Table 7-6 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 7-19.
Figure 7-19 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:
When ready, click Save. Any change you specify takes effect immediately.
Example 7-14 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 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.
To define application logout events:
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 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).
Reporting of Content Messages
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 7-24.
Defining Content Messages
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 7-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 7-25 appears.
Use the Search type menu to specify the scope of the search. The search location can be one of request header, reply header, request content, reply content, or URL. The search type is either XPath or literal. For more information about the use of XPath queries, see Working with XPath Queries.
If you specify a request or response header, you can choose to specify the header that should be searched. If you choose to leave this field blank, it will be filled automatically with the full header content.
If you specify a URL, you can choose to specify a URL argument, which will be reported additionally to the URL part.
Note that the use of wildcards is not supported and all specified characters are treated as literals.
When ready, click Save. Any changes you make will take effect within five minutes. Note that after creating an XPath-based or header content message, you can use the ruling facility to refine the message's specification. This is fully described in 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:
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 7-7.
Table 7-7 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 7-27 appears.
Figure 7-27 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:
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 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:
An example of enhanced page delivery details is shown in Figure 7-30.
Figure 7-30 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 7-31.
Figure 7-31 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 Monitoring OAM 10g-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 "(no value)". For more information on the reporting of items with no value in RUEI, see Summary of Data Items.
Configuring an Application's User Identification Scheme
To configure an application's user identification scheme, do the following:
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 Working With Reports.
Example 7-15 National Language Support
See Working with National Language Support for a detailed discussion of the implications for identification when working with international character sets.
Newly created applications and services by default do not have localization sources configured. However, you can configure the application's localization (territory and language) sources in terms of URLs, cookies, request or response headers, XPath expressions, or custom tag or responses.
Configuring an Application's Localization Sources
To configure an application's localization sources, do the following:
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 7-34.
Figure 7-34 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 7-34. 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 7-35 allows you to control which type of pages are displayed in the structure overview.
The options shown in Table 7-8 are available.
Table 7-8 View Menu Options
Options | Description |
---|---|
All |
List all application pages. |
Report pages |
List only pages that have been specified as report filters (see Using Report Filters). |
Checked pages |
List only pages for which content checks have been defined (see Specifying Page Content Checks). |
Manually named pages |
List only pages that have been manually defined (see Manually Identifying Pages"). |
Key pages |
List only pages that have defined as key pages (see 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:
Information about each page detected for an application is available through the page Analysis window. An example is shown in Figure 7-37.
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 Specifying Page Content Checks.
Reporting: lists the reports in which this page appears. Reports are described in Working With Reports.
Monitoring: list the KPIs in which this page appears. See for more information about the procedure for defining KPIs.
Use the Key page check box in Figure 7-37 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.
Reporting Page Content Checks
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 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.
Defining Page Content Checks
To define a page content check, do the following:
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:
The URL diagnostics group (described in URL Diagnostics for Problem Analysis) 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 feature (see Introduction to Session Diagnostics), 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:
Example 7-16 Excluded URL Information
Note that forced objects (described in 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 Introduction to Session Diagnostics). JavaScript execution can be completely disabled, or you can specify that specific functions or files should be replaced during page replay.
Defining Execution Rules
To define the JavaScript execution rules that should be used when replaying an application's pages, do the following:
Example 7-17 Uploading Replacement Files
The replacement .js
file is uploaded to the /opt/ruei/gui/upload
directory on the Reporter system. Note that, if necessary, you can modify the contents of the replacement file by selecting the appropriate rule, and either uploading a modified version of the original file, or specifying a completely new file. In either case, the contents of the original file are overwritten with the newly uploaded file. When a rule is deleted, any file uploaded for it is automatically also deleted.
Be aware that, if an application contains multiple rules referring to the same file, only one version of the file is held on the Reporter file system, and this is always the latest version to be uploaded. The file is only removed from the file system when all rules that use it have also be been deleted.
Quite often the same JavaScript files are used across multiple applications. Be aware that each replacement file specified for an application represents a unique file. This is true even if the same file name is specified across multiple applications. For example, imagine that three applications, A, B, and C, all have the replacement file mychecks.js
specified for them. In this case, three versions of the mychecks.js
file are maintained by RUEI. Any changes made to one particular file only apply to its associated application, and not to any other applications.
If there is a load balance server with a hostname www.load-balancer.com
, and there are several real servers behind the load balance server with hostnames such as www.real-server-1.com
, www.real-server-2.com
, etc, in that case, requests first come into load balancers, and then they are distributed across real servers.
Assume that RUEI is deployed between load balance server and real servers, and you are not able to access real servers by its hostname. Also, there are no routes from real servers to public networks. In this scenario, all pages captured will have URLs like www.real-server-*.com/
.
If you have deployed RUEI to monitor the traffic between load balancer and web servers, FSR page may not display all the objects from replay storage page. This is because you do not have access to original URL and objects of the page being replayed. To solve this issue, define a Replay URL mapping for a successful page replay to make sure that RUEI displays all the objects correctly in FSR window.
For example:
When you replay http://www.real-server-1.com/1.html
page in FSR, there will be no route from public network to www.real-server-1.com
. RUEI rewrites the URL of such pages. You can define a Replay URL mapping rule http://www.real-server-*.com
into https://www.load-balance.com
.
Now, you can see that the page is replayed successfully including all the objects on the page. This is because load-balance.com
is visible in public network. This indicates a successful Replay URL mapping.
Such Replay URL mapping rules are based on applications. Each application has separate mapping rules.
To configure the replay URL mapping rules for an application, do the following:
Go to Configuration >Applications, and then select required application.
Figure 7-46 Replay URL Mapping tab
Figure 7-47 Add New Rule
Enter Source URL pattern and Target URL.
Click Save.
Note:
Source and destination URL must contain URL schemes like http, https, etc.
For the source URL, you can use wildcards in hostname string of the URL. However, you must not use wildcards in the target URL.
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 feature. An example is shown in Figure 7-48.
Figure 7-48 Action Incidence on Page Views
To define an action-naming scheme, do the following:
The Enriched data exchange facility enables you to combine the data gathered by RUEI with other data sources. See Enriched Data Export Facility for more information on using this feature.
Enriched data exchange can be enabled or disabled for individual applications by:
Select Configuration, then Applications, and select the application you want to modify.
Select the Advanced tab, and then the Enriched data exchange subtab.
Choose whether to enable or disable Enriched data exchange and KPI data exchange.
The Audit data is kept for recording modifications made to every application. The audit data shows the User name, IP address and time of the modification event. An example is shown in Figure 7-49
Figure 7-49 Audit Data Sample
The audit data can be checked by:
Select Configuration, then Applications, and select the application you want to check.
Select the Advanced tab, and then the Audit sub tab.
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 7-50 illustrates how application authentication works when enabled by an SSO server.
Figure 7-50 Authentication Flow Within SSO-Enabled Application Traffic
The authentication flow shown in Figure 7-50 takes the following sequence:
Finally, note the network lines over which steps 1, 2, and 5 pass must be within the scope of RUEI monitored traffic.
Example 7-18 SSO Profiles and Applications
It is important to understand that SSO profiles and applications, although closely related, are reported as separate entities within RUEI. For this reason, SSO profile and application definitions should be mutually exclusive. That is, each should be based on separate domains and cookies. Otherwise, the monitored traffic is reported as application-related traffic, and the potential benefits to enhanced reporting are not realized.
To define a SSO profile, do the following:
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 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 7-54 appears.
Figure 7-54 Edit SSO Profile Filter Dialog
The note at the bottom of the dialog indicates the current rule ordering scheme. This is explained in 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 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 7-55 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 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 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 feature. To configure an application or suite to detect service test traffic, do the following: