February 4, 2008 – Persistent Storage Solutions

Upgrading Jinitiator for Oracle Applications 11i

Published on February 4, 2008February 4, 2008 by Advait2 Comments

Oracle JInitiator is basically available on two streams of JDK for Oracle Applications 11i customers. One stream is based on Jinitiator version 1.1.8.X version and another stream is based on 1.3.1.X version. As JDK 1.1.8 has long been de-supported by Sun, Oracle will continue to provide critical updates to Jinitiator 1.1.8 through the de-support date for Release 11.0;

Oracle strongly recommends that Oracle Applications 11i customers move to the latest certified version of JInitiator 1.3.1.x. In some cases, migration to JInitiator 1.3.1.x requires additional technology upgrades.

Many a times you might face a situation where you need to upgrade your Jinitiator version to the latest version available. Also some times users are unable to open the forms. When they click on forms, system constantly ask for jinitiator upgrade, and even after upgrading the Jinititator system keeps on asking to install the same version again and again.

This happens because of fundamental reason — Your client system is not having correct version of Jinitiator then your application is at currently. Example the situation might be that your client PC is having a Jinitiator version of 1.3.1.18 where as your application expects a Jinitiator version of 1.3.1.25. In that case when you click on the forms window it will automatically ask you for installation of required Jinitiator version. But note that installation of required Jinitiator version is only one time job. Next time click on forms should open the forms window correctly.

Reason for asking to install Jinitiator repeatedly is that if your application system is not having a correct version of Jinitiator then it will prompt to install the highest available version with it. If this version happens to be lower version then the required then it will repeatedly as you to install the same Jinitiator version again and again.

This problem has two solutions. First solution is to download the correct version of Jinitiator manually and install in your client PC.

Another solution is to upgrade your Jinitiator version in application system. This will put the correct Jinit exe in your application which will be downloaded and installed first time when you click on forms. With proceeding clicks it will open up the forms correctly.

This post explains about upgrading Jinitiator version of your application system.

For more details, please refer to metalink note ID 124606.1.

Upgrading JInitiator for application system

For upgrading JInitiator version of your application, you need to apply 2 patches as given below depending on your Jinitiator current version.

JInitiator Version	JInitiator Patch	Interop Patch
1.3.1.29	6350285	6169479
1.1.8.27	6612584	6615232

In the JInitiator patch (6350285 or 6612584) , there will be jinit*.exe. You can extract this exe file by unzipping the patch.

Once the exe file is extracted, place the exe file at $COMMON_TOP/util/jinitiator/ directory. This is the place from where the jinitiator will be downloaded in your local client PC.

After placing the exe, apply the interop patch for the respective version using the following steps.

1) Apply the patch driver in the interop patch using AutoPatch.

2) Run the jinit.sh script from the <patch_top>/<interop_patch_number>/fnd/patch/115/bin/ directory, against the web node of your middle tie.

The usage of the script is

jinit.sh <jversion>

Example: jinit.sh 13129
(If you are upgrading to 1.3.1.29 version).

The script will return the appropriate file, or prompt you for the following values:

– Location of APPSORA.env file (This is located in APPL_TOP)

– Location of Context File (echo $CONTEXT_FILE will give the location of context file)

– Password for the APPS User in the database

This will make the necessary changes to the application system and JInitiator version is now upgraded.

You can bounce the services now and access the application. This will download the correct latest JInitiator version that you have upgraded to your local PC and it will install. You will be able to access the forms as well correctly.

You can verify the JInitiator version that you have upgraded by enabling the Jinitiator’s console as per the steps given in metalink note ID 124606.1.

Hope this helps !!

References:

Metalink note ID 124606.1

Changing Forms Servlet mode to Socket mode – E-Business Suite R12

Published on February 4, 2008February 4, 2008 by Advait1 Comment

In E-Business suite R12, by default we have forms servlet mode for opening up the forms. If we check the opmnctl for the OC4J forms services, the forms services are listed as shown below.

-bash-2.05b$ ./adopmnctl.sh status

You are running adopmnctl.sh version 120.4

Checking status of OPMN managed processes…

In servlet mode a java servlet called the Forms Listener Servlet manages the communication between the Forms Java Client and the OracleAS Forms Services. The Forms Listener Servlet communicates through the HTTP server port and does not need extra ports to handle the communication between the client and the Oracle Applicaiton Server Forms Services.

Although this is the preferred method for accessing the forms, in R12 one can also use socket mode connectivity for accessing the forms. In case of socket mode a separate port is configured for client to connect to the server. The connection is not made through Apache port. It means that in case the Apache services are down the forms services will be still up.

This may be required in the following situations:

Customers network topology is multinode and the forms Services are configured on a node different from the node on which Web services(Web Entry Point and Web Applications) are configured.
Customers constrained by network bandwidth, or machine resources may consider socket mode as an alternative to improve performance.
To reduce network traffic. The servlet mode uses http protocol on each transaction between a client and the Forms Server requiring the exchange of cookies and http headers which increases network traffic.
To reduce consumption of resources use by the JVMS needed in servlet mode architecture.

For difference between socket mode of Forms 6i and Forms 10g check metalink node ID 384241.1.

Enabling Forms Socket Mode

Changing forms servlet mode to forms socket mode is very easy. This needs running of just 1 script and bouncing the services.

