Skip Headers
Oracle® Real User Experience Insight User's Guide
Release 6.5.2 for Linux x86-64

Part Number E20330-01
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 · Mobi

M Oracle E-Business Suite (EBS) Support

This appendix provides a detailed discussion of the support available for the accurate monitoring of Oracle E-Business Suite (EBS)-based applications. Note that this support is only available if you have a valid Application Management Suite for EBS licence. For more information, contact your Oracle representative.

M.1 Introduction

The monitoring support provided by RUEI has been verified against EBS R12. However, it is designed to work equally well with other versions of EBS.

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

See Section M.9, "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.

M.2 Working Within a Forms-Only Environment

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 Section M.7, "Synchronizing RUEI With the EBS Production Environment", this is done through running the 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 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 Section M.11, "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:

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 Section M.7, "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:

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 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,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,762361.1,1,1,1,helvetica.

M.3 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:


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 Section M.9, "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 Section 8.1, "Managing the Scope of Monitoring".

M.4 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 Section 6.5, "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 M-1 appears.

Figure M-1 Advanced Suite Configuration Section

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

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

M.5 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. There are a number of cookies available in EBS. However, these are not generally usable. The main problems with them are they not sufficiently unique (for instance, oracle.uix), and not wide enough (for instance, JSESSIONID is only used for the /OA_HTML/ part of the Web site).

It is recommended that you implement a client-side cookie mechanism. The procedure to do so is described in Section 7.1, "Specifying Cookie Technology".


Within a Forms-only environment, if visitors logon to applications within Forms, the user ID is automatically tracked on the Forms logon page.

M.5.1 Configuring Custom Cookies

If it is not possible to configure unique domain-wide cookies, you should do the following:

  1. Locate the $OA_HTML/AppsLocalLogin.jsp file on the EBS server. It is normally found in the $JAVA_TOP directory.

  2. Add the following JavaScript code to the page:

    <SCRIPT LANGUAGE="JavaScript">if(document.cookie.indexOf('RUEItrack=')==-1){document.cookie='RUEItrack='+parseInt(Math.random()*2147418112)+new Date().getTime()+';path=/;domain=''.','.') - 1));}</SCRIPT>
  3. Open the EBS login page, and use a header inspection analysis tool (such as the Live HTTP Headers plug-in available for Mozilla Firefox) to verify that the RUEItrack value is set to client side.


In addition, when analyzing the existing RUEItrack cookie, ensure that it is present on the client-side for all object hits and requests (such as .gif, and .js files). Alternatively, the JavaScript code shown above can be added to the t.htm or AppsLocalLogin.jsp file to make it patch proof. That is, it does not get overwritten when installing subsequent EBS patches or releases. Do not add this JavaScript to both files.

M.5.2 Verifying the Cookie Configuration

To verify your cookie configuration, do the following:

  1. Clear all cookies in the browser.

  2. (Re)login to the EBS application.

  3. Execute some actions that load Oracle Forms.

  4. Execute some actions in Oracle Forms.

  5. Logout.

  6. Wait for at least 10 minutes.

  7. Open the RUEI Reporter environment.

  8. Select Browse data, open the All sessions group, select Session diagnostics, and locate the recorded session (by user ID or time). You can filter on applications.

  9. Open the session and verify that:

    • There where more page views than just the login page. This verifies that the session ID is preserved in the OA framework after the login.

    • At least some Oracle Forms activity has been recorded with "unidentified action". This verifies that servlet calls are recorded correctly.

    • The page names reported within the Data Browser indicate events similar to those highlighted in Figure M-2.

      Figure M-2 Example Page Names

      Description of Figure M-2 follows
      Description of "Figure M-2 Example Page Names"

When not all hits are connected with the same cookie, it is recommended that you investigate where the problem is located (for instance, the domain or path option of the cookie), and resolve it in the appropriate manner.

M.5.3 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 URL Argument

Figure M-3 shows how the Session URL argument can be determined. If running in socket mode, this setting is not applicable. Otherwise, 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.

Figure M-3 Forms Session URL Argument

Description of Figure M-3 follows
Description of "Figure M-3 Forms Session URL Argument"

Correlation Variable

The Correlation variable allows the sessions (on TCP and socket mode) to be merged into one end-user session. Figure M-4 shows how the Correlation variable can be determined.

Figure M-4 Correlation Variable

Description of Figure M-4 follows
Description of "Figure M-4 Correlation Variable"

