The monitoring support provided by RUEI has been verified against EBS R12. However, form names will be “incorrect" for older Forms versions (releases prior to 11.2).

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.

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 has the following benefits:

• It is possible to distinguish multiple Forms names within traffic that has identical window titles.

• The creation of additional Forms does not require the re-running of the configuration script.

Apply the correct patch from the following table to extend your Oracle Forms environment to support sending of technical form names.

Oracle Forms Support

Oracle Forms can be configured in two modes: servlet and socket. In servlet mode, a Java servlet (called the Forms Listener servlet) manages the communication between the Forms Java client and the OracleAS Forms services. In socket mode, the desktop clients access the Forms server directly. RUEI supports both servlet and socket mode. A detailed description of the operation and configuration of Oracle Forms in servlet and socket mode is available at the following location:

http://metalink.oracle.com/metalink/plsql/ml2_documents.showNOT?p_id=384241.1

See Checking Socket and Servlet Mode for information about verifying the mode in which Oracle Forms is configured.

Forms Only Customers

The information provided in this guide is relevant to all EBS customers. However, where information is specific to EBS or Forms-only customers, this is highlighted.

Customers working within a Forms-only environment should pay particular attention to the issues highlighted in this section.

In order for RUEI to accurately report on EBS-based applications, it needs information about your production environment. In particular, it needs to map functional areas to reported names. As explained in Synchronizing RUEI With the EBS Production Environment, this is done through running the create_EBS_info.pl Perl script. Customers within Forms-only environments are also recommended to run this script and upload the generated .txt files within a .zip file.

Manually Creating Functional Mappings

The create_EBS_info.pl script uses a number of EBS database tables to retrieve information about the installation and configuration of your Oracle Forms instance. The exact database tables used are described in Database Tables.

However, the APPLSYS.FND_APPLICATION, APPLSYS.FND_APPLICATION_TL, APPLSYS.FND_FORM, APPLSYS.FND_FORM_TL and other tables used by the script do not exist in a Forms-only environment. Therefore, you can either rely on the default (template) mappings provided with RUEI (described later in this section), or you can specify the required mappings by creating the associated .txt files manually.

When creating these files manually, the following tab-separated files are required:

• EBS_formname2details.txt: specifies a functional description for each form. Each line in the file should have the following format:

  formname{TAB}form_description
  

  For example:

  ADSAPCRD        Credit Card Expense Transaction Entry
  ADSAPPRC        Procurement Card Transaction Entry
  ADSCONC         Running Jobs
  ADSCONC         Tax Locations
  ADSCSCRC        Healthcare CC
  ADSMAILI        Mail InformationADSRSETUP       ADS Repurpose Setup
  ADSSOE          Custom Order EntryADSSOE          View Person Life Event Information
  AKDAPREG        Application Module Parameters Registry
  

• EBS_formname2appshort.txt: specifies the short (3-letter) version of the application name of which each form is part. Each line in the file should have the following format:

  formname{TAB}short_application_name
  

  For example:

  ADSAPCRD        ads
  ADSAPPRC        ads
  ADSCONC         ads
  ADSCSCRC        ads
  ADSMAILI        ads
  ADSRSETUP       ads
  ADSSOE          ads
  AKDAPREG        ak
  AKDATTRS        ak
  AKDFLOWB        ak
  

• EBS_appsort2appname.txt: specifies the mapping between the short (3-letter) application name and the full application name. It has the following format:

  short_application_name{TAB}application_name
  

  For example:

  abm     Activity Based Management (Obsolete)
  ad      Applications DBA
  ads     Applications Demonstration Services
  ads_dev ADS Development
  ahl     Complex Maintenance Repair and Overhaul
  ahm     Hosting Manager(Obsolete)
  ak      Common Modules-AK
  alr     Alert
  ame     Approvals Management
  amf     Fulfillment Services (Obsolete)
  

Be aware that the created configuration files must be uploaded for each required suite in a .zip file. This may only contain non-empty .txt files. In addition, all files must be in the root directory. That is, subdirectories are not permitted. It is important that you upload the correct configuration file for the required suite, and that it is based on the actual production environment. The procedure to update the configuration file is described in Synchronizing RUEI With the EBS Production Environment.

