N Oracle Forms and Oracle E-Business Suite Support

This appendix provides a detailed discussion of the support available for the accurate monitoring of Oracle E-Business Suite (EBS) and Oracle Forms based applications. For more information, contact your Oracle representative.

Verifying the Scope of Monitoring

Often the EBS software is configured to use a non-standard port, such as 8000. The port on which your EBS installation is running can be found by examining the login URL. This takes the following format:

https(s)://hostname:portnumber/OA_HTML/AppsLogin

Verify that the portnumber is configured as one of the defined ports (these are described below). In addition, if a HTTPS port is specified, ensure that a copy of the web server's private SSL key is imported into the Collector system. To verify the port number, follow the procedure described in Managing the Scope of Network Based Monitoring.

Creating EBS Suite Definitions

You can create suite definitions for EBS-based applications in the same way as for any other supported Oracle Enterprise architecture. The procedure to create suites is described in Working With Suites.

Note that for EBS suites that make use of Forms, select the Advanced section, and click the Forms tab. The suite overview changes to that shown in Figure N-1 appears.

Figure N-1 Advanced Suite Configuration Section

Description of Figure N-1 follows
Description of "Figure N-1 Advanced Suite Configuration Section"

The use of these settings is explained in the following section.

Enabling APM integration

In case you have a APM service configured in the Oracle Cloud Infrastructure, use the instructions below to configure RUEI to send Forms details. For more information about Tracing for Oracle EBS in APM, see Configure Tracing for Oracle E-Business Suite.

Pre-requisites are:

  • The EBS suite name as configured in RUEI
  • The complete APM data upload URL including the private data key

Run the following commands as the RUEI_USER user:

$ execsql config_set_match_http_api "<EBS suite name>" apm "<APM data upload URL>"
$ execsql config_set_match_http_api_filter "<EBS suite name>" apm EBS_FRAMEWORK == form-based

Specifying the Tracking Technology

Within RUEI, session information is based on cookies. The cookies are used to connect hits to a specific visit. In general, the cookie is also connected to the user login page which allows RUEI to include a user name to all subsequent hits with the same cookie.

Session Tracking, Correlation Variable, and Session URL argument

The tracking mechanisms that should be specified for the Correlation variable and Session URL argument are best determined through a number of flow charts.

Forms Session Parameter

The forms URL should be examined for an argument that provides a unique value for each Forms session. Typically, this argument is located after a semicolon or question mark character in the URL. For example, jsessionid or JServSessionIdforms. Note that if the specified parameter is not found in the URL, then the cookie is searched for it.

Correlation Variable

The Correlation variable allows the sessions to be merged into one end-user session.

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.

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).

Functional Errors

A default RUEI installation recognizes different types of errors, see Defining Translations for Content Messages. These are in the area of network and HTTP errors. In addition, predefined content messages are automatically provided for all standard FRM and message dictionary items (that is, messages with the prefix "APP_"). By default, only messages of type "Error" are reported as errors; all other message types (such as "Note" and "Hint") are reported as notifications. In the case of Oracle Forms traffic, the content messages specified are searched inside all readable text strings within individual forms element exchanges.

For operational reasons, message IDs (such as APP-FND-01702) are normalized (that is, leading zeros are ignored). This should taken into consideration when performing string comparisons.

Causes of 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.

Forms Name Reporting

By default, reported Forms names are derived from the Forms window tile based on the mapping uploaded through the configuration script. However, if the environment variable FORMS_RUEI_SEND_FORM_NAME is set, the Forms server will send the Forms module name along with the window creation message. By default, environment information is set in the default.env file. You can use another file name, but this must be specified in the formsweb.cfg file. This makes it possible to distinguish multiple Forms names within traffic that has identical window titles.

OA Framework Page Name Deduction

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.

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.

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.

Data Items

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

Table N-1 EBS-Specific Data Items

Item Description

Database Time per Page (ms)

Database time per page. This is only available if Chronos or End User Monitoring is enabled.

Total Database Time (ms)

Total Database Time