If unique client IP addresses are used, then this setting is not applicable. If running in socket mode, sessions are annotated with the value from the Correlation variable (available via "INDEX_INITIAL_CMDLINE") available on both HTTP and socket-mode traffic. For EBS environments, this will always include the icx_ticket variable. For non-EBS environments, some other variable must be specified. On the HTTP layer, the variables are found in the query part of Forms-initializing calls, or in constructions such as gp1=....&gv1=... , where gp1 specifies the value name.

On the HTTP layer, you might observe the following:

/OA_HTML/frmservlet?…&gp15=icx_ticket&gv15=255. 184.210.99jE82BtqiYLHJ8T6-bLxTLw…



Note that, on the Forms layer, the variable "INDEX_INITIAL_CMDLINE" can be found in the Collector log files. For example:

&Runform-001.INDEX_INITIAL_CMDLINE=server module=/oracle/r12/VIS12/apps/apps_st/appl/fnd/12.0.0/forms/US/FNDSCSGN fndnam=APPS  config='VIS12'  icx_ticket='' resp='FND/APPLICATION_DEVELOPER' secgrp='STANDARD' start_func='FND_FNDPOMPO' other_params=…

Session Tracking Cookie

Figure M-5 shows how the session tracking cookie can be determined.

Figure M-5 Session Tracking Cookie

Description of Figure M-5 follows
Description of "Figure M-5 Session Tracking Cookie"

If unique client IP addresses can be identified, then the default client IP-based tracking can be used. Otherwise, if a cookie with a unique value across the full host is available, then this can be created using JavaScript. Otherwise, the default EBS (JSESSIONID) tracking scheme should be used.

For example, consider the situation in which it is not possible to modify the login page to add a session cookie. In that case, some other EBS cookie within the non-Forms traffic might be selected (for example, JSESSIONID), and the correlation variable can be used in this case to connect non-Forms traffic with Forms-based traffic. Here, non-Forms hits would be identified using JSESSIONID, shared hits identified by a combination of JSESSIONID and the correlation argument, and Forms hits by the combination of the session-tracking variable jsessionid and the correlation argument in the initial command line.

M.6 Specifying The Forms Socket Mode Timeout

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. It is recommended that you specify the timeout used within your EBS environment. Note this setting is only relevant for Forms socket mode.

To specify the Forms socket mode timeout, do the following:

  1. Select Configuration, then General, then Advanced settings, and then Collector Forms settings. Use the View menu to select the required Collector. The System (localhost) represents the Collector running on the Reporter system. Click the currently defined Forms socket mode timeout setting. The dialog shown in Figure M-6 appears.

    Figure M-6 Edit Forms Timeout Dialog

    Description of Figure M-6 follows
    Description of "Figure M-6 Edit Forms Timeout Dialog"

  2. Specify (in minutes) the socket mode timeout. The default is 10 minutes. When ready, click Save.

  3. You are prompted to restart the Collector. This is necessary in order to make your changes effective. Note you can also restart the selected Collector by clicking the Restart Collector icon in the toolbar.

Note that you can specify the Forms socket mode timeout to be somewhat higher than the EBS environment timeout. However, be aware that while this has the advantage that sessions are more likely to be successfully detected and monitored, it can increase the amount of required memory.

