Tuesday, March 8, 2011

Cloning SSO-Enabled Environments in E-Business Suite


This is already discussed in Steven Chan's Blog article http://blogs.oracle.com/stevenChan/2006/05/11/ and much of this note is a straight copy from this article.  Please review this blog article in it's entirety before proceeding.

If you're willing to experiment a bit, the following are general guidelines to point you in the right direction.  Some customers and Oracle Consultants have used the following approaches to get the job done but have reported that there was some trial-and-error involved.

These are neither detailed nor comprehensive instructions.  The following should be attempted only by system administrators who have a solid understanding of the principles outlined in Metalink Note 261914.1.

If you're going to experiment with these approaches, I strongly recommend that you take all sensible precautions, including backing up your environments at multiple stages, taking careful notes, and doing things in small, incremental steps to control your risk.

There is no single stop, supported or documented method to create a clone of your eBiz instance when integrated with SSO.   Please use this note with caution and make sure you thoroughly test any procedure you decide to use to ensure it fits with all aspects of your specific setup.

1- Use Rapid Clone to create a clone of your E-Business Suite, including the application-tier and database-tier.
   For 11i, please use:
     Note 230672.1 Cloning Oracle Applications Release 11i with Rapid Clone
  
   For R12 ,please use:
     Note 406982.1   Cloning Oracle Applications Release 12 with Rapid Clone

2- In the  newly-cloned E-Business Suite instance, set the APPS_SSO_LDAP_SYNC profile option to "Disabled" at the site level (since there's no new Oracle Internet Directory instance to synchronize with yet).

3 -  In your newly-cloned E-Business Suite instance, unlink all E-Business Suite users that were linked to the original Oracle Internet Directory 10g users (i.e. where FND_USER.USER_GUID is populated), since the those old links are no longer valid. Those E-Business Suite users will need to be linked to their corresponding accounts in the as-yet non-existent new Oracle Internet Directory instance.

To Unlink EBS users, you should execute the following Command for each individual user (For both 11i and R12):

$FND_TOP/patch/115/sql/fndssouu.sql

See Note 429375.1 for more information on this utility

4 -  In your newly-cloned E-Business Suite instance, remove all reference to the original OID/SSO instance

Use the “removereferences” to cleanup the previous registration information of SSO & OID

For R12 this is described in Note 376811.1 "Section 3: Remove References"

For 11i :  Note 233436.1  "Appendix D:  Advanced Configuration - Manual SSO/OID Registration" - Option 6

5 -  Create a fresh install of Single Sign-On and Oracle Internet Directory 10g on your new server.

6 - Assuming that you enabled bidirectional provisioning between the E-Business Suite and Oracle Internet Directory, do one of the following (but not all three):

a) Redo your bulkload from the E-Business Suite into Oracle Internet Directory.
   On Release 12, please refer to "System Administrator's Guide - Security" on Section 6 (Oracle Single Sign-On Integration )

Then  Reregister your E-Business Suite environment using the Bidirectional Provisioning Profile, and enable the APPS_SSO_AUTO_LINK_USER profile option, and set the profile option APPS_SSO_LDAP_SYNC back to Enabled at site level.

b) Export your LDAP namespace from your original Oracle Internet Directory instance into an LDIF file, and then import the LDIF file into the new Oracle Internet Directory instance. Reregister your E-Business Suite environment using the Bidirectional Provisioning Profile, and (assuming that the Oracle Internet Directory accounts are identical to the E-Business Suite accounts) enable the APPS_SSO_AUTO_LINK_USER profile option, and set the profile option APPS_SSO_LDAP_SYNC back to Enabled at site level.

c) Connect the original Oracle Internet Directory instance to your new Oracle Internet Directory instance via a connector, synchronizing the namespaces. Reregister your E-Business Suite environment using the Bidirectional Provisioning Profile, and (assuming that the Oracle Internet Directory accounts are identical to the E-Business Suite accounts) enable the APPS_SSO_AUTO_LINK_USER profile option, and set the profile option APPS_SSO_LDAP_SYNC back to Enabled at site level.

