--------------------------------------------------------------------------------
Modified 06-MAR-2008 Type TROUBLESHOOTING Status PUBLISHED
In this Document
Purpose
Last Review Date
Instructions for the Reader
Troubleshooting Details
References
--------------------------------------------------------------------------------
Applies to:
Oracle Applications Technology Stack - Version: 12.0 to 12.1
Information in this document applies to any platform.
Forms in R12
Purpose
The Oracle Applications Release 12 technology stack introduces major enhancements to some of the most commonly used technologies in Oracle Applications, including the HTTP listener, Java deployments, Forms and Reports. The purpose of this document is to give an insight on tracing and diagnostics tools that can aid in diagnosis and detection of various anomalies and errors with forms in Oracle Applications Release.12i
Last Review Date
September 10, 2007
Instructions for the Reader
A Troubleshooting Guide is provided to assist in debugging a specific issue. When possible, diagnostic tools are included in the document to assist in troubleshooting.
Troubleshooting Details
Release 12 now includes Oracle Application Server (OracleAS) 10g 10.1.2 as the foundation for Forms, Reports, and C code. This replaces the 8.0.6-based ORACLE_HOME that 9iAS 1.0.2.2 provides today in Release 11i.
This document is an introduction to the Forms Runtime Diagnostics, Forms Trace diagnostics utility and Servlet logging tools available in Oracle Applications Release. 12, and includes the following sections:
Section 1: Identify if forms is implemented in socket /servlet mode
Section 2: Forms Runtime Diagnostics (FRD)
Section 2.1: Activating Forms Runtime Diagnostics (FRD)
Section 2.2: Trace file location
Section 2.3: Sample output
Section 3: Forms Trace Diagnostics Utility
Section 3.1: Activating Forms trace
Section 3.2: Trace file location
Section 3.3: Viewing Forms trace output
Section 3.4: Sample output
Section 4: Servlet logging
Section 4.1: Activating logging
Section 4.2: Log file location
Section 4.3: Sample output
Section 1: Identify if forms is implemented in socket /servlet mode
--------------------------------------------------------------------------------
Oracle Applications Release12 by default configures Forms 10g stack in servlet mode, as this is the preferred and recommended deployment model for deploying forms on the web. In this mode, there is a java servlet called the Forms Listener Servlet, manages the communication between the Forms Java Client and OracleAS Forms Services. The Forms Listener Servlet architecture operates through the HTTP server port alone and does not need extra ports to handle communication between the client and the application server. The servlet architecture is designed to work with industry standards, and also to be fully supported for advanced network configurations with no additional ports or SSL configuration.
Although forms servlet is the preferred deployment method, there may be circumstances where customers need to switch from Forms servlet mode to socket mode, which allows desktop clients to access the Forms server directly.
To check if forms is implemented in socket /servlet mode perform the following steps:
Step 1: Source the middle-tier environment file from
Note: Replace
Step 2: Open the appsweb.cfg file pointed by environment variable "FORMS_WEB_CONFIG_FILE" and check the values for following parameters:
serverURL=
connectMode=
Note: Refer the table below for the values that they must contain based on the implementation mode
In servlet mode In Socket mode
serverURL=/forms/lservlet
connectMode=servlet serverURL=(should be blank)
connectMode=Socket
Step 3: Based on the values for these two parameters one should be able to determine if forms is implemented in socket /servlet mode
Section 2: Forms Runtime Diagnostics (FRD)
--------------------------------------------------------------------------------
The Forms Runtime Diagnostic (FRD) is a method for capturing all events that occur in a form session and writing a file with the details of those events. There is overhead in writing this file, so you should only use this for the purposes of development and debugging
When a form is run with FRD enabled, a combination of external user-application interactions and internal Forms processing events are written in chronological order to a log on the file system.
Section 2.1: Activating Forms Runtime Diagnostics (FRD)
Forms Runtime Diagnostics (FRD) can be enabled /activated in one of the following ways:
Option 1: Obtain FRD Trace Using Profile Options
Option 2: Obtain FRD Trace Using Appsweb.cfg
Option 3: Obtain FRD in an ADHOC way
Option 1: Obtain FRD Trace Using Profile Options
Method 1: Using profile option 'ICX: Forms Launcher'
When accessing Applications through the 'Home Page' (the page resultant after successful login) there is no way to pass command line parameters such as record=all, etc. for the duration of a single session. This method enables users to run FRD tracing through the 'Home Page' by using the profile option 'ICX: Forms Launcher'.
To start tracing in this way, modify Profile Option 'ICX: Forms Launcher' at USER level to include the Forms parameters required for FRD logging:
Note:
* It is recommended to pass FRD variables at the USER level and not at the SITE level since SITE level affects all users.
* If the 'ICX: Forms Launcher' profile option is not updatable at the USER level, then you may need to access 'Application Developer' to set the option 'Updatable' for the profile 'ICX_FORMS_LAUNCHER'
Step 1: Set the profile option 'ICX: Forms Launcher' at user level to same as site value
E.g. copy the site level value for profile option 'ICX: Forms Launcher' and paste it in user level field so as to set it at the user level
Step 2: Append the user value of ICX: Forms Launcher with the Forms parameters for FRD i.e '?record=collect'
E.g.
In Servlet mode In Socket mode
http://hostname.domain:port/forms/frmservlet?record=collect http://hostname.domain:port/OA_HTML/frmservlet?record=collect
replace hostname, domain and port as applicable
Step 3: Save this change at the USER level.
Step 4: For trace file details and location, refer Section 2.2 Trace file location.
Note:
You may need to bounce Apache for profile level changes to take effect
Step 4: Login into Oracle Applications and launch forms via self-service
Method 2: Using profile option 'Forms Runtime Parameters'
When accessing Applications through the 'Home Page' (the page resultant after successful login) there is no way to pass command line parameters such as record=all, etc. for the duration of a single session. This method enables users to run FRD tracing through the 'Home Page' by using the profile option 'Forms Runtime Parameters'
To start tracing in this way, modify Profile Option 'Forms Runtime parameters' at USER level to include the Forms parameters required for FRD logging:
Note:
* It is recommended to pass FRD variables at the USER level and not at the SITE level since SITE level affects all users.
* If the 'Forms Runtime Parameters' profile option is not updatable at the USER level, then you may need to access 'Application Developer' to set the option 'Updatable' for the profile 'Forms Runtime Parameters'
Step 1: Set the profile option 'Forms Runtime Paramter' with a value of 'record=collect' at user level (without quotes)
Step 2: Save this change and logout of applications
Note:
You may need to bounce Apache for profile level changes to take effect
Step 3: Login into Oracle Applications and launch forms via self-service
Step 4: For trace file details and location, refer Section 2.2: Trace file location.
Option 2: Obtain FRD Trace Using Appsweb.cfg
When accessing Applications through the 'Home Page' (the page resultant after successful login) there is no way to pass command line parameters such as record=all, etc. for the duration of a single session. It is also possible to obtain FRD trace by using Appsweb.cfg file.
To start tracing in this way, please refer to the steps below:
Step 1: Edit the appsweb.cfg file pointed by environment variable "FORMS_WEB_CONFIG_FILE"
Step 2: Forms parameters for FRD can be set in appsweb.cfg file in one of the following ways :
Method 1:
Look for "record=" parameter after the 'ENVIRONMENT SPECIFIC PARAMETERS' section and set it to collect as shown below.
Once done login into Oracle Applications and launch forms via self-service.
Extracts from appsweb.cfg file :
; ********************************
; ENVIRONMENT SPECIFIC PARAMETERS
; ********************************
; These parameters describe the main production environment.
; They have to be updated after every patching of this file.
;
; Forms Server Information: servlet, port, machine name and domain
; ----------------------------------------------------------------
serverURL=/forms/lservlet
; If you are using the Forms Servlet, uncomment the line that sets a value
; for the ServerURL and comment the line that that sets serverURL to
; no value. Lines are commented by inserting a semi-colon at line's beginning.
;
# Forms runtime argument: whether to run in debug mode
debug=no
# Other Forms runtime arguments: grouped together as one parameter.
# These settings support running and debugging a form from the Builder:
otherparams=buffer_records=%buffer% debug_messages=%debug_messages% array=%array% obr=%obr% query_only=%query_only%
quiet=%quiet% render=%render% record=%record% tracegroup=%tracegroup% log=%log% term=%term%
# Sub argument for otherparams
buffer=no
# Sub argument for otherparams
debug_messages=no
# Sub argument for otherparams
array=no
# Sub argument for otherparams
obr=no
# Sub argument for otherparams
query_only=no
# Sub argument for otherparams
quiet=yes
# Sub argument for otherparams
render=no
# Sub argument for otherparams
record=collect
For trace file details and location, refer Section 2.2: Trace file location.
OR
Method 2:
Update appsweb.cfg by adding the required Forms parameters for FRD
E.g.
[debug1]
record=collect
Logon to Applications 12i and start FRD trace by accessing the forms URL directly or updating profile option ICX: Forms Launcher by appending
'?config=debug1' as below
In Servlet mode In Socket mode
http://hostname.domain:port/forms/frmservlet?config=debug1 http://hostname.domain:port/OA_HTML/frmservlet?config=debug1
replace hostname, domain and port as applicable
Note:
Login into applications via forms directly using above URL's is not supported but can be used for basic troubleshooting purpose on recommendation of Oracle Support
For trace file details and location, refer Section 2.2: Trace file location.
Option 3: Obtain FRD in an ADHOC way
The steps below show how to create an FRD trace in an ADHOC way. This is not a supported or preferred method of tracing, however, it may be useful to use this method for ad hoc and basic troubleshooting purposes.
Step 1: Logon to Applications 12i and start FRD trace by accessing the forms URL directly and appending '?record=collect' as below
In Servlet mode In Socket mode
http://hostname.domain:port/forms/frmservlet?record=collect http://hostname.domain:port/OA_HTML/frmservlet?record=collect
replace hostname, domain and port as applicable
Note:
Login into applications via forms directly using above URL's is not supported but can be used for basic troubleshooting purpose on recommendation of Oracle Support
Step 2:For trace file details and location, refer Section 2.2: Trace file location.
Section 2.2: Trace file location
The FRD log file will be written in the directory pointed by environment variable $FORMS_TRACE_DIR. By default, the trace file with name collect_
Note:
Unlike in Release 11i, you can no longer create a trace file in any ad hoc directory by using '&log=' directive like '&log=/usr/tmp/user1.log'.In R12, the FRD log file will be written in the directory pointed by environment variable $FORMS_TRACE_DIR and one can specify the log filename with '.log'extension in one of the following ways:
1. In appsweb.cfg:
Look for "log=" parameter after the 'ENVIRONMENT SPECIFIC PARAMETERS' section and set it with name that you want the trace file to be created with.
E.g
log=user1.log
2. Using +log directive in the URL used to set the frd trace via profile options or in ad hoc way
E.g
http://hostname.domain:port/forms/frmservlet?record=collect+log=user1.log
http://hostname.domain:port/OA_HTML/frmservlet?record=collect+log=user1.log
Section 2.3: Sample output
When a form is run with FRD enabled, a combination of external user-application interactions and internal Forms processing events are written in chronological order to a log file. These events can be analyzed to determine user actions and corresponding system responses, which aid in problem diagnosis and issue resolution. Kindly refer below display for a brief extract from a frd log file.
Extracts from a frd log file :
File Name: /oracle1/PROD/inst/apps/PROD_vkaria/logs/ora/10.1.2/forms/collect_32188
Process ID: 32188
Client IP: 152.69.172.99
Forms 10.1 (Forms Runtime) Version 10.1.2.0.2 (Production)
PL/SQL Version 10.1.0.5.0 (Production)
Oracle Virtual Graphics System Version 10.1.2.0.0 (Production)
Oracle Multimedia Version 10.1.2.0.2 (Production)
Oracle Tools Integration Version 10.1.2.0.2 (Production)
Oracle Tools Common Area Version 10.1.2.0.2
Oracle CORE 10.1.0.4.0 Production
Opened file: /oracle1/PROD/apps/apps_st/appl/fnd/12.0.0/forms/US/FNDSCSGN.fmx
ON-LOGON Trigger Fired:
Form: FNDSCSGN
State Delta:
FNDSCSGN, 1, Trigger, Entry, 2016355936, ON-LOGON
FNDSCSGN, 2, Prog Unit, Entry, 2017421936, /FNDSCSGN-1/P53_04_JAN_200703_41_43
FNDSCSGN, 3, Prog Unit, Entry, 2018075936, /FNDSCSGN-1/DO_LOGON
Executing DEFAULT_VALUE Built-in:
In Argument 0 - Type: String Value: NULL
In Argument 1 - Type: String Value: GLOBAL.FNDSCSGN_UNAME
Executing GET_APPLICATION_PROPERTY Built-in:
In Argument 0 - Type: Number Value: 73
Out Argument 0 - Type: String Value: NULL
Section 3: Forms Trace Diagnostics Utility
--------------------------------------------------------------------------------
Forms Trace allows you to record information about a precisely defined part of forms functionality or a class of user actions. It provides detailed data collection and other features to assist the user in diagnosing and investigating forms runtime problems
Additional to old FRD logging, forms trace promises to have more structured logging with additional event which can be traced. Forms Trace works by assigning an event id to each traceable event; for example, event 66 = Trigger Start & End, event 41 = Window Close. For a complete list of events, refer to Oracle® Application Server Forms Services Deployment Guide, Section 8, Tracing and Diagnostics. These events can be pooled into a trace group to provide customized output that suits the problem being investigated.
Section 3.1: Activating Forms trace
In addition to activating options as suggested in Note:373548.1 - Using Forms Trace in Oracle Applications Release 12, you can also activate forms trace using :
Option 1: Obtain FRD Trace Using Appsweb.cfg
Option 2: Obtain FRD in an ADHOC way
Option 1: Obtain Forms Trace Using Appsweb.cfg
When accessing Applications through the 'Home Page' (the page resultant after successful login) there is no way to pass command line parameters such as record=all, etc. for the duration of a single session. It is also possible to obtain FRD trace by using appsweb.cfg file.
To start tracing in this way, please refer to the steps below:
Step 1: Edit the appsweb.cfg file pointed by environment variable "FORMS_WEB_CONFIG_FILE"
Step 2: Forms trace can be set in appsweb.cfg file in one of the following ways :
Method 1:
Look for "record=" parameter after the 'ENVIRONMENT SPECIFIC PARAMETERS' section and set it to form as shown below. This will activate Forms Trace. By default, it will trace errors only. To utilize the full flexibility of Forms Trace, the record=forms parameter must be used in conjunction with the 'tracegroup' parameter. This parameter defines specific events to be traced
The tracegroup parameter can be:
A list of events, E.g. tracegroup=1,2,3,4,5.
A range, E.g. tracegroup=1-5
A keyword that is specified in the file ftrace.cfg, E.g. tracegroup=mygroup.
A combination of some or all of the above, E.g. tracegroup=0-3,34,67,mygroup.
Exhibit:1
With the many trace events available, a trace file could quickly become a maze. After testing various combinations, Applications Development has created several recommended levels of tracing, which are predefined in the file $ORA_CONFIG_HOME/10.1.2/forms/server/ftrace.cfg:
light (0-71,192): Records user actions, error messages and form service events.
medium (0-97,192,194,195): Includes events in the light tracegroup also captures built-in and user-exit events.
full (0-98,100-199): Captures all information that is currently available through Forms Tracing.
dbsql (32,64,98,100,101,136,137,192): All events related to the database and forms interaction with it
network (64,32,128,129,131,130,132,133,134,192): All events related to communications between client tier and Forms server.
Complete list of traceable events is available in
Oracle® Application Server Forms Services Deployment Guide, Section 8, Tracing and Diagnostics, Table 8-2, "List of Traceable Events"
Once done login into Oracle Applications and launch forms via self-service
Extracts from appsweb.cfg file :
; ********************************
; ENVIRONMENT SPECIFIC PARAMETERS
; ********************************
; These parameters describe the main production environment.
; They have to be updated after every patching of this file.
;
; Forms Server Information: servlet, port, machine name and domain
; ----------------------------------------------------------------
serverURL=/forms/lservlet
; If you are using the Forms Servlet, uncomment the line that sets a value
; for the ServerURL and comment the line that sets serverURL to
; no value. Lines are commented by inserting a semi-colon at line's beginning.
;
# Forms runtime argument: whether to run in debug mode
debug=no
# Other Forms runtime arguments: grouped together as one parameter.
# These settings support running and debugging a form from the Builder:
otherparams=buffer_records=%buffer% debug_messages=%debug_messages% array=%array% obr=%obr% query_only=%query_only%
quiet=%quiet% render=%render% record=%record% tracegroup=%tracegroup% log=%log% term=%term%
# Sub argument for otherparams
buffer=no
# Sub argument for otherparams
debug_messages=no
# Sub argument for otherparams
array=no
# Sub argument for otherparams
obr=no
# Sub argument for otherparams
query_only=no
# Sub argument for otherparams
quiet=yes
# Sub argument for otherparams
render=no
# Sub argument for otherparams
record=collect
# Sub argument for otherparams
tracegroup=medium
For trace file location and details, refer Section 3.2: Trace File location
OR
Method 2:
Update appsweb.cfg by adding the required Forms parameters for FRD
E.g.
[debug1]
record=forms
tracegroup=medium
The tracegroup parameter can be:
A list of events, E.g. tracegroup=1,2,3,4,5.
A range, E.g. tracegroup=1-5
A keyword that is specified in the file ftrace.cfg, E.g. tracegroup=mygroup.
For more information on tracegroups, please refer Exhibit 1 in Method 1 of Section 3
Login to Applications R12 and start Forms trace by accessing the applications via forms URL directly or updating the value of profile option ICX: Forms Launcher by appending '?config=debug1' as below
In Servlet mode In Socket mode
http://hostname.domain:port/forms/frmservlet?config=debug1 http://hostname.domain:port/OA_HTML/frmservlet?config=debug1
replace hostname, domain and port as applicable
Note:
Login into applications via forms directly using above URL's is not supported but can be used for basic troubleshooting purpose on recommendation of Oracle Support
For trace file location and details, refer Section 3.2: Trace File location
Option 2: Obtain Forms trace in an ADHOC way
The steps below show how to create an forms trace in an ADHOC way. This is not a supported or preferred method of tracing, however, it may be useful to use this method for ad hoc and basic troubleshooting purposes.
Step 1: Login to Applications R12 and start FRD trace by accessing the forms URL directly and appending '?record=forms tracegroup=full' as below
The tracegroup parameter can be:
A list of events, E.g. tracegroup=1,2,3,4,5.
A range, E.g. tracegroup=1-5
A keyword that is specified in the file ftrace.cfg, E.g. tracegroup=mygroup.
For more information on tracegroups, please refer Exhibit 1 in Method 1 of Section 3
In Servlet mode In Socket mode
http://hostname.domain:port/forms/frmservlet?record=forms tracegroup=full http://hostname.domain:port/OA_HTML/frmservlet?record=forms tracegroup=full
Note:
Login into applications via forms directly using above URL's is not supported but can be used for basic troubleshooting purpose on recommendation of Oracle Support
Step 2: For trace file location and details, refer Section 3.2: Trace File location
Section 3.2: Trace file location
The forms trace file will be written in the directory pointed by environment variable $FORMS_TRACE_DIR. By default, the trace file with name forms_
Note:
Unlike in Release 11i, you can no longer create a trace file in any ad hoc directory by using '&log=' directive like '&log=/usr/tmp/user1.log'.In R12, the FRD log file will be written in the directory pointed by environment variable $FORMS_TRACE_DIR and one can specify the log filename with '.trc' extension in one of the following ways:
1. In appsweb.cfg:
Look for "log=" parameter after the 'ENVIRONMENT SPECIFIC PARAMETERS' section and set it with name that you want the trace file to be created with.
E.g
log=user1.trc
2. Using +log directive in the URL used to set the forms diagnostics trace via profile options or in ad hoc way
E.g
http://hostname.domain:port/forms/frmservlet?record=forms+log=user1.trc tracegroup=full
http://hostname.domain:port/OA_HTML/frmservlet?record=forms+log=user1.trc tracegroup=full
Section 3.3: Viewing Forms trace output
To view the binary data one needs to convert it to a readable format using Translate utility. The Translate utility converts trace data to XML or HTML formats. You'll need to specify an additional parameter "OutputClass" which has two legal values: "WriteOut" and "WriteOutHTML". If you use "WriteOut", the output file will be in XML format. If you use "WriteOutHTML", the output file will in HTML format.These two values ("WriteOut" and "WriteOutHTML") are case-sensitive.
To perform the translation you will need access to the Java executable, and either a Forms 10.1.2 Home or the Forms Developer Suite. The command used to translate is as shown below:
E.g
To convert the binary file into XML format:
Note:
* Replace $1.trc with the trace file name as applicable
* Replace$1.xml /$1.html with the filename you wish to have the translated data into
* The XML format will include values that are not visible in the HTML output file. We therefore recommend using the XML formatted output for Oracle Applications
R12.
Section 3.4: Sample output
Kindly refer below display for a brief extract from a forms trace file (XML translated) wherin one can see trace events and assignment of event id to each traceable event.
Extracts from a forms trace file (XML translated):
-
-
..
..
..
..
-
-
-
-
-
-
Section 4: Servlet logging
--------------------------------------------------------------------------------
In addition to Forms Runtime Diagnostics (FRD) and Forms Trace, forms administrators can also enable servlet logging for forms implemented in servlet mode. Servlet logging options enable forms administrators in :
Recording of all Oracle Forms sessions, including session start and end times, and the user's IP address and host name (session-level logging)
Monitoring of Oracle Forms-related network traffic and performance (session-performance and request-performance-level logging)
Generating debugging information for site configuration issues (debug-level logging)
Supported Logging parameters are as shown below:
(none) No log messages are produced. However, during Forms Servlet initialization, a message is written to the log file stating the name and path of the configuration file being used.
/session Log messages are written whenever a Forms session starts or ends. These give the host name and IP address of the client (the computer on which the user's web browser is running), the runtime process id, and a unique internal session id number.
/sessionperf Performance summary statistics are included with the session end message.
/perf A performance message is written for every request from the client.
/debug Full debug messages. Other debug messages are written in addition to the messages mentioned above. This logging level is very verbose and is intended mainly for debugging and support purposes.
Section 4.1: Activating logging
Servlet logging can be enabled as shown below :
Option 1: Obtain Servlet logging Using Appsweb.cfg
Step 1: Edit the appsweb.cfg file pointed by environment variable "FORMS_WEB_CONFIG_FILE"
Step 2: Set the forms parameters for servlet logging (either /session , /sessionperf, /perf, /debug) in appsweb.cfg file as shown below :
Extracts from appsweb.cfg file :
; ********************************
; ENVIRONMENT SPECIFIC PARAMETERS
; ********************************
; These parameters describe the main production environment.
; They have to be updated after every patching of this file.
;
; Forms Server Information: servlet, port, machine name and domain
; ----------------------------------------------------------------
serverURL=/forms/lservlet/session
Step 3: For trace file location and details, refer Section 4.2: Log File location
Section 4.2: Log file location
The servlet log file is application.log. It is written to the application-deployments/formsapp directory of the OC4J instance to which Forms is deployed.
In Oracle Applications:
$LOG_HOME/ora/10.1.3/j2ee/forms/forms_default_group_1/application.log
Section 4.3: Sample output
•
Kindly refer below for the sample output from application.log file with servlet logging enabled. With no logging enabled, no log messages will be recorded except an entry stating the name and path of the configuration file being used .
Extracts from application.log file with servlet logging enabled:
07/06/23 16:01:02.26 formsweb: =============== ListenerServlet ===============
07/06/23 16:01:02.31 formsweb: GET request received, cmd=getinfo, qstring=ifcmd=getinfo&ifhost=VKARIA-lap&ifip=111.144.104.113
07/06/23 16:01:02.31 formsweb: Existing servlet session, id = 9845d02755fae8020de2c0d94f34902d914af3058c8d.e34Lc3yQbhmTaO0OahqPcheNby0, not from cookie
07/06/23 16:01:02.33 formsweb: Trying to get a prestarted proc
07/06/23 16:01:02.33 formsweb: PreStarted process is not available
07/06/23 16:01:02.34 formsweb: Creating new Runtime Process using default executable
07/06/23 16:01:02.34 formsweb: Starting Forms Server in EM mode
07/06/23 16:01:02.48 formsweb: startProcess: executing frmweb server webfile=HTTP-0,0,1,default,111.144.104.113
07/06/23 16:01:02.50 formsweb: startProcess: execution failed, trying again using /oracle1/PROD/apps/tech_st/10.1.2/bin/frmweb server webfile=HTTP-0,0,1,default,111.144.104.113
07/06/23 16:01:02.57 formsweb: Getting stdin, stdout and stderr of child process
07/06/23 16:01:02.58 formsweb: New server process created
07/06/23 16:01:02.237 formsweb: Forms session <9> started for VKARIA-lap ( 111.144.104.113 )
07/06/23 16:01:04.255 formsweb: ***********************************************
07/06/23 16:01:04.256 formsweb: Got POST request, length = 8
07/06/23 16:01:04.309 formsweb: HTTP request headers:
07/06/23 16:01:04.315 formsweb: ACCEPT: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
07/06/23 16:01:04.315 formsweb: CACHE-CONTROL: no-cache
07/06/23 16:01:04.315 formsweb: CONNECTION: keep-alive
07/06/23 16:01:04.315 formsweb: CONTENT-LENGTH: 8
07/06/23 16:01:04.315 formsweb: CONTENT-TYPE: application/octet-stream
07/06/23 16:01:04.315 formsweb: COOKIE: ORA_UCM_VER=%2FMP%2F8tgnsj%2Ci_pg_%3Emp_ajc%2CamkMP%2F8relqh*g%5Dne%5D%3Ckn%5D_ha*_kiMP%2F8pckmrcGnMP%2F8naikpaEl; ORA_UCM_INFO=3~EB7BEB414AEC643CE030018A18B92319~Vipul~Karia~vipul.karia@oracle.com~IND~en~39~34~-1~~1; ORA_UCM_SRVC=3*OPN~1~0~//~SE1%3ASE1%3ASE1%3ASE1%3ASE1%3ASE1%3ASE1%3ASE1%3A~*EMP~1~0~/34/~null~*GMO~1~0~/34/~null; oracle.uix=0^^GMT+5:30^p
07/06/23 16:01:04.315 formsweb: HOST: vkaria.idc.oracle.com:8002
07/06/23 16:01:04.315 formsweb: PRAGMA: 1
07/06/23 16:01:04.316 formsweb: USER-AGENT: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_01
07/06/23 16:01:04.316 formsweb: ORACLE-ECID: 1182594664:152.69.208.39:32120:0:2382,0
References
NOTE:384241.1 - Using Forms Socket Mode with Oracle E-Business Suite Release 12
Note:373548.1 - Using Forms Trace in Oracle Applications Release 12
Oracle® Application Server Forms Services Deployment Guide, Section 8, Tracing and Diagnostics, Table 8-2
--------------------------------------------------------------------------------
Related
--------------------------------------------------------------------------------
Products
--------------------------------------------------------------------------------
Oracle E-Business Suite > Applications Technology > Technology Components > Oracle Applications Technology Stack
Keywords
--------------------------------------------------------------------------------
FORMS RUNTIME DIAGNOSTICS; FORMS TRACE; FTRACE.CFG; ICX_FORMS_LAUNCHER; LOGGING TOOLS; SERVLET; TRACEGROUP
Back to top
Rate this document
Article Rating
Rate this document
Excellent
Good
Poor
Did this document help you?
Yes
No
Just browsing
How easy was it to find this document?
Very easy
Somewhat easy
Not easy
Comments
Provide some feedback
Cancel
No comments:
Post a Comment