Skip Headers
Oracle® Real User Experience Insight Accelerator for Oracle E-Business Suite Guide
Release 5.1 for Linux x86-64

Part Number E14896-02
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

2 Monitoring and Reporting Considerations

This chapter explains how information within EBS-based applications is captured and reported by RUEI. Information about specific mechanisms or characteristics to be aware of when monitoring EBS-based applications are also highlighted. It is recommended that you review this information to better understand the reporting of EBS applications within RUEI.

2.1 Hostnames and URL Prefixes

An EBS implementation, the EBS instance, can be identified with a hostname and, sometimes, a URL prefix. Generally, an EBS suite can be accessed in two ways: using only the hostname, or using the fully-qualified hostname (including the domain). Generally, you only need to specify the domain, without any specific URL prefix, and the application is accessed at the default location that is configured out-of-the-box.

Table 2-1 shows how an application's dimensions are reported in RUEI.

Table 2-1 EBS Suite Definitions mapping

Dimension level Content

application_name (suite_name)

Application. page-group » form_description » responsibility_description » jsp_group » jsp_name » servlet_group » servlet_name » DAD_location » form_name » form_block » form_action » responsibility_key » action_description » jsp_group » jsp_name » jsp_name » html_title » servlet_group » servlet_name » servlet_name » html_title » DAD_location » function_name


Figure 2-1 shows an example of how an EBS application is reported in RUEI.

Figure 2-1 Example of EBS Application Page-Group Reporting

Description of Figure 2-1 follows
Description of "Figure 2-1 Example of EBS Application Page-Group Reporting"

2.2 Database Tables

The following EBS database tables are used by the script to retrieve information about the customizations:

To make the retrieval easier, the select statements make use of the JDR_UTILS and JDR_MDS_INTERNAL packages.

2.3 Actions, Pages, and Objects

Each EBS framework needs to be analyzed to obtain the correct configuration in which all hits are classified as either object hits or action/page hits. Framework-specific considerations are described below.


The OA framework is built using the M-V-C model (Model-View-Controller). Only the controller is relevant to RUEI, because that is the part that will be seen from the HTTP level. The controller decides internally to either show a specific page, or to redirect the visitor to another location that builds up the page. The redirects are recognized automatically; this is normal RUEI functionality.

Based on the URL parameters, the page name is defined (in a redirect situation, the URL of the redirected URL should be used, not the original URL with parameters of the previous page). Besides the controller, the framework also contains some fixed URLs (that by-pass the controller, such as OALogout.jsp). These files are recognized together with the JTT-based files.


The JTT framework is built using the M-V-C model (Model-View-Controller). It differs from the OA framework definition in that there is not one controller for all applications, but one (or multiple) controllers per application. This means that more .jsp files are involved, and that requires a investigation of all .jsp files involved. A server-side analysis of the .jsp files makes it possible to determine the application definition (based on the location of the .jsp files).

2.4 Functional Errors

A default RUEI installation recognizes different types of errors. These are in the area of network and HTTP errors. In addition, there is also the facility to manually add functional errors (that is, as site errors). For the EBS frameworks, these content-based errors can be analyzed automatically. To enable this, the functionality described below is implemented.

Oracle Forms Errors

The errors that might occur during a Forms session can be caused by different layers:

2.5 OA Framework Page Name Deduction

A detailed discussion of the OA framework is available at

OA-based traffic is mapped to RUEI as follows:

Parameter Mapping

Note that the mapping is only possible when the EBS_*.txt files are populated with IDs that match the deployments that are being monitored. To obtain the correct configuration files, the script (described in Section 1.10, "Synchronizing RUEI With the EBS Production Environment") is used to retrieve the correct information from the deployment environment.

The script uses two methods to retrieve the relevant information:

2.6 Page Context

Not all actions relate to pages. Hence, this section explains how actions (such as HTTP requests) are reported as page views.

Each time a request is received for a page, the OA Framework creates an OAPageContext that persists until a new page finishes processing. Specifically, the OAPageBean, the primary force behind page processing, creates the OAPageContext.

Note that reporting within RUEI is based on the requests seen at the HTTP level. If the page changes within one request, the timings are reported against the original page.

2.6.1 Request and Page Boundaries

A Web application's unit of work is a request/response pair: the browser submits a request, the servlet processes the request, and returns a response. The transmission of a response signifies the end of a single request, or the "boundary" between the completed request and a new one. Similarly, when the OAPageBean finishes processing a page, this is the "boundary" between the current page and a new one.Hence, in the following scenario where a user navigates from Page X to Page A and then to Page B, we have two request boundaries: the first is between Page X and Page A, the second is between Page A and Page B. We also have two page boundaries in the same conceptual location between Page X and Page A, and Page A and Page B. This is shown in Figure 2-2.

Figure 2-2 Request and Page Boundaries the same

Description of Figure 2-2 follows
Description of "Figure 2-2 Request and Page Boundaries the same"

Different Request and Page Boundaries

However, in some situations, the request and page boundaries are not the same. Consider the following JSP Forward case:

  • The user navigates from Page X to Page A, as illustrated in Figure 2-2.

  • While on Page A, the user selects a control that the Page A code must evaluate before deciding which page to display in response. Therefore, the browser issues a request to Page A which the OA Framework processes (including creating an OAPageContext for the page). Once Page A finishes processing, we've reached the first page boundary as illustrated in Figure 2-3.

  • Within the Page A code, the developer evaluates which control the user selected, and issues a JSP Forward to Page B. Instead of providing an HTTP response at this point because we do not want to redisplay Page A, the OA Framework begins processing for Page B (including creating a new OAPageContext for this page). Once Page B finishes processing, we've reached the second page boundary.

  • Because Page B must now be displayed to the user, an HTTP response is sent to the browser. We've now reached the request boundary.

Figure 2-3 Different Request and Page Boundaries in the JSP Forward Case

Description of Figure 2-3 follows
Description of "Figure 2-3 Different Request and Page Boundaries in the JSP Forward Case"

Further information on how a generic JSP application is constructed is available at

2.7 Data Items

The EBS-specific data items shown in Table 2-2 are reported by RUEI.

Table 2-2 EBS-Specific Data Items

Item Description


The kind of forms used. The form ID and form description are reported.


The EBS framework used. For example, FORMS (Forms traffic), OA (Oracle Application framework), JTT (JTT framework), servlet (servlets), and other-traffic (only visible when the unclassified pages setting is checked; use page-URL to see the actual URL).


The name of JSP-based files used. For example, this could contain login-events or actions such as 'runforms'.


The EBS module within which the end user was navigating.


The responsibility that was used to access the area. This only applies to OA framework-related URLs, and a limited set of JTT files. In this case, EBS-formname reports the form name within which the end user was browsing (using either Forms or the OA framework).


The name of an EBS suite, as defined in its configuration definition. This data makes it possible to distinguish between different monitored EBS suites.

2.8 Resources

You may find the information sources useful: