| Oracle® Real User Experience Insight User's Guide 12c Release 1 for Linux x86-64 Part Number E26360-03 |
|
|
PDF · Mobi · ePub |
| Oracle® Real User Experience Insight User's Guide 12c Release 1 for Linux x86-64 Part Number E26360-03 |
|
|
PDF · Mobi · ePub |
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.
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 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 Section M.8, "Checking Socket and Servlet Mode" for information about verifying the mode in which Oracle Forms is configured.
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 Section M.7, "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 Section M.10, "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 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:
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 Section M.8, "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 13.3, "Managing the Scope of 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 Section 10.1, "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
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. 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 12.2, "Specifying the Cookie Technology".
Note:
Within a Forms-only environment, if visitors logon to applications within Forms, the user ID is automatically tracked on the Forms logon page.If it is not possible to configure unique domain-wide cookies, you should do the following:
Locate the $OA_HTML/AppsLocalLogin.jsp file on the EBS server. It is normally found in the $JAVA_TOP directory.
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='+document.location.host.substring(document.location.host.lastIndexOf('.', document.location.host.lastIndexOf('.') - 1));}</SCRIPT>
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.
To verify your cookie configuration, do the following:
Clear all cookies in the browser.
(Re)login to the EBS application.
Execute some actions that load Oracle Forms.
Execute some actions in Oracle Forms.
Logout.
Wait for at least 10 minutes.
Open the RUEI Reporter environment.
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.
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.
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.
The tracking mechanisms that should be specified for the Correlation variable and Session URL argument are best determined through a number of flow charts.
Figure M-3 shows how the Session parameter 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. Note that if the specified parameter is not found in the URL, then the cookie is searched for it.
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.
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…
Alternatively:
/OA_HTML/frmservlet?…&env=NLS_LANG='AMERICAN_AMERICA'+…+icx_ticket='255.184.210.99.jE82BtqiYLHJ8T6-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='255.184.210.99.jE82BtqiYLHJ8T6-bLxTLw..' resp='FND/APPLICATION_DEVELOPER' secgrp='STANDARD' start_func='FND_FNDPOMPO' other_params=…
Figure M-5 shows how the session tracking cookie can be determined.
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.
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:
Select Configuration, then General, then Advanced settings, and then Collector Forms settings. Use the View menu to select the required Collector. The System (localhost) item 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.
Specify (in minutes) the socket mode timeout. The default is 10 minutes. When ready, click Save.
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.
In order for RUEI to understand how the EBS frameworks are implemented within your environment, do the following:
Copy the create_EBS_info.pl 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.
Run the create_EBS_info.pl script as any user on the EBS serverFoot 1 . This script assigns an identification to the identified page IDs within the environment. The create_EBS_info.pl script must be run with the following syntax:
create_EBS_info.pl -part=all|DB|JTT|FORM [-connectstring=connectstring] [-debug] [-exeloc=exedir] [-dir=dir1,dir2]
where:
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 create_EBS_info.pl -part=all -connectstring=APPS/APPS@linux-ebs-r12-pc:1522/VIS12 perl create_EBS_info.pl -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.
Note:
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.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.
Follow the procedure described in Section 10.1.2, "Uploading Configuration Files" to upload the generated files to the Reporter System.
Note:
If you receive warning or error messages while running the
create_EBS_info.pl script, see Section M.18.4, "Create_EBS_info.pl Script Reports FRM-91500 Error" for important troubleshooting information.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 create_EBS_info.pl 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.
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....
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-7.
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.
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 |
|
|
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.
servlet_group is the group name assigned to a set of servlets.
servlet_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 M-8 shows an example of how an EBS application is reported in RUEI.
Figure M-8 Example EBS Application Page Naming 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
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.
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).
A default RUEI installation recognizes different types of errors. 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.
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.
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 the following location:
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.
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:
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 M-9.
Figure M-9 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-9.
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-10.
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-10 Different Request and Page Boundaries in the JSP Forward Case
The EBS-specific data items shown in Table M-2 are reported by RUEI.
Table M-2 EBS-Specific Data Items
| Item | Description |
|---|---|
|
database-time-per-page(ms) |
The average time (in milliseconds) per page view taken by the database server to process an action. This is only available if Chronos or End User Monitoring is enabled. |
|
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 database time |
The total time (in milliseconds) per second interval taken by the database server to process an action. This is only available if Chronos or End User Monitoring is enabled. |
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.
This section highlights the most common problems encountered when monitoring EBS applications. The information in this section should be reviewed before contacting Customer Support.
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 13.4.2, "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 create_EBS_info.pl 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).
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 Figure M-2), 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 Section M.3, "Verifying the Scope of Monitoring". In particular, verify that servlet port is configured as the HTTP port.
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).
When the create_EBS_info.pl 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 create_EBS_info.pl configuration script. Set the display mode using the following command:
$ set ORACLE_TERM=vt220; export ORACLE_TERM
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.
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.
If you receive errors and/or warnings while running the create_EBS_info.pl script, depending on their nature, do the following:
Database related:
Verify the connectstring specified for the create_EBS_INFO.pl 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 https://support.oracle.com/CSP/ui/flash.html.
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.
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
