Phase in the Sun JRE plug-in

By now you probably know error correction support ends for JInitiator for E-Business Suite on July 31, 2009 (see Metalink note 552692.1). There has been a lot of strong encouragement from Oracle to migrate to the Sun JRE Native plug-in prior to the de-support date:

Note 393931.1: Deploying Sun JRE (Native Plug-in) for Windows Clients in Oracle E-Business Suite Release 12

Note 290807.1: Deploying Sun JRE (Native Plug-in) for Windows Clients in Oracle E-Business Suite 11i

Having gone through several of these migrations for various clients, I would recommend caution and thorough testing; there are several nuances to the Sun JRE that in many shops did not apply to JInitiator.

First, it is likely that more than one E-Business Suite user already has some version of the Sun JRE installed on their desktop; this version may or may not be the version you have tested and deployed for E-Business Suite. The plug-in version selection is browser dependent and the subject of much discussion both on the notes listed above (see the sections on Static Versioning) and various discussion boards, forums, and bug notes. Second, the Sun JRE may or may not be compatible with some of your shop’s desktop operating systems; the JRE plug-in and JInitiator do not have exactly the same certification matrices, so a desktop that worked fine with JInitiator may not work at all with Sun JRE. Finally, beyond Oracle’s certified plug-in and desktop operating system combinations detailed in the migration notes above, video hardware incompatibilities may create crippling performance problems or render forms unusable.

The purpose of this article is not to detail the specifics of these issues; the problems you may or may not experience migrating to the JRE have too many local dependencies to list in one note. Indeed, each of the 11i and R12 migration notes contain a “Known Issues” section that should be carefully read and considered for your environment.

The purpose of this article is to expand on a simple trick that will allow you to phase in the JRE over a period of time (on a user-by-user basis if necessary) so that you do not have to ensure 100% desktop compatibility before deployment.

When a user logs in to E-Business Suite, the plug-in used is controlled by the profile option ICX: Forms Launcher. Typically, ICX: Forms Launcher will be set at the Site level and all users will inherit the default value:

http://ap123abc.us.oracle.com:8001/dev60cgi/f60cgi

If this is the case, the default plug-in specified in your context file will be used to launch forms. You can, however, override the default by specifying a different value for ICX: Forms Launcher at the User level.

Once you migrate to Sun JRE, ICX: Forms Launcher will default to the Sun JRE for all users. If some users experience trouble with the JRE for any reason, you may wish to selectively roll them back to JInitiator. You can do this by creating a JInitiator plug-in profile in appsweb.cfg and overriding ICX: Forms Launcher at the user level.

1. To revert back to JInitiator for an individual user, perform the following steps:
Copy $FND_TOP/admin/template/appsweb.cfg to a custom template file at $FND_TOP/admin/template/custom/appsweb.cfg. Create the custom subdirectory if it doesn’t exist already; this method will ensure your customized template will be picked up by autoconfig and not overwritten by a patch. If you already have a custom template, perform the next steps against your custom template.
2. At the end of the custom appsweb.cfg template, add an entry below the [myExtensions] section as follows:

connectMode=socket
serverPort=9001
jinit_name=jinit13128.exe
jinit_classid=clsid:CAFECAFE-0013-0001-0028-ABCDEFABCDEF
jinit_ver_name=Version=1,3,1,28
jinit_mimetype=application/x-jinit-applet;version=1.3.1.28
plugin=jinit
;

3. Substitute the correct version of JInitiator, serverPort, and executable name for your install.

4. Run autoconfig to propagate the changes.

5. Now, set the ICX: Forms Launcher value for a user experiencing trouble:

http://ap123.us.oracle.com:8001/dev60cgi/f60cgi?config=J13128

6. When the user logs in again, the JInitiator will launch instead of the JRE. Keep in mind, the plug-in executable specified by the jinit_name token must be found in $OA_HTML for new users to find it.

This is great for a single user or a few troubles desktops, but what if you have dozens or hundreds of desktops in your shop? What if dozens of users experience trouble, and you, Constant Apps DBA, do not have time or ability to troubleshoot each problem all at once? Do you hold up the entire JRE rollout?

Depending on how many users cannot use the Sun JRE right away, you may choose to set ICX: Forms Launcher to the JInitiator at the Site level, and individually enable only those JRE users that don’t have trouble:

To revert back to JInitiator for the entire install, perform the following steps:

1. Perform steps 1 though 4 above.

2. Set the ICX: Forms Launcher value at the Site level:

http://ap123.us.oracle.com:8001/dev60cgi/f60cgi?config=J13128

Now all future logins will use the old JInitiator instead of JRE. To allow individual users to use JRE, simply update their ICX: Forms Launcher values to the default value:

http://ap123.us.oracle.com:8001/dev60cgi/f60cgi

This method is a simple way of allowing you to control when you deal with desktop plug-in issues. The JRE is coming and we all must comply; however, we can decide if we want to fix all problems before rollout, or perform a phased rollout and troubleshoot individual issues without interrupting other users by employing one of the techniques above.