Handle Blocking sessions for oracle database

For blocking session most important is to find out which session is getting blocked and which is holding the session.
most of the time seeing one session is blocking many other session so to handle this type of situations use this method to clear the blocks.

steps:
1) select instance_name||' - '||status||' - '||startup_time||' - '||host_name||' - '||sysdate from v$instance;

to confirm the db name are you in correct database.

2) select sid from v$lock where block=1;

this query gives you the sid's which are getting effected.

3) find the sql text for this sessions.

select sql_text from v$sqltext where hash_value=( select prev_hash_value from v$session where sid='&sid');

4) check for the other detials like their sid, serail#, osuser, machine and their status ( Active / Inactive) by passing the sid from previous query of step 2.
check for all sid's from all of the results you may not get any sql text with one sid which will be active in status that is the one main culprit blocking session which is holding lock for other sessions to execute.


select sid||' - '||serial#||' - '||osuser||' - '||username||' - '||machine||' - '||status||' - '||logon_time
from v$session where sid=&123;

Identify the holder session which is active for more confirmation you can also check the holders and waiters.

check holders & waiters:
========================
set pagesize 100
select decode(request,0,'Holder: ','Waiter: ')||sid sess, id1, id2, lmode, request, type from v$lock
where (id1, id2, type) IN (SELECT id1, id2, type from v$lock where request>0) ORDER BY id1, request;

This query results with more details the top one is the holder and others are waiters.
which is notthing but the active session which you can see with the pervous query.

5) kill the holder session

ALTER SYSTEM KILL SESSION '&sid, &serial';

or run this.

SELECT 'alter system kill session ''' || s.sid || ',' || s.SERIAL# || ''';' a,
'ps -ef |grep LOCAL=NO|grep ' || p.SPID SPID,
'kill -9 ' || p.SPID
FROM gv$session s, gv$process p
WHERE ( (p.addr(+) = s.paddr) AND (p.inst_id(+) = s.inst_id))
AND s.sid = &sid;

you will get the result like
alter system kill session '123, 32422';
ps -ef |grep LOCAL=NO|grep 234223
kill -9 234223

use any one of the result to clear the lock.

Most of the time a DBA  can not directly kill the locks, in this situation consult with the application team to clear the lock and use this easy steps to clear the lock.

Workflow Mailer Troubleshooting

Check workflow mailer service current status
  sqlplus apps/<apps password>
  select running_processes
    from apps.fnd_concurrent_queues
   where concurrent_queue_name = 'WFMLRSVC';

  Number of running processes should be greater than 0

 Find current mailer status
  sqlplus apps/<apps password>
  select component_status
    from apps.fnd_svc_components
   where component_id =
        (select component_id
           from apps.fnd_svc_components
          where component_name = 'Workflow Notification Mailer');

  Possible values:
  RUNNING
  STARTING
  STOPPED_ERROR
  DEACTIVATED_USER
  DEACTIVATED_SYSTEM
 Stop notification mailer
  sqlplus apps/<apps password>
  declare
       p_retcode number;
       p_errbuf varchar2(100);
       m_mailerid fnd_svc_components.component_id%TYPE;
  begin
       -- Find mailer Id
       -----------------
       select component_id
         into m_mailerid
         from fnd_svc_components
        where component_name = 'Workflow Notification Mailer';
       --------------
       -- Stop Mailer
       --------------
       fnd_svc_component.stop_component(m_mailerid, p_retcode, p_errbuf);
       commit;
  end;
  /
Start notification mailer
  sqlplus apps/<apps password>
  declare
       p_retcode number;
       p_errbuf varchar2(100);
       m_mailerid fnd_svc_components.component_id%TYPE;
  begin
       -- Find mailer Id
       -----------------
       select component_id
         into m_mailerid
         from fnd_svc_components
        where component_name = 'Workflow Notification Mailer';
       --------------
       -- Start Mailer
       --------------
       fnd_svc_component.start_component(m_mailerid, p_retcode, p_errbuf);
       commit;
  end;
  /

A workflow notification send event (notification email) can fail at several different points, so monitoring it using one method usually is not going to give you a complete picture.Additionally, you have to keep in mind that the process is dynamic, meaning that as transactions are created into the queues they are also mailed out; so a
count of data is at best only a snapshot of a particular moment in time.
 
  Here is a more robust script for monitoring the wf_notifications table:
