As explained earlier, page identification within RUEI is based on applications. However, if these applications are based on certain Oracle Enterprise architectures (such as Oracle E-Business Suite, Siebel, and WebLogic Portal), then a fourth level, suite, is introduced. A suite is essentially a collection of applications, and web pages associated with these suites have the structure suite » application » group » page.
Important
If you are using any of the currently supported Oracle Enterprise architectures within your monitored environment, it is recommended that you make use of this facility. It not only saves you time in defining your applications, and makes applications within suites more compatible, but also ensures that these architectures are monitored correctly.
To define a suite instance, do the following:
By default, suites are defined to use network based data collection. For WebCenter Sites only, it is possible to use tag based data collection. You can enable this on the suite definition screen as shown in Figure 10-4.
If you enable tag based data collection, you must define an Browser JS Library as described in Defining Browser JS Library Settings. For more information on setting up tag and network based monitoring, see Installing the RUEI Software in the RUEI Installation Guide.
It is recommended that you run the appropriate script supplied for use when monitoring traffic that is based on certain Oracle architecture production environments. For example, the create_EBS_info.pl
script. This is in order determine how these architectures have been implemented within your environment. In particular, the page-naming scheme. Do the following:
Note:
This configuration file must be uploaded for each required suite instance. It may only contain known (and non-empty) .txt
files. All these files must be in the root directory. That is, subdirectories are not permitted. It is important you upload the correct configuration file for the required suite instance, and that it is based on the actual production environment. If you make any changes to the monitored application(s), you need to re-run the script, and re-import the generated .zip
file.The result of importing an erroneous configuration file is incorrect reporting.
As explained earlier, a suite is essentially a collection of applications. Once you have defined your suites, you can modify its associated properties in the same way as described for applications in Defining Applications.
You should pay particular to the following points:
The suite instance's Enterprise name must be correctly specified for clickout functionality to be available for the suite (see Configuring Clickouts to External Tools). It can be obtained from the suite's configuration within EMGC. For example, ec2ebs2-Oracle E-Business Suite
or siebel_emgc-amp11.oracle.com
.
A number of default suite-specific functional errors are defined. You should review these to reflect the requirements of your environment. The procedure is the same as described in Trapping Application Content Messages.
By default, unclassified pages are not reported. You can modify this through the Report unclassified pages check box. The procedure is the same as described in Reporting Unclassified Pages.
You can use the Report service test traffic check box to specify whether service test traffic configured within Oracle Enterprise Manager for the selected suite should be reported within RUEI. By default, reporting is disabled. For further information on the use of this facility, see Reporting Service Test Traffic. Monitored service tests can also be converted into RUEI user flows. This is fully described in Converting Service Test Sessions into User Flows.
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 header. This is fully explained in Monitoring NATed Traffic.
A default user identification scheme is defined for each suite. You should review this to reflect the requirements of your environment. The procedure is the same as described in Defining User Identification.
The suite diagnostics groups (described in Suite URL Diagnostics for Problem Analysis) allow you to view the functional URLs reported for hits within suites. The use of this facility is equivalent to that for applications (described in Controlling Reporting Within the Problem Analysis Group).
In addition to identifying pages through suites, you can also define pages manually. The procedure is the same as described in Manually Identifying Pages. However, you cannot define a new page from scratch. You must use an existing page as the basis for a new page.
To ensure the quality of the data being collected and reported by RUEI for your Oracle Enterprise architecture-based applications, it is recommended you verify their reported details. You should pay particular attention to the number of associated pages detected for the defined suite(s).
Select Browse data, then select the All pages group, and then the Applications sub-group. Within the individual dimensions, such as Page views and hits, you can see page views are reported for several applications. The suite name in the definition is shown between brackets. The example shown in Figure 10-6 is for a WLP streaming portal.
As explained earlier in Working With Suites, RUEI provides dedicated support for the monitoring of certain Oracle Enterprise architectures (such as Siebel and Oracle E-Business Suite). This support is made possible because each of these architectures is based upon a standard underlying framework. However, when an application has been developed using a customized version of the architecture's framework, RUEI needs information about the modifications made in order to accurately monitor and report its network traffic. This is also the case when an architecture framework has been used as a wrapper to a legacy application. Application developers can use the Framework exception facility to specify the exceptions that should be made to RUEI's standard architecture reporting scheme. This facility is also available for use with non-suite applications.
If you have modified your application's underlying framework to include customized pages, it is recommended that you use the Framework exception facility, rather than manual page definitions (described in Manually Identifying Pages), to ensure that these pages are correctly identified.
Application URL patterns
Typically, an application is identified by its domain. For example, myshop.com
. A possible home page is shown in Figure 10-7.
Figure 10-7 Example Application Home Page
Each of its discrete functional parts is identified by a URL pattern. For example:
myshop.com/catalog
: contains a facility for customers to browse and order items from an online catalog of available items. This is based on a standard framework implementation.
myshop.com/user/preferences
: contains a facility where customers can modify the web site's appearance to reflect their personal preferences. For example, national language, units of measurements, and currency. This is based on a customized framework implementation.
myshop.com/shop/checkout
: contains a facility where customers can confirm their orders and arrange payment. This is based on a customized billing implementation.
In this case, information about the customizations made to the user/preferences
and shop/checkout
parts of the application needs to be provided in order to ensure correct reporting. The catalog
part is based on a standard framework and, therefore, does not require further information to be specified.
Specifying Framework Exceptions
To define the framework exceptions that should be used for an application, do the following:
Select Configuration, then Applications, and then Framework exceptions. Click the New framework exception item. The dialog shown in Figure 10-8 appears.
Figure 10-8 Add Framework Exception Dialog
Specify a unique name for the framework exception. Select "Generic" if the framework exception applies to all application definitions, or "Suites" if it only applies to a specific Oracle Enterprise architecture. In the case of the latter, you will need to specify the architecture. Suites only appear in the Suites type menu if at least one suite instance of it has been defined. Optionally, specify a brief description. It is recommended that it includes an indication of the purpose and scope of the defined exceptions.
Click Save.
Click the newly created framework exception. An overview similar to the one shown in Figure 10-9 appears.
Click Identification tab, and then the Add new URL pattern item. This specifies the scope of the framework exception. Enter one or more patterns, to reflect the structure of your application. The patterns must start with either a slash ("/"), or a wildcard ("*"), otherwise they will not match any URL. Use wildcards as appropriate to include all sub-directories of a given URL pattern, or to specify only a given sub-directory regardless of the path leading to that directory. For instance, */preferences
/* will match any path that contains preferences, including deeper paths, such as:.
www.myshop.com/preferences
www.myshop.com/user/preferences
www.myshop.com/another/location/preferences/subdir/subdir/
However, that a path without any wild cards will only match the exact URL, e.g. /shop/checkout
will not match /shop/checkout/payments/
.
Also, URL arguments in a path are not take into consideration, so the same path with or without URL arguments is seen as identical.
In the Page/object conditions tab, click Add new condition item. The dialog shown in Figure 10-10 appears.
Figure 10-10 Add Hit Type Condition Dialog
Use the Hit type menu to specify how detected hits should be treated. The available options are shown in Table 10-1.
Table 10-1 Hit Type Options
Hit type | Page name(1) | Loading time(2) | Content error(3) | Preview(4) |
---|---|---|---|---|
Page |
X |
X |
X |
X |
Object |
- |
X |
- |
- |
Redirect |
- |
X |
- |
- |
Heartbeat |
- |
- |
- |
- |
Footnote 1 The reported page name is derived from the hit.
Footnote 2 Hit taken into account when determining page-load time.
Footnote 3 Hit is scanned for content errors.
Footnote 4 Used for previewing in the Session Diagnostics feature.
Specify the events that must be met for the exception to be applied. 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. If the required value is not available within the Value menu, you can click the Search icon beside it to locate it.
Optionally, 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. Click Add. While only one defined condition needs to be achieved in order for the exception to be applied, all events within a condition must be met for it to be considered achieved. Click Save. You are returned to the dialog shown in Figure 10-9.
Click the Dimensions definitions tab. A list of dimensions specific to the selected application type is displayed. An example is shown in Figure 10-11.
Figure 10-11 Dimension Definitions Section
Click the dimension whose default source you want to modify. Use the Source type and Source value fields to specify how the selected dimension's reported values should be derived, see Figure 10-12.
Optionally, you can use the Replace value field to specify a transformation that should be applied to the retrieved value. The available options are explained in Table 10-2. Click Save.
Table 10-2 Identification Options
Option | Description |
---|---|
URL argument |
The dimension value should be derived from a specified URL argument. |
XPath in request |
The dimension value should be derived from an XPath expression applied to the request. |
XPath in JSON request |
The dimension value should be derived from an XPath expression applied to the JSON request. |
Header in request |
The dimension value should be derived from a specified request header. |
XPath in response |
The dimension value should be derived from an XPath expression applied to the response. |
XPath in JSON response |
The dimension value should be derived from an XPath expression applied to the JSON response. |
Header in response |
The dimension value should be derived from a specified response header. |
Cookie |
The dimension value should be derived from a specified cookie element. |
Custom tag |
The dimension value should be derived from a specified custom tag. |
Custom function |
The dimension value should be derived from a specified custom function. Only the first parameter is used, and it must be enclosed in single or double quotes. For example: wiViewState("wi_menu_main_menu"); |
Literal value |
The dimension value should be set to a specified literal value. |
HTML title |
The dimension value should be derived from the text found within the page's <title> tag |
URL |
The dimension value should be derived from the complete domain and URL as it appears in the visitor browser location bar. |
URL base |
The dimension value should be derived from the main directory and file name (without the file extension) parts of the URL. |
URL directory |
The dimension value should be derived from the directory part of the URL. |
URL full |
The dimension value should be derived from the main directory, the file name (without the file extension), and the configured arguments within the URL. |
Once created, you can use the ruling facility to specify additional matching rules that should be used to refine the newly created definition. This is described in Using the Ruling Facility.
By default, the order in which individual URL patterns are evaluated is the order in which they were defined in the system. In other words, each new URL pattern that you define would be placed at the bottom of the pattern evaluation chain. During processing, RUEI will try to match an URL against the available patterns in that sequence.
There are cases in which you might need to change the evaluation priority of one or more URL patterns. For example, if a pattern contains a high level of detail so that it narrowly identifies a specific URL, e.g. /shop/checkout/payment-failed.jsp
, it would need to be evaluated before a more generic expression, such as /shop/*
.
RUEI provides you with the facility to manage the evaluation priority of the URL patterns. In the framework exceptions overview screen, click the "Edit framework exception priority" button in the toolbar.
The following dialog appears:
Figure 10-14 Framework Exception Priority Window
This dialog presents an overview of all framework exception URL patterns, in the order in which they will be evaluated (patterns at the top of the chain will be evaluated before patterns at the bottom).
The first column contains the URL pattern. The second shows the framework exception for which this pattern was defined. The third column identifies the type of the framework exception (this is the type specified during the creation of the framework exception). The fourth column shows whether the framework exception is currently enabled. (Note that URL patterns for disabled framework exceptions will be skipped during URL matching, regardless of their position in the matching priority chain.)
The final column contains the controls that let you move patterns up and down the chain. Clicking on an "Up" arrow will move the current URL pattern up by one row thereby increasing its matching priority. Clicking on the "Down" arrow will move the current URL pattern down by one row, decreasing its matching priority. Note that changes become effective immediately.
Click the "Close" button when you are done.
It is recommended that framework exceptions 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 exceptions 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 exception rules. 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.
This facility is particularly useful when deploying an application across multiple environments. For example, when providing an Extranet-based application for use by your business partners.
Note:
The generated framework exception files are in a proprietary format, and must not be modified in any way.
Downloading Framework Exception Definitions
To download a defined framework exception, do the following:
Example 10-1 Uploading Framework Exception Definitions
When you upload a framework exception definition, any URL patterns contained within the definition are added to the end of the evaluation priority chain. Therefore you are strongly advised to review the URL pattern evaluation priority after uploading a definition. If the framework exception definition already exists, the URL patterns are replaced with the URL patterns in the upload.
Note:
Any URL patterns that were added or changed after the framework exception was originally downloaded are deleted if that framework exception definition is uploaded.
For all replaced patterns, both the pattern matching priority, and the counter indicating when they were last used, is reset. Therefore replacing patterns can be used as a technique to reset the reported last-used information.
Remember to review and adjust the URL pattern matching priority after each upload.
The emergence of web services has become one of the most important advances in the technology industry. Organizations are increasingly integrating enterprise applications to exchange information such as purchase orders, inventory levels, shipment notices, and interbank transactions, to name but a few.
Understanding Web Services
It is important to distinguish this new breed of web services from traditional ones. Generally, a web service was any service available over the web (such as search engines, language translators, weather guides, maps, and so on). However, these types of web services required some human intervention.
A web service is defined by the W3CFoot 5 as "a software system designed to support interoperable machine-to-machine interaction over a network". It implements a clearly defined business function that operates independently of the state of any other service. It has a well-defined contract with the consumer of the service. Services are loosely coupled - a service does not need to know the technical details of another service in order to work with it - and all interaction takes place through the interfaces. Using this technology, the service provider simply exposes a service on the web, publishes the interface and service naming specifications, and waits for a connection.
Services are made available through service descriptions. They describe how to call the service, and what information is required to request the service and get a response. The data exchange takes a request-response pattern. RUEI primarily supports the monitoring of XML-SOAP and similar messages.
Creating Web Service Definitions
To define a web service, do the following:
Example 10-2 Refining Your Service Definitions
Once you have defined your service, you can modify its associated function scheme. Within the Identification section, you can click Add new filter to specify additional filters for the functions that should be associated with the service. A function will be assigned to a service when one of the defined filters is matched. You can also modify an existing filter definition by clicking it. In each case, you can select from the same filters as shown in Figure 10-16. The service overview is updated to reflect your additions or modifications.
Example 10-3 Client Identification
The procedure for defining the client ID identification scheme is identical to that for applications and suites, and is described in Defining User Identification.
Example 10-4 Specifying the IP Address Source
When reporting on user visits, the client IP address is, by default, fetched from the TCP packet. However, when the RUEI system is placed in front of a NAT device, it may be more useful for the client IP address to be obtained from a specific header. The Client IP source check box within the Advanced section (shown in Figure 10-16) allows you to specify the required scheme. This is explained in Monitoring NATed Traffic.
By default, function calls that have been identified as belonging to a service through its URL definition, but for which no classified name has been found, are discarded and not reported. However, if you want these unclassified calls to be reported, use the Report unclassified calls check box within the Functions section.
Because hits not identified as belonging to the service are identified as unclassified calls, incorrect or insufficiently defined function calls will be identified as unclassified. Unclassified calls are reported in the relevant Data Browser group under the category "Other".
In order to assess a function's responsiveness, RUEI assigns a satisfaction level for each function call. This is equivalent to the page-loading thresholds described in Specifying Page Loading Satisfaction.
The procedure for detecting strings associated with functions is equivalent to that for applications, and is described Trapping Application Content Messages.
The procedure for locating function calls for web services is equivalent to locating pages for applications, and is described in Locating Page Details.
Footnote Legend
Footnote 5:The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web.