|Oracle® Real User Experience Insight Accelerator for Oracle E-Business Suite Guide
Release 1.1 for Linux x86-64
Part Number E13494-06
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.
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
action_description is a description of the action corresponding with one of the following entries in the EBS database:
The USER_FUNCTION_NAME column in the FND_FORM_FUNCTIONS_TL table.
The ATT_VALUE column in the JDR_ATTRIBUTES table with the property
application-name is the name for the application corresponding with the APPLICATION_NAME column in the FND_APPLICATION_TL table.
app is the application short name corresponding with the APPLICATION_SHORT_NAME column in the FND_APPLICATION table.
DAD_location is the location of the pls DAD definition, the full directory, for path that starts with '
form_action is one of the following predefined actions:
COMMIT: in Forms, issuing a File > Save or Commit triggers a sequence of events that culminate in a database commit being requested. Each form in the current session is internally navigated, and then each block within those forms. Any inserts, updates, and deletes that are required are then sent to the database. Finally, a database commit is issued. The Forms server "Post & Commit" time will comprise the time for this complete operation.
QUERY: records the initial query execute and fetch time. Due to the nature of Forms-record buffering inside a block, no attempt is made to accumulate any subsequent fetches after the first fetch. Consequently, a form that fetches only the first 15 rows of a large query will record faster times than one which retrieves all the rows for a query. This is consistent with recording the end-user experience.
OPEN: can be used to have multiple forms open at the same time.
CALLFORM: can be used to call a new form while keeping the calling form active. When the called form is exited, the processing starts in the calling form from the point where call_form was initiated.
NEW FORM: exits the current form and enters the new form. If the calling form was called from a higher form, Forms keeps that higher form active.
RUNFORM: records the time taken from calling the forms servlet to actually having a form to work in. Due to the nature of forms initialization, it is unlikely that the start of this operation can be recorded. For most purposes, this time approximates to the time between the Forms server receiving the 'Runform' for an initial Form, and returning to the user for input, including any time spent in the database server.
All other actions within forms are reported as 'unidentified action'.
form_block is the name of a functional area within the form.
form_name is the of the form corresponding with the USER_FORM_NAME column in the FND_FORM_TL table.
function_name is the function name of the PLS call.
html_title is the title retrieved from the HTML send from the server back to the end user.
jsp_group is the group name given to a set of .
jsp_name is the file name of a .
n servlet_group is the group name given to a set of servlets.
n sevlet_name is the name of an individual servlet.
responsibility_key is the name of the responsibility corresponding with the RESPONSIBILITY_KEY in the FND_RESPONSIBILITY table.
suite_name is the user-defined name specified for the suite upon creation.
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
The following EBS database tables are used by the
create_EBS_info.sh script to retrieve information about the customizations:
Function_id is used to fill the
Names and the tree structure.
Path_name is used to fill the
Application short name.
Application_name is used to fill the
Form_name is used to fill the
To make the retrieval easier, the
select statements make use of the JDR_UTILS and JDR_MDS_INTERNAL packages.
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
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:
Network errors: are reported in the same way as RUEI does for all applications.
HTTP server errors (such as 500, 404, and so on) are reported in the same way as all applications are in RUEI.
Forms servlet errors (servlet connection errors) are reported with their corresponding
ifError code. These are internal communication errors that occur within the Forms framework.
Functional errors: these appear as pop-up windows to the end-user, and are created server-side. For normal applications, RUEI supports content scanning of these screens. Content scanning works only when Forms encryption is disabled and, optionally, SSL encryption is used.
FRM-99999: errors classified in the Forms interface with either of these IDs are also captured. They are reported as network or server errors within RUEI using default functionality.
A detailed discussion of the OA framework is available at
OA-based traffic is mapped to RUEI as follows:
The controller is used as a key indicator for the user-initiated actions. Hits closely related to the controller are assumed to be elements of that page. The OA framework has two controllers:
The naming of the page is based on the parameters send to the controller. The following parameters are taken into account: function_id, _rc, akRegionCode, OAFunc, page, and region. Pages that do not contain references to a (new) form or responsibility will preserve the form name or responsibility of previous pages.
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:
Analysis of local JSP files to obtain the names of all possible JSP files from the JTT environment. This is done through the execution of a
find statement in the $APPL_TOP directory.
A list of SQL statements in the
create_EBS_info.sh script to retrieve the functional names of the OA framework from the database. These are described in the following section.
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.
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
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
Further information on how a generic JSP application is constructed is available at
You may find the information sources useful:
Configuring HTTP Server to use SSL in Oracle applications (note 341904.1).
Oracle Forms Service 10g: configuring transport layer security with SSL (white paper)
Oracle Application Server Forms Services Deployment Guide 10g Release 2 (10.1.2), 5.11 Oracle Forms Services and SSL
How to enable SSL for JPI clients (Sun plug-in) (note 307429.1).