select message_type, mail_status, count(*) from wf_notifications
where status = 'OPEN'
GROUP BY MESSAGE_TYPE, MAIL_STATUS
messages in 'FAILED' status can be resent using the concurrent request 'resend failed workflow notificaitons'
messages which are OPEN but where mail_status is null have a missing email address for the recipient, but the notification preference is 'send me mail'
 
 Some messages like alerts don't get a record in wf_notifications table so you have to watch the WF_NOTIFICATION_OUT queue.

select corr_id, retry_count, msg_state, count(*)
from applsys.aq$wf_notification_out
group by corr_id, msg_state, retry_count
order by count(*) desc;
Messages with a high retry count have been cycling through the queue and are not passed to smtp service.Messages which are 'expired' can be rebuilt using the wfntfqup.sql

The following SQL to collect all the info except IMAP account password.

select p.parameter_id,
p.parameter_name,
v.parameter_value value
from fnd_svc_comp_param_vals_v v,
fnd_svc_comp_params_b p,
fnd_svc_components c
where c.component_type = ‘WF_MAILER’
and v.component_id = c.component_id
and v.parameter_id = p.parameter_id
and p.parameter_name in (‘OUTBOUND_SERVER’, ‘INBOUND_SERVER’,
‘ACCOUNT’, ‘FROM’, ‘NODENAME’, ‘REPLYTO’,'DISCARD’ ,’PROCESS’,'INBOX’)

How to Enable the Workflow Logging:

From Self Service > Select “Workflow Manager” under “Oracle Applications Manager” > Click “Notification Mailers” > Service Components (Service Components: <SID>) >
b. Click “Workflow Mailer Service” under “Container” Column.
e. From “Service Instances for Generic Service Component Container:<SID>”page, click “Pull Down” button from the Start All/ Stop All.
f . Select Stop All > Go.
g. We conformed that for the Services to read Actual 0 Target 0 and Deactivated.
h. Restart the mailer services using the “Start All” button.
I. We run the following SQL to make sure service are stopped. 
SELECT component_name, component_status, component_status_info
FROM fnd_svc_components_v
WHERE component_name like ‘Workflow%’;
Enable the Statement logging in Workflow Mailer.
Log files are created  $APPLCSF/$APPLLOG/FNDCPGSC*.txt i.e. the log file for the Active process for Workflow Mailer Service and Agent Listener services. 
To retrieve the last 2 log files for Workflow Mailer and Agent Listener services, run the following command:
ls -lt $APPLCSF/$APPLLOG/FNDCPGSC*.txt

How does workflow Notification Mailer IMAP (Inbound Processing) Works:
This is the inbound flow:

1. Approver sends email response which is directed to the value defined in Replyto address.
a. This address has been setup by the customer’s mail administrator to route incoming mail to the IMAP Inbox folder.
2. The Workflow Inbound Agent Listener picks up the message. Only messages which are in ‘unread’ state are evaluated; the rest of the messages in the inbox are ignored.

3. The message is scanned to see if it matches entries in the TAG file . Mail tags are defined in the OAM mailer configuration pages and these list strings of text and actions to take if those strings are encountered. An example of this are ‘Out of Office’ replies. If the string of the message matches a mail tag and the action is ‘Ignore’ then nothing else will happen.

4. The message is then scanned for the presence of a Notification Id (NID). This NID is matched against valid NID for the mailer node.

5. If valid NID is not detected, (and there is no matching TAG file entry) then the message is placed into the DISCARD folder.

6. If a valid NID is detected the listener raises a subscription to the WF_NOTIFICATION_IN queue and places the mail message in the Processed folder.

7. From this point on the message is handled by the product workflow (like PO APPROVAL) . An event created by that group will monitor the WF_NOTIFICATION_IN queue and will trigger the rest of the approval workflow.

Here are steps/events for Oracle Workflow Notification Outbound Processing(eMail from Oracle Applications Workflow to Users)

1.When workflow Engine determines that a notification message must be sent, it raises an event in BES (Business Event System) oracle.apps.wf.notifications.send
Event is raised with Notification ID (NID) as event key

2. There is seeded subscription to this Event

3. Event is placed on WF_DEFERRED agent

4.Event is dequeued from WF_DEFERRED and subscription is processed

5. Subscription places event message to WF_NOTIFICATION_OUT agent.