M.7 Synchronizing RUEI With the EBS Production Environment

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

  1. Copy the script to the home directory of the EBS server. It is located in the /var/opt/ruei/processor/local/download/ebs directory of the RUEI system.

  2. Run the script as any user on the EBS serverFoot 1 . This script assigns an identification to the identified page IDs within the environment. The script must be run with the following syntax: -part=all|DB|JTT|FORM [-connectstring=connectstring] [-debug] [-exeloc=exedir] [-dir=dir1,dir2]


    • the part option specifies the subset of files to be generated. You can specify the following:

      • all: generates all files. This is the default, and is a combination of the three options listed below.

      • DB: this option is primarily intended for EBS environments, and generates a subset of the configuration file. If you use this option (or the all option), you must specify the -connectstring parameter. In addition, you must specify the -exeloc parameter. This should specify the location of the SQLPlus executable if it is not in one of the directories in the PATH.

      • JTT: this option is primarily intended for EBS environments, and generates all Java-based files. The location of the Java files is based on the APPL_TOP setting. Otherwise, the directories specified with the -dir parameter are used.

      • FORM: this option is primarily intended for Forms-based environments, and generates all Forms-based files. If you specify this option (or the all option), you must specify the -exeloc parameter. This should specify the location of the frmcmp or frmcmp_batch executable if they are not in one of the directories in the PATH. The location of the Forms (.fmb) files is based on the APPL_TOP setting. Otherwise, the directories specified with the -dir parameter are used.

    • connectstring specifies the string passed to SQLPlus to gain access to the database.

    • debug specifies debug mode should be enabled.

    • execloc specifies that the executable is not in one of the directories in the PATH, and that the exedir directory should be searched. Note that multiple directories must be separated with a comma, or by specifying the -exeloc option multiple times.

    • dir1, dir2, and so on, specify the directories to search for Java or Forms-related information. Note that multiple directories must be separated with a comma, or by specifying the -dir option multiple times.

    The script reads from the APPLSYS schema, and generates .txt files in the current directory. For example:

    perl -part=all -connectstring=APPS/APPS@linux-ebs-r12-pc:1522/VIS12
    perl -part=all -connectstring=APPS/APPS@VIS12

    In multiple instance environments, run the script for each required instance, and separately preserve their created .txt files. In addition, create a separate suite definition for each instance.


    If you create new customizations (or make changes to existing customizations) to your EBS applications, you will need to re-run the script, and re-import the generated zip file.
  3. The script creates a number of .txt files in the directory where the script is executed. All relevant .txt files are collected and stored in a .zip file. Copy this .zip file to a location that can be used for uploading the files to the RUEI Reporter system.

  4. Select Configuration, then Applications, then Suites, and select the suite you defined earlier. Click Upload Configuration.

  5. Specify the name of the .zip file containing the generated .txt files. If you manually create .txt files, you should use the same structure present in the .zip file. To protect against receiving empty definitions, the upload will fail when it contains empty .txt files. When ready, click Upload.


If you receive warning or error messages while running the script, see Section M.19.4, " Script Reports FRM-91500 Error" for important troubleshooting information.

The Perl Interpreter

By default, the Perl interpreter is not shipped with Microsoft Windows. It is often installed as part of the Oracle database, as well as some other Oracle products. To locate the Perl interpreter on a Microsoft Windows system, select Start > Find > Find for files > perl.exe. Use the located executable to run the configuration script.

When no Perl executable is available, you can run the DB part of the above query from the RUEI system (providing that a connection to the EBS database from it is possible). This can be achieved by using the -part=DB option with a connectstring that refers to the APPS scheme in the EBS database on the remote host. Note that only the database-based EBS customizations are generated (and not the JTT/Java-based customizations or Forms-based changes).

Note that if you skip running the script, RUEI will still report on EBS and Forms activities. However, the reported names will not reflect your customizations. For example, responsibilities will be reported using the responsibility-key instead of the responsibility name, and Forms will be reported using the formname instead of a functional description of the form. This may be acceptable in environments with little customization.

M.8 Verifying and Evaluating Your Configuration

To ensure the quality of the data being collected and reported by RUEI for your EBS-based applications, it is strongly recommended that you verify their reported details. You should pay particular attention to the number of associated pages detected for the defined suite(s).

Select Browse data, then select the All pages group, and then the Application sub-group. Within the individual dimensions, such as Page views and hits, you can see that page views are reported for several applications. The suite name in the definition is shown between brackets. An example is shown in Figure M-7.

Figure M-7 Example EBS Suite Page Views

Description of Figure M-7 follows
Description of "Figure M-7 Example EBS Suite Page Views"


The Unique pages identified counter and the Last page identified indicator (shown in Figure 6-47) are disabled. Similarly, the manual page naming facility is not available.

M.9 Checking Socket and Servlet Mode

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:


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:


Use the following command:

$ grep xsport FORMS60_WEB_CONFIG_FILE

The required port number is required:


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

Figure M-8 Example Launch Page Details

Description of Figure M-8 follows
Description of "Figure M-8 Example Launch Page Details"

The relevant connection mode information is highlighted.

M.10 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 M-1 shows how an application's dimensions are reported in RUEI.

Table M-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

Application/Page name » form_name » form_action » form_block » 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 M-9 shows an example of how an EBS application is reported in RUEI.

Figure M-9 Example EBS Application Page Naming Reporting

Description of Figure M-9 follows
Description of "Figure M-9 Example EBS Application Page Naming Reporting"

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

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


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

M.13 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:

M.14 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 M.7, "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:

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

M.15.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, 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 M-10.

Figure M-10 Request and Page Boundaries the Same

Description of Figure M-10 follows
Description of "Figure M-10 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 M-10.

  • 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 M-11.

  • 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 M-11 Different Request and Page Boundaries in the JSP Forward Case

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

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

M.16 Data Items

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

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