Relying on the Default (Template) Mapping

If manually creating the required mappings is not practical, you can simply rely on the default (template) mappings already configured within RUEI. While this approach provides an adequate level of reporting, it is subject to the following restrictions:

• form_name: normally this would be the 8-character technical name translated to a functional description. However, because this is not available, the 8-character technical name is reported instead.

• app: normally this would be derived from the mapping file that connects the form name with the application. However, because this is not available, the first three letters of the form name are reported instead.

• application_name: normally this would be derived from the mapping file. However, because this is not available, the app is reported instead.

Keeping Matching Information up-to-Date

Because Forms-only environments typically change over time, it is strongly recommended that you regularly review your mapping information. Be aware that the above restrictions will also apply to any forms that have been added to your environment since your last ran the create_EBS_info.pl script or manually created the mapping files.

Memory Requirements for Forms-Based Environments

Be aware that the monitoring of Forms-based traffic requires significant amounts of memory. For example, the monitoring of 10,000 simultaneous Forms sessions would require approximately 10 GB of Collector memory. Therefore, it is recommended that you deploy the Collector monitoring Forms-based traffic as a remote Collector with at least 16 GB of RAM. Alternatively, if you are using a single-server deployment, the server should have at least 32 GB of RAM.

In addition, it is recommended that you review the level of system memory available to the Collector. For a single-server deployment with 24 GB of RAM, this should be set to 50%, while for a server with 32 GB of RAM, this should be set to 40%. Information about how to increase the amount of available Collector memory is available at the following location:

https://support.oracle.com/CSP/ui/flash.html#tab=KBHome%28page=KBHome&id=%28%29%29,%28page=KBNavigator&id=%28from=BOOKMARK&bmDocType=PROBLEM&bmDocTitle=Remote%20Collector%20not%20able%20to%20run%20due%20to%20memory%20restrictions&bmDocDsrc=KB&bmDocID=762361.1&viewingMode=1143%29%29

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. See Checking Socket and Servlet Mode for information about how to identify the mode and port number. To verify the port number, follow the procedure described in Managing the Scope of Network Based Monitoring.

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 Advanced Suite Configuration Section"

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

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.

The Forms socket mode setting enables you to prevent active socket-mode sessions being discarded by the Collector after they have been inactive for a few minutes. Note this setting is only relevant for Forms socket mode. It is set to 10 minutes by default.

In order for RUEI to understand how the EBS frameworks are implemented within your environment, do the following:

This section presents a description of how to check whether the Oracle Forms server is running in servlet or socket mode.

Oracle Applications Release 12

Note Oracle Application Release 12 is, by default, configured to run in servlet mode.

Use the following command:

$ grep connectMode FORMS_WEB_CONFIG_FILE

The current connection mode is reported:

connectMode=servlet

Alternatively, use the following command:

$ grep frmConnectMode CONTEXT_FILE

The current connection mode is reported:

<forms_connect oa_var="s_frmConnectMode">servlet</forms_conr....

Oracle Applications Release 11

Note Oracle Application Release 11 is, by default, configured to run in socket mode.

Use the following command:

$ grep connectMode FORMS60_WEB_CONFIG_FILE

The current connection mode is reported:

connectMode=socket

Use the following command:

$ grep xsport FORMS60_WEB_CONFIG_FILE

The required port number is required:

xsport=9095

Alternatively, use the following command:

$ grep socket CONTEXT_FILE

The current connection mode is reported:

<forms_connect oa_var="s_frmConnectMode">socket</forms_conr....

Checking the HTML Source

Finally, you can also check the HTML source of the page used to launch the Oracle Forms application. To do so within Internet Explorer, select View, and then Source. This contains the connection mode, as shown in Figure N-4.

Figure N-4 Example Launch Page Details

Description of "Figure N-4 Example Launch Page Details"

The relevant connection mode information is highlighted.

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.

In forms socket mode, the server-ip must be specified. In the case of multiple servers, each server-ip/port combination needs to be specified for the forms socket mode to work correctly.

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