6.Notification Mailer dequeues message from WF_NOTIFICATION_OUT agent and
6.1convert XML representation of notification into MIME encoded message (Multi-purpose Internet Mail Extensions) and
6.2 Send message by SMTP (Simple Mail Transfer Protocol) to intended user (IfTest Address/Override Address is set then email is sent to Test Address

E-Mail Notification is sent if all below conditions are truea) Notification status is OPEN or CANCELED   and
b) Notification mail_status is MAIL or INVALID  and
c) Recipient Role has a valid e-mail address and Notification Preference is in the format MAIL%
d) Workflow Deferred Agent Listener is running
e) Workflow Notification Mailer is running

To check a) & b) run below query
SELECT status, mail_status  FROM wf_notifications WHERE notification_id = ‘&NID’;

mail_status >> SENT means mail has gone out of mailer to user

To check c) run below query
SELECT email_address, nvl(WF_PREF.get_pref(name, ‘MAILTYPE’),notification_preference)
FROM wf_roles
WHERE name = upper(‘&recipient_role’);

To check d) & e) Use OAM (Oracle Application Manager)

How to purge e-mail notifications from the Workflow queue

Sometimes Due to large number of e-mail notifications to accumulated in the queue Workflow mailer will not start,To fix this issue we need purge the notifications from the Workflow queue.


The below outlines the steps, Please take proper backup before performing the below.

1) You need to update the notifications you do not want sent, in the WF_NOTIFICATIONS table.

2) Check the WF_NOTIFICATIONS table as below. Records where status = ‘OPEN’ and mail_status = ‘MAIL’ are notifications that will have an e-mail notification sent.

SQL> select notification_id,status,mail_status,begin_date from WF_NOTIFICATIONS where status = ‘OPEN’ and mail_status = ‘MAIL’;

3) This should show you which notifications are waiting to be e-mailed.

4) To update a notification so that it will not get e-mailed. Set the MAIL_STATUS = ‘SENT’. The mailer will think the e-mail has already been sent and it will not send it again.

SQL> update WF_NOTIFICATIONS set mail_status = ‘SENT’ where mail_status = ‘MAIL’;

-> This will update all notifications waiting to be sent by the mailer.

5) Then run the script wfntfqup.sql to purge the WF_NOTIFICATION_OUT queue and rebuild it with data currently in the WF_NOTIFICATIONS table. This is what purges all notifications waiting in the queue to be sent.Only the ones where mail_status = ‘MAIL’ and status = ‘OPEN’ will be placed in the WF_NOTIFICATION_OUT queue and sent by the mailer.

SQL>sqlplus apps/apps_pwd @$FND_TOP/patch/115/sql/wfntfqup APPS APPS_PWD APPLSYS

6) Now you can start your WF Containers and then Mailer

Workflow Mailer Debugging Script for Debugging Emails issues

This article contains various Workflow and Business Event debugging scripts.

--Checking workflow Components status whether are they running or stopped.

select component_type, component_name, Component_status,COMPONENT_STATUS_INFO Error
from fnd_svc_components
where component_type like 'WF%'
order by 1 desc,2,3;


Query to get the log file of active workflow mailer and workflow agent listener Container--Note All Workflow Agent Components logs will stored in single file i.e. container log file.

select fl.meaning,fcp.process_status_code, decode(fcq.concurrent_queue_name,'WFMLRSVC', 'mailer container',
'WFALSNRSVC','listener container',fcq.concurrent_queue_name),
fcp.concurrent_process_id,os_process_id, fcp.logfile_name
from fnd_concurrent_queues fcq, fnd_concurrent_processes fcp , fnd_lookups fl
where fcq.concurrent_queue_id=fcp.concurrent_queue_id and fcp.process_status_code='A'
and fl.lookup_type='CP_PROCESS_STATUS_CODE' and fl.lookup_code=fcp.process_status_code
and concurrent_queue_name in('WFMLRSVC','WFALSNRSVC')
order by fcp.logfile_name;


Linux Shell script Command to get outbound error in Mailergrep -i '^\[[A-Za-z].*\(in\|out\).*boundThreadGroup.*\(UNEXPECTED\|ERROR\).*exception.*' <logfilename> | tail -10 ;
--Note: All Mailer log files starts with name FNDCPGSC prefix

Linux Shell script Command to get inbound processing error in Mailer grep -i '^\[[A-Za-z].*.*inboundThreadGroup.*\(UNEXPECTED\|ERROR\).*exception.*' <logfilename> | tail -10 ;

Query to Check Workflow Mailer Backlog --State=Ready implies that emails are not being sent & Waiting mailer to send emails

select tab.msg_state, count(*) from applsys.aq$wf_notification_out tab group by tab.msg_state ;