Is it Possible to Clone an SSL Enabled E-Business Suite Middle Tier?

The Rapidclone utility does not support like for like cloning of an SSL enabled E-business suite middle tier.
Note 230672.1 Cloning Oracle Applications Release 11i with Rapid Clone
Note 406982.1 Cloning Oracle Applications Release 12 with Rapid Clone

The problem can be broken down into 3 issues

1:- File system changes.

The location of the SSL files on the clone is different to that from the source. From the bug we can see the following were not the same between source and target.

s_frmWalletDir
s_web_ssl_directory
s_web_ssl_keyfile
s_web_ssl_certfile
s_web_ssl_certchainfile

2:- SSL Port is wrong in the clone.

s_webssl_port - Gets Defaulted to 443, ideally it should take Apache Port given during adcfgclone run.

3:- SSL certificates are the same on the clone as they are on source.

This might be a security issue depending on your security requirements.

However Rapidclone will create a clone of an SSL enabled middle tier, but the target will require additional configuration to allow it to function correctly. To progress the issue further you must decide if

A:- You want the middle tier clone to be SSL enabled.

Re-implement SSL on the clone following the note below.

Note 123718.1 11i: A Guide to Understanding and Implementing SSL for Oracle Applications

B:- You want the middle tier clone to be HTTP only.

Remove the SSL configuration added in

Note 123718.1 11i: A Guide to Understanding and Implementing SSL for Oracle Applications

Should I Implement a Shared Appl Top? And if so How?

1:- Is it recommended to implement a shared APPL_TOP?

Both single APPL_TOP and shared APPL_TOP are supported. Full details of the requirement can be found in

Note.233428.1 Sharing the Application Tier File System in Oracle Applications Release 11i
Note.384248.1 Sharing The Application Tier File System in Oracle E-Business Suite Release 12

There is no official Oracle support document that would recommend a shared APPL_TOP over a normal APPL_TOP. The DBA and the business need to decide if the costs and factors involved in implementing a shared file system, outweigh the benefits (reduced patching time etc)

However there is a very good blog article by the Oracle E-Business suite integrations team that explains the choices and benefits of using a shared APPL_TOP.

Choosing a Shared File System for Oracle E-Business Suite
http://blogs.oracle.com/stevenChan/2009/07/choosing_an_ebs_shared_file_system.html

There is also some good information in

Reducing Patching Downtimes via Shared Apps File Systems
http://blogs.oracle.com/stevenChan/2007/05/reducing_patching_downtimes_vi.html

2:- What are the requirements from the Backend?

This is an area that Oracle support is unable to help you with, other than tell you that you need to have a storage system that can mount drives to multiple servers. Full detail of Oracle's position on this can be found in

Choosing a Shared File System for Oracle E-Business Suite
http://blogs.oracle.com/stevenChan/2009/07/choosing_an_ebs_shared_file_system.html

The issue generally come down to how much money you have for the storage system. NFS for example is very cheap but the NFS mount can be classed as a single point of failure (e.g. NFS mount goes down, all E-business suite middle tiers go down).

How to Gather Statistics on Custom Schemas for Ebusiness Suite 11i and R12?



To gather statistics for Oracle Applications Ebusiness Suite 11i or R12 modules you should use the concurrent programs 'Gather Schema Statistics', 'Gather Table Statistics', or run 'FND_STATS'.

In order to run the programs 'Gather Schema Statistics', 'Gather Table Statistics', or run 'FND_STATS'  for a custom schema, the schema must be registered with the Application.

To register an schema with Oracle Applications, follow the steps listed in
Note 176852.1 - Integrating Custom Applications with Oracle Applications

If the custom schema is not registered, it will not show up in the LOV for schema selection for the mentioned concurrent programs.

You can run the following statement to see which schemas are currently registered with the Ebusiness Suite:


select   distinct(upper(oracle_username)) sname
from     fnd_oracle_userid a, fnd_product_installations b
where    a.oracle_id = b.oracle_id
order by sname;