Follow the below steps for changing from forms servlet mode to forms socket mode. Also note that both these modes cannot co-exits.

1) Stop all services using adstpall.sh present in $ADMIN_SCRIPTS_HOME location.

Note that while stopping this will call adformsctl.sh script for stopping forms services. This is because the current mode is servlet mode.

2) Run the following command to enable Forms Socket Mode:

$FND_TOP/bin/txkrun.pl -script=ChangeFormsMode \ [-contextfile=<CONTEXT_FILE>] \ -mode=socket \ [-port=<Forms port number>] \ -runautoconfig=<No or Yes> \ -appspass=<APPS password>

Example :

$FND_TOP/bin/txkrun.pl -script=ChangeFormsMode \ -contextfile=$INST_TOP/appl/admin/mycontext.xml \ -mode=socket \ -port=9095 \ -runautoconfig=Yes

In this case you can get the forms port number from context file.

Make sure that autoconfig has run successfully and that it has updated the forms launcher in database.

3) start the services using adstrtall.sh present in $ADMIN_SCRIPTS_HOME

Note that this time it will use adformsrvctl.sh script to start the forms. This is the script for starting forms in socket mode.

Executing service control script:
/slot02/appmgr/inst/apps/SCM3R3X3/admin/scripts/adformsrvctl.sh start
script returned:
****************************************************

You are running adformsrvctl.sh version 120.9.12000000.6

Starting FORMS Server in Socket Mode…

adformsrvctl.sh: exiting with status 0

adformsrvctl.sh: check the logfile /slot02/appmgr/inst/apps/SCM3R3X3/logs/ora/10.1.2/forms/socket.log for more information …

You have new mail in /var/spool/mail/appmgr02

.end std out.

.end err out.

After converting to forms socket mode the ICX_FORMS_LAUNCHER will take below form.

<web_protocol>://<web_host>.<web_domain>:<web_port>/OA_HTML/frmservlet

Also adopmnctl.sh will not list the forms process now.

-bash-3.00$ ./adopmnctl.sh status

You are running adopmnctl.sh version 120.4.12000000.3

Checking status of OPMN managed processes…

adopmnctl.sh: exiting with status 0

Hope this helps !!

References:

Metalink note ID 384241.1

Error while starting oacore in R12 – failure looking up ConnectionFactoryJndiName

Published on February 4, 2008 by Advait2 Comments

In case of E-Business suite R12, Some times if the services of middle tier is not stopped properly then there are changes that while bringing up the services it will fail with an error code of 204. Specially this is the case with oacore and oc4j process for forms.

Usually Apache wont cause any problem while coming up.

Following error can be seen in $INST_TOP/log/ora/10.1.3/opmn/oacore_default_group_1/oacorestd.err file.

==========================================================

08/02/03 21:39:32 Error: <connector name=”OracleASjms” path=”OracleASjms.rar” /> will not be bootstrapped since corresponding module declaration was not found in application.xml.
08/02/03 21:39:33 *** (SEVERE) Failed to set the internal configuration of the OC4J JMS Server with: XMLJMSServerConfig[file:/slot/ems1696/appmgr/inst/apps/mz2st121_rws60050rems/ora/10.1.3/j2ee/oacore/config/jms.xml]
08/02/03 21:39:34 Error initializing server: Error initializing ejb-modules: Resource exception(OracleASjms) for MessageDrivenBean event during endpoint activation: failure looking up ConnectionFactoryJndiName:jms/XAQueueConnectionFactory: javax.resource.spi.ResourceAdapterInternalException: Looking up jms/XAQueueConnectionFactory: javax.naming.NameNotFoundException: jms/XAQueueConnectionFactory not found
08/02/03 21:42:28 Error: <connector name=”OracleASjms” path=”OracleASjms.rar” /> will not be bootstrapped since corresponding module declaration was not found in application.xml.

==========================================================

When we start the services, a lock file will be generated for the process and this lock file will persist till the time services are up.

This is a “safety feature” within the lightweight (pure java) OC4J Java Messaging System (JMS) implementation. The OC4J Java Messaging System creates a lock file to constrain access to a specific persistent message store to the single OC4J instance that created it.

The persistence lock file captures information about the OC4J instance that owns or previously owned the persistence store and this information includes the IP address of the owning oc4j instance. During startup if the OC4J Java Messaging System (JMS) discovers that a persistence store it has been configured to use has a lock file that it doesn’t own it will abort the startup procedure to avoid data corruption.When we bring down the services, the lock file will be removed automatically.

Now when the services are not brought down gracefully then in that case the lock file will be still present and this file will create problem when we try to bring up the environment. Because for system, the message store is owned by some other OC4J instance and so it won’t allow any other OC4J instance to start the service.

Solution to this problem is to remove these lock files and start the service. Lock files will be present at the below locations.

In case of OACORE services, lock file will be present at $INST_TOP/ora/10.1.3/j2ee/oacore/persistence/oacore_default_group_1 directory.

Remove all the files under this directory and start the oacore service.

In case even the forms are not opening and giving the same error, then lock files for forms can be located at $INST_TOP/ora/10.1.3/j2ee/forms/persistence/forms_default_group_1 directory and all the files under this directory can be removed. Forms services will come up, once these lock files are removed.

Hope this helps.

References:

Metalink note ID 372412.1

Metalink note ID 398973.1