Check any particular Alert Message email has be pending by Mailer

select decode(wno.state,
0, '0 = Pending in mailer queue',
1, '1 = Pending in mailer queue',
2, '2 = Sent by mailer on '||to_char(DEQ_TIME),
3, '3 = Exception', 4,'4 = Wait', to_char(state)) State,
to_char(DEQ_TIME),
wno.user_data.TEXT_VC
from wf_notification_out wno
where corrid='APPS:ALR'
and upper(wno.user_data.TEXT_VC) like '%<Subject of Alert Email>%';


Check The Workflow notification has been sent or not

select mail_status, status from wf_notifications where notification_id=<notification_id>
--If mail_status is MAIL , it means the email delivery is pending for workflow mailer to send the notification
--If mail_status is SENT, its means mailer has sent email
--If mail_status is Null & status is OPEN, its means that no need to send email as notification preference of user is "Don't send email"
--Notification preference of user can be set by user by logging in application + click on preference + the notification preference


Check Whether workflow background Engine is working for given workflow or not in last 2 days -- Note: Workflow Deferred activities are run by workflow background engine.
select a.argument1,a.phase_code, a.status_code ,a.actual_start_date,a.* from fnd_concurrent_requests a
where CONCURRENT_PROGRAM_ID =
(select concurrent_program_id from fnd_concurrent_programs where
CONCURRENT_PROGRAM_NAME='FNDWFBG')
and last_update_Date>sysdate-2 and argument1='<Workflow Item Type>'
order by last_update_date desc

 Check whether any business event is pending to process 
i.e. Query to get event status & parameters value of particular event in wf_deferred table.

select wd.user_Data.event_name,wd.user_Data.event_key,
rank() over ( partition by wd.user_Data.event_name, wd.user_Data.event_key order by n.name) as serial_no,
n.NAME Parameter_name, N.value Parameter_value ,
decode(state, 0, '0 = Ready', 1, '1 = Delayed', 2, '2 = Retained',
3, '3 = Exception', 4,'4 = Wait', to_char(state)) state,
wd.user_Data.SEND_DATE,
wd.user_Data.ERROR_MESSAGE,
wd.user_Data.ERROR_STACK,
wd.msgid,wd.delay
from WF_DEFERRED wd , TABLE(wd.user_Data.PARAMETER_LIST) n
where lower(wd.user_data.event_name)='<event Name >'
order by wd.user_Data.event_name, wd.user_Data.event_key, n.name

When the workflow mailer is either disabled or the mail server restricts its access to the workflow mailer, all the workflow notifications will retry and upto the limit set at the workflow mailer configuration and later all the notifications will be failed. This will result in 2 things at Application level

i) MAIL_STATUS column of the WF_NOTIFICATIONS set to FAILED. 

ii) After a series of failure notifications the Notification Style for the respected User will be set as Disabled and a corresponding user details are sent to SYSADMIN.

A similar issue araised in one of the client and the many of the users notification style has been set to Disabled.

Solution:

To overcome the above issue, initially fix the workflow mailer issue and later need to change the Notification Preference at Workflow Administrator to "HTML with Attachments" (or any other as per the client's requirement).

But sometime this setting won't be affected to all the users whose Preference is set to Disabled. To overcome this situation:

i) Backup the following tables:

CREATE FND_USER_PREFERENCES_BAK as select * from FND_USER_PREFERENCES;

CREATE WF_LOCAL_ROLES_BAK as select * from WF_LOCAL_ROLES;

ii) To set the mail preference for all the users execute the following:

update wf_local_roles
set notification_preference='<wished_preference>'
where orig_system in ('FND_USR','PER');

update fnd_user_preferences
set preference_value='<wished_preference>'
where preference_name='MAILTYPE'
and module_name='WF'
and user_name <> '-WF_DEFAULT-'; 

iii) To update the mail preference of the users only whose preference is set to "FAILED", execute the below steps:

 update wf_local_roles
set notification_preference='<wished_preference>'
where orig_system in ('FND_USR','PER')
and name in
(select user_name
from fnd_user_preferences
where preference_name='MAILTYPE'
and module_name='WF'
and preference_value='DISABLED');

update fnd_user_preferences
set preference_value='<wished_preference>'
where preference_name='MAILTYPE'
and module_name='WF'
and preference_value='DISABLED';

Possible values for <wished_preference> are:

QUERY (corresponds to preference value "Do not send me mail")
MAILTEXT (corresponds to preference value "Plain text mail")
MAILATTH (corresponds to preference value "Plain text mail with HTML attachments")
MAILHTML (corresponds to preference value "HTML mail with attachments")
MAILHTM2 (corresponds to preference value "HTML mail")
SUMMARY (corresponds to preference value "Plain text summary mail")
SUMHTML (corresponds to preference value "HTML summary mail")
DISABLED (corresponds to preference value "Disabled")

iii) To Resend all the failed notifications again to the respected users run the following concurrent program as SYSADMIN, with the relevant parameters.

Retry Errored Workflow Activities 

Log file location in Oracle Apps 11i/R12

The following log files location could help you to find-out issues and errors from your application 11i instance.

Database Tier Logs are

Alert Log File location:

$ORACLE_HOME/admin/$CONTEXT_NAME/bdump/alert_$SID.log

Trace file location:

$ORACLE_HOME/admin/SID_Hostname/udump

Application Tier Logs

Start/Stop script log files location:

$COMMON_TOP/admin/log/CONTEXT_NAME/ 

OPMN log file location

$ORACLE_HOME/opmn/logs/ipm.log

Apache, Jserv, JVM log files locations:

$IAS_ORACLE_HOME/Apache/Apache/logs/ssl_engine_log

$IAS_ORACLE_HOME/Apache/Apache/logs/ssl_request_log

$IAS_ORACLE_HOME/Apache/Apache/logs/access_log

$IAS_ORACLE_HOME/Apache/Apache/logs/error_log

$IAS_ORACLE_HOME/Apache/JServ/logs

Concurrent log file location:

$APPL_TOP/admin/PROD/log or $APPLLOG/$APPLCSF

Patch log file location:

$APPL_TOP/admin/PROD/log

Worker Log file location:

$APPL_TOP/admin/PROD/log

AutoConfig log files location:

Application Tier:

$APPL_TOP/admin/SID_Hostname/log//DDMMTime/adconfig.log

Database Tier:

$ORACLE_HOME/appsutil/log/SID_Hostname/DDMMTime/adconfig.log

Error log file location:

Application Tier:

$APPL_TOP/admin/PROD/log

Database Tier :

$ORACLE_HOME/appsutil/log/SID_Hostname

In Oracle Applications R12, the log files are located in $LOG_HOME (which translates to $INST_TOP/logs)

Below list of log file locations could be helpful for you:

Concurrent Reqeust related logs

$LOG_HOME/appl/conc - > location for concurrent requests log and out files

$LOG_HOME/appl/admin - > location for mid tier startup scripts log files

Apache Logs (10.1.3 Oracle Home which is equivalent to iAS Oracle Home - Apache, OC4J and OPMN)

$LOG_HOME/ora/10.1.3/Apache - > Location for Apache Error and Access log files

$LOG_HOME/ora/10.1.3/j2ee - > location for j2ee related log files

$LOG_HOME/ora/10.1.3/opmn - > location for opmn related log files

Forms & Reports related logs (10.1.2 Oracle home which is equivalent to 806 Oracle Home)

$LOG_HOME/ora/10.1.2/forms

$LOG_HOME/ora/10.1.2/reports

Startup/Shutdown Log files location:

$INST_TOP/apps/$CONTEXT_NAME/logs/appl/admin/log

Patch log files location:

$APPL_TOP/admin/$SID/log/ 

Clone and AutoConfig log files location in Oracle E-Business Suite Release 12 

Logs for the adpreclone.pl are located: 

On the database tier: 

RDBMS $ORACLE_HOME/appsutil/log/< context >/StageDBTier_< timestamp >.log 

On the application tier: 

$INST_TOP/admin/log/StageAppsTier_< timestamp >.log 

Where the logs for the admkappsutil.pl are located? 

On the application tier: 

$INST_TOP/admin/log/MakeAppsUtil_< timestamp >.log 

MWA Services in Oracle Apps

Login as applmgr user :
Go to $ADMIN_SCRIPTS_HOME

Stop Mobile Application Services :

./mwactl.sh -login apps/apps_password stop_force
./mwactlwrpr.sh stop apps/apps_password

Start Mobile Application Services :

./mwactl.sh -login apps/apps_password start
./mwactlwrpr.sh start apps/apps_password

Check Mobile Services are up and Runing:

ps -ef | grep mwa

Find port Number of Mobile Services :

grep mwa $CONTEXT_FILE

Connect to Mobile Services :
telnet hostname.domainname portnumber(mobile application service port_number)
++++++++++++++++++++++++++++++++++++