M.17 Resources

You may find the information sources useful:

M.18 Known Limitations

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

M.19 Troubleshooting

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

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

  • Once data starts arriving into the RUEI system, it is not reported automatically. At least one application must be defined. At a minimum, this application must contain the relevant domain name, and the unique page-identification scheme within that domain.

  • If the monitored traffic includes VLAN-encapsulated traffic, ensure this is configured within RUEI. Select System, then Configuration, then Security, then Network filters, and then VLAN traffic, to review the defined settings. The use of this facility is fully described in Section 8.2.1, "Defining VLAN Filters".

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

  • Be aware that because the Traffic summary facility (select System, then Status, and then Data processing) is based on application logic, non-application traffic (such as suites, services, and SSOs) is not represented in the traffic overviews.

It is strongly recommended that after configuring an EBS suite definition, you login to the EBS application, and execute a critical path through the application. Then, you should search for recorded action within RUEI, and use the Session Diagnostics facility to verify that it is correctly reported. In particular:

  • Verify that descriptions are reported, and not codes. If codes are reported instead of application names, or page-group level codes instead of page-group names, it indicates that the information derived from the script is not activated correctly.

  • A large number of reported short sessions indicates that Forms traffic is not being measured.

  • A large number of reported .jsp files indicates the need for manual page naming (if required by the customer).

M.19.2 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" (as shown in ), this indicates that some specific characteristic in the monitored traffic is not being captured. In this case, you should contact Customer Support.

  • If all monitored traffic is reported with unidentified actions, you should verify that the URL prefix and Session URL argument settings specified within the Forms tab of the suite's overview (as shown in Figure M-6) match those used within your environment. This information is available within the Page URL dimension.

  • Verify that the server ports are correctly configured, as described in . In particular, verify that servlet port is configured as the HTTP port.

M.19.3 Sessions are Reported as "Anonymous"

If sessions are reported as "anonymous", but user IDs are available in the All sessions cube, you should verify the Correlation URL argument specified within the Forms tab of the suite's overview (as shown in Figure M-6).

M.19.4 Script Reports FRM-91500 Error

When the script is run on a Unix system, the following error is reported multiple times:

FRM-91500: Unable to start/complete the build.

This is caused by the frmbatch script not having access to the user interface. You should consider the following:

  • Ensure that the DISPLAY variable is correctly set. You can use X Window System tools such as xclock or xeyes to verify it. You might also consider using X-forwarding of SSH to enable the use of the X Windows System on another server.

  • The frmcmp_batch script is trying to work without the X Windows System. This is the first script used by the configuration script. Set the display mode using the following command:

    $ set ORACLE_TERM=vt220; export ORACLE_TERM

M.19.5 Perl Zip Functionality is not Available

In some systems, zip functionality is not installed as part of the Perl package. In this case, you receive the following message:

The Archive::Zip package is not available on this system.

After this message, a sample command indicates how the archive might be created. Be aware that the archive should consist of non-empty files, and that files should not be in directories. If so, the upload to RUEI will fail. Alternatively, you can execute the command zip EBS_*txt in the appropriate directory.

M.19.6 The frmcmp_batch Script Fails

The frmcmp_batch script fails due to some unknown error, and reports something similar to the following:

execution of 'frmcmp_batch module=XXX/XXX/XXX.fmb module_type=form batch=yes logon=no forms_doc=yes strip_source=yes build=no output_file=/tmp/XXX.txt' failed: 11. Ignoring /XXX/XXX/XXX.fmb

This indicates that the reported .fmb file could not be converted into .txt format (possibly due to corruption). If only a very small proportion of the total number of .fmb files are reported, this will probably not be an issue. Indeed, it is likely that the reported forms would not work in a production environment in any case. However, if you know that visitors to your Web site are actively using the reported forms without trouble, then please report this issue. When doing so, please provide the relevant .fmb files, together with some indication of how they are deployed within your EBS environment.

M.19.7 Script Generates Warnings/Errors

If you receive errors and/or warnings while running the script, depending on their nature, do the following:

  • Database related:

    • Verify the connectstring specified for the script by issuing the following command:

      sqlplus connectstring @temporarysqlfile
  • Forms related:

    • frmcmp or frmcmp_batch are not working correctly. Detailed troubleshooting information is available about this from Note 266731.1 at

    • frmcmp or frmcmp_batch return a sig 11 segmentation fault. This is know to occur for GRDDHIST.fmb.

Footnote Legend

Footnote 1: The script can also be run in the acceptance environment if it is equivalent to the production environment.