| Oracle® Real User Experience Insight Accelerator for Oracle E-Business Suite Guide Release 6.5.0 for Linux x86-64 Part Number E17193-02 |
|
|
View PDF |
| Oracle® Real User Experience Insight Accelerator for Oracle E-Business Suite Guide Release 6.5.0 for Linux x86-64 Part Number E17193-02 |
|
|
View PDF |
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
| Dimension level | Content |
|---|---|
|
Application/Name |
|
|
Application/Page group |
|
|
Application/Page name |
|
Where:
action_description is a description of the action corresponding to 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 windowTitle, title, docName, or shortDesc.
application-name is the name for the application corresponding to the APPLICATION_NAME column in the FND_APPLICATION_TL table.
app is the application short name corresponding to 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 '/pls/'.
form_action provides a description of the action, and the element on which the action was performed.
form_block is the name of a functional area within the form.
form_description is the of the form corresponding with the USER_FORM_NAME column in the FND_FORM_TL table.
form_name is the 8-character technical name.
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 assigned to a set of .jsp files.
jsp_name is the file name of a .jsp file.
n servlet_group is the group name assigned 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.pl script to retrieve information about the customizations:
APPLSYS.FND_FORM_FUNCTIONS
Function_id, application_id.
Function_id is used to fill the EBS_function_id2*.txt files.
APPLSYS.FND_FORM_FUNCTIONS
User_function_name.
APPLSYS.JDR_PATHS
Names and the tree structure.
Path_name is used to fill the EBS_pathname2*.txt files.
APPLSYS.FND_APPLICATION
Application short name.
Application_name is used to fill the EBS_appshort2*.txt files.
APPLSYS.FND_APPLICATION_TL
Application name
APPLSYS.FND_FORM
Form_name, application_id
Form_name is used to fill the EBS_formname2*.txt files.
APPLSYS.FND_FORM_TL
User-form-name.
APPLSYS.FND_RESPONSIBILITY
Responsibility keys
APPLSYS.FND_RESPONSIBILITY_TL
Responsibility descriptions
APPLSYS.JDR_ATTRIBUTES
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.
OA
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 within 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.
JTT
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 an 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).
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.
A detailed discussion of the OA framework is available at http://www-apps.us.oracle.com:1100/fwk/fwksite/510/devguide/ess/ess_state.htm.
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: OA.jsp, and RF.jsp.
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.
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.9, "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.pl 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, and 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 http://www-apps.us.oracle.com:1100/fwk/fwksite/510/devguide/ess/ess._jspprimer.htm.
The EBS-specific data items shown in Table 2-2 are reported by RUEI.
Table 2-2 EBS-Specific Data Items
| Item | Description |
|---|---|
| EBS suite/Code | The code of an EBS suite, as defined in its configuration definition. This data makes it possible to distinguish between different monitored EBS suites. |
| EBS suite/Name | The name of an EBS suite, as defined in its configuration definition. This data makes it possible to distinguish between different monitored EBS suites. |
| EBS framework/Name | 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). |
| EBS form name/ID | The ID of forms used. |
| EBS form name/Name | The form description of forms used. |
| EBS JSP filename/Filename | The name of JSP-based files used. For example, this could contain login-events or actions such as 'runforms'. |
| EBS responsibility/Key | The responsibility key 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 form name reports the form name within which the end user was browsing (using either Forms or the OA framework). |
| EBS responsibility/Name | The responsibility description 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 form name reports the form name within which the end user was browsing (using either Forms or the OA framework). |
| EBS module/ID | The ID of the EBS module within which the end user was navigating. |
| EBS module/Name | The EBS module name within which the end user was navigating. |
| EBS screen region/ID | The ID of the EBS region within which the end user was navigating. |
| EBS screen region/Name | The EBS region view within which the end user was navigating. |
|
Total dabase time |
The time (in milliseconds) required to execute the Forms-related querries on the database. |
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).
|
 Copyright © 2010, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