Hot to configure Mobile applications on EBS – 11i

++++++++++++++++++++++++++++++++++++

1. Stop the current servers.

a. $ cd $MWA_TOP/bin

b. $ nohup mwactl.sh -login SYSADMIN/sysadmin1 stop 10260

    $ netstat -na  | grep 10260

c. $ ./mwactl.sh stop_dispatcher

2. Verify that MWA servers are stopped.

a. $ ps -ef | grep mwa

b. No processes should be found.

3. Locate the mwa.cfg file in the $MWA_TOP/secure directory.

4. Edit the mwa.cfg file and configure following parameters

a. Set mwa.DbcFolder=full directory of folder containing the .dbc file ending with “/”:

mwa.DbcFolder=/d01/oracle/SVRSUPTappl/fnd/11.5.0/secure/SVRSUPT_svrsuptsql1

b. Set mwa.DbcFile=dbc file name with extension:

mwa.DbcFile=SVRSUPT

c. Set mwa.logdir=full directory of log file without the trailing “/”:

mwa.logdir=/d01/oracle/SVRSUPTcomn/admin/log/SVRSUPT_svrsuptsql1

d. Set mwa.LogLevel=error or trace:

mwa.LogLevel=error

e. Set mwa.TelnetPortNumber=port number

mwa.TelnetPortNumber=10240

f. Set mwa.DropConnectionTimeout= no. of minutes:

mwa.DropConnectionTimeout=5

g. Set mwa.StaleSessionTimeout= no. of minutes:

mwa.StaleSessionTimeout=60

h. Specify the port number and machine for running the dispatcher:

mwa.Dispatcher=svrsuptsql1.d-rco.com:10328

i. Specify the server manager telnet server information

mwa.TelnetServer=svrsuptsql1.d-rco.com:10260;10262

5. Start the MWA telnet servers

a. $ cd $MWA_TOP/bin

b. $ nohup ./mwactl.sh start 10260 &

6. Start the dispatcher

a. $ nohup ./mwactl.sh start_dispatcher &

++++++++++++++++++++++++++++++++

how to check it is working or not:
Start  à  Run à cmd à telnet hostame:portnumber  ß press enter  , it will show 4 options select , appropriate option & give username & password.

++++++++++++++++++++++++++++++++

Resolving "JInitiator version too low" Errors in EBS Environments

Oracle JInitiator 1.3 was desupported for E-Business Suite environments at the end of July 2009.  JInitiator 1.1.8 was desupported at the end of December 2008. E-Business Suite users should have switched from Oracle JInitiator to the native Java JRE plug-in at that time.

Some users might be seeing confusing error messages like this:

FRM-92095: Oracle Jlnitiator version too low. Please install version 1.1.8.2 or higher.

Details:
Java Exception: oracle.forms.engine.RunformException: FRM-92095: oracle Jlnitiator version too low. Please install version 1.1.8.2 or higher.

at oraclr.forms.net.HTTPConnection.<init>(Unknown Source)
at oraclr.forms.engine.FormsDispatcher.initConnection(Unknown Source)
at oraclr.forms.engine.FormsDispatcher.init(Unknown Source)
at oraclr.forms.Runform.initConnection(Unknown Source)
at oraclr.forms.Runform.startRunForm(Unknown Source)
at oraclr.forms.Main.createRunform(Unknown Source)
at oraclr.forms.Main.start(Unknown Source)
at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.start(Unknown Source)
at sun.plugin2.applet.plugin2Manager$AppletExecutuonRunnable.run(Unknown Source)
at java.lang.Thread.run(Threat.java.722)

What's causing this error?

This error message may occur if you try and launch an E-Business Suite form using the JRE 7 client plug-in without applying the prerequisite Forms patch needed to enable JRE 7 compatibility.

What's needed to enable EBS environments for JRE 7?
EBS customers should ensure that they are running the latest JRE 7 plug-in, at minimum, on Windows desktop clients.  If you've reached this article via a search engine, please check our Certifications summary page for the latest certified JRE 7 release.

Of the compatibility issues identified with JRE 7, the most critical is an issue that prevents E-Business Suite Forms-based products from launching on Windows desktops that are running JRE 7. 

Customers can prevent this issue -- and all other JRE 7 compatibility issues -- by ensuring that they have applied the latest certified patches documented for JRE 7 configurations to their EBS application tier servers.  These are summarized here for convenience. If the requirements change over time, please check the Notes for the authoritative list of patches: 

