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;

Compile forms in Release 12

Follow the instructions below to compile your forms in Release 12
1:- Log into the forms tier.
2:- Set the applications environment
3:- Ensure that the $FORMS_PATH includes $AU_TOP/resource and $AU_TOP/resource/stub, for example

echo $FORMS_PATH

/u01/oracle/TEST/apps/apps_st/appl/au/12.0.0/resource:
/u01/oracle/TEST/apps/apps_st/appl/au/12.0.0/resource/stub

4:- Compile the form
a:- If you are using forms customizations (CUSTOM.pll) then run the command below to compile the form.

frmcmp_batch.sh module=<path to fmb file> userid=APPS/APPS output_file=<full path to fmx output file> module_type=form compile_all=special

For eg:-

frmcmp_batch.sh module=/u01/oracle/TEST/apps/apps_st/appl/au/12.0.0/forms/US/XXX.fmb userid=APPS/APPS output_file=/u01/oracle/TEST/apps/apps_st/appl/inv/12.0.0/forms/US/XXX.fmx module_type=form compile_all=special

b:- If you are NOT using forms customizations, then run the command below to compile the form.

frmcmp_batch.sh module=<path to fmb file> userid=APPS/APPS output_file=<full path to fmx output file> module_type=form

For example..

frmcmp_batch.sh module=/u01/oracle/TEST/apps/apps_st/appl/au/12.0.0/forms/US/XXX.fmb userid=APPS/APPS output_file=/u01/oracle/TEST/apps/apps_st/appl/inv/12.0.0/forms/US/XXX.fmx module_type=form

Shared Application File System in R12 and 11i

E-Business suites (EBS) 11i and R12 both support the sharing of the Applications Tier File System. Sharing a file system in EBS involves sharing a volume between 2 or more physical servers. In a shared Application Tier File System (ATFS) implementation, the application services can be configured to run (utilize CPU and memory) on any server sharing the ATFS simply by changing some context file variables via OAM, running Autoconfig and restarting the services. This process is detailed in the following notes:

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

Some key concepts of sharing ATFS:

• Each server sharing the ATFS will have its own context file
• Certain context file variables dictate which application services start and run on which server(s)
• Certain context file variables dictate how AD Utilities will behave on each server

The Unified Applications Tier File System (UATFS)

The term "Unified Applications Tier File System" (UATFS) came along with R12 as a new feature. Oracle Development decided it would be beneficial to always install all the files needed on every server in a given R12 installation, even if the server was only to host some of the Application services. Even though this term was coined for an R12 feature, it still applies to some 11i file systems. A Unified Applications File System essentially means that the file system contains all the files required to support all 4 base service groups in E-Business Suite:

• Web
• Forms
• Admin (Not a true process or service as the other 3 are. The "admin" component dictates which server administers the application database objects and therefore has the needed files for that task.)
• Concurrent Processing (Reports)

Again, all versions of R12 are always installed with UATFS as delivered by Rapid Install. However in 11i only single node-installations are unified at install time. In 11i in order to achieve a unified file system from a multi-node installation, a merge of the file systems must be performed. This is the only supported manner in which to achieve a unified file system from an installation which was originally multi-node. APPL_TOP Merging in 11i is accomplished by Note 233428.1, Section 4, "Merging existing APPL_TOPs into a single APPL_TOP". Because R12 is always unified there is not an APPL_TOP merge process in R12.

Some Non-Typical Scenarios for Shared File Systems in 11i

In 11i it is also possible to share an ATFS even if the file system is not unified or complete; i.e., it only supports 1, 2 or 3 of the 4 core services. For example 11i can have an ATFS which only has the files for Forms and Web. That ATFS can then be shared with another server for Forms / Web services only. The other core services, Admin and Concurrent would then have its own ATFS on another server or servers. This would be done for some advanced topology configurations like load-balancing or perhaps a standby Web / Forms server and would minimize the footprint of the ATFS. Because the ATFS in this example is not unified, the ATFS of the Forms/Web servers could never host the Concurrent Processing or Admin services without first being merged with an ATFS which has the necessary Concurrent Processing and Admin files. So while in 11i it is possible to share a non-unified ATFS, it would not be a typical configuration. A typical configuration is sharing 1 unified ATFS for amongst multiple servers. The advantages of this non-typical example would be:

• Smaller Footprint for the ATFS on each volume/disk (however the overall combined footprint would be larger)
• Better performance from the shared volume/disk, as there are 2 instead of 1

The disadvantages would be:

• Must maintain multiple ATFS's
• Patches have to be applied multiple times 
• Cloning is more difficult as 2 ATFS's must be cloned

For disk performance reasons, you could implement a similar strategy in R12, for example sharing 2 volumes (VOL1, VOL2) amongst 4 servers: 2 web/forms servers accessing only VOL1 and the 2 CCM/Admin servers accessing only VOL2. Those 2 disks would each have a unified ATFS in R12, where the same configuration in 11i the file systems could be partial or unified.

For more information please refer :

Explanation of Context Variables for Shared Application File System in R12 and 11i [ID 1070152.1]

References
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
NOTE:406558.1 - Configuring Applications Node Services in Oracle E-Business Suite Release 12
NOTE:415385.1 - On a R12 Multi-Node Install -- Why do all Middle Tiers run all Services?

Quest Foglight - Oracle E-Business Management

 

Oracle E-Business Management       

Foglight helps organizations achieve application service levels and improve

Oracle E-Business application performance.

 

http://www.quest.com/application-and-service-management-technology/oracle-e-business.aspx