EBS Action

Description of the action executed by the user (depends on framework how this is determined

EBS Component

Description of the active component (if it can be determined in this framework)

EBS Form Hierarchy

The component hierarchy of the element that was active inside Oracle Forms protocol during measured activity

EBS Form Message

The information related to specific programmed messages indicating start/end Oracle Forms messages

EBS Form Name

The name of the Oracle form related to the activity

EBS Form Name Description

The description of the Oracle Form Name that was active

EBS Framework

The EBS framework used. For example, FORMS (Oracle 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 JSP Filename

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

EBS Java Class

The class name of the component that was active for user activity

EBS Module

The EBS module within which the end user was navigating

EBS Module Code

The EBS Module within which the end user was navigating

EBS Responsibility

The responsibility that was active during activity

EBS Responsibility ID

The id for the responsibility that was active during activity

EBS User Input

The literal text that was entered by user during activity in cases where it could be identified.

Known Limitations

Currently, RUEI does not work with all EBS functionality. In particular, the following known limitations exist:

  • The Forms framework includes functionality to create reports. This functionality is highly configurable by customers. As a result, it is not possible to track reports automatically. In addition, there is no useful translation table with a relevant business-oriented name for the reports. The only solution would to rewrite the known report URLs to correct report names based on a translation file.

    An additional side note on this issue is that some customers are using the 'jobs' functionality to create reports. This is an insecure way to do this, because the next and previous numbers can easily be guessed, and allows users to see reports they may not be authorized to view. Because of the randomness of the name (only a number), it is not useful to report on these type of reports when they are used.

    As a result of the issues described above, Forms reports are not monitored.

  • Reporting is based on the last activated area. Hence, when an end-user is browsing simultaneously in multiple browser windows, the reported page name might contain incorrect information.

  • Currently, only applications based on the OA and JTT frameworks are supported. Therefore, such packages as Oracle Applications Manager (OAM) and Oracle Portal are not supported at this time.

  • Applications that make use of a Rich Internet Application (RIA) framework (such as Ajax) may have reduced replay capability. This is particularly seen in the case of Oracle Forms-based applications.

Troubleshooting EBS Applications

This section highlights the most common problems encountered when monitoring EBS applications. The information in this section should be reviewed before contacting Customer Support.

Network Traffic Does Not Appear to be Measured

In the event that expected network traffic does not appear to be reported, it is recommended that you review the following points:

  • RUEI can monitor EBS applications based on the OA, JTT, PLS, Oracle Forms, and servlet frameworks. Generally, suites are configured to run on a specific port which differs per installation. These also need to be specified in RUEI. Select Configuration, then Security, and then Protocols. Review the defined port settings, and ensure they meet the requirements of your EBS applications.

  • Be aware that there is no suitable out-of-the-box cookie available for session tracking in EBS. Therefore, a cookie needs to be created on the login page. This should cover the complete application. By default, the Jession cookie only covers the application links, and not the images, CGIs, and libraries. While the oracle.uix cookie does cover all hits, it is not unique for each visitor.

A Large Number of Unidentified Actions are Reported

If a large portion of the reported traffic contains unidentified actions, this indicates that Forms tracking is not functioning correctly. You should consider the following:

  • If you do not see such things as "Status Bar" and "Textfield", this indicates that some specific characteristic in the monitored traffic is not being captured. In this case, you should contact Customer Support.

  • Verify that the server ports are correctly configured, as described in Verifying the Scope of Monitoring. In particular, it must be configured as the Forms servlet mode port, not the regular HTTP port.

Configuring user-id Recognition in a Forms Only Environment

Because the forms protocol does not equal the normal http traffic, to which RUEI is native, configuring the user-id source for a forms only environment requires some additional knowledge. This section describes how to configure the user-id in such an environment.

Two types of sources can be used and these should be configured as a client request:

  • Oracle Forms Client Element

    This refers to a value in a forms element directed to by the hierarchical structure of the forms.

  • Oracle Forms Client Property

    A uniquely named property that contains the user-id.