1. Apply Forms patch 14615390 to EBS 11i environments (Note 125767.1)
2. Apply Forms patch 14614795 to EBS 12.0 and 12.1 environments (Note 437878.1)

These patches are compatible with JRE 6 and 7, production ready, and fully-tested with the E-Business Suite.  These patches may be applied immediately to all E-Business Suite environments. All other Forms prerequisites documented in the Notes above should also be applied. 

Where are the official patch requirements documented?
All patches required for ensuring full compatibility of the E-Business Suite with JRE 7 are documented in these Notes:

For EBS 11i: 

• Deploying Sun JRE (Native Plug-in) for Windows Clients in Oracle E-Business Suite Release 11i (Note 290807.1)
• Upgrading Developer 6i with Oracle E-Business Suite 11i (Note 125767.1)

For EBS 12

• Deploying Sun JRE (Native Plug-in) for Windows Clients in Oracle E-Business Suite Release 12 (Note 393931.1)
• Upgrading OracleAS 10g Forms and Reports in Oracle E-Business Suite Release 12 (Note 437878.1)

Obtaining Forms Runtime Diagnostics (FRD) In Oracle Applications

A. Introduction

When starting a Forms-based session in Applications it is possible to pass various useful parameters like formname=xyz, or lang=US, or NLS=xyz etc. This is really helpful when debugging Forms. In addition, there are two other parameters config=debug and record=all which make it possible to perform Forms Runtime Diagnostics (FRD.)

FRD is a runtime event-based logging system intended to aid in the debugging of Forms applications. FRD is enabled at runtime on a user by user basis.  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.

<>FRD generates extensive output useful for analysis and debugging, and it is therefore recommended FRD be utilized as a logging mechanism only when specific issues are encountered.
 

B. The Contents of an FRD Log File

The following data is typically collected in an FRD trace file:

- Trigger firing: includes name and hierarchical location.

- Built-in Execution: includes name and IN and OUT parameter types and values.

- Messages: includes message numbers and text.

- The opening of forms executables (.fmx) and menu executables (.mmx)

- Unhandled exceptions: includes error message if available, otherwise only
   error numbers.

- All external user events via normal runtime (RT) recording mechanism

To see more details about the expected output in Forms, please see
<Note:62664.1> Forms Server Logging and Forms Runtime Diagnostics (FRD) Explained.

C. Tracing in R12

1. Set the user value for profile option  'ICX: Forms Launcher' to be

   'http://hostname.domain:port/forms/frmservice?record=forms'

2. By default, this will enable tracing for errors only. As an optional step, you can enable different trace options (e.g. user actions, user-exit events, dbsql events, network events) by setting a trace group in file $ORA_CONFIG_HOME/10.1.2/forms/server/ftrace.cfg 

3. Login to the Personal Home Page,  navigate to the form and perform the steps that you wish to trace.

4. Locate the file in the directory set by variable FORMS_TRACE_DIR. Note: by default, this directory is named forms_<pid>.trc, where <pid> is the process identifier.

Related reference:
<Note:373548.1> Using Forms Trace in Oracle Applications Release 12.

D. Tracing in 11.5.10

1. Make the user value for profile option  'ICX: Forms Launcher' the same as the site value

   e.g. copy value of ICX: Forms Launcher for the site Test115
   'http://testserver.oracle.com:8005/dev60cgi/f60cgi'
    to be the value for the user.

2. Append the user value of ICX: Forms Launcher with the Forms parameters for FRD

   e.g. update the value of  ICX: Forms Launcher for the user to be
   'http://testserver.oracle.com:8005/dev60cgi/f60cgi?record=all&log=/tmp/username_frd.log'

3. Login to the Personal Home Page,  navigate to the form and perform the steps that you wish to trace.

4. Locate the file in the directory set by variable $FORMS60_TRACE_PATH. Note: the default directory for
$FORMS60_TRACE_PATH is $ORACLE_HOME/forms60/log.

Related reference:
<Note:290210.1> Forms FRD Trace With New Variable FORMS60_TRACE_PATH. 

E. FRD Tracing in 11.5.x to 11.5.9

This method enables users to run FRD tracing through the Personal Home Page by setting debugging to true using the profile option 'ICX: Forms Launcher'.

When accessing Applications through the Personal Home Page (PHP), there is no way to pass command line parameters such as config=debug and record=all for the duration of a single session. For example, you cannot add these variables to the PHP connect string
http://testserver.oracle.com/OA_HTML/US/ICXINDEX_test115.htm.

The advantages of using the profile option 'ICX: Forms Launcher' are that you can easily trace the activities of multiple users and assign different log file names.

With Oracle Developer Forms patch 16 and higher, users cannot create adhoc FRD trace files in any directory. The trace files are either created in the directory set by parameter $FORMS60_TRACE_PATH or they are created in 8.0.6 $ORACLE_HOME/forms60/log directory.

Steps:

To start tracing in this way, modify Profile Option 'ICX: Forms Launcher' at USER level to include the Forms parameters required for FRD logging:

1. Make the user value for profile option  'ICX: Forms Launcher' the same as the site value

   e.g. copy value of ICX: Forms Launcher for the site Test115
   'http://testserver.oracle.com:8005/dev60cgi/f60cgi' to be the value for the user.

2. Append the user value of ICX: Forms Launcher with the Forms parameters for FRD

   e.g. update the value of  ICX: Forms Launcher for the user to be
  'http://testserver.oracle.com:8005/dev60cgi/f60cgi?record=all&log=/tmp/username_frd.log'

3. Save this change at the USER level, and the next time you access the test115 database through PHP, the Forms variables will be enabled.

E. Points to Consider When Running FRD

1. Check that sufficient space exists in the directory in which the FRD log file is to be created

2. For each run of FRD, specify a different log file name. The FRD log file will replace an existing file of the same filename.

3. On certain platforms, the log file is only created after the user exits Applications. Therefore, remember to exit Applications.

4. If no file name is specified for FRD, a unique file name is used based on the operating system process ID. The file is created in the current working directory. The file may be overwritten if the operating system reuses the process ID.

5. The log file is likely to be hundreds of lines long. To keep the content of the trace file to a minimum amount, follow the steps to reproduce a problem precisely and avoid performing any other actions. This is particularly helpful when using for troubleshooting purposes.

6. Specify the tmp directory for the log file location since all users usually have permission to write to it.

7. In a multi-node environment, the trace file is created on the Applications tier. 

8. It is recommended to pass FRD variables at the USER level and not at the SITE level since SITE level affects all users.

9. Please create your own user to set this value. Please do not enable FRD for user 'vision' or any of the seeded users since you will then start FRD logs for all people using those login accounts.

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

F. Extracts From an FRD Log File For 11i

Below displays brief extracts from a log file. The FRD documents the steps executed from Forms when signing on to Applications 11i and navigating to a form within core Applications.

Forms Runtime Diagnostic Collection Log
File Name: /tmp/form1.frd
Process ID: 19166
Client IP: @  x
Forms 6.0 (Forms Runtime) Version 6.0.8.12.1 (Production)
PL/SQL Version 8.0.6.1.0 (Production)
Oracle Virtual Graphics System Version 6.0.5.36.0 (Production)
Oracle Multimedia Version 6.0.5.33.0 (Production)
Oracle Tools Integration Version 6.0.5.32.0 (Production)
Oracle Tools Common Area Version 6.0.5.32.0
Oracle CORE Version 4.0.6.0.0 - Production

Opened file: /stable/oracle/vis006/vis006appl/fnd/11.5.0/forms/US/FNDSCSGN.fmx

ON-LOGON Trigger Fired:
Form: FNDSCSGN

State Delta:
FORM FNDSCSGN
  STATUS     NEW
  BLOCK PROGRESS_INDICATOR
    STATUS     NEW
    RECSTATUS  ""
    FIELD TEXT
      CANVAS     PROGRESS_INDICATOR
      GEOMETRY   100,250:4000,400
      ENABLED    TRUE
      NAVIGABLE  TRUE
      INSERTABLE TRUE
      QUERYABLE  TRUE
      UPDATEABLE TRUE
...
WHEN-NEW-ITEM-INSTANCE Trigger Fired:
Form: FNDSCSGN
Block: SIGNON
Item: USERNAME
...
WHEN-BUTTON-PRESSED Trigger Fired:
Form: FNDSCSGN
Block: SIGNON
Item: CONNECT_BUTTON
...
MENU_TO_APPCORE Trigger Fired:
Form: FNDNLDLG
...
CLOSE_WINDOW Trigger Fired:
Form: FNDNLDLG
...
Executing DO_KEY Built-in:
In Argument 0 - Type: String   Value: EXIT_FORM

KEY-EXIT Trigger Fired:
Form: FNDSCSGN
...