Forms not launching from self service after migration to new app tier

Raju reported the issue of forms not launching from self service after migration to new desktop. Sure enough it was happening for me too.

192.168.10.188 - - [03/Jun/2009:23:21:22 -0400] "GET /dev60cgi/f60cgi?&appletmode=nonforms&HTMLpageTitle=&HTMLpreApplet=&code=oracle/apps/fnd/formsClient/FormsLauncher.class&width=400&height=100&archive=/OA_JAVA/oracle/apps/fnd/jar/fndforms.jar,/OA_JAVA/oracle/apps/fnd/jar/fndformsi18n.jar,/OA_JAVA/oracle/apps/fnd/jar/fndewt.jar,/OA_JAVA/oracle/apps/fnd/jar/fndswing.jar,/OA_JAVA/oracle/apps/fnd/jar/fndbalishare.jar,/OA_JAVA/oracle/apps/fnd/jar/fndaol.jar,/OA_JAVA/oracle/apps/fnd/jar/fndctx.jar,/OA_JAVA/oracle/apps/fnd/jar/fndlist.jar&gp14=jinit_appletcache&gv14=offjinit_appletcache=off&gp2=resp_app&gv2=SYSADMIN&gp3=resp&gv3=SYSTEM_ADMINISTRATOR&gp4=sec_group&gv4=STANDARD&gp5=function&gv5=FND_FNDCPQCR_SYS&gp6=other_params&gv6=&gp7=forms_url&gv7=http%3A%2F%2F11ioltp.justanexample.com%3A8029%2Fpls%2Ferppgrd2%2Ffnd_icx_launch.runforms%3FICX_TICKET%3D%26resp_app%3DSYSADMIN%26resp_key%3DSYSTEM_ADMINISTRATOR%26secgrp_key%3DSTANDARD%26start_func%3DFND_FNDCPQCR_SYS%26other_params%3D&encoding=UTF-8&gp8=error_url&gv8=http%3A%2F%2Fdev56.justanexample.com%3A8029%2FOA_HTML%2Fjsp%2Ffnd%2Ffnderror.jsp&gp12=port&gv12=6945&gp13=dbc&gv13=dev56&gp15=icx_ticket&gv15=qT_sKHY-DtwzZo6CWStyqg.. HTTP/1.1" 200 42954 0




Do you wish to force regeneration of all jar files? [No] ? Yes


Forcing generation of all product jar files.
Creating and signing every jar file can take about thirty
minutes depending on the hardware being used.
You can watch the file $APPL_TOP/admin/$TWO_TASK/log/adadmin.log to see the progress of jar file generation.

Signing product JAR files in JAVA_TOP -
$OA_JAVA
using entity DEV21_ERPDEV21 and certificate 1.

Successfully created javaVersionFile.

Generating product JAR files in JAVA_TOP -
$OA_JAVA with command:

adjava -mx512m -nojit oracle.apps.ad.jri.adjmx @$APPL_TOP/admin/$TWO_TASK/out/genjars.cmd

After regenerating jar files and logging in as administrator on my laptop, it worked fine. It did not work for Raju as he did not have administrator rights on his laptop.

Forms doesn't launch from self service

Srinivas contacted me about this issue today.  After converting an instance into shared application file system aka shared APPL_TOP, forms were not launching from self service.

I opened a putty session in one window and tailed the apache access log.  On another window I opened Internet Explorer and arranged both side by side.  I logged in successfully. The OA framework page showing responsibilities came up.  I chose System Administrator and clicked on Concurrent Requests.  Internet Explorer stopped there progress bar froze at midway.  Apache access log showed HTTP-403:

192.168.122.10 - - [02/Apr/2009:18:12:03 -0400] "GET /pls/apps11i/fnd_icx_launch.launch?resp_app=SYSADMIN&resp_key=SYSTEM_ADMINISTRATOR&secgrp_key=STANDARD&start_func=FND_FNDCPQCR_SYS&other_params= HTTP/1.1" 403 244 0

I checked the $IAS_CONFIG_HOME/Apache/Apache/conf/httpd_pls.conf file and found these lines:

Allow from apps11i.justanexample.dev.com

This was incorrect.  It should have been:

Allow from apps11i.dev.justanexample.com

Once I corrected this and bounced Apache, no more HTTP-403 errors appeared and forms launched correctly