• APPLSYS.FND_NEW_MESSAGES

  The MESSAGE_NUMBER, MESSAGE_TEXT, and TYPE columns are used to populate the EBS_msgid2details.txt file.

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

If you have created customizations to the message dictionary, it is recommended that you run the create_EBS_info.pl script to merge them into your RUEI installation.

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.

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 has the following benefits:

• It is possible to distinguish multiple Forms names within traffic that has identical window titles.

• The creation of additional Forms does not require the re-running of the configuration script (described in Synchronizing RUEI With the EBS Production Environment).

Oracle Forms 11g Release 2 (and above) supports the use of the MESSAGE built-in. This allows for the inclusion of customized strings into a form. This particularly useful for debugging purposes. For RUEI-monitored traffic, two constants are available within the user_response parameter of the MESSAGE build-in. They are RUEI_BEGIN and RUEI_END. For example:

MESSAGE('my message1', RUEI_BEGIN);
...
...
MESSAGE('my message1' RUEI_END);

When the Forms server processes the MESSAGE built-in, it sends a message so that RUEI can note the information contained in the note. This information is visible within Session Diagnostics (see Working With the Session Diagnostics Feature). Note that the message will not be displayed on the client.

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

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.

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

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

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.

End User Monitoring is Forms functionality that triggers additional information messages to be sent by the applet to the Web server. RUEI uses these messages to record database time and the related KPI. If you do not need this KPI, you may skip this section.

End User Monitoring functionality was introduced in Forms 6i as Chronos messaging. This functionality is not available in Oracle Forms 9.0.4. In release 10.1.2 and higher, this functionality is called End User Monitoring.

Depending on the Oracle Forms version you are using, follow the procedure described in the relevant section below. If you are not using Oracle Forms, the rest of this section can be skipped.

Enabling End User Monitoring (for Oracle Forms Version 10.1.2 and Higher)

The following steps are required to activate End User Monitoring for release 10.1.2 and higher.

1. Configure the $ORACLE_HOME/forms/server/formsweb.cfg file to enable monitoring of specific applications. Set the following:

   			EndUserMonitoringEnabled=true
   			EndUserMonitoringURL=http://EBS-hostname:EBS-portnumber/oracle_smp_chronos/oracle_smp_chronos_sdk.gif

2. Restart the Forms server to activate the changes. The changes will only become available for new sessions.

Additional information can be found in the Oracle Application Server Forms Services Deployment Guide 10g Release 2 (10.1.2). This is available at http://download.oracle.com/docs/cd/B25527_01/doc/frs/forms/B14032_02/chronos.htm#sthref606. The webcache functionality mentioned in that guide is not required for the correct working of RUEI. The URL mentioned in the guide is incorrect, and is clarified in later release notes.

Enabling Chronos Monitoring (for Oracle Forms Version 6i)

For Forms release 6i, Chronos monitoring should be used as an alternative to the procedure described above. To enable Chronos monitoring, do the following:

1. Ensure that the patch 7130248 for release 6.0.8.28.0 is installed on the Oracle Forms system.

2. Configure the $ORACLE_HOME/forms/server/formsweb.cfg file by adding the following lines:

   	ChronosEnabled=true
   	ChronosURL=http://EBS-hostname:EBS-portnumber/oracle_smp_chronos/oracle_smp_chronos_sdk.gif

Verifying Chronos End User Monitoring

Verify that Chronos hits are sent by doing the following:

1. Login to Forms.

2. Open the Java console of the JVM in which Oracle Forms is running.

3. Activate trace level 2 by pressing 2.

4. Perform some Forms-based action that leads to a commit.

5. Verify that the reported trace output contains the file /oracle_smp_chronos/oracle_smp_chronos_sdk.gif. An example is shown in Figure N-7

   Figure N-7 Java Console

   
   
   

6. Confirm the hit appears in the log files on the RUEI Reporter system using the following command as the moniforce user:

   		zgrep oracle_smp_chronos 
   		$WEBSENSOR_HOME/data/*/http/currentdate/http-*

   Note:

   The use of the timestamp in the above command is to limit the displayed list. The currentdate should be specified in the form yyyymmdd.

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