Oracle Forms Web CGI: Error detected

We faced this error after migrating to shared application file system on one of our dev instances. Forms sessions would not start up through self service or through dev60cgi/f60cgi and report these errors:

Oracle Forms Web CGI: Error detected

Your request cannot be serviced at this time due to the following error:

ERROR: Parameter "userid" not found in URL or configuration parameters.

After a lot of tests I came across Metalink Note: 299206.1 which pointed the cause as:

Cause

This error indicates that the baseHTML (typically this is =%OA_HTML%/US/appsbase.htm)  file for forms has parameters which are not defined in the associated appsweb*.cfg file.

In other words the appsbase.htm and appsweb.cfg are out of sync.

However we followed the steps given to compare and found that appsbase.htm and appsweb.cfg were in sync.  We then checked the versions of appsbase.htm on a different instance and found that the version of appsbase.htm in web tier and concurrently tier were very different.  

$OA_HTML/US/appsbase.htm

$ adident Header appsbase.htm

appsbase.htm:

$Header appsbase.htm 115.40 2008/03/05 06:12:28 upinjark ship $

$ adident Header appsbase.htm.original

appsbase.htm.original:

$Header appsbase.htm 115.9 2001/06/11 19:59:45 pkm ship      $

During migration to shared appl_top we had mistakenly preserved the older appsbase.htm of concurrent tier and did not copy the newer appsbase.htm of web tier.

After copying the latest appsbase.htm from a different instance, the problem was resolved.

Forms doesn't launch from self service

This is one of my favorite problems. I have posted about this problem before. The problem exhibited is same but the cause is always different. Here's the latest one I found. In one of the releases last year, I had tried to push Sun JRE client and replace Jinitiator. At that time, Sun JRE client was an early adopter program and was not certified. During testing, the team faced the lost focus problem and there was so much hue and cry that it was abandoned. In 2008, a new release and a new clone, I am told about a problem where Jinitiator doesn't launch on clicking any of the forms based options. Strangely it works on some PCs and doesn't work on others. It works on all DBA's PCs but doesn't work on the PCs of the people who have to do the actual testing. One common thing I noticed is that on the PCs where this was working, it was working with IE but not with Firefox. Launching with Firefox would give the message, you require to install Sun JRE 1.5.0_07. After almost half a day of trying out different stuff, Akhilesh suggested that we check the appsweb.cfg file and found that it had the plugin=jdk instead of plugin=jinit. Once this was changed to plugin=jinit and Apache was bounced, it started working for everyone. And yes it started working in Firefox browser too. A quick comparison of the context files revealed the variable s_sun_plugin whose value was set to jinit in a working instance and set to jdk in case of this instance.

Forms doesn't launch from self service

I am sure you must have faced this so many times and spent frustating hours debugging it. I'll update this thread with all the possible solutions I have found:

Solution I

Do a ping -s
It should return the correct hostname.domainname
Check whether the hostname.domainname is the value of the context file variable "s_oacore_trusted_oproc_nodes"

grep s_oacore_trusted_oproc_nodes $CONTEXT_FILE

If it is not present, add it in the variable value as ,hostname

Run autoconfig.

Check for the string Allow in Apache configuration files:

grep Allow $IAS_ORACLE_HOME/Apache/Apache/conf/*.conf

Look for the phrase Allow from hostname.domainname

If its not present, add it in all the files.

Bounce Apache

Retest issue

Solution II

vi $IAS_ORACLE_HOME/Apache/Apache/conf/security.conf
Go to end of the file with the vi command: Shift+G
Comment these two lines which begin with SecFilterSelective by placing # before them:

SecFilterSelective "REQUEST_URI" !^/pls/[-a-z0-9_]+/!?[a-z](([a-z0-9_\$#]){0,29})(\.[a-z](([a-z0-9_\$#]){0,29})){0,2}(\?.*
){0,1}$

# Make sure the parameter names contains only valid subset of 7-bit ascii
SecFilterSelective "ARGS_NAMES" !^(([a-z0-9_]){1,30})((\.[a-z0-9_]{1,30}){0,1})$

These lines appear in security.conf after applying ATG_PF.H RUP4 or TXK Rollup O.

Save the file security.conf with vi command :wq

Bounce Apache

Retest issue.

Solution III