16 Moving Components for Oracle Fusion Applications Across Environments

This chapter describes how to move Oracle Fusion Applications components from one environment to another.

This chapter contains the following topics:

• Introduction to Moving Oracle Fusion Applications

• Understanding the Full-Movement Tasks

• Getting Started with Moving Components

• Moving the Oracle Identity Management Domain Component Artifacts

• Moving Binary Files in the Oracle Fusion Applications Environment

• Moving Configurations in the Oracle Fusion Applications Environment

• Moving Functional Setup Data

• Completing Postmovement Tasks

• Moving Components from a Production Environment to a Test Environment

• A Case Study: Moving Oracle Fusion Supply Chain Management Components

16.1 Introduction to Moving Oracle Fusion Applications

Replicating an Oracle Fusion Applications environment requires moving Oracle Fusion Applications components from one environment to another. The task of moving Oracle Fusion Applications components from one environment to another is simplified by movement tools (scripts for moving binary and configuration information). These tools minimize the amount of work that would otherwise be required to reapply all the customization and configuration changes made in one environment to another.

Typically, Oracle Fusion Applications is installed, configured, customized, and validated in a source environment, such as a test environment. Once the system is stable and performs as desired, the target environment, such as a production environment, would then be created by moving all the components from the source environment, instead of redoing all the changes that were incorporated into the source environment.

The movement of Oracle Fusion Applications components from one environment to another can be achieved in several different movement scenarios, but this chapter focuses on the full-movement scenario.

In a full-movement scenario, the target environment does not exist. First, the source environment is created, configured, customized, and tested. Then, the target environment is created by moving all the components along with their configurations from the source environment.

When moving Oracle Fusion Applications components from one environment to another, you must adhere to the following guidelines:

• The source and target environments must share the same operating system and the same platform architecture (in terms of number of bits). For example, you cannot move components and their configurations from a source environment that is running Microsoft Windows to a target environment that is running UNIX. Similarly, you cannot move components and their configurations from a source environment with a 32-bit platform to a target environment with a 64-bit platform.

• The source and target environments must have identical topologies. (Any changes to the target environment topology can be done post movement).

• The Oracle Fusion Applications domain name must not be changed in the provisioned environment or while performing the full-movement tasks.

• The path relative to APPLICATIONS_CONFIG that is used while moving the domain and system component should be the same as the path used in the provisioned source environment.

• The Common domain should be moved to the target environment first because Metadata Services (MDS) operations for Oracle Fusion Applications partitioning is handled in the Common domain.

With the completion of the full-movement tasks, the following artifacts are moved from the source environment to the target environment:

• Seed data (created with Oracle Fusion Middleware Repository Creation Utility (RCU) in the target environment)

• Oracle WebLogic Server domain configuration, stored in the file system

• System component configuration, stored in the file system

• Configuration and metadata stored in MDS, such as Oracle Application Development Framework (Oracle ADF) connections, service-oriented architecture (SOA) composites, and so on

• Configuration and metadata stored in component-specific schemas outside of MDS

• Non-user layer customizations, such as Site and Enterprise Layer, in MDS

• Security artifacts created by the Oracle Fusion Applications Provisioning framework, such as application IDs, policies, and so on

• Functional setup data

Following are some of the artifacts that are not moved to the target environment:

• Transactional data, which is assumed to be test transactions

• Transient data, such as job status, process status, and so on

• Content data, such as Oracle Universal Content Management data, wiki pages, discussion forums, and so on (which can be moved using data movement tools if necessary)

  Note:

  In the case of Oracle HTTP Server (OHS), the contents of document root are moved as part of OHS movement, as they are part of application data.

• Any configuration or metadata associated with users, such as:

  • Users in the identity store

  • User layer customizations in MDS

  • Component configurations associated with specific users, such as Oracle Human Workflow work groups associated with users

  Users are assumed to be test users, and they may not be present in the target environment.

• MDS sandboxes

16.2 Understanding the Full-Movement Tasks

Moving Oracle Fusion Applications components from one environment to another is a complex process involving multiple tasks.

Table 16-1 lists the high level set of tasks for moving artifacts from the source environment to the target environment in a full-movement scenario. It also provides references to detailed information for each task.

Table 16-1 Full-Movement Tasks

Task	Description	Documentation Reference
1	Complete the prerequisite tasks.	Section 16.3, "Getting Started with Moving Components"
2	Move the Oracle Identity Management domain component artifacts.	Section 16.4, "Moving the Oracle Identity Management Domain Component Artifacts"
3	Copy the binaries (that is, the installed applications or components along with any applied patches) in the source environment, and apply the archive to the target environment to move the Oracle Fusion Applications binary files. Run the copyBinary script for each Middleware home in the source environment to create the binary archives. Apply the copied binary files from the source environment to the target environment by running the pasteBinary script in the target environment. Move the dbclient installation.	Section 16.5, "Moving Binary Files in the Oracle Fusion Applications Environment"
4	Move the configurations of each Oracle WebLogic Server domain, OHS instance, and Node Manager in Oracle Fusion Applications from the source environment to the target environment. Run the copyConfig script for each Oracle WebLogic Server domain, OHS instance, and Node Manager in the source environment to create the configuration archives. Extract the move plan by running the extractMovePlan script on the list of configuration archive locations, separated by comma. Modify the move plan to specify properties for the target environment. Apply the copied configurations from the source environment to the target environment by running the pasteConfig script for each Oracle WebLogic Server domain, OHS instance, and Node Manager separately, using the same move plan. If there are multiple machines for the domain, recreate the local domain directory using the Oracle WebLogic Server pack and unpack mechanisms. Complete the component-specific configuration move by performing additional movement tasks on the Oracle Fusion Middleware components. Configure the database client. Move the Oracle Global Order Promising server instance.	Section 16.6, "Moving Configurations in the Oracle Fusion Applications Environment"
5	Apply the setup configuration data of the source environment to the target environment.	Section 16.7, "Moving Functional Setup Data"
6	Complete postmovement tasks.	Section 16.8, "Completing Postmovement Tasks"

Note:

Oracle Fusion Applications movement has a default logging level of INFO. To ensure copyBinary, copyConfig, pasteBinary, pasteConfig, and extractMovePlan scripts, set the T2P_JAVA_OPTIONS variable to include the following:

-Dt2p.logging.level=log level 

where log_level is one of the following (ordered from the most verbose to the least verbose):

SEVERE
WARNING 
CONFIG 
FINE
FINER
FINEST
ALL 

For an example of moving Oracle Fusion Applications product family components from a source environment to a target environment using these full-movement tasks, see Section 16.10.

While you can create a production environment from a test environment, you can also create a test environment that is similar to a production environment. For information, see Section 16.9.

16.3 Getting Started with Moving Components

Before you begin to move Oracle Fusion Applications components across environments, you must complete the following tasks:

• Prepare the source environment. See Section 16.3.1.

• Prepare the target environment. See Section 16.3.2.

16.3.1 Preparing the Source Environment

Before performing the full-movement tasks, you must make sure that the source environment is completely functional for the following requirements:

1. The database server is installed and the required schemas are created. The seed data must also be loaded.

   For information, see the "Installing a Transaction Database" chapter in the Oracle Fusion Applications Installation Guide.

2. Any custom schemas, such as custom PL/SQL scripts, client extensions, or database views used by your applications are created.

3. The Oracle Identity Management environment is set up.

4. All the necessary software has been installed through Oracle Fusion Applications provisioning.

5. The setup data has been created using Oracle Fusion Functional Setup Manager (Functional Setup Manager).

6. All needed customizations and extensions have been applied to the source environment. For more information, see the Oracle Fusion Applications Extensibility Guide.

7. If you have performed any edits of the Oracle BI repository, you must upload the final repository file through Fusion Applications Control before performing the movement. For more information, see the, "Configuring Repositories" chapter in the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

8. The environment has been tested, and any necessary patches have been applied.

16.3.2 Preparing the Target Environment

Before performing the full-movement tasks, you must complete the following preparations in the target environment:

1. Install the database server and create the required schemas.

   For information, see the "Installing a Transaction Database" chapter in the Oracle Fusion Applications Installation Guide.

2. Copy the metadata of FUSION schema from the source database to the target database. This is to ensure that any modifications done to the FUSION schema at the source environment such as changes to table, views, grants, PLSQL packages and so on are reproduced at the target. Note that this will completely overwrite and replace the FUSION schema definition at the target environment.

3. Duplicate the test instance to create the production instance using RMAN duplicate or other RDBMS utilities.

4. Refresh Oracle Fusion Middleware schemas by running Drop, followed by Create operation for all Oracle Fusion Middleware schemas, in Oracle Fusion Applications Repository Creation Utility (Applications RCU), see the Oracle Fusion Applications Installation Guide.

5. Recreate grants and synonyms between Oracle Fusion Applications and Oracle Fusion Middleware schemas by invoking selected SQL scripts packaged with Applications RCU.

6. Clean up any test data in Oracle Fusion Applications transaction tables, by running truncate against these tables.

7. Reset the path of Oracle Database directory objects

8. Refresh materialized views and rerun statistics.

9. If the partition feature is activated in the source environment and the partition configuration is not using preexisting table spaces owned by the SEARCHSYS schema, then you must create the same table space in the Oracle Secure Enterprise Search (Oracle SES) database of the target environment before invoking pasteConfig. For information, see the "Partitioning for Parallel Query" section in the Oracle Secure Enterprise Search Administration API Guide.

10. Create the identity keystores and trust keystores for the middle tier Managed Servers and Node Manager. For information, see the "Enabling Node Manager to Run in SSL Mode for CRMHOST2" section in the Oracle Fusion Applications Enterprise Deployment Guide.

11. Set up the Oracle Identity Management environment, if it is not already set up. All the required Oracle Identity Management components should be integrated and working together. The components required in the Oracle Identity Management domain are Oracle Internet Directory, Oracle Virtual Directory, Oracle Access Manager, Oracle Identity Manager, and optionally Oracle Fusion Applications.

16.4 Moving the Oracle Identity Management Domain Component Artifacts

Prior to moving Oracle Fusion Applications components across environments, you must move the Oracle Fusion Applications related artifacts for Oracle Identity Management from the source domain to the target domain. The artifacts created by Oracle Fusion Applications provisioning in the source domain are distributed across the following Oracle Identity Management products:

• Oracle Internet Directory (used as the identity store and policy store)

• Oracle Virtual Directory (used as the identity store)

• Oracle Access Manager

• Oracle Identity Manager

• Oracle Identity Federation

Movement of the Oracle Identity Management artifacts assumes that a source Oracle Identity Management environment has been provisioned for Oracle Fusion Applications and that a target Oracle Identity Management environment is configured for Oracle Fusion Applications. Move to the target environment any customizations that were applied to the source environment on an as needed basis.

For information about moving the Oracle Identity Management components, see the "Moving Identity Management Components to a Production Environment" section in the Oracle Fusion Middleware Administrator's Guide.

To move the artifacts of Oracle Identity Management domain components for Oracle Fusion Applications from a source environment to a target environment, complete the following procedures:

1. Move the security artifacts in the identity store. See Section 16.4.1.

2. Move the policy and credential store. See Section 16.4.2.

3. Move the data security policies. See Section 16.4.3.

4. Modify the Credential Store Framework (CSF) entries in the target environment. See Section 16.4.4.

5. Move Oracle Access Manager artifacts. See Section 16.4.5.

6. Configure Oracle Identity Manager for Oracle Fusion Applications. See Section 16.4.6.

7. Move Oracle Identity Federation artifacts. See Section 16.4.7.

16.4.1 Moving the Security Artifacts in the Identity Store

Movement of the security artifacts in the identity store from the source to target environment is based on the following assumptions:

• The source and target Lightweight Directory Access Protocol (LDAP) instances are based on the same product, such as Oracle Internet Directory, Active Directory, and so on.

• The LDAP schema in the target environment is compatible with that of the source environment. Using the same version of the directory server guarantees schema compatibility between the source and destination directory instances.

• Only the system users, roles, and groups are moved to the target LDAP server. The users in the Enterprise Users container in the source environment are not moved. The temporary enterprise groups that are created are also not moved.

To move the security artifacts in the identity store from the source to target environment, follow the procedures in the following tasks and execute them in the Oracle Identity Management domain:

• Task 1, "Create the System Identities"

• Task 2, "Move the App ID Users"

• Task 3, "Move the App ID Groups"

• Task 4, "Move the Enterprise Roles"

• Task 5, "Move the Roles"

Task 1   Create the System Identities

Create all the required system identities (systemid) at the target LDAP, if they do not exist. The minimal list of users required for configuring the Oracle Fusion Applications domain include the following users:

• Oracle WebLogic Server administration user

  Note:

  The user ID of the Oracle WebLogic Server administration user in the target environment must be the same as the user ID of the Oracle WebLogic Server administration user in the source environment. However, the passwords can be different.

• Oracle Access Manager administration user

• Oracle Identity Manager administration user and administration group

• Other users for configuring the authentication providers in Oracle WebLogic Server

If the users were created using idmConfigTool in the source environment, you can use the tool with the same parameters in the target environment. For information, see the "Integrating Oracle Access Manager with Oracle Identity Manager by Using idmConfigTool" section in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition).

Running the command creates the following complete set of artifacts:

• Creates the following groups:

  • Group with read privileges to the Users Container (orclFAUserReadPrivilegeGroup)

  • Group with read and write privileges to the Users Container (orclFAUserWritePrivilegeGroup)

  • Group with read privileges to the Groups Container (orclFAGroupReadPrivilegeGroup)

  • Group with write privileges to the Groups Container (orclFAGroupWritePrivilegeGroup)

  • Group with write privileges to a partial set of attributes (orclFAUserWritePrefsPrivilegeGroup)

  It also provides the access control information (ACI) to the Users and Groups Container in Oracle Internet Directory.

  Note:

  If the target identity store already exists, then the users and groups containers might be protected by Access Control Policies. To provide privileges to the above groups, you need to manually modify the policies. For information, see the "Managing Directory Access Control" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

• Creates the user specified by the IDSTORE_READONLYUSER parameter (this user is configured as the proxy user in the Authenticator configuration of Oracle WebLogic Server, so this user should be the same as the user in the source environment), and assigns it to the orclFAWritePrefsPrivilegeGroup and orclFAGroupReadPrivilegeGroup groups.

• Creates the user specified by the IDSTORE_READWRITEUSER parameter and assigns it to the orclFAUserWritePrivilegeGroup and orclFAGroupWritePrivilegeGroup groups.

• Creates the user specified by SUPER_USER (this is the Oracle WebLogic Server administration user, and needs to be the same as the user configured in the source environment), and assigns it to the orclFAUserReadPrivilegeGroup group.

• Creates the System ID container.

• Creates Oracle Access Manager users.

• Creates the Oracle Identity Management user and sets the corresponding ACIs.

Task 2   Move the App ID Users

App IDs are stored under cn=appidUsers,cn=users,dc=mycompany,dc=com in the Users Container. To move these entries, use the following Lightweight Directory Interchange Format (LDIF) export and import procedure:

1. Dump the contents of the source App ID container to a file.

   ldapsearch -h oid_hostname -p ldap_port -D "binddn" -w password -b 'cn=appidUsers,cn=users,dc=mycompany,dc=com' -L -s sub 'objectclass=*' cn sn uid givenname displayname objectclass  >&  appidUsersDump.ldif
   

2. Search for the naming context and replace it with the new naming context.

   perl -pi -e 's/oldnamingcontext/newnamingcontext/g' appidUsersDump.ldif
   

3. Upload the LDIF file to the target environment.

   ldapadd -h oid_hostname -p ldap_port -D "binddn" -w password -a -c -f appidUsersDump.ldif
   

Task 3   Move the App ID Groups

App ID groups are stored under cn=appIDGroups,cn=groups,dc=mycompany,dc=com in the Groups Container.

To move these entries, use the following LDIF export and import procedure:

1. Dump the source entries to a file.

   ldapsearch -h oid_hostname -p ldap_port -D "binddn" -w password -b 'cn=appidGroups,cn=users,dc=mycompany,dc=com' -L -s sub 'objectclass=*'  "*" orclguid >&  appidGroupsDump.ldif
   

2. Search for the naming context and replace it with the new naming context.

   perl -pi -e 's/oldnamingcontext/newnamingcontext/g' appidGroupsDump.ldif
   

3. Upload the LDIF file to the target environment.

   ldapmodify -h oid_hostname -p ldap_port -D "binddn" -w password -a -f appidGroupsDump.ldif
   

Task 4   Move the Enterprise Roles

Enterprise roles are stored under cn=fusionGroups,cn=groups,dc=mycompany,dc=com in the LDAP directory. The enterprise roles can be associated with App ID users, App ID groups, and other enterprise users. Since the enterprise users in the source environment are not moved from the source directory to the target directory, the memberships are not moved between the source and target directories. To move these entries, use the following LDIF export, clean up, and import procedure:

1. Dump the source entries to a file.

   ldapsearch -h oid_hostname -p ldap_port -D "binddn" -w password -b 'cn=fusionGroups,cn=users,dc=mycompany,dc=com' -L -s sub 'objectclas=*' dn cn objectclass orclguid >fusionGroupsDump.ldif
   

2. Search for the naming context and replace it with the new naming context.

   perl -pi -e 's/oldnamingcontext/newnamingcontext/g' fusiongroupsDump.ldif
   

3. Upload the LDIF file to the target environment.

   ldapadd -h oid_hostname -p ldap_port -D "binddn" -w password -a -c -f fusiongroupsDump.ldif
   

Task 5   Move the Roles

Create the Administrators, Monitors, and Operators roles at the target identity store, then assign the required users to these roles. If these groups already exist, then you can ignore the error message.

1. Move the Administrators group from the source environment.

   ldapsearch -h oid_hostname -p ldap_port -D "binddn" -w password  -b 'cn=Administrators,cn=groups,dc=mycompany,dc=com  >& administrators.ldif
   

2. Remove any source environment users that should not be in the group.

   perl -pi -e 's/oldnamingcontext/newnamingcontext/g' administrators.ldif
   

3. Upload the LDIF file to the target environment.

   ldapadd -h oid_hostname -p ldap_port -D "binddn" -w password -a -c -f administrators.ldif
   

4. Move the Monitors group from the source environment.

   ldapsearch -h oid_hostname -p ldap_port -D "binddn" -w password  -b 'cn=Monitors,cn=groups,dc=mycompany,dc=com  >& monitors.ldif
   

5. Remove any source environment users that should not be in the group.

   perl -pi -e 's/oldnamingcontext/newnamingcontext/g' monitors.ldif
   

6. Upload the LDIF file to the target environment.

   ldapadd -h oid_hostname -p ldap_port -D "binddn" -w password -a -c -f monitors.ldif
   

7. Move the Operators group from the source environment.

   ldapsearch -h oid_hostname -p ldap_port -D "binddn" -w password  -b 'cn=Operators,cn=groups,dc=mycompany,dc=com  >& operators.ldif
   

8. Remove any source environment users that should not be in the group.

   perl -pi -e 's/oldnamingcontext/newnamingcontext/g' operators.ldif
   

9. Upload the LDIF file to the target environment.

   ldapadd -h oid_hostname -p ldap_port -D "binddn" -w password -a -c -f operators.ldif
   

16.4.2 Moving the Policy and Credential Store

There are two policy domains created in the Oracle Fusion Applications deployments, one for Oracle Identity Management domain components and one for Oracle Fusion Applications components. Movement of the policy store from source to target involves moving contents of both policy domains from the source to target environment. It is assumed that the Oracle Identity Management domain related entities in the policy and credential store are moved as part of the Oracle Identity Management domain move.

To move the policy store that is related to Oracle Fusion Applications from the source environment to the target environment, follow the procedures in the following tasks:

• Task 1, "Move the Policy and Credential Store Artifacts"

• Task 2, "Reset the App ID Passwords"

• Task 3, "Seed Oracle ADF Credentials"

Task 1   Move the Policy and Credential Store Artifacts

To move the policy and credential store artifacts, you must first identify the policy domain created for Oracle Fusion applications. The policy domain is an LDAP container that is seeded by the Oracle Fusion Applications provisioning in the source environment. It is very important that the policy store container name is the same in both the source and target environments. Then, move the entire content of the policy store from the source environment to the target environment. For information, see the "Migrating Large Volume Policy and Credential Stores" section in Oracle Fusion Middleware Application Security Guide.

Task 2   Reset the App ID Passwords

When invoking web services, Oracle Fusion Applications must rely on a type of credential known as the App ID. Each application has its own App ID, which is initially provisioned for the application. For information about resetting App ID passwords (a task typically done during scheduled downtime), see the Oracle Fusion Applications Security Guide.

Task 3   Seed Oracle ADF Credentials

To seed the Oracle ADF credentials:

1. From the fusionapps Middleware subdirectory, start WLST:

   (UNIX) FA_MW_HOME/oracle_common/common/bin/wlst.sh
   (Windows) FA_MW_HOME\oracle_common\common/bin\wlst.cmd
   

2. Connect to Oracle WebLogic Server.

3. Use the following WLST commands from the fusionapps Middleware directory:

   listCred(map="oracle.apps.security", key="appidname-KEY")
   

   where appidname is one of the following values:

   FUSION_APPS_ATK_BI_APPID
   FUSION_APPS_CRM_BI_APPID
   FUSION_APPS_FIN_BI_APPID
   FUSION_APPS_HCM_BI_APPID
   FUSION_APPS_IC_BI_APPID
   FUSION_APPS_PRC_BI_APPID
   FUSION_APPS_PRJ_BI_APPID
   FUSION_APPS_SCM_BI_APPID
   

4. Update the credentials with Fusion Applications Control using the same map and key values as used with the listCred command. See the "How to Edit Credentials Deployed with the Application" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Application Development Framework.

16.4.3 Moving Data Security Policies

Data security policies created in the simplified Data Security management UI or in Oracle Authorization Policy Manager should be migrated using Functional Setup Manager. The business object name associated for data security is Application Data Security Policy.

For more information on moving data security policies, see the following documentation:

• Section 16.7 for further information on how to move data Oracle Fusion Applications security policies using Functional Setup Manager export and import functions.

• "Moving Common Reference Objects" section in the "Importing and Exporting Setup Data" chapter in the Oracle Fusion Applications Common Implementation Guide to understand data security policy migration

• "Importing and Exporting Setup Data" chapter in the Oracle Fusion Applications Information Technology Management, Implement Applications Guide for information on moving setup data

16.4.4 Modifying the CSF Entries in the Target Environment

After you run the configuration scripts, you must modify the Credential Store Framework (CSF) entries, listed in Table 16-2, in the target environment.

Table 16-2 CSF Entries to Modify

Map	Key	Description
oracle.apps.security	FUSION_APPS_ECSF_SES_ADMIN-KEY	This entry stores the SEARCHSYS schema password for ECSF and Oracle SES for Oracle SES 11.2.1.
oracle.bi.enterprise	scheduler.schema	This entry stores the schema password for Oracle BI Scheduler schema.
oracle.apps.security	FUSION-DB-KEY	Oracle Fusion database credentials
oracle.patching	FUSION_APPS_CRM_MDS_SOA_SCHEMA-KEY	User credentials for the patch MDS SOA schema
oracle.patching	FUSION_APPS_FIN_MDS_SOA_SCHEMA-KEY	User credentials for the patch MDS SOA schema
oracle.patching	FUSION_APPS_HCM_MDS_SOA_SCHEMA-KEY	User credentials for the patch MDS SOA schema
oracle.patching	FUSION_APPS_MDS_ESS-KEY	User credentials for the patch MDS Oracle Enterprise Scheduler schema
oracle.patching	FUSION_APPS_MDS-KEY	User credentials for the patch MDS schema
oracle.patching	FUSION_APPS_MDS-SPACES	User credentials for the patch MDS Oracle WebCenter Spaces schema
oracle.patching	FUSION_APPS_ODI_SCHEMA-KEY	Oracle Data Integrator schema credentials
oracle.patching	FUSION_APPS_OIC_MDS_SOA_SCHEMA-KEY	User credentials for the patch MDS SOA schema
oracle.patching	FUSION_APPS_PATCH_FUSION_DYNAMIC_SCHEMA-KEY	The credential for the FUSION_DYNAMIC schema in the Oracle Fusion transactional database
oracle.patching	FUSION_APPS_PATCH_FUSION_RUNTIME_SCHEMA-KEY	The credential for the FUSION_RUNTIME schema in the Oracle Fusion transactional database
oracle.patching	FUSION_APPS_PATCH_FUSION_SCHEMA-KEY	User credentials for patch
oracle.patching	FUSION_APPS_PATCH_ID_STORE-KEY	User credentials for patching to connect to the Identity Store. Currently, this credential is a read-write user supplied to provisioning.
oracle.patching	FUSION_APPS_PATCH_POLICY_STORE-KEY	User credentials for patching to connect the Policy Store
oracle.patching	FUSION_APPS_PATCH_WLS_ADMIN	User credentials for Oracle WebLogic Server administrator
oracle.patching	FUSION_APPS_PATCH_WLS_NODE_MANAGER-KEY	User credentials for Oracle WebLogic Server Node Manager
oracle.patching	FUSION_APPS_PRC_MDS_SOA_SCHEMA-KEY	User credentials for the patch MDS SOA schema
oracle.patching	FUSION_APPS_PRJ_MDS_SOA_SCHEMA-KEY	User credentials for the patch MDS SOA schema
oracle.patching	FUSION_APPS_SCM_MDS_SOA_SCHEMA-KEY	User credentials for the patch MDS SOA schema
oracle.patching	FUSION_APPS_SETUP_MDS_SOA_SCHEMA-KEY	User credentials for the patch MDS SOA schema
oracle.search	SEARCH_DATABASE	Oracle SES data source credentials. Provide user name and password. Use the database connection string of the target environment for the user name in this format: host:port:database_service_name The password is the dummy value SEARCH.
oracle.t2p	FUSION_APPS_ODI_SCHEMA-KEY	Oracle Data Integrator schema credentials
oracle.wsm.security	basic.credentials	Oracle WebLogic Server user credentials key. This credential corresponds to the user name and password of bootstrap credential, FUSION_APPS_PROV_PATCH_APPID , which comes from the provisioning plan.
oracle.wsm.security	enc-csf-key	User credential for specifying which keystore alias to use for encrypting the message. Both enc-csf-key and sign-csf-key aliases will be the same.
oracle.wsm.security	FUSION_APPS_HCM_HR2HR_APPLOGIN-KEY	The user credentials for the PeopleSoft Enterprise Application web service SOAP interaction. The user credentials corresponds to the PeopleSoft Enterprise Application application user with access privileges to invoke the PeopleSoft Application web service FT_FUSION_TO_PSFT_MSG.1.wsdl.
oracle.wsm.security	FUSION_APPS_PRC_SUPP_SYNC_SVC-KEY	The credentials of the external service for the supplier synchronization service (integration)
oracle.wsm.security	FUSION_APPS_PRJ_P6INT_ADMIN-KEY	The Primavera P6 administration super user credentials designated for use with the integration between Oracle Fusion Projects Portfolio Management and Oracle Primavera P6 Enterprise Project Portfolio Management (P6 EPPM).
oracle.wsm.security	keystore-csf-key	User credential is for specifying the password of the default_keystore.jks keystore.
oracle.wsm.security	sign-csf-key	User credential is for specifying which keystore alias to use for signing the message. Both enc-csf-key and sign-csf-key aliases will be the same.

To modify the CSF entries:

1. In the target system, invoke the Oracle Weblogic Scripting Tool using a shell script as follows:

   >MW_HOME/oracle_common/common/bin/wlst.sh
   >wls:/offline>connect()
   

2. Enter the login user name and password for the Oracle WebLogic Server Administration Console and the connection information at the prompt.

   Make sure the domain runtime server is enabled (that is, the prompt becomes wls:/>).

3. Edit each of the CSF entries listed in Table 16-2, using the following syntax:

   >wls:/>updateCred(map=" map",key=" KEY", user="username", password="password")
   

   For example,

   >wls:/>updateCred(map=" oracle.search",key=" SEARCH_DATABASE", user="jdbc:oracle:thin:@machine01.us.example.com:6521:fusion",password="search")
   >wls:/>updateCred(map=" oracle.apps.security",key=" FUSION_APPS_ECSF_SES_ADMIN-KEY", user="searchsys", password="welcome1")
   

16.4.5 Moving Oracle Access Manager Artifacts

Oracle Access Manager artifacts are moved from a source environment to target environment when you move the Webgate installation and change the Webgate identifier to reflect the target end points during the movement of Oracle Fusion Applications components across environments. For information, see the task "Move Oracle Access Manager 11g to a New Target Environment" in the Oracle Fusion Middleware Administrator's Guide and Section 16.6.3.

16.4.6 Configure Oracle Identity Manager for Oracle Fusion Applications

To configure Oracle Identity Manager for Oracle Fusion Applications, follow the procedures in the following tasks:

• Task 1, "Move the Callback Configuration File"

• Task 2, "Seed the Oracle Fusion Applications Artifacts"

• Task 3, "Reconcile Records from the Identity Store"

Note:

The Administration Server and Oracle Identity Manager and SOA Managed Servers must be running when you perform the procedures.

Movement of the Governance Risk and Controls client configuration is performed when you move the configurations in the Oracle Fusion Applications environment. See Section 16.6.8.7.

Task 1   Move the Callback Configuration File

The CallbackConfiguration.xml file is an MDS document that contains information on the web services that need to be invoked for completion and postprocessing callbacks. For information, see the "MDS Utilities and User Modifiable Metadata Files" chapter in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

To move CallbackConfiguration.xml from the source to the target environment:

1. In the source environment, use the weblogicExportMetadata.sh utility, located in IDENTITY_MANAGER_HOME/bin/, to export CallbackConfiguration.xml, located in /metadata/iam-features-callbacks/sample_data/.

2. Edit the CallbackConfiguration.xml file to specify the host and port of the target environment in the web service URLs.

3. In the target environment, import the CallbackConfiguration.xml file into MDS using the weblogicImportMetadata.sh utility located in IDENTITY_MANAGER_HOME/bin/.

Task 2   Seed the Oracle Fusion Applications Artifacts

To seed the Oracle Fusion Applications artifacts:

Note:

Use JConsole to invoke the managed beans (MBean), and use the Oracle WebLogic Server domain administrator credentials for performing all MBean operations.

For more information, see the Oracle Fusion Middleware Oracle WebLogic Server MBean Reference.

1. Invoke the MLSLanguageSeedingMBean.seedAllLanguages method to seed all the multi-language support (MLS) and multi-representation (MR) languages in the target system. This MBean method does not take any parameters.

2. Invoke the APPIDSeedingMBean.seedFusionAPPID method once for each App ID to create the App IDs for Oracle Fusion Applications in Oracle Identity Manager. (You can get the App IDs from the source environment where they are already seeded.) This MBean method takes a single parameter that is the actual App ID itself and will seed this App ID in the Oracle Identity Manager data store. For information about App IDs, see Table 3-4.

Task 3   Reconcile Records from the Identity Store

Use Oracle Identity Manager to reconcile records from the identity store.

To reconcile records from the identity store:

1. Sign in to Oracle Identity Manager.

2. Click Advanced, then the System Management tab, and then Scheduler. Alternatively, you can click the Search Scheduled Jobs link on the Welcome screen.

3. Run each of the following scheduled tasks by selecting it and clicking Run Now. You must run one job at a time in the following sequence and wait for each job to complete successfully before running the next one:

   1. Fusion Applications Role Category Seeding

      Note:

      Make sure that Oracle Virtual Directory is configured properly for the change log adapter. For information, see Section 24.1.1.

   2. LDAP Role Create and Update Full Reconciliation

   3. LDAP Role Hierarchy Full Reconciliation

   4. LDAP User Create and Update Full Reconciliation

   5. LDAP Role Membership Full Reconciliation

16.4.7 Moving Oracle Identity Federation Artifacts

Oracle Identity Federation artifacts are moved from a source environment to target environment when you move Oracle Identity Management components across environments.

Oracle Identity Federation has already been moved from the source environment to target environment. For information, see the "Moving Identity Management to an Existing Production Environment" section in the Oracle Fusion Middleware Administrator's Guide.

16.5 Moving Binary Files in the Oracle Fusion Applications Environment

There are two Middleware home directories, both of which reside in APPLICATIONS_BASE (/net/mount1/appbase), which represents the top level applications base directory for binaries:

• fusionapps contains all the Oracle Fusion applications and J2EE components, such as Oracle SOA Suite, Oracle Enterprise Content Management Suite, and J2EE components.

• webtier_mwhome contains all the system components, such as OHS. A system component is an Oracle Process Manager and Notification Server (OPMN) manageable process that is not deployed as a Java application.

For information about the Oracle Fusion Applications directory structure, see:

• Section 1.2.3, "Provisioned Oracle Fusion Applications Home Directories"

• The "Oracle Fusion Applications Directory Structure" section in the Oracle Fusion Applications Installation Guide

Moving installed binaries and patches in the Middleware home of an Oracle Fusion Applications environment requires the use of a set of scripts. These scripts are available in the following fusionapps Middleware directories:

(UNIX) FA_MW_HOME/oracle_common/bin
(Windows) FA_MW_HOME\oracle_common\bin

For more information, see the "Cloning Syntax" section in the Oracle Fusion Middleware Administrator's Guide.

Notes:

• If you want to create obfuscated password files for use with these scripts, use the following scripts:

  (UNIX) FA_MW_HOME/oracle_common/bin/obfuscatePassword.sh
  (Windows) FA_MW_HOME\oracle_common\bin\obfuscatePassword.cmd
  

  These interactive scripts prompt you to enter your password and the location of the password file to be written.

• The Java version should be at least 1.6.04.

Using the copyBinary and pasteBinary scripts allows you to create a copy of the source Middleware home into an archive file, then apply the archive to the target environment, as shown in Figure 16-1.

Figure 16-1 Movement of Binaries

Since the binaries are in shared storage and are shared by all Oracle Fusion Applications domains, copyBinary needs to be performed only once from the primordial machine and pasteBinary only once on the target primordial machine.

To move binary files in the Oracle Fusion Applications environment, you must complete the following steps:

1. Create the binary archives by running the copyBinary script for each Middleware home in the source environment. See Section 16.5.1.

2. Apply the copied binary files from the source environment to the target environment by running the pasteBinary script in the target environment. See Section 16.3.2.

3. Manually move the Oracle Database installation from the source environment to the target environment. See Section 16.5.3.

16.5.1 Creating Binary Archives

Run the copyBinary script for each Middleware home in the source environment. This copies the binary files of each Middleware home, including all of its Oracle homes and its Oracle WebLogic Server home, into an archive file.

Note:

The Oracle homes in the Middleware home must share the same platform architecture (in terms of number of bits). The copyBinary script does not support a mix of 32-bit and 64-bit Oracle homes.

When you run the script, you must specify a Java home of the same number of bits as the Oracle homes. For example, for 64-bit Oracle homes, you must specify a 64-bit Java home.

Before creating the binary archive of a Middleware home, make sure that the Oracle WebLogic Server product directories are installed in the Middleware home. Oracle WebLogic Server installed outside of Middleware home is not supported.

In a Windows environment, before creating an archive of a Middleware home, make sure that no Java or Oracle WebLogic Server processes are running from that Middleware home.

Use the following syntax to run the copyBinary script:

copyBinary -javaHome path_of_jdk
           -archiveLoc archive_location 
           -sourceMWHomeLoc MW_HOME   
           [-invPtrLoc Oracle_InventoryLocation]
           [-logDirLoc log_dir_path]
           [-silent {true | false}]
           [-ignoreDiskWarning {true | false}]

The following example shows how to create an archive of a Middleware home on UNIX:

copyBinary.sh -javaHome USER_HOME/jrockit_160_04
              -archiveLoc /FIN_T2P/FIN_clone1.jar
              -sourceMWHomeLoc /net/mount1/appbase/fusionapps
              -invPtrLoc /etc/oraInst.loc
              -logDirLoc /FIN_T2P/logs
              -silent true
              -ignoreDiskWarning true

/net/mount1/appbase represents the top level applications base directory for binaries.

Table 16-3 describes the options for the copyBinary script.

Table 16-3 Options for the copyBinary Script

Options	Shortcut	Description	Mandatory or Optional
-javaHome	None	The absolute path of the Java Developer's Kit.	Mandatory
-d64	None	If the operating system is 64-bit UNIX, pass the -d64 option to the scripts in the command line. To set the runtime property, you can specify the -d64 option in the T2P_JAVA_OPTIONS environment variable. For example: setenv T2P_JAVA_OPTIONS "-d64 -Djava.io.tmpdir=/home/t2p/temp"	Optional
-archiveLoc	-al	The absolute path of the archive location. Use this option to specify the location of the archive file to be created with the copyBinary script. The archive location must not already exist, but its parent directory must exist and have write permission. Ensure that the archive location is not within the Middleware home structure.	Mandatory
-invPtrLoc	-ipl	The absolute path to the Oracle Inventory pointer. Use this option if the inventory location is not in the default location, so that the operation can read the Oracle homes present in the inventory. You must have write permission to the inventory location. The default location is /etc/oraInst.loc on UNIX and C:\Program Files\Oracle\Inventory on Windows.	Optional, if the inventory is in the default location. Otherwise, it is mandatory.
-logDirLoc	-ldl	The location of an existing directory. A new log file is created in the directory.	Optional
-silent	None	Specifies whether the operation operates silently. That is, it does not prompt for confirmation. The default is that the operation prompts for confirmation. To continue, you must type yes, which is not case sensitive. Typing anything other than yes causes the script to return an error. To specify that it not prompt for confirmation, specify this option with the value of true.	Optional
-sourceMWHomeLoc	-smw	The absolute path of the Middleware home to be archived. You can only specify one Middleware home.	Mandatory
-ignoreDiskWarning	-idw	Specifies whether the operation ignores a warning that there is not enough free space available. The default is false. You may need to use this flag if the target is NFS mounted or is on a different file system, such as Data ONTAP	Optional

16.5.2 Applying the Binary Files to the Target Environment

Run the pasteBinary script to apply the archive to the target environment. This pastes the binary files of the source Middleware home in the target environment. You must run the pasteBinary script for each Middleware home in the target environment.

Note:

If you are applying the archive of a Middleware home on a host that does not yet have Oracle Fusion Middleware installed, then:

• The host must have JDK 1.6.04 or higher installed. In addition, ensure that the PATH, CLASSPATH, and JAVA_HOME environment variables point to the JDK.

• Copy the pasteBinary script from the following location in the source host to the target host:

  (UNIX) FA_MW_HOME/oracle_common/bin/pasteBinary.sh
  (Windows) FA_MW_HOME\oracle_common\bin\pasteBinary.cmd
  

• Copy the following file from the following location in the source host to the target host:

  (UNIX) FA_MW_HOME/oracle_common/jlib/cloningclient.jar
  (Windows) FA_MW_HOME\oracle_common\jlib\cloningclient.jar
  

  If you run the pasteBinary script from a different location than FA_MW_HOME/oracle_common/bin, then you must copy the cloningclient.jar file to the same directory.

• In a UNIX environment, make sure to properly set the inventory_loc and inst_group properties in the inventory file. For example:

  inventory_loc=/FIN_T2P/oraInventory
  inst_group=dba
  

  The inventory file location itself is specified through the invPtrLoc option of the copyBinary command. If the invPtrLoc option is not specified, the inventory is assumed to be in its default location of /etc/oraInst.loc.

• Make sure that the files have execute permission.

• The Middleware home must be created on the shared storage of the target environment.

• The pasteBinary script must be run from the primordial machine.

• Even though the absolute path need not be the same as the one in the source environment, the directory structure relative to APPLICATIONS_BASE should be the same.

Use the following syntax to run the pasteBinary script:

pasteBinary -javaHome path_of_jdk
            -archiveLoc archive_location
            -targetMWHomeLoc target_MW_Home_location
            [-executeSysPrereqs {true | false}]
            [-invPtrLoc Oracle_InventoryLocation]
            [-logDirLoc log_dir_path]
            [-silent {true | false}]
            [-ignoreDiskWarning {true | false}]

The following example shows how to apply the archive to the directory /net/mount1/appbase/fusionapps on UNIX:

pasteBinary.sh -javaHome USER_HOME/jrockit_160_04
               -archiveLoc /FIN_T2P/FIN_clone1.jar
               -targetMWHomeLoc /net/mount1/appbase/fusionapps
               -logDirLoc /FIN_T2P/logs/
               -silent true
               -ignoreDiskWarning true

/net/mount1/appbase represents the top level applications base directory for binaries.

Table 16-4 describes the options for the pasteBinary script.

Table 16-4 Options for the pasteBinary Script

Options	Shortcut	Description	Mandatory or Optional
-javaHome	None	The absolute path of the Java Developer's Kit.	Mandatory
-d64	None	If the operating system is 64-bit UNIX, pass the -d64 option to the scripts in the command line. To set the runtime property, you can specify the -d64 option in the T2P_JAVA_OPTIONS environment variable. For example: setenv T2P_JAVA_OPTIONS "-d64 -Djava.io.tmpdir=/home/t2p/temp"	Optional
-archiveLoc	-al	The absolute path of the archive location. Use this option to specify the location of the archive file created with the copyBinary script. The location must exist. Ensure that the archive location is not within the Middleware home structure.	Mandatory
-executeSysPrereqs	-esp	Specifies whether the pasteBinary operation checks the prerequisites of the Oracle homes. The default is that it checks the prerequisites. To specify that it does not check the prerequisites, specify this option with the value false.	Optional
-invPtrLoc	-ipl	The absolute path to the Oracle Inventory pointer. Use this option if the inventory location is not in the default location, so that the operation can read the Oracle homes present in the inventory. You must have write permission to the inventory location. The default location is /etc/oraInst.loc on UNIX and C:\Program Files\Oracle\Inventory on Windows.	Optional, if the inventory is in the default location. Otherwise, it is mandatory.
-logDirLoc	-ldl	The location of an existing directory. A new log file is created in the directory.	Optional
-silent	None	Specifies whether the operation operates silently. That is, it does not prompt for confirmation. The default is that the operation prompts for confirmation. To continue, you must type yes, which is not case sensitive. Typing anything other than yes causes the script to return an error. To specify that it not prompt for confirmation, specify this option with the value of true.	Optional
-targetMWHomeLoc	-tmw	The absolute path of the target Middleware home. If a multihost target topology is being used, the path would need to be /net/mount1/appbase addresses in order to make it visible to other hosts. For example: /net/mount1/appbase/fusionapps. Make sure that the Middleware home's parent directory, for example, fusionapps exists. If it does not exist, the program will error out. The targetMWHomeLoc cannot be inside another Middleware home.	Mandatory
-ignoreDiskWarning	-idw	Specifies whether the operation ignores a warning that there is not enough free space available. The default is false. You may need to use this flag if the target is NFS mounted or is on a different file system, such as Data ONTAP.	Optional

16.5.3 Moving the Oracle Database Client Installation

The Oracle Database client home is in the following location:

(UNIX) APPLICATIONS_BASE/dbclient
(Windows) APPLICATIONS_BASE\dbclient

Its contents must be manually moved from the source environment to the target environment.

Perform the following steps to move the dbclient installation:

1. Copy or tar the /net/mount1/appbase/dbclient directory to the target directly or from source.

   /net/mount1/appbase represents the top level applications base directory for binaries.

2. Run the installer clone command, shown in the following example:

   /net/mount1/appbase/dbclient/oui/bin/runInstaller -clone
          ORACLE_BASE=/net/mount1/appbase ORACLE_HOME=/net
   /net/mount1/appbase/dbclient ORACLE_HOME_NAME="dbclient" -jreLoc 
          /net/mount1/appbase
   /fusionapps/jrockit_160_17_R28.0.0-679 -defaultHomeName
   

   You will be prompted to run the root.sh command during the process.

3. Use an account with root access and run net/oracle/dbclient/root.sh.

   Note:

   You will not be prompted for permission to copy to the local bin.

16.6 Moving Configurations in the Oracle Fusion Applications Environment

For each Oracle Fusion application, you must move the configurations of each Oracle WebLogic Server domain, OHS instance, and Node Manager that is part of the source environment to the target environment. This configuration movement relies on the use of the configuration scripts. For information, see Section 16.6.1.

Before you move the configurations to the target environment, you must set system properties for Oracle SES and Oracle Enterprise Scheduler Service (ESS). For information, see Section 16.6.2.

You must also move the Webgate installation. For information, see Section 16.6.3.

To move configurations, you must complete the following steps:

1. Create the configuration archives by running the copyConfig script for each domain, OHS instance, and Node Manager in the source environment. See Section 16.6.4.

2. Extract the move plan by running the extractMovePlan script on the list of configuration archive locations, separated by comma. See Section 16.6.5.

3. Modify the move plan to specify properties for the target environment. See Section 16.6.6.

4. Apply the copied configurations from the source environment to the target environment by running the pasteConfig script for each Oracle WebLogic Server domain, OHS instance, and Node Manager separately, using the same move plan. See Section 16.6.7.

5. Complete the component-specific configuration move by performing additional movement tasks on the Oracle Fusion Middleware components. See Section 16.6.8.

6. If there are multiple machines for the domain, recreate the local domain directory using the Oracle WebLogic Server pack and unpack mechanisms. See Section 16.6.9.

Notes:

• If the database is not tuned correctly, copyConfig and pasteConfig operations can result in performance issues. To avoid these performance issues, in addition to following standard database performance tuning guidelines, ensure that you have sufficient RAM allocated for your RDBMS for the import of the MDS tables. Also run statistics against the target database by executing the following procedure:

  BEGIN
  dbms_stats.gather_schema_stats(
  ownname => 'FUSION_MDS',
  METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO',
  CASCADE => TRUE,
  ESTIMATE_PERCENT => NULL);
  END;
  

  where FUSION_MDS is the MDS schema name for your Oracle Fusion Applications installation.

• If OHS is configured with Webgate, note that the WebgateInstalldir property and references to this path are updated in the webgate.conf file located in the following directories:

  (UNIX) INSTANCE_HOME/config/OHS/component_name/webgate.conf
  (Windows) INSTANCE_HOME\config\OHS\component_name\webgate.conf
  

  The Java version should be at least 1.6.04.

16.6.1 Understanding the Configuration Scripts

Moving configurations in the Oracle Fusion Applications environment requires the use of a set of configuration scripts. These scripts are available in FA_MW_HOME/oracle_common/bin. For more information, see the "Cloning Syntax" section in the Oracle Fusion Middleware Administrator's Guide.

Using the copyConfig, extractMovePlan, and pasteConfig scripts allows you to create a copy of the source Oracle WebLogic Server domain home or OHS instance home configuration files into an archive file, extract the configuration information from one or more configuration archive into a move plan so you can edit the properties for the target environment, and apply the copied configurations (along with the move plan) to the target environment. Figure 16-2 illustrates the flow of the configuration movement from the source environment to the target environment.

Figure 16-2 Movement of Configurations

You must create a configuration archive for each source. The environment specific configuration information from each of the configurations archives are extracted to and consolidated in the source move plan that you must edit to specify the properties for the target environment. Then you must apply the edited move plan and the copied configuration archives from each source to each target.

Note:

The configuration archive files should be copied to the target environment, preferably to the shared storage so they are visible to all the target domains. Similarly, the extracted move plan and the updated move plan must also be present in the shared storage.

16.6.1.1 copyConfig Script

The copyConfig script creates a configuration archive that contains the snapshot of the configuration of a source entity (for example, Oracle WebLogic Server domain, OHS instance, or Node Manager). The underlying components of a source entity persist their configuration information in different data stores, such as a file system, Oracle Metadata Service (MDS), Lightweight Directory Access Protocol (LDAP), database, and so on.

You must run the copyConfig script for each source entity in the source environment. A configuration archive is created for each source domain or component instance.

The Administration Server and all Managed Servers in the domain must be up and running when you run the script.

16.6.1.2 extractMovePlan Script

The extractMovePlan script extracts the environment specific configuration information from one or more configuration archives into a move plan (XML file).

The extractMovePlan script also extracts any J2EE component specific configuration file, such as Oracle SOA composite configuration plans, application deployment plans, adapter deployment plans, and so on.

A move plan contains the environment specific configuration information, such as data source definitions, host names, port numbers, and end-point URLs, from one or more configuration archives created for each source domain or component instance in the source environment. You must edit the move plan to specify the properties for the target environment.

16.6.1.3 pasteConfig Script

The pasteConfig script applies the copied configurations from the source environment to the target environment. Inputs for the script include the location of the configuration archive created with the copyConfig script for each source entity and the modified move plan. The pasteConfig script recreates the configuration information for the source entity in the target environment. It also merges the move plan property values for the target environment. You must run the pasteConfig script for each source entity in the target environment.

16.6.2 Setting System Properties

Before you run copyConfig or pasteConfig for the Oracle WebLogic Server domain, you must set certain system properties for the following components:

• Oracle SES. See Section 16.6.2.1.

• Oracle Enterprise Scheduler Service (ESS). See Section 16.6.2.2.

In Windows, you must also set the Java Virtual Machine (JVM) system variable. See Section 16.6.2.3.

16.6.2.1 Setting Oracle SES System Properties

Before you run the copyConfig and pasteConfig scripts, you must set the T2P_JAVA_OPTIONS system property to include the encryption key search.encrypt.key.

Note:

If both Oracle SES and ESS are installed on your environment, then combine the options for both components with the following command:

(UNIX C shell) setenv T2P_JAVA_OPTIONS "-Dsearch.encrypt.key=full_path_to_the_file_containing_the_encryption_key -Dess.config.dir=DirLocationOfPropsFile"
(UNIX Bourne shell) export T2P_JAVA_OPTIONS "-Dsearch.encrypt.key=full_path_to_the_file_containing_the_encryption_key -Dess.config.dir=DirLocationOfPropsFile"
(Windows) set T2P_JAVA_OPTIONS "-Dsearch.encrypt.key=full_path_to_the_file_containing_the_encryption_key -Dess.config.dir=DirLocationOfPropsFile"

Set the system property with the following command:

(UNIX C shell) setenv T2P_JAVA_OPTIONS "-Dsearch.encrypt.key=full_path_to_the_file_containing_the_encryption_key"
(UNIX Bourne shell) export T2P_JAVA_OPTIONS="-Dsearch.encrypt.key=full_path_to_the_file_containing_the_encryption_key"
(Windows) set T2P_JAVA_OPTIONS "-Dsearch.encrypt.key=full_path_to_the_file_containing_the_encryption_key"

For the value of search.encrypt.key, provide the full path of the file that contains the encryption key used by the Oracle SES Admin API to export and create configuration objects. For example:

(UNIX C shell) setenv T2P_JAVA_OPTIONS "-Dsearch.encrypt.key=/scratch/tmp/encrypt_key.txt"
(UNIX Bourne shell) export T2P_JAVA_OPTIONS "-Dsearch.encrypt.key=/scratch/yiqi/tmp/encrypt_key.txt"
(Windows) set T2P_JAVA_OPTIONS "-Dsearch.encrypt.key=/scratch/yiqi/tmp/encrypt_key.txt"

The encryption key in the file must be the same for both copyConfig and pasteConfig. It also must contain both numbers and letters, be at least 8 characters long, and not use any multibyte characters.

16.6.2.2 Setting the Oracle Enterprise Scheduler Service System Properties

Prior to moving ESS, you must specify the directory location of the environment.properties file.

Note:

If both Oracle SES and ESS are installed on your environment, then combine the options for both components with the following command:

(UNIX C shell) setenv T2P_JAVA_OPTIONS "-Dsearch.encrypt.key=full_path_to_the_file_containing_the_encryption_key -Dess.config.dir=DirLocationOfPropsFile"
(UNIX Bourne shell) export T2P_JAVA_OPTIONS "-Dsearch.encrypt.key=full_path_to_the_file_containing_the_encryption_key -Dess.config.dir=DirLocationOfPropsFile"
(Windows) set T2P_JAVA_OPTIONS "-Dsearch.encrypt.key=full_path_to_the_file_containing_the_encryption_key -Dess.config.dir=DirLocationOfPropsFile"

In both the source and target environments, set the location of the file using the following command:

(UNIX C shell) setenv T2P_JAVA_OPTIONS "-Dess.config.dir=DirLocationOfPropsFile"
(UNIX Bourne shell) export T2P_JAVA_OPTIONS="-Dess.config.dir=DirLocationOfPropsFile"
(Windows) set T2P_JAVA_OPTIONS="-Dess.config.dir=DirLocationOfPropsFile"

where DirLocationOfPropsFile is the directory location of the environment.properties file.

In source environment, the -Dess.config.dir property points to the location of environment.properties file to be picked up for reading.

In target environment, the -Dess.config.dir property points to the location where the new environment.properties file will be created.

16.6.2.3 Setting the JVM System Variable on Windows

Before you run the pasteConfig script in Windows, you must set the USER_MEM_ARG variable as follows:

set USER_MEM_ARGS="-Xms256m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m  -XX:MaxPermSize=1024m"

16.6.3 Moving the Webgate Installation

Webgate acts as the proxy for user authentication. It must be manually moved from the source environment to the target environment. To move the Webgate installation, follow the instructions below:

• UNIX. See Section 16.6.3.1.

• Windows. See Section 16.6.3.2.

Note:

The Webgate directory must be in the following directory:

Oracle_Instance/config/OHS/ohs_component_name

Successfully moving the Webgate installation is based on the assumption that the web server and Webgate setup on the source machine is functioning correctly.

16.6.3.1 Moving the Webgate Installation on UNIX

Before you move the Webgate installation on UNIX, make sure that the file permissions of the directory to which the Webgate installation is moved are the same as those of the source.

To move the Webgate installation on UNIX:

1. Go to the Webgate installation directory on source machine. For example:

   $ cd /net/mount1/appbase/webgate
   

2. Copy files recursively from the source machine to the target machine.

   For example, if the source machine file system is mounted on the network, then the Webgate installation can be copied with the following command:

   $ cp -rf * /net/mount1/appbase/webgate
   

   If the source machine file system is not mounted on the network, then the Webgate installation can be copied with the following command:

   $ tar cvf source_webgate.tar
   

   Then you must copy the archive file to the target machine and use the following command to extract the files from the archive:

   $ tar xvf source_webgate.tar -C target_Webgate_installation
   

3. If the Oracle Access Manager access servers to be used in the target environment are different than those used in the source environment:

   1. Copy the artifacts generated for this Webgate to Webgates installation directory. Artifacts generated should be copied as follows

      - ObAccessClient.xml to webgate_install_dir/access/oblix/lib

      - logout.html to webgate_install_dir/access/oamsso

      If the security mode is Simple:

      - password.xml to webgate_install_dir/access/oblix/config

      - aaa_key.pem and and aaa_cert.pem to webgate_install_dir/access/oblix/config/simple

      If the security mode is Cert:

      - password.xml to webgate_install_dir/access/oblix/config

      - It is the user's responsibility to generate certificate request and get it signed by a third-party Certificate Authority and copy to webgate_install_dir/access/oblix/config

16.6.3.2 Moving the Webgate Installation on Windows

Before you move the Webgate installation on Windows, if the target machine is running Windows 64 make sure that the Microsoft Visual Studio C++ 2005 runtime libraries (MSVCR80.dll and MSVCP80.dll) are installed. You can copy the libraries from SYSVOL\windows\SysWOW64 on the source machine to the same directory on the target machine.

To move the Webgate installation on Windows:

1. Copy the access directory from the Webgate installation directory on source machine and paste the directory in the Webgate installation directory on the target machine.

   1. Create an archive file by archiving the contents of the source_webgate_install_dir\access directory.

   2. Transfer the archive file to the target machine using File Transfer Protocol (FTP) or similar means.

   3. On target machine, extract the archive file to the required target_webgate_install_dir directory.

2. If the Oracle Access Manager access servers to be used in the target environment are different than those used in the source environment:

   1. Create the Webgate profile, then modify it in the Oracle Access Manager Access System Console. For information, see the "Managing OAM 10g Webgates with OAM 11g" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

   2. Create a Oracle Access Manager 10g Webgate profile using Oracle Access Manager Console. This will generate the artifacts for this Webgate under the following directories:

      FA_MW_HOME\user_projects\domains\base_domain\output\agent_ID
      

      For information, see the "Managing OAM 10g Webgates with OAM 11g" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

   3. Copy the artifacts generated for this Webgate to Webgates installation directory. Artifacts generated should be copied as follows

      - ObAccessClient.xml to webgate_install_dir\access\oblix\lib

      - logout.html to webgate_install_dir/access/oamsso

      If the security mode is Simple:

      - password.xml to webgate_install_dir\access\oblix\config

      - aaa_key.pem and aaa_cert.pem to webgate_install_dir\access\oblix\config\simple

      If the security mode is Cert:

      - password.xml to webgate_install_dir\access\oblix\config

      - It is the user's responsibility to generate certificate request and get it signed by a third-party Certificate Authority and copy to webgate_install_dir\access\oblix\config

16.6.4 Creating Configuration Archives

Run the copyConfig script for each source entity (for example, Oracle WebLogic Server domain, OHS instance, Node Manager, or Oracle BI Enterprise Edition) to create a copy of the source entity configuration files into an archive file.

This section covers the following topics:

• Running copyConfig for Oracle WebLogic Server Domains

• Running copyConfig for System Components

• Running copyConfig for Node Manager

• Running copyConfig for Oracle BI Enterprise Edition

16.6.4.1 Running copyConfig for Oracle WebLogic Server Domains

J2EE domains reside in the Oracle WebLogic Server Domain configuration home, APPLICATIONS_CONFIG/instance/domains. CRMDomain and FinancialDomain are two examples of J2EE domains.

Running copyConfig creates a copy of the source Oracle WebLogic Server Java EE component into a configuration archive file that contains the Oracle WebLogic Server domain configuration and all configurations stored in MDS. It also packs the other configuration information specific to components such as SOA composites, human workflow, Oracle B2B agreements, and Oracle Application Development Framework (Oracle ADF) connection settings for all connections.

Note:

copyConfig handles only global data sources defined in each Oracle WebLogic Server domain. For application level data sources, you must manually configure them on the target domain.

Use the following syntax to run the copyConfig script for each Oracle WebLogic Server domain:

copyConfig  -javaHome absolute_location_of_JDK
            -archiveLoc archive_location 
            -sourceDomainLoc source_WebLogic_domain_location
            -sourceMWHomeLoc source_Middleware_home_location
            -domainHostName source_domain_admin_server_host_name
            -domainPortNum  source_domain_admin_server_port
            -domainAdminUserName source_domain_admin_server_user_name
            -domainAdminPassword source_domain_admin_server_user_password_file_location
            [-logDirLoc existing_log_directory_location]
            [-silent {true | false}]

The following example copies the configuration of the Java EE FinancialDomain:

copyConfig.sh  -javaHome USER_HOME/jrockit_160_04
               -archiveLoc /FIN_T2P/FIN_FinancialDomain1.jar 
               -sourceDomainLoc /net/mount2/instance/applications/FinancialDomain
               -sourceMWHomeLoc /net/mount1/appbase/fusionapps
               -domainHostName server.us.example.com
               -domainPortNum 9001
               -domainAdminUserName faadmin
               -domainAdminPassword /FIN_T2P/domain_admin_server_pw.txt
               -logDirLoc /FIN_T2P/logs
               -silent true

/net/mount1/appbase represents the top level applications base directory for binaries, while /net/mount2 represents the top level applications configuration directory for configuration files.

Table 16-5 describes the options for the copyConfig script for Oracle WebLogic Server Java EE components.

Table 16-5 Options for the copyConfig Script for Oracle WebLogic Server Java EE Components

Options	Shortcut	Description	Mandatory or Optional
-javaHome	None	The absolute location of the Java Developer's Kit.	Mandatory
-d64	None	If the operating system is 64-bit UNIX, pass the -d64 option to the scripts in the command line. To set the runtime property, you can specify the -d64 option in the T2P_JAVA_OPTIONS environment variable. For example: setenv T2P_JAVA_OPTIONS "-d64 -Djava.io.tmpdir=/home/t2p/temp"	Optional
-archiveLoc	-al	The absolute location of the archive. Use this option to specify the location of the archive file to be created by the copyConfig script.	Mandatory
-sourceDomainLoc	-sdl	The absolute location of the source domain containing the Java EE component.	Mandatory
-sourceMWHomeLoc	-smw	The absolute location of the source Middleware home.	Mandatory
-domainHostName	-dhn	The name of the host on which the source domain is configured.	Mandatory
-domainPortNum	-dpn	The port number of the source domain.	Mandatory
-domainAdminUserName	-dau	The name of the administrative user for the source domain.	Mandatory
-domainAdminPassword	-dap	The password file location for the administrative user for the domain. For example, /FIN_T2P/domain_admin_server_pw.txt.	Mandatory
-logDirLoc	-ldl	The location of an existing log directory. A new log file is created in the directory.	Optional
-silent	None	Specifies whether the operation operates silently. That is, it does not prompt for confirmation. The default is that the operation prompts for confirmation. To continue, you must type yes, which is not case sensitive. Typing anything other than yes causes the script to return an error. To specify that it not prompt for confirmation, specify this option with the value of true.	Optional

16.6.4.2 Running copyConfig for System Components

Running copyConfig creates a copy of the source component instance for a system component, such as OHS, by copying the configuration files of that component instance into an archive file.

Use the following syntax to run the copyConfig script for system components:

copyConfig  -javaHome absolute_location_JDK
            -archiveLoc archive_location 
            -sourceInstanceHomeLoc source_instance_home_location
            -sourceComponentName source_component_name
            [-logDirLoc existing_log_directory_location]
            [-silent {true | false}]

The following example shows how to create a copy of the OHS instance named ohs1 in the Oracle instance located in APPLICATIONS_CONFIG/instance/CommonDomain_webtier on UNIX:

copyConfig.sh -javaHome USER_HOME/jrockit_160_17_R28.0.0-679/
              -archiveLoc /FIN_T2P/FIN_CommonDomain_webtier.jar
              -sourceInstanceHomeLoc /net/mount2/instance/CommonDomain_webtier
              -sourceComponentName ohs1
              -logDirLoc /FIN_T2P/logs
              -silent true

/net/mount2 represents the top level applications configuration directory for configuration files.

Table 16-6 describes the options for the copyConfig script for system components.

Table 16-6 Options for the copyConfig Script for System Components

Options	Shortcut	Description	Mandatory or Optional
-javaHome	None	The absolute location of the Java Developer's Kit.	Mandatory
-d64	None	If the operating system is 64-bit UNIX, pass the -d64 option to the scripts in the command line. To set the runtime property, you can specify the -d64 option in the T2P_JAVA_OPTIONS environment variable. For example: setenv T2P_JAVA_OPTIONS "-d64 -Djava.io.tmpdir=/home/t2p/temp"	Optional
-archiveLoc	-al	The absolute location of the archive. Use this option to specify the location of the archive file to be created by the copyConfig script.	Mandatory
-logDirLoc	-ldl	The location of an existing log directory. A new log file is created in the directory.	Optional
-silent	None	Specifies whether the operation operates silently. That is, it does not prompt for confirmation. The default is that the operation prompts for confirmation. To continue, you must type yes, which is not case sensitive. Typing anything other than yes causes the script to return an error. To specify that it not prompt for confirmation, specify this option with the value of true.	Optional
-sourceComponentName	-scn	The name of the source component to be moved. For example, if your Oracle Internet Directory component is named oid1, specify oid1.	Mandatory
-sourceInstanceHomeLoc	-sih	The absolute location of the Oracle instance for the source component.	Mandatory

16.6.4.3 Running copyConfig for Node Manager

Node Manager is an Oracle WebLogic Server utility that enables you to start, shut down, and restart the Administration Server and Managed Server instances from a remote location. The Node Manager for each host resides in Oracle WebLogic Server home, in wlserver_version/common/nodemanager/host_name.

Running copyConfig creates a copy of the source Node Manager configuration into an archive file.

Use the following syntax to run the copyConfig script for Node Manager on each machine within topology of the source environment:

copyConfig  -javaHome absolute_location_of_JDK
            -archiveLoc archive_location
            -sourceNMHomeLoc source_Node_Manager_home_location
            [-logDirLoc existing_log_directory_location]
            [-silent {true | false}]

The following example shows how to create a copy of the source Node Manager configuration located in /net/abcdef03/scratch/work/mw2903/wlserver_10.3/common/nodemanager/abcdef04.us.example.com (with a folder corresponding to each Node Manager) into an archive file:

copyConfig.sh -javaHome USER_HOME/jrockit_160_17_R28.0.0-679/
              -archiveLoc /FIN_T2P/node_manager_abcdef04.jar
              -sourceNMHomeLoc /net/mount1/appbase/fusionapps/wlserver_10.3/common/nodemanager/abcdef04.us.example.com
              -silent true

Table 16-7 describes the options for the copyConfig script for Node Manager.

Table 16-7 Options for the copyConfig Script for Node Manager

Options	Shortcut	Description	Mandatory or Optional
-javaHome	None	The absolute location of the Java Developer's Kit.	Mandatory
-d64	None	If the operating system is 64-bit UNIX, pass the -d64 option to the scripts in the command line. To set the runtime property, you can specify the -d64 option in the T2P_JAVA_OPTIONS environment variable. For example: setenv T2P_JAVA_OPTIONS "-d64 -Djava.io.tmpdir=/home/t2p/temp"	Optional
-archiveLoc	-al	The absolute location of the archive. Use this option to specify the location of the archive file to be created by the copyConfig script.	Mandatory
-sourceNMHomeLoc	-snh	The absolute location of the source Node Manager Home.	Mandatory
-logDirLoc	-ldl	The location of an existing log directory. A new log file is created in the directory.	Optional
-silent	None	Specifies whether the operation operates silently. That is, it does not prompt for confirmation. The default is that the operation prompts for confirmation. To continue, you must type yes, which is not case sensitive. Typing anything other than yes causes the script to return an error. To specify that it not prompt for confirmation, specify this option with the value of true.	Optional

16.6.4.4 Running copyConfig for Oracle BI Enterprise Edition

You copy the configuration of the following Oracle BI Enterprise Edition components:

• Oracle BI Server

• Oracle BI Presentation Services

• Oracle BI Cluster Controller

• Oracle BI Scheduler

• JavaHost

• Oracle Essbase server, if it is installed in your environment

Running copyConfig creates a copy of the source Oracle BI Enterprise Edition configuration into an archive file. You do not need to use the copyconfig script for each component. Use the copyconfig script once for all the Oracle BI Enterprise Edition components.

Use the following syntax to run the copyConfig script to run a complete Oracle BI Enterprise Edition instance copy:

copyConfig  -javaHome path_of_jdk 
            -archiveLoc archive_location 
            -sourceInstanceHomeLoc src_instance_path
           [-additionalParams essbaseServerUserName=xxx,essbaseServerPassword=pwdfile] 
           [-logDirLoc existing_log_directory_location] 
           [-silent {true | false}]

The following example shows how to apply the copy of Oracle BI Enterprise Edition to the Oracle BI Enterprise Edition home located in BIDomain:

copyConfig -javaHome USER_HOME/jrockit_160_17_R28.0.0-679/ 
           -archiveLoc /FIN_T2P/BIInstance.jar 
           -sourceInstanceHomeLoc /net/mount1/appbase/instance/BIInstance
           -additionalParams essbaseServerUserName=weblogic,essbaseServerPassword=/tmp/welcome1.txt 
           -silent true

Table 16-8 describes the options for the pasteConfig script for Oracle BI Enterprise Edition.

Table 16-8 Options for the copyConfig Script for Oracle BI Enterprise Edition

Options	Shortcut	Description	Mandatory or Optional
-javaHome	None	The absolute path of the Java Developer's Kit.	Mandatory
-archiveLoc	-al	The absolute path of the archive location. Use this option to specify the location of the archive file created by the copyConfig script.	Mandatory
-sourceInstanceHomeLoc	-sih	The absolute path of the Oracle BI Enterprise Edition instance for the source component.	Mandatory
-additionalParams	-ap	Specifies Oracle Essbase administrative user and password.	Mandatory
-logDirLoc	-ldl	The location of an existing directory. A new log file is created in the directory.	Optional
-silent	None	Specifies whether the operation operates silently. That is, it does not prompt for confirmation. The default is that the operation prompts for confirmation. To specify that it not prompt for confirmation, specify this option with the value of true.	Optional

16.6.5 Extracting the Move Plan

Run the extractMovePlan script to extract the configuration settings from multiple configuration archives of the source environment into a single move plan (XML file). Extracting the move plan from multiple configuration archives consolidates and tries to remove duplicate configuration properties in the consolidated move plan. It also tries to remove the configuration properties that could be derived from other configuration properties. Running extractMovePlan also extracts other application specific standard configuration plans such as the configuration plan for SOA composite, the deployment plan for J2EE App, and so on.

Note:

Extract the move plan in a location that is shared by all systems in the configuration topology. You can then use the move plan and underlying configuration or deployment plans from the same location to recreate multiple domains or system component instances.

Use the following syntax to run the extractMovePlan script:

extractMovePlan -javaHome absolute_location_of_JDK
             -archiveLoc archive_location [,archive_location...] 
             -planDirLoc move_plan_directory
             [-optimizationHints fusionApps,sameSchemaNameSinglePassword]
             [-logDirLoc existing_log_directory_location]

The following example extracts configuration information from two configuration archives into a single move plan:

extractMovePlan.sh -javaHome USER_HOME/jrockit_160_20_D1.0.1-1705
                -archiveLoc /FIN_T2P/FIN_CommonDomain1.jar,/FIN_T2P/FIN_FinancialDomain1.jar
                -planDirLoc /FIN_T2P/CommonDomain1_plan
                -opth fa,ssnsp
                -logDirLoc /FIN_T2P/logs

A list of configuration archive locations, separated by comma, is specified to create a single move plan containing the configuration settings from the listed configuration archives.

Note:

Make sure there is no space before or after the comma in the list of configuration archive locations.

You can also extract the configuration settings from each individual configuration archive to create multiple move plans. However, this neither consolidates, nor optimizes the move plans.

Table 16-9 describes the options for the extractMovePlan script:

Table 16-9 Options for the extractMovePlan Script

Options	Shortcut	Description	Mandatory or Optional
-javaHome	None	The absolute location of the Java Developer's Kit.	Mandatory
-d64	None	If the operating system is 64-bit UNIX, pass the -d64 option to the scripts in the command line. To set the runtime property, you can specify the -d64 option in the T2P_JAVA_OPTIONS environment variable. For example: setenv T2P_JAVA_OPTIONS "-d64 -Djava.io.tmpdir=/home/t2p/temp"	Optional
-archiveLoc	-al	The absolute location of one or more archives. Use this option to specify the locations of the archive files created by the copyConfig script. If you specify more than one archive, separate the locations with a comma with no spacing in between.	Mandatory
-planDirLoc	-pdl	The absolute path to a directory to which the move plan, along with any needed configuration plans, is to be extracted. The directory must not already exist.	Mandatory
-logDirLoc	-ldl	The location of an existing directory. A new log file is created in the directory.	Optional
-optimizationHints	-opth	Specifies the configuration values to auto-populate based on the topology on the target environment. These values are omitted from the move plan. Use of the hints is recommended if they apply to your environment. The -optimizationHints takes the following arguments: fusionApps. You need to provide this hint always. This simplifies the move plan for Oracle Fusion Applications. sameSchemaPassword (ssnsp). The same password is used for all database schema users. You are prompted for the password only once.	Optional

16.6.6 Modifying the Move Plan

After the move plan is extracted, you must modify it with a text editor to specify the properties (such as data source definitions, host names, port numbers, and end point addresses) for the target environment before you apply the copied configurations from the source environment to the target environment.

Note:

If you extracted multiple move plans, you must modify each of those move plans. You must also modify other extracted plans, such as composite configuration plans, JEE application deployment plans, and adapter plans, if they contain any configuration that is environment specific. These plans are extracted under the domain directories, which are created at the same level as the move plan.

For information about the Oracle Fusion Middleware component properties in the move plan, and which properties you can edit, see the "Move Plans for Components" section in the Oracle Fusion Middleware Administrator's Guide.

In addition to editing the Oracle Fusion Middleware component properties in the move plan, you must also edit the properties for:

• Custom identity keystore and trust keystore properties. See Section 16.6.6.1.

• Oracle Fusion Applications patching framework. See Section 16.6.6.2.

• Node Manager. See Section 16.6.6.3.

• Oracle BI EE. See Section 16.6.6.4.

• Oracle Topology Manager. See Section 16.6.6.5.

• Oracle Enterprise Crawl and Search Framework (ECSF). See Section 16.6.6.6.

• Oracle Secure Enterprise Search (Oracle SES). See Section 16.6.6.7.

• Oracle Enterprise Scheduler Service (ESS). See Section 16.6.6.8.

• Oracle Universal Content Management (Oracle UCM). See Section 16.6.6.9.

• Oracle Imaging and Process Management (Oracle I/PM). See Section 16.6.6.10.

• Oracle Data Integrator. See Section 16.6.6.11.

• Oracle Fusion Applications additional environment properties. See Section 16.6.6.12.

16.6.6.1 Editing Custom Identity Keystore and Trust Keystore Properties

You must manually update the custom identity keystore and custom trust keystore property values to specify the location values for the target domain. To update the custom identity keystore and custom trust keystore property values, edit the values of the properties in the SERVER_CONFIG element of the move plan.

Table 16-10 describes the custom identity keystore and custom trust keystore properties.

Table 16-10 Custom Identity Keystore and Custom Trust Keystore Properties

Property	Description	Sample Value
Custom Identity Keystore File	Absolute path of custom identity keystore file location	/net/mount1/appbase/fusionapps/wlserver_10.3/server/lib/xyz1234567.us.example.com_fusion_identity.jks
Custom Identity Keystore Passphrase File	Absolute path to the secure file containing the custom identity keystore password	/scratch/pass.txt
Custom Trust Keystore File	Absolute path of custom trust keystore file location	/net/mount1/appbase/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks
Custom Trust Keystore Passphrase File	Absolute path to the secure file containing the custom trust keystore password	/scratch/pass.txt
Custom Identity Private Key Alias	Alias of the private key	xyz1234567.example.com_fusion
Custom Identity Private Key Passphrase File	Absolute path to the secure file containing the custom identity private key password	/scratch/pass.txt

16.6.6.2 Editing Oracle Fusion Applications Patching Framework Properties

You must manually update the Oracle Fusion Applications patching framework configuration information to specify the properties for the target domain. To update the Oracle Fusion Applications patching framework configuration information, edit the values of the patching framework properties in the move plan.

Table 16-11 describes the patching framework properties.

Table 16-11 Move Plan Properties for Oracle Fusion Applications Patching Framework

Properties	Description	Example
Top directories for various components used by Patching Framework	The following properties are defined in FUSION_prov.properties:
APPTOP	Applications base directory, APPLICATIONS_BASE	/u01/APPTOP
BI_WEBCAT_ROOT	Top directory for Oracle BI Presentation Catalog	/u01/APPTOP/instance/BIShared/OracleBIPresentationServicesComponent/coreapplication_obips1/catalog/OracleBIApps
WLS_DOMAIN_HOME	Oracle WebLogic Server domain home where domain configuration files can be found	/u01/APPTOP/instance/domains/adc6170361.us.oracle.com/FinancialDomain
Database-Related Properties	The following properties are in the ASOAppsTableSpaceCustomizations config group. Each aggregate storage (ASO) application has a name and table space property, followed by the following properties:
TWO_TASK	Oracle Database database service as defined by the SERVICE_NAME parameter in the tnsnames.ora file	prod
DB_CONNECT_STRING	JDBC thin driver URL to connect to the database	jdbc:oracle:thin:@adcdah01.us.oracle.com:1576/fapatch7
Taxonomy Related Properties
TAXONOMY_URL	URL to connect to the MBean to fetch taxonomy information. This URL is usually the same as the Administration Server URL. See Section 2.4 to find the URL for the Administration Server.	adc6170361.us.oracle.com:7001
LDAP-related properties	The following properties are defined in FUSION_prov.properties:
POLICY_STORE_LDAP_HOSTNAME	Host name for policy store	adc6260031.us.oracle.com
POLICY_STORE_LDAP_PORT	Port for policy store connection	3060
IDENTITY_STORE_LDAP_HOSTNAME	Host name for identity store	adc6260031.us.oracle.com
IDENTITY_STORE_LDAP_PORT	Port for identity store connection	3060

16.6.6.3 Editing Node Manager Properties

You must modify the move plan to specify the Oracle Data Integrator properties for the target environment before you apply the copied configurations from the source environment to the target environment.

Table 16-12 describes the Node Manager properties. The following properties are present in the move plan only if the source environment is configured with Secure Sockets Layer (SSL):

Table 16-12 Node Manager Properties

Property	Description	Sample Value
Listen Address	The following properties are defined in FUSION_prov.properties:	xyz1234567.example.com
Listen Port	Listen port of Node Manager	5557
Custom Identity KeyStore File	Absolute path of the custom identity keystore file location	/net/mount1/appbase/fusionapps/wlserver_10.3/server/lib/xyz1234567.us.example.com_fusion_identity.jks
Custom Identity Private Key Alias	Value of the identity keystore alias	xyz1234567.example.com_fusion
Custom Identity Private Key Passphrase File	Absolute path to the secure file containing the private key used when creating the certificate	/scratch/pass.txt

16.6.6.4 Editing Oracle BI EE Properties

This section describes the move plan properties for Oracle BI Enterprise Edition, Oracle BI EE Data Warehouse Administration Console, Oracle Essbase, EPM Registry, and Oracle BI Action Framework.

Table 16-13 shows the move plan properties that you can change for Oracle BI Enterprise Edition.

Table 16-13 Move Plan Properties for Oracle BI EE

Properties	Description	Sample Value
Oracle BI Publisher Configuration	The following properties are in the XMLP-SERVER-CONFIG configuration group.
SAW_SERVER	The name of the host that is running the Oracle BI Presentation Services to which you must connect	example_host
SAW_PORT	The port number for connecting to Oracle BI Presentation Services	10217
SAW_PASSWORD	The absolute path of a secure file that contains the password for Oracle BI Presentation Services	/scratch/oracle/bip_pass.txt
SAW_USERNAME	The user name for Oracle BI Presentation Services	user1
Data Sources Configuration	The following properties are in the XMLP-DATASOURCES configuration group.
	The following properties are in the connection configProperty, a sub-property of dataSource. Specifies that the data source is a Connection type. Each data source can be either a Connection or File type.
url	The URL of the connection	jdbc:oracle:thin:@host:port:sid
driver	The driver to use for the connection	oracle.jdbc.OracleDriver
username	The user name for the connection	user1
password	The absolute path of a secure file that contains the password for the connection	/scratch/oracle/ds_conn_pass.txt
	The following property is in the file configProperty, a sub-property of dataSource. Specifies that the data source is a File type.
path	The file system path that points to the relevant data source file	/scratch/APPTOP/instance/domains/example.com/BIDomain/config/bipublisher/repository/DemoFiles
Oracle BI Publisher Client	The following properties are in the XDO-CLIENT_CONFIG configuration group:
XMLPClientDirPath	The absolute path to the Oracle BI Publisher client directory	/scratch/APPTOP/instance/domains/example.com/CommonDomain/config
* (any name)	The Oracle BI Publisher configured endpoint connecting URL. The move plan may have more than one endpoint	http://example.com:10621/xmlpserver
	The following properties are in the XMLP-SCHEDULER-JMS-CONFIG configuration group:
JMS_WEBLOGIC_JNDI_URL	The Oracle WebLogic Server JNDI URL for the Oracle BI EE Managed Server	cluster:t3://bi_cluster
JMS_Shared_Temp_Directory	The JMS shared temporary directory used in an Oracle BI EE cluster environment	/scratch/APPTOP/instance/BIShared/BIPublisher/biptemp
Oracle BI Publisher Provider	The following properties are in the XMLP-PROVIDER-CONFIG configuration group:
	The following properties are in the provider configProperty. The Oracle BI Publisher provider. There is a separate configProperty for each BI Publisher provider configured
uri	The URI for the Oracle BI Publisher provider	http://example.com:10603/financialCommon
nonSSOUri	The non-SSO URI for the Oracle BI Publisher provider	http://example.com:7404/financialCommon
Oracle BI Publisher Server	The following properties are in the XDO-SERVER_CONFIG configuration group:
XMLPServerConfigDirPath	The absolute path to the Oracle BI Publisher server configuration directory	/scratch/APPTOP/instance/domains/example.com/BIDomain/config/bipublisher
	The following property is in the RepositoryDirPath configProperty, the directory path of the Oracle BI Publisher server repository
path	The directory of the Oracle BI Publisher server configuration repository. (It can be located outside of the BIDomain that is specified as the server xdo.server.config.dir system property.) The default value is ${xdo.server.config.dir}/repository.	/scratch/APPTOP/instance/BIShared/BIPublisher/repository
	The following property is in the SawSourcePath configProperty. The Oracle BI Publisher server connection resource details for the Oracle BI EE Presentation Server.
source	The path for the Oracle BI Publisher repository directory	/scratch/APPTOP/instance/domains/example.com/BIDomain/config/bipublisher/repository
Oracle BI EE Domain Configuration	The following properties are in the OracleInstances configuration group:
instanceHome	The path of the Oracle instance in which Oracle BI EE is deployed	/scratch/APPTOP/instance/BIInstance
host	The host where the Oracle BI EE instance is configured	example.com
	The following properties are in the BIInstanceDeployment configProperty. Instance configuration details
listenAddress	The listen address for the host. It can be set to a virtual IP address or a subset on a multi-homed computer. You can specify an asterisk to specify multiple network addresses for the host	example.com *
portRangeStart	The start of the range of ports used by the Oracle BI EE system components	10206
portRangeEnd	The end of the range of ports used by the Oracle BI EE system components	10214
	The following properties are in the BIInstance configuration group:
	The following properties are in the EmailOptions configProperty:
smtpServerName	The host name of the SMTP server	example.com
port	The port number of the SMTP server	25
fromDisplayName	The sender's name that is used as the display name by the Oracle BI EE system when it sends email	Oracle Business Intelligence
emailAddressOfSender	The email address used by the Oracle BI EE system when it sends email	[e-mail]
	The following properties are in the MarketingOptions configProperty:
url	The base URL used by the Oracle BI EE system when the emails have embedded URLs	http://example.com:7012/_dav/cs/idcplg
	The following properties are in the PresentationServerOptions configProperty:
webCatalogLocation	The absolute path of the location of the Oracle BI Presentation Catalog	/scratch/APPTOP/instance/BIShared/OracleBIPresentationServicesComponent/coreapplication_obips1/catalog/OracleBIApps
	The following property is in the Scheduler configProperty only
dataSource	The connection details for the Oracle BI Scheduler data source	(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=example.com)(PORT=1565)))(CONNECT_DATA=(SERVICE_NAME=d8b4lfc1))
	The following properties are in the ServerOptions configProperty:
repositoryDataSourceName	The name of the data source for the Oracle BI repository	Star
repositoryName	The name of the Oracle BI repository file.	OracleBIApps_BI0002
repositorySharedLocation	The shared location for the Oracle BI repository	/scratch/APPTOP/instance/BIShared/OracleBIServerComponent/coreapplication_obis1/repository
	The following property in the PerformanceOptions configProperty:
globalCacheStoragePath	The global location of the Oracle BI EE server cache	/scratch/APPTOP/instance/BIShared/OracleBIServerComponent/coreapplication_obis1/cache
Oracle RTD Inline Services (BI_RTD_SPE_ILS_DEPLOY_CONFIG)	The following properties are in the DEPLOY_USER_CREDENTIALS configuration group:
username	The user name used to deploy the RTD SPE inline service	weblogic
password	The absolute path of a secure file that contains the password for the connection	/scratch/oracle/rtd_pass.txt
RPD_CONFIG	The following properties are in the CONNECTIONPOOLS configuration group:
user	Connection pool user name (the database schema name). The name may be a variable, in the format VALUE_OF(varname) which would then appear in the VARIABLES configuration group.	VALUEOF(ORACLE_INITBLOCK_USER)
datasource	Oracle BI repository connection pool data source name or definition. The name may be a variable, in the format VALUE_OF(varname) which would then appear in the VARIABLES configuration group.	VALUEOF(ORACLE_INITBLOCK_DSN)
appServerName	If this is an ADF connection, the Business Component URL	http://example.com:10603/fscmAnalytics/obieebroker
password	The absolute path of a secure file that contains the password for the connection to the Oracle BI repository data source	/scratch/oracle/rpd_ds_conn_pass.txt
	The following properties are in the VARIABLES configuration group:
name	The name of the variable that is used in the Oracle BI repository connection pool definitions. There can be multiple name/value pairs.	ORACLE_INITBLOCK_USER
value	The value of the variable that is used in the Oracle BI repository connection pool definitions. There are multiple name/value pairs.	'ORA_INIT_USER'

Table 16-14 describes the move plan properties that you can change for Oracle BI EE Data Warehouse Administration Console.

Table 16-14 Move Plan Properties for Oracle BI EE Data Warehouse Administration Console (DAC)

Properties	Description	Example
DAC Configuration	The following properties are in the DAC-SERVER-CONFIGURATION configuration group:
jdbc.url	The URL to connect to the DAC repository	jdbc:oracle:thin:@example.com:1521/example.com
jdbc.driver	The name of the JDBC driver	oracle.jdbc.driver.OracleDriver
Username	The user name used to connect to the DAC repository	IMPORT_DAC
Password File	The absolute path of a secure file containing the password for the user to connect to the DAC repository. You must provide a password file, even if you are not changing the configuration.	/scratch/biplatform/cloning/password_DAC.txt
	The following properties are in the EMAIL-CONFIGURATION configuration group:
email_host	The host name of the email server	example
email_protocol	The protocol for the email server	smtp
email_address	The email address of the user	[e-mail]
needs_authentication	The flag indicating whether the corporate email server requires authentication. Valid values are true or false.	true
needs_ssl	The flag indicating whether an SSL connection is required. Valid values are true or false.	false
email_host_port	The port where the email server listens	5555
email_user	User name for the email account	test
email_password	The absolute path of a secure file containing the password for the user of the email server. (Only required if you needs_authentication is true.)	/scratch/biplatform/cloning/password_email.txt
	The following properties are in the DATAWAREHOUSE-CONFIGURATION configuration group:
jdbc.url	The URL to connect to the Data Warehouse	jdbc:oracle:thin:@example.com:1521/example.com
jdbc.driver	The name of the JDBC driver	oracle.jdbc.driver.OracleDriver
Username	The user name used to connect to the Data Warehouse	IMPORT_DW
Password File	The absolute path of a secure file containing the password for the user to connect to the Data Warehouse. You must provide a password file, even if you are not changing the configuration.	/scratch/biplatform/cloning/password_DW.txt
	The following properties are in the INFORMATICA-CONFIGURATION configuration group:
Informatica server home	The Informatica server home	/scratch/infahome/
Domains infa file location	The domain's infa file location	/scratch/infahome/domains.info
InformaticaParameterFileLocation	The directory where the Informatica parameter files are stored (or DEFAULT)	DEFAULT
	The following properties are in the DATASOURCES-CONNECTION-DETAILS configuration group:
type	The physical data source type. Possible values are: Source, Warehouse, Informatica Repository, DAC Repository, or Other.	Source
Connection Type	The type of database connection. Possible values are: BI Server, Oracle (OCI8), Oracle (Thin), DB2, DB2-390, MSSQL, Teradata, and Flat File.	Oracle (Thin)
Connection String	The data source connection string. If you are using: Oracle (OCI8): Use the tnsnames.ora file entry. Oracle (Thin): Use the instance name. SQL Server: Use the database name. DB2-UDB/DB2-390: Use the connect string as defined in the DB2 configuration. Teradata: Use the database name.	orcl.example.com
Table Owner	The name of the table owner	DB_USER
Host	The host name of the server where the database resides	example.com
Port	The port where the database receives requests	1521
JDBC Driver (Optional)	The JDBC driver for the data source connection. The value in this field must conform to the database specifications.	oracle.jdbc.driver.OracleDriver
URL (Optional)	The JDBC URL for the data source connection. The value in this field must conform to the database specifications.	jdbc:oracle:thin:@example.com:1521/orcl.example.com
Password File	The absolute path of a secure file containing the password for the user to connect to data source. You must provide a password file, even if you are not changing the configuration.	/scratch/biplatform/cloning/password_ds.txt
Connection Pool Name (BIPool)	The connection pool name	FSCM_OLTP."Connection Pool"
Database Type (BIPool)	Database type of the transactional data source	Oracle
	The following properties are in the EXTERNAL-EXECUTORS configuration group:
Execution type	The execution type for the tasks that will be executed by the external executor	ODI 11g Embedded Agent
name	The name of the property that must be configured to integrate DAC with other Extract, Transform, and LoadExtract, Transform, and Load (ETL) tools. There are multiple properties for the external executors. Name is the name of the property. Value is the value that defines the property.	<name>ODIUser</name> <value>TestUser</value>

Table 16-15 describes the move plan properties that you can change for Oracle Essbase.

Table 16-15 Move Plan Properties for Oracle Essbase

Properties	Description	Example
Oracle Essbase	The following properties are in the EssbaseAgentConfig configuration group
ARBORPATH	The absolute path for ARBORPATH	/scratch/oracle/shared_essbase
PortRange	The port range for Oracle Essbase	9000-9499
agent-port	The port number of the Oracle Essbase agent	9799
EssbaseAdminUserName	The administration user name for Oracle Essbase	weblogic
EssbaseAdminPassword	The absolute path of a secure file containing the password for the Oracle Essbase administration password	/scratch/oracle/essbase_passwd.txt
Aggregate Storage (ASO) Application	The following properties are in the ASOAppsTableSpaceCustomizations config group. Each aggregate storage (ASO) application has a name and table space property, followed by the following properties:
file_location	The absolute path of the application file	/scratch/oracle/aso
max_file_size	The maximum size of the file, in bytes.	1.34217727E8
max_disk_size	The maximum size of the disk, in bytes	4.294967295E9
Block Storage (BSO) Application	The following properties are in the BSOAppsDiskVolumeCustomizations configuration group. Each Oracle Essbase block storage (BSO) application has a name and database name property, followed by the following properties:
volume	The location of the disk volume	/scratch/biplatform
file_type	The file type of the disk volume, such as index, data, or index_data	index_data
file_size	The size of the volume, in bytes	2.147483648E9
partition_size	The size of the partition, in bytes	9.007199254739968E15

Table 16-16 describes the move plan properties that you can change for the EPM Registry.

Table 16-16 Move Plan Properties for the EPM Registry

Properties	Description	Example
EPM Registry	The following properties are in the reg.properties configuration group:
jdbc.url	The URL to connect to the EPM Registry database	jdbc:oracle:thin:@example.com:1570/db20258
jdbc.driver	The name of the JDBC driver	oracle.jdbc.OracleDriver
username	The user name used to connect to the EPM database	FUSION_BIPLATFORM
password	The absolute path of a secure file containing the password for the user to connect to the EPM database. You must provide a password file, even if you are not changing the configuration.	/scratch/biplatform/password_epm_jdbc.txt
	The following properties are in the EPM_COMPONENTS group.
	The following properties are in the DATABASE_CONN configProperty:
host	The database server host name	example.com
dbUserName	The database user name	FUSION_BIPLATFORM
dbJdbcUrl	The JDBC URL to connect to the database	jdbc:oracle:thin:@example.com:1570/db20258
dbName	The database name. For Oracle Database, use the service name or SID	db20258
dbPort	The database port number	1570
dbPassword	The absolute path of a secure file containing the password for the user to connect to the database. You must provide a password file, even if you are not changing the configuration.	/scratch/biplatform/password_epm_db.txt
	The following properties are in the Default configProperty:
host	The host name of the front-end web server or load balancer	example2.com
port	The port of the front-end web server or load balancer. This is a subentry to the Default property.	10621
isSSL	The flag indicating whether the front end is in SSL mode. Valid values are true and false.	false
SSLPort	The SSL port of the front-end web server or load balancer	10218
	The following properties are in the WORKSPACE_APP configProperty:
host	The host name of the server hosting the Workspace web application	example.com
port	The port where the Workspace web application is running	10217
SSLPort	The SSL port (if configured for SSL) where the Workspace web application is running	10218
	The following properties are in the WEB_SERVER configProperty:
host	The host name of the web server that the web application is configured to use	example.com
port	The port where the web application is running	10217
isSSL	The flag indicating whether the front end is in SSL mode. Valid values are true and false.	false
	The following properties are in the CALC_WEBAPP configProperty:
host	The host name of the server hosting the Oracle Calculation Manager web application	example.com
port	The port where the Oracle Calculation Manager web application is running	10217
SSL_Port	The SSL port (if configured for SSL) where the Oracle Calculation Manager web application is running	10218
	The following property contains the name of the Oracle Essbase cluster
name	The name of the Oracle Essbase cluster. There may be more than one cluster	EssbaseCluster-1
	The following properties are in the essbaseservern configProperty:
host	The host name of the Oracle Essbase server	example.com
arborPath	The ARBORPATH of the Oracle Essbase server	/scratch/rmunugal/shared_essbase
ess_AppLocation	The location of the Oracle Essbase application location	/scratch/biplatform/instances/instance1/Essbase/essbaseserver1
agent_PortNumber	The agent port number of the Oracle Essbase server	9511
agent_StartPort	The start of the range of ports used by agent for Oracle Essbase server	9000
agent_StopPort	The end of the range of ports used by agent for Oracle Essbase server	9499
	The following properties are in the BIEE_WEBAPP configProperty:
host	The host name of the server hosting the Oracle BI EE web application.	example.com
port	The port where the Oracle BI EE web application is running	10217
SSL_Port	The SSL port (if configured for SSL) where the Oracle BI EE web application is running	10218
	The following properties are in the PROVIDER_SERVICES_WEB_APP configProperty:
host	The host name of the server hosting the Oracle Essbase APS web application	example.com
port	The port where the Oracle Essbase APS web application is running	10217
SSL_Port	The SSL port (if configured for SSL) where the Oracle Essbase APS web application is running	10218
	The following properties are in the PFINANCIAL_REPORTING_WEB_APP configProperty
host	The host name of the server hosting the Financial Reporting web application.	example.com
port	The port where the Financial Reporting web application is running	10217
SSL_Port	The SSL port (if configured for SSL) where the Financial Reporting web application is running	10218

Table 16-16 describes the move plan properties that you can change for Oracle BI Action Framework

Table 16-17 Oracle BI Action Framework

Properties	Description	Sample Value
Action Framework	The following property is in the location-alias group:
alias_name	The URL corresponding to the action name Note that there may be more than one name/value pair	http://adc10001.us.oracle.com:9704/analytics

16.6.6.5 Editing Oracle Topology Manager Properties

Configuration information for Oracle Topology Manager is moved from a source environment to a target environment using the configuration scripts. However, you must modify the move plan to specify the Oracle Topology Manager properties for the target environment before you apply the copied configurations from the source environment to the target environment.

Table 16-18 describes the Oracle Topology Manager properties. Edit the values of each property.

Table 16-18 Oracle Topology Manager Properties

Configuration Group	Property	Description	Sample Value
deployed-environment	name	Name of the environment	oracle
deployed-database	name	Database name	abprod
	sid	Database system identifier (SID)	x01yz234
	host	Database host name	abc12345fems.us.example.com
	port	Database port number	1525
deployed-domain	admin-server-name	Name of the administrator server for this domain	AdminServer
	admin-server-protocol	Protocol used by the administrator server for this domain	http
	admin-host	Administrator server host name for this domain	serverhost.us.example.com
	admin-port	Administrator server port number for this domain	7101
	internal-server-protocol	Protocol used by the internal server for this domain	http
	internal-endpoint-host	Host name of the internal server for this domain	hostname.us.example.com
	internal-endpoint-port	Port number of the internal server for this domain	7102
	external-server-protocol	Protocol used by the external server for this domain	https
	external-endpoint-host	Host name of the external server for this domain	fusionapps-systemfin-us.example.com
	external-endpoint-port	Port number of the external server for this domain	80
	node-manager-protocol	Protocol used by the node manager for this domain	https
	node-manager-port	Port number of the node manager for this domain	5556
	jmx-port	JMX port number for this domain	9001
	em-home-url	Full path of the location where Oracle Enterprise Manager is hosted for this domain	http://emhome.us.example.com:7101/em
deployed-application	external-server-protocol	Protocol used by the external server for this deployed application	http
	external-endpoint-host	Host name of the external server for this deployed application	fusionapps-systemfin-us.example.com
	external-endpoint-port	Port number of the external server for this deployed application	80

16.6.6.6 Editing ECSF Properties

The ECSF seed data (data in the ECSF tables) is moved from the source environment to the target environment using the configuration scripts. Running the copyConfig script creates a configuration archive that contains the snapshot of the ECSF seed data. The extractMovePlan script extracts the environment specific ECSF configuration properties from the source environment into the move plan. You must modify the move plan to specify the ECSF parameter values for the target environment before you execute the pasteConfig script.

ECSF plug-in execution varies from domain to domain. In the CommonDomain domain, it extracts all the data from ECSF tables from source database and imports the data into the target database. In the CRMDomain, HCMDomain, and FinancialDomain domains, if the corresponding search service component is active, it updates certain records specified in the move plan. The plug-in does not do anything in other domains.

Table 16-19 describes the ECSF properties. Edit the values of the ECSF properties in the move plan.

Table 16-19 ECSF Properties

Property	Description	Sample Value
SES_ADMIN_SERVICE	URL to Oracle SES administrative web service end point	http://example.com:12345/search/api/admin/AdminService
SES_QUERY_SERVICE	URL to Oracle SES Query web service end point	http://example.com:12345/search/query/OracleSearch
ECSF_DATA_SERVICE	URL to ECSF servlets. This URL is used to construct config feeds for Oracle SES	http://example.com:67890/crmSearch/searchfeedservlet
ECSF_SECURITY_SERVICE	URL to ECSF servlets. This URL is used to construct config feeds for Oracle SES. ECSF runtime URL and ECSF Security Service URL can be set to two different servers, which is also what Oracle SES supports	http://example.com:67890/crmSearch/searchfeedservlet
ECSF_REDIRECT_SERVICE	URL to ECSF feed servlets. This URL is used to redirect drilldowns or actionable results	http://example.com:67890/crmSearch/searchfeedservlet

Note:

Any properties that are internally derived do not appear in the move plan.

16.6.6.7 Editing Oracle SES Properties

You must modify entries in the move plan to change the writable attributes of configuration properties (configProperty) such as server names, user names, passwords, and so on for the target environment before you apply the copied configurations from the source environment to the target environment.

Table 16-20 describes the Oracle SES properties. Edit the values of these properties in the move plan.

Note:

Oracle SES is dependent on the SEARCH_TOP property of the ESS-EXT component. You must modify the value of the SEARCH_TOP property. For information, see Section 16.6.6.

Table 16-20 Oracle SES Properties

Configuration Group	Property	Description	Sample Value
identityPlugin	HTTP endpoint for authentication	The HTTP endpoint for authentication. This is the URL for the search application deployment endpoint for the Oracle Fusion customer.	http://abcdef05.us.example.com:10615/crmSearch/searchfeedservlet/SecurityService
userDefinedSource	Configuration URL	The file or HTTP URL of the configuration file. For Oracle Fusion sources, the value is the URL for the search application deployment endpoint. For WebCenter sources, the value is the WebCenter RSS crawl servlet endpoint.	For Oracle Fusion sources: http://abcdef05.us.example.com:10615/crmSearch/searchfeedservlet/oracle.apps.contracts.dashBoard.textSearch.publicModel.view.ContractHeaderSearchVO/ConfigFeed?engineInstId=100010032752886 For WebCenter sources: http://abcdef05.us.example.com:10613/rsscrawl?excludedServiceIds=oracle.webcenter.peopleconnections.profile For Oracle UCM sources: http://abcdef05.us.example.com:10613/cs/idcplg?IdcService=SES_CRAWLER_DOWNLOAD_CONFIG&source=default
	Oracle SSO Login URL	(Optional) The Oracle Single Sign-On login URL that protects all Oracle Single Sign-On applications. This parameter is relevant when the authentication type is ORASSO.	https://login.example.com/mysso/signon.jsp
	Oracle SSO Action URL	(Optional) The Oracle Single Sign-On action URL that authenticates Oracle Single Sign-On user credentials. This is the URL to which the Oracle Single Sign-On login form is submitted. This parameter is relevant when the authentication type is ORASSO.	https://login.example.com/sso/auth
	Scratch Directory	(Optional) Local directory where status files can be temporarily written	/net/adc12345/dir123
	Database Connection String	The JDBC connect string for the database	jdbc:wolf:thin:@xyz2120830.us.example.com:1521/ntlywcdb
	Password	The password to log in to the database
	URL Prefix	The prefix to the content of the URL column to form display URL. For Oracle WebCenter sources, use the Oracle WebCenter instance URL.	http://abcdef05.us.example.com:10613/webcenter
authorizationPlugin	HTTP endpoint for authorization	The HTTP endpoint for Oracle Fusion authorization. For Oracle Fusion sources, the value is the URL for the search application deployment endpoint.	For Oracle Fusion sources: http://abcdef05.us.example.com:10615/crmSearch/searchfeedservlet/SecurityService?engineInstId=100010032752886 For Oracle UCM sources: http://abcdef05.us.example.com:10613/cs/idcplg
	Display URL prefix	(Optional) The HTTP host to prefix the access URL to form the display URL. For Oracle Fusion sources, the value is the URL for the search application deployment endpoint.	For Oracle Fusion sources: http://abcdef05.us.example.com:10615/crmSearch/searchfeedservlet/Redirect For Oracle UCM sources: http://abcdef05.us.example.com:10613/cs
	Authorization Endpoint	The URL servicing the lookup of authorization information. For WebCenter sources, the value is the WebCenter auth servlet endpoint.	http://abcdef05.us.example.com:10613/sesUserAuth
	Authorization Database Connection String	The JDBC connect string for the database	jdbc:wolf:thin:@xyz2120830.us.example.com:1521/ntlywcdb
	Password	The password to log in to the database.
docServiceInstance	WebCenter URL Prefix	The prefix to the content of the URL column to form the display URL. For WebCenter sources, use the WebCenter instance URL.	http://abcdef05.us.example.com:10613/webcenter

16.6.6.8 Editing Oracle Enterprise Scheduler Properties

Modify the move plan by editing the environment.properties specific entries within the movableComponent of type ESS-EXT according to the target environment.

Table 16-21 describes the required ESS properties. Edit the values of these properties in the move plan.

Note:

You do not need to change the value of the ID attribute in configProperty that corresponds to location of the environment.properties file.

Table 16-21 ESS Properties

Property	Description	Sample Value
APPL_TOP	The top level directory where the bin directory of C executables resides	/net/mount1/appbase/fusionapps
ZX_TOP	The top level directory of the product	/net/mount1/appbase/fusionapps/applications/fin/zx
VERTEX_TOP	The top level directory of the product	/net/mount1/appbase/fusionapps/applications/thirdparty/hcm/vertex
ESSBASEPATH	The top level directory of the product	/net/mount1/appbase/fusionapps/bi/clients/epm/Essbase/EssbaseRTC
PAY_TOP	The top level directory of the product	/net/mount1/appbase/fusionapps/applications/thirdparty/hcm/vertex
XLA_TOP	The top level directory of the product	/net/mount1/appbase/fusionapps/applications/fin/xla
AR_TOP	The top level directory of the product	/net/mount1/appbase/fusionapps/applications/fin/ar
GL_TOP	The top level directory of the product	/net/mount1/appbase/fusionapps/applications/fin/gl
ATGPF_TOP	The top level directory of the product	/net/mount1/appbase/fusionapps/atgpf
FA_TOP	The top level directory of the product	/net/mount1/appbase/fusionapps/applications/fin/fa
HRX_TOP	The top level directory of the product	/net/mount1/appbase/fusionapps/applications/hcm/hrx
LD_LIBRARY_PATH	Colon separated set of library directories	/net/prod/oracle/lib:/usr/openwin/lib:/usr/dt/lib
ORACLE_HOME	The top level directory where Oracle products are installed for the database client	/net/prod/oracle
PATH	The full path of the spawned job. In Windows environments, PATH must include all directories that are normally part of LD_LIBRARY_PATH.	/usr/local/bin:/bin:/usr/bin:/net/prod/oracle/bin
SEARCH_TOP	Oracle SES mid-tier installation home, which is one directory level below the Middleware home	/net/mount1/appbase/fusionapps/Oracle_SES1
TNS_ADMIN	The directory that stores files related to the database connection, such as tnsnames.ora and sqlnet.ora	/net/prod/oracle/network/admin
TWO_TASK	The TNS name identifying the database to which spawned jobs should connect. In Windows environments, the environment variable is LOCAL.	proddb
ORACLE_CSF_WALLET_LOC	The CSF wallet location in the Oracle Fusion Applications Middleware home	file:/net/mount1/appbase/fusionapps/wlserver_10.3/server/lib
ORACLE_JPS_CONFIG_LOC	The location of the jps-config.xml file in the product family domain directory. You must provide the value for only one product family domain, and it can be from any of the domains.	/net/mount1/appbase/instance/domains/abc05.us.example.com/FinancialDomain/config/fmwconfig/jps-config.xml

16.6.6.9 Editing Oracle Universal Content Management Properties

You must modify the move plan to specify the Oracle Universal Content Management (Oracle UCM) properties for the target environment before you apply the copied configurations from the source environment to the target environment.

Table 16-22 describes the Oracle UCM properties. Edit the values of each property.

Table 16-22 Oracle UCM Properties

Configuration Group	Property	Description	Sample Value
	MailServer	Name of the local mail server. The Oracle Content Server contacts this system to deliver email.	mail.example.com
	SysAdminAddress	The email address for the system administrator. This address is used in the From field of emails sent by the Oracle Content Server. The Oracle Content Server may also email generated reports to this address.	[e-mail]
	HttpServerAddress	Many generated HTML pages refer to the web server you are using. The address specified here is used when generating those pages. The address should include the host and domain name in most cases. If your web server is running on a port other than 80, append a colon and the port number. This defaults to the Oracle WebLogic Server host and port number if left blank.	www.example.com:80
	IdcCommandServerHost	The actual host where the Oracle UCM is running and where the Intradoc server ports are available for Oracle Content Server and Oracle Inbound Refinery (Oracle IBR).	server1.example.com
CS_Init		The properties in this configuration group apply to the Oracle Content Server deployment.
	IntradocServerPort	The server socket port number that applications like Remote Intradoc Client (RIDC) use to communicate with the Oracle Content Server.	4444
	SocketHostAddressSecurityFilter	A security filter for the Server Socket Port. Hosts that are allowed to communicate directly with the server port may access any resources managed by the server. Ensure that hosts that need access are included in the filter.	127.0.0.1|0.0.0.0.0.0.0.1
IBR_Init		The properties in this configuration group apply to the Inbound Refinery deployment.
	IntradocServerPort	The server socket port number that applications like RIDC use to communicate with the Inbound Refinery server.	5555
	SocketHostAddressSecurityFilter	A security filter for the Server Socket Port. Hosts that are allowed to communicate directly with the server port may access any resources managed by the server. Ensure that hosts that need access are included in the filter.	127.0.0.1|0.0.0.0.0.0.0.1
	fontdirectory	The path to the system font directory. Used by Outside-In filters when generating font images. Required to create thumbnails and direct conversions to PDF. In order for the path to resolve, you must use / for the directory separator even when specifying a Windows path.	/usr/X11R6/lib/X11/fonts/TTF

16.6.6.10 Editing Oracle Imaging and Process Management Properties

You must modify the move plan to specify the Oracle Imaging and Process Management (Oracle I/PM) properties for the target environment before you apply the copied configurations from the source environment to the target environment.

Table 16-23 describes the Oracle I/PM properties. Edit the values of each property.

Table 16-23 Oracle I/PM Properties

Configuration Group	Property	Description	Sample Value
	AdminUser	Administrative user ID used during the pasteConfig operation to seed system security. If left blank, the domain administrator user provided on the pasteConfig command line is used. This property should be used for situations where the Oracle I/PM administrative user must be a user other than the domain administrator. For example, during a pasteConfig operation, the Oracle I/PM database being used for the target has rows in the SYSTEM_SECURITY table. These rows grant system security privileges to the user FUSION_APPS_PROV_PATCH_APPID and no other users or groups. Therefore, for this case, you would set this value to FUSION_APPS_PROV_PATCH_APPID.	FUSION_APPS_PROV_PATCH_APPID
MBean Settings	InputAgentInputDirectories	A comma separate list of directories where input sources look for work	IPM/InputAgent/Input
	InputSampleDirectory	Directory that holds the sample data for the input UI	IPM/InputAgent/Input/Samples
	RenderGDFontPath	Location of the TrueType (TTF) font files used by the OIT rendering package	/usr/share/X11/fonts/TTF
UCM Connection	repository.machine	Location of the repository. The value must be localhost if the connection is configured for "Use Local Content Server."	localhost
	repository.port	Oracle UCM server port used when the local content server is used. If not using local content server connection, remove the configuration property.	4444
	repository.useSSL	Specifies (true or false) whether the connection to Oracle UCM systems use SSL.	false
WORKFLOW Connection	bpel.front.address	HTTP Front End Address used in the IPM SOA: Connection Settings UI	http://abc1234567:8001
	bpel.csf.key	Credential alias used in the IPM SOA: Connection Settings UI	basic.credentials

16.6.6.11 Editing Oracle Data Integrator Properties

You must modify the move plan to specify the Oracle Data Integrator properties for the target environment before you apply the copied configurations from the source environment to the target environment.

Table 16-24 describes the Oracle Data Integrator properties. Edit the values of each property.

Table 16-24 Oracle Data Integrator Properties

Configuration Group	Property	Description	Sample Value
Master Repository	Master Repository Id	ODI Master Repository ID. It should be different than source repository ID	502
	SUPERVISOR password file	Password for the SUPERVISOR user in ODI repository when target ODI repository was created.	/scratch/tank/src_bin/passwd_for_SUPERVISOR.txt
Physical Data Servers	Schema name	Directory location for the data source of "file" technology	/temp
	Work schema	Directory location for the data source of "file" technology	/temp
	Driver Class	Drive class for "Oracle" technology	oracle.jdbc.RedDriver
	Url	JDBC URL for connecting to the data server	jdbc:red:thin:@abc1230000:1521:lion
	User	User name for the physical data servers connection	fox_odi
	Password File	Password file for the physical data servers connection	/scratch/tank/src_bin/passwd_fox_odi.txt
Agents	Host name	Agent host name	localhost
	Host port	Agent host port	12311

16.6.6.12 Editing Additional Oracle Fusion Applications Environment Properties

This section describes the move plan properties for Oracle Fusion Applications, startup configuration, Oracle Human Workflow configuration, and Oracle Database client configuration.

Note:

The Oracle Database client configuration is reset to the initial out-of-box configuration set by provisioning. Any additional properties added to the source environment are not moved to the target environment. Therefore, you need to copy any additional properties to the target environment.

Table 16-25 describes the Oracle Fusion Applications properties.

Table 16-25 Oracle Fusion Applications Properties

Configuration Group	Property	Description	Sample Value
Fusion Applications Environment Properties	GOP Home	Oracle Global Order Promising home location present in the fusionapps_start_params.properties file	/scratch/aime/work/APPTOP/instance/gop_1
	OCM Instance Home	Oracle Enterprise Content Management instance home location present in the fusionapps_start_params.properties file	/scratch/aime/work/APPTOP/instance/ocm
	Heap Dump Path	Heap dump path location present in the fusionapps_start_params.properties file	/scratch/aime/work/APPTOP/instance/debug
	ESS Instance Home	Oracle Enterprise Scheduler instance home location present in the fusionapps_start_params.properties file	/scratch/aime/work/APPTOP/instance/ess
	DBClient Home	Oracle Database client home location present in the fusionapps_start_params.properties file	/scratch/aime/work/APPTOP/dbclient
wf_client_config	rootEndPointURL	OHS or load balancer URL value for the SOA cluster configured in wf_client_config.xml.	http://abc.example.com:10603
Database Client Configuration	Wallet Password File	Location of password file which contains password to create the database client wallet	/tmp/wallet_password.txt
	ORACLE_SERVICE_NAME	Database service name of the tnsnames.ora file to connect to database	adbc1234
	DB_HOST_NAME	Database host name of the tnsnames.ora file to connect to database. (In the case of Oracle Real Application Clusters (Oracle RAC) database the property names are DB_HOST_NAME0, DB_HOST_NAME1, and so forth.)	adc.example.com
	DB_PORT	Database port number of the tnsnames.ora file to connect to database (In the case of Oracle RAC databases, the property names are: DB_PORT0, DB_PORT1, and so forth)	1521
	Fusion Runtime Schema	Database schema name (user name) to login to database	fusion_runtime
	Fusion Runtime Schema Password File	Location of password file which contains schema password to login to the database	/tmp/fusion_runtime_password.txt
Fusion Applications Front end Host URL Configuration	FusionAppsFrontendHostUrl	The external OHS URL for all the Oracle Fusion applications human workflow task flows	https://agc.example.com:10608
	SupplierPortalFrontendHostUrl	The external OHS URL for all the Oracle Fusion applications human workflow task flows (ProcurementDomain)	https://acd.example.com:10610

16.6.7 Applying the Configurations to the Target Environment

Apply the copied configurations from the source environment to the target environment by running the pasteConfig script for each source entity (for example, Oracle WebLogic Server domain, OHS instance, or Node Manager) separately, using the same modified move plan. You must run the pasteConfig script on the target environment.

Run the pasteConfig script for the source entities in the following order:

1. CommonDomain

2. Oracle Fusion Applications domains, such as CRMDomain and FinancialDomain

3. All system component instances

4. All Node Managers

For Oracle WebLogic Server domains, run the pasteConfig script on the Administration Server host. For system components like OHS, run the script on the host where that component runs. For Node Manager, run the script on each host.

This section covers the following topics:

• Running pasteConfig for Oracle WebLogic Server Domains

• Running pasteConfig for System Components

• Running pasteConfig for Node Manager

• Running pasteConfig for Oracle BI Enterprise Edition

Note:

If you extracted multiple move plans, you must use the move plan corresponding to each domain or system component instance.

16.6.7.1 Running pasteConfig for Oracle WebLogic Server Domains

Running pasteConfig applies the copy of the source Oracle WebLogic Server Java EE component to the target environment by unpacking and recreating the domain configuration, MDS, and component-specific configuration into the specified Middleware home.

Note:

Make sure the Oracle WebLogic Server administrator user name is the same on both source and target environments. The password will be the same across the environments if the authenticator is on an embedded LDAP, but the password can be different if the authenticator is on an external LDAP. The hostname and listen port of any server can be different on the target environment, and you can modify those entries accordingly in the move plan.

You can only invoke pasteConfig once for each target entity (that is, Oracle WebLogic Server domain, OHS instance, or Node Manager). If you need to rerun pasteConfig on the same target entity, you must clean up the target environment before invoking pasteConfig again. For information about cleaning up target entities, see Section 24.1.9.

Use the following syntax to run pasteConfig for Oracle WebLogic Server domains:

pasteConfig  -javaHome path_of_jdk 
             -archiveLoc archive_location
             -targetDomainLoc trgt_domain_path
             -targetMWHomeLoc trgt_Middleware_Home_path
             -domainAdminPassword path_of_file_with_domain_admin_server_user_password
             -movePlanLoc move_plan_path
             -appDir WLS_application_directory]
             [-logDirLoc log_dir_path]
             [-silent {true | false}]

The following example shows how to apply the copy of the domain to the /fusionapps Middleware home:

pasteConfig -javaHome USER_HOME/jrockit_160_20_D1.0.1-1705/
            -archiveLoc /FIN_T2P/FIN_FinancialDomain1.jar
            -targetDomainLoc /net/mount2/instance/applications/FinancialDomain
            -targetMWHomeLoc /net/mount1/appbase/fusionapps
            -domainAdminPassword /home/oracle/password.txt
            -movePlanLoc /FIN_T2P/moveplan.xml
            -appDir /net/mount2/instance/applications/FinancialDomain
            -logDirLoc /FIN_T2P/logs
            -silent true

/net/mount1/appbase represents the top level applications base directory for binaries, while /net/mount2 represents the top level applications configuration directory for configuration files.

Table 16-26 describes the options for the pasteConfig script for Oracle WebLogic Server Java EE components.

Table 16-26 Options for the pasteConfig Script for Oracle WebLogic Server Java EE Components

Options	Shortcut	Description	Mandatory or Optional
-javaHome	None	The absolute path of the Java Developer's Kit.	Mandatory
-d64	None	If the operating system is 64-bit UNIX, pass the -d64 option to the scripts in the command line. To set the runtime property, you can specify the -d64 option in the T2P_JAVA_OPTIONS environment variable. For example: setenv T2P_JAVA_OPTIONS "-d64 -Djava.io.tmpdir=/home/t2p/temp"	Optional
-archiveLoc	-al	The absolute path of the archive location. Use this option to specify the location of the archive file created by the copyConfig script.	Mandatory
-targetDomainLoc	-tdl	The absolute path of the target domain. The domain location must not already exist for the specified Middleware home. The domain directory may be located outside of the directory structure of the Middleware home.	Mandatory
-targetMWHomeLoc	-tmw	The absolute path of the target Middleware home in which the copy of the domain will be applied.	Mandatory
-domainAdminPassword	-dap	The absolute path of the file containing the domain Administration Server user password.	Mandatory
-movePlanLoc	-tpl	The absolute path of the modified move plan in the target environment.	Mandatory
-appDir	-ad	The absolute path of the Oracle WebLogic Server application directory on the target.	Optional
-logDirLoc	-ldl	The location of an existing directory. A new log file is created in the directory.	Optional
-silent	None	Specifies whether the operation operates silently. That is, it does not prompt for confirmation. The default is that the operation prompts for confirmation. To specify that it not prompt for confirmation, specify this option with the value of true.	Optional

16.6.7.2 Running pasteConfig for System Components

Running pasteConfig applies the copy of a system component, such as OHS, to the target environment by pasting the configuration files of the source component into the specified Oracle instance.

Note:

You must use an Oracle home that contains the OHS binaries when you paste the OHS configuration files into the specified Oracle instance.

Use the following syntax to run pasteConfig for system components:

pasteConfig  -javaHome path_of_jdk 
             -archiveLoc archive_location
             -movePlanLoc move_plan_path
             -targetComponentName trgt_component_name 
             -targetInstanceHomeLoc trgt_Instance_path 
             [-targetInstanceName trgt_Instance_name] 
             [-targetOracleHomeLoc trgt_ORACLE_HOME_path]
             [-silent {true | false}]
             [-logDirLoc log_dir_path]
             [-domainHostName domain_host_name]
             [-domainPortNum  domain_port_number]
             [-domainAdminUserName domain_admin_username]
             [-domainAdminPassword domain_admin_password_file]

The following example shows how to apply the copy of the OHS instance to the Oracle instance CommonDomain_webtier and how to name the moved OHS instance ohs1:

pasteConfig -javaHome USER_HOME/jrockit_160_17_R28.0.0-679/
            -archiveLoc /FIN_T2P/FIN_CommonDomain_webtier4.jar
            -movePlanLoc /FIN_T2P/moveplan.xml
            -targetComponentName ohs1
            -targetInstanceHomeLoc /net/mount2/instance/CommonDomain_webtier
            -targetInstanceName CommonDomain_webtier
            -targetOracleHomeLoc /net/mount1/appbase/webtier_mwhome/webtier
            -silent true
            -logDirLoc /FIN_T2P/logs

/net/mount1/appbase represents the top level applications base directory for binaries, while /net/mount2 represents the top level applications configuration directory for configuration files.

Table 16-27 describes the options for the pasteConfig script for system components.

Table 16-27 Options for the pasteConfig Script for System Components

Options	Shortcut	Description	Mandatory or Optional
-javaHome	None	The absolute path of the Java Developer's Kit.	Mandatory
-d64	None	If the operating system is 64-bit UNIX, pass the -d64 option to the scripts in the command line. To set the runtime property, you can specify the -d64 option in the T2P_JAVA_OPTIONS environment variable. For example: setenv T2P_JAVA_OPTIONS "-d64 -Djava.io.tmpdir=/home/t2p/temp"	Optional
-archiveLoc	-al	The absolute path of the archive location. Use this option to specify the location of the archive file created by the copyConfig script.	Mandatory
-movePlanLoc	-tpl	The absolute path of the modified move plan in the target environment.	Mandatory
-targetComponentName	-tcn	The name of the target component to be moved. The name must be unique in the instance.	Mandatory
-targetInstanceName	-tin	The name of the target Oracle instance. The name must be unique in the domain.	Mandatory for OHS
-targetInstanceHomeLoc	-tih	The absolute path of the target Oracle instance. If the Oracle instance does not exist at that location, the command creates the instance.	Mandatory
-targetOracleHomeLoc	-toh	The absolute path of the target Oracle home. The target Oracle home must exist and it must contain the binaries for the component you are moving.	Optional, if the targetInstanceHomeLoc exists. In this case, the operation retrieves the value from the configuration.
-logDirLoc	-ldl	The location of an existing directory. A new log file is created in the directory.	Optional
-silent	None	Specifies whether the operation operates silently. That is, it does not prompt for confirmation. The default is that the operation prompts for confirmation. To specify that it not prompt for confirmation, specify this option with the value of true.	Optional
Domain-Detail Options		These parameters are optional. If you choose to use the domain parameters, you must use all four parameters.
-domainHostName	-dhn	The name of the host on which the domain is configured. Use this option if you want to register the component with the domain.	Optional, if you do not want to register the component with the domain.
-domainPortNum	-dpn	The port number of the domain. Use this option if you want to register the component with the domain. The domain port number is listed in the following file as the adminPort. ORACLE_INSTANCE/config/OPMN/opmn/instance.properties For example: adminPort=7001	Optional, if you do not want to register the component with the domain.
-domainAdminUserName	-dau	The name of the administrative user for the domain. For example, faadmin.	Optional, if you do not want to register the component with the domain.
-domainAdminPassword	-dap	The password file for the administrative user for the domain. For example, /FIN_T2P/domain_admin_server_pw.txt. Use this option if you want to register the component with the domain.	Optional, if you do not want to register the component with the domain.

16.6.7.3 Running pasteConfig for Node Manager

Running pasteConfig applies the copy of Node Manager to the target environment by pasting the configuration files of the source Node Manager into the specified Node Manager home.

Note:

All the domains that are to be managed by the Node Manager should be moved before applying the copy of Node Manager to the target environment, and the Administration Server must be in running state.

After running pasteBinary, if the Node Manager directory exists in WL_HOME/common/nodemanager then remove it before running pasteConfig.

Even if the source Node Manager connection between the Administration Server and the Node Manager is configured with SSL, they will both change to plain socket connection type after the copy of Node Manager is applied to the target environment. For more information, see Section 16.8.3.

Use the following syntax to run pasteConfig for Node Manager on each machine within the topology in the target environment:

pasteConfig  -javaHome path_of_jdk 
             -archiveLoc archive_location
             -targetNMHomeLoc trgt_Node_Manager_Home_path 
             -targetMWHomeLoc trgt_Middleware_Home_path 
             -movePlanLoc move_plan_path
             [-logDirLoc log_dir_path]
             [-silent {true | false}]

The following example shows how to apply the copy of Node Manager to the Node Manager home located in CommonDomain_webtier:

pasteConfig -javaHome USER_HOME/jrockit_160_17_R28.0.0-679/
            -archiveLoc /tmp/a.jar
            -targetNMHomeLoc /net/mount1/appbase/fusionapps/wlserver_10.3/common/nodemanager/xyz456.us.example.com
            -targetMWHomeLoc net/mount1/appbase/fusionapps/
            -movePlanLoc /FIN_T2P/moveplan.xml
            -silent true

Table 16-28 describes the options for the pasteConfig script for Node Manager.

Table 16-28 Options for the pasteConfig Script for Node Manager

Options	Shortcut	Description	Mandatory or Optional
-javaHome	None	The absolute path of the Java Developer's Kit.	Mandatory
-d64	None	If the operating system is 64-bit UNIX, pass the -d64 option to the scripts in the command line. To set the runtime property, you can specify the -d64 option in the T2P_JAVA_OPTIONS environment variable. For example: setenv T2P_JAVA_OPTIONS "-d64 -Djava.io.tmpdir=/home/t2p/temp"	Optional
-archiveLoc	-al	The absolute path of the archive location. Use this option to specify the location of the archive file created by the copyConfig script.	Mandatory
-targetNMHomeLoc	-tnh	The absolute path of the target Node Manager.	Mandatory
-targetMWHomeLoc	-tmw	The absolute path of the target Middleware home in which the copy of Node Manager will be applied.	Mandatory
-movePlanLoc	-tpl	The absolute path of the modified move plan in the target environment.	Mandatory
-logDirLoc	-ldl	The location of an existing directory. A new log file is created in the directory.	Optional
-silent	None	Specifies whether the operation operates silently. That is, it does not prompt for confirmation. The default is that the operation prompts for confirmation. To specify that it not prompt for confirmation, specify this option with the value of true.	Optional

16.6.7.4 Running pasteConfig for Oracle BI Enterprise Edition

You past the configuration of the following Oracle BI Enterprise Edition components:

• Oracle BI Server

• Oracle BI Presentation Services

• Oracle BI Cluster Controller

• Oracle BI Scheduler

• JavaHost

• Oracle Essbase server, if it is installed in your environment

Running pasteConfig applies the copy of Oracle BI Enterprise Edition to the target environment by pasting the configuration files of the source Oracle BI Enterprise Edition into the specified Oracle BI Enterprise Edition home.

Use the following syntax to run pasteConfig for Oracle BI Enterprise Edition on each machine within the topology in the target environment:

pasteConfig  -javaHome path_of_jdk 
             -archiveLoc archive_location
             -targetInstanceHomeLoc trgt_Node_Manager_Home_path 
             -targetInstanceName trgt_Instance_name 
             -targetOracleHomeLoc trgt_Middleware_Home_path 
             -domainHostName domain_host_name
             -domainPortNum domain_port_number
             -domainAdminUserName domain_admin_user_name
             -domainAdminPassword domain_admin_password_file
             [-silent {true | false}]
             [-logDirLoc log_dir_path]

The following example shows how to apply the copy of Oracle BI Enterprise Edition to the Oracle BI Enterprise Edition home located in BIDomain:

pasteConfig -javaHome USER_HOME/jrockit_160_17_R28.0.0-679/ 
            -archiveLoc /FIN_T2P/BIInstance.jar 
            -targetInstanceHomeLoc /net/mount1/appbase/instance/BIInstance
            -targetInstanceName BIInstance 
            -targetOracleHomeLoc /net/mount1/appbase/fusionapps/bi 
            -domainHostName localhost -domainPortNum 10201 
            -domainAdminUserName faadmin 
            -domainAdminPassword /tmp/welcome1.txt -silent true

Table 16-29 describes the options for the pasteConfig script for Oracle BI Enterprise Edition.

Table 16-29 Options for the pasteConfig Script for Oracle BI Enterprise Edition

Options	Shortcut	Description	Mandatory or Optional
-javaHome	None	The absolute path of the Java Developer's Kit.	Mandatory
-archiveLoc	-al	The absolute path of the archive location. Use this option to specify the location of the archive file created by the copyConfig script.	Mandatory
-targetInstanceHomeLoc	-tih	The absolute path of the target Oracle instance. If the Oracle instance does not exist at that location, the command creates the instance	Mandatory
-targetInstanceName	-tin	The name of the target Oracle instance. The name must be unique in the domain.	Mandatory for OHS
-targetOracleHomeLoc	-toh	The absolute path of the target Oracle home. The target Oracle home must exist and it must contain the binaries for the component you are moving.	Mandatory
-domainPortNum	-dpn	The port number of the source domain.	Mandatory
-domainAdminUserName	-dau	The name of the administrative user for the source domain.	Mandatory
-domainAdminPassword	-dap	The password file location for the administrative user for the domain.	Mandatory
-logDirLoc	-ldl	The location of an existing directory. A new log file is created in the directory.	Optional
-silent	None	Specifies whether the operation operates silently. That is, it does not prompt for confirmation. The default is that the operation prompts for confirmation. To specify that it not prompt for confirmation, specify this option with the value of true.	Optional

16.6.8 Completing the Component-Specific Configuration Move

Moving the Oracle WebLogic Server domains from a source environment to a target environment also moves some Oracle Fusion Middleware components, but additional tasks are required for completing the move.

• Oracle Database Client. Section 16.6.8.1

• Oracle WebCenter. Section 16.6.8.2

• Oracle BI EE. See Section 16.6.8.3.

• Oracle Enterprise Scheduler Service. See Section 16.6.8.4.

• Oracle SES. See Section 16.6.8.5.

• Oracle Global Order Promising. See Section 16.6.8.6.

• Governance Risk and Controls. See Section 16.6.8.7.

16.6.8.1 Oracle Database Client

Update the following files in the domains to fix the Oracle Database client install location on the target environment:

(UNIX)    DOMAIN_HOME/init-info/startscript.xml
          DOMAIN_HOME/bin/setDomainEnv.sh
          DOMAIN_HOME/init-info/startscript-unsub.xml

(Windows) DOMAIN_HOME\init-info\startscript.xml
          DOMAIN_HOME\bin\setDomainEnv.sh
          DOMAIN_HOME\init-info\startscript-unsub.xml

16.6.8.2 Moving Oracle WebCenter

In this scenario, you have installed Oracle WebCenter in a source environment as described in the section "Moving Oracle WebCenter to a Production Environment," of the Oracle Fusion Middleware Administrator's Guide, and you want to move it to a target environment, which does not yet exist. To move Oracle WebCenter to a new target environment, perform the following tasks:

To move Oracle WebCenter, follow the procedures in the following tasks:

• Task 1, "Export Oracle WebCenter from the Source Environment"

• Task 2, "Import Oracle WebCenter to the Target Environment"

• Task 3, "Copy Oracle Universal Content Management Configuration to the Target Environment for Seeded Space Templates"

Task 1   Export Oracle WebCenter from the Source Environment

To export Oracle WebCenter and data required for the applications from the source environment:

1. Export the Oracle WebCenter Portal application data from the source database, using the following commands from the ORACLE_home/bin (UNIX) and the ORACLE_HOME\bin (Windows) directories, where ORACLE_HOME is the Oracle home for the Oracle Database):

   sqlplus "sys/password as sysdba"
   create or replace directory directory as 'path';
   exit;
   

   expdp "sys/password@connect_id as sysdba"
   schemas=prefix_WEBCENTER directory=directory dumpfile=filename
   

2. Export the Discussion Forum using the Oracle Database export utility from the ORACLE_home/bin (UNIX) and the ORACLE_HOME\bin (Windows) directories, where ORACLE_HOME is the Oracle home for the Oracle Database):

   sqlplus "sys/password@connect_id as sysdba"
   create or replace directory directory as 'path';
   exit;
   

   expdp "sys/password@connect_id as sysdba"
   schemas=prefix_DISCUSSIONS directory=directory dumpfile=file_name
   

Task 2   Import Oracle WebCenter to the Target Environment

To import the Oracle WebCenter data to the target environment:

1. Import the Oracle WebCenter Portal data to the target database, using the file you exported in Task 1. Execute the following commands, where ORACLE_HOME is the Oracle home for the Oracle Database):

   ORACLE_HOME/bin/sqlplus "sys/password as sysdba"
   create or replace directory directory as 'path';
   exit;
   

   ORACLE_HOME/bin/impdb "sys/password@connect_id as sysdba"
   DIRECTORY=directory dumpfile=filename
   TABLE_EXISTS_ACTION=REPLACE
   

2. Import the Discussion Forum, where ORACLE_HOME is the Oracle home for the Oracle Database):

   ORACLE_HOME/bin/sqlplus "sys/password as sysdba"
   create or replace directory directory as 'path';
   exit;
   

   ORACLE_HOME/bin/impdb "sys/password@connect_id as sysdba"
   DIRECTORY=directory dumpfile=filename
   TABLE_EXISTS_ACTION=REPLACE
   

Task 3   Copy Oracle Universal Content Management Configuration to the Target Environment for Seeded Space Templates

To copy Oracle Universal Content Management configuration from the source to the target for seeded Space Templates:

1. Clean-up existing security groups and roles:

   1. Log into the target Oracle Universal Content Management as an administrative user.

   2. Choose Administration > Admin Applets > User Admin.

   3. Choose Security > Permission by role.

   4. Select the role, and then click Delete Role.

   5. Delete the following roles:

      - appNameUser (and appNameAuthenUser if it exists), for example: UCM_Spaces_adcges03_us_oracle_User and UCM_Spaces_adcges03_us_oracle_AuthenUser

      - PersonalSpacesRole (and PersonalSpacesAuthenRole if it exists)

   6. Choose Security > Permission by role.

   7. Select the group, and then click Delete Group.

   8. Delete the following groups:

      - appName, for example, UCM_Spaces_adcges03_us_oracle_

      - PersonalSpaces

   9. Restart Managed Server WC_Spaces.

2. Get a value for the IdcToken token:

   1. Log into the target Oracle Universal Content Management as an administrative user.

   2. Ensure the user has the Layout set to Top Menus in thier profile. To check, click the user name on the top right after logging in to go to the user's profile.

   3. Navigate to Browse Content > webcenter_hostname > spacetemplate.

   4. Add IsSoap=1 to the end of the URL produced from navigation done in the previous step.

   5. Search for idcToken and take note of its value. For example:

      <idc:field name="idcToken">1316956945552:743550D8570AA40D33A2A1A3968481FC</idc:field>
      

3. Provision the Space Templates in Oracle Universal Content Management:

   For each template which requires provisioning and folder creation in Oracle Universal Content Management, a service call URL needs to be build to create the folders. For Oracle Fusion Applications, this step needs to be repeated for two Space Templates:

   URL for Space Template Oracle_Fusion_Sales_GS_Template:

   IdcService=COLLECTION_ADD&xForceFolderSecurity=TRUE&&hasParentCollectionPath=true&dParentCollectionPath=<parentFolderPath>&idcToken=<idcToken>&dCollectionName=Oracle_Fusion_Sales_GS_Template&hasCollectionGUID=true&dCollectionGUID=d83c0211-ed25-4f4b-9fe8-8f82549e6dca&dDocAccount=sd83c0211ed254f4b9fe8-8f82549e6dca
   

   URL for Space Template Project_Space_Template_for_Oracle_Fusion_Projects:

   IdcService=COLLECTION_ADD&xForceFolderSecurity=TRUE&&hasParentCollectionPath=true&dParentCollectionPath=<parentFolderPath>&idcToken=<idcToken>&dCollectionName=Project_Space_Template_for_Oracle_Fusion_Projects&hasCollectionGUID=true&dCollectionGUID=fb668b78-acd1-47ce-b83b-2ec77dcd525a&dDocAccount=sfb668b78acd147ceb83b2ec77dcd525a
   

   In the above URLs, replace the values in <> with the values for your environment, where:

   • <parentFolderPath> is the path to the folder containing the template folders, for eample:

     /webcenter_<hostname>/spacetemplate
     

   • <idcToken> is thev alue obtained from sub-step 1a of this task, for example:

     1316957740739:4E131D3DBCB73F8C283B9BD9D942BFEF
     

   For both URLs, perform the following steps:

   1. In the browser, logged into Oracle Universal Content Management from step 1a of this task, remove all the contents of the URL starting with IdcService and including IdcService.

   2. Append the URLs built up for the templates and hit return.

      The folder for the template is created.

4. Verify that the templates have been created. Navigate to Browse Content > webcenter_hostname > spacetemplate.

   All the templates created should now be listed.

16.6.8.3 Moving Oracle BI Enterprise Edition Components

To complete the movement of Oracle BI EE, perform the following tasks:

To move Oracle BI EE, follow the procedures in the following tasks:

• Task 1, "Update the App ID passwords"

• Task 2, "Refresh Global Unique Identifiers (GUIDs)"

• Task 3, "Enable New Agents"

Task 1   Update the App ID passwords

If the passwords for following App IDs are not properly provided in move plan, you must the update target environment with the new passwords:

• FUSION_APPS_PROV_PATCH_APPID

• FUSION_APPS_PRC_BI_APPID

• FUSION_APPS_BI_APPID

To update the App ID passwords:

1. Obtain the APP ID passwords through the credential store. Execute the following Execute following listCred commands to retrieve passwords for FUSION_APPS_PROV_PATCH_APPID, FUSION_APPS_PRC_BI_APPID, and FUSION_APPS_BI_APPID .

   1. From the fusionapps Middleware subdirectory, start the WebLogic Scripting Tool (WLST):

      (UNIX) FA_MW_HOME/oracle_common/common/bin/wlst.sh
      (Windows) FA_MW_HOME\oracle_common\common/bin\wlst.cmd
      

   2. Connect to Oracle WebLogic Server.

   3. Use the following WLST commands from the fusionapps Middleware directory:

      listCred(map="oracle.patching", key="FUSION_APPS_PATCH_WLS_ADMIN-KEY") 
      listCred(map="oracle.apps.security", key="FUSION_APPS_PRC_BI_APPID-KEY") 
      listCred(map="oracle.apps.security", key="FUSION_APPS_BI_APPID-KEY") 
      

2. Change JDBC Data for the source configuration for FUSION_APPS_PROV_PATCH_APPID and FUSION_APPS_PRC_BI_APPID .

   In Oracle Fusion Applications, there are two data sources which are configured using APP IDs:

   • BIDomain: BIAnalytics data-source

     User: FUSION_APPS_PROV_PATCH_APPID

   • ProcurementDomain: BIAnalyticsServer data-source

     User: FUSION_APPS_PRC_BI_APPID

   To change JDBC data for the source configuration through the Oracle WebLogic Server Administration Console for the BIDomain and ProcurementDomain domains:

   1. Locate the Change Center in the upper left of the Administration Console screen

   2. Click Lock & Edit to lock the configuration edit hierarchy for the domain.

   3. From the Domain Structure pane, choose Services > Data Sources.

      The Summary of JDBC Data Sources page displays.

   4. In the Data Sources table, click the BIAnalytics data source for the BIDomain domain or BIAnalysticsServer data source for the ProcurementDoamin domain.

   5. Click the Connection Pool sub-tab.

   6. Locate the Password and Confirm Password fields, and modify the passwords.

   7. Click Save.

   8. Restart all the data source's target Managed Servers.

3. Change repository publishing directory connection pools through Oracle BI Administration Tool.

   1. Choose Start > Programs > Oracle Business Intelligence > BI Administration.

   2. In the Administration Tool, choose File > Open > Offline.

   3. Navigate to the repository you want to open, and then select Open.

   4. In the Open Offline dialog box, type a valid user ID and password, and then click OK.

      This opens the repository in offline mode. This mode enables you to view and modify a repository while it is not loaded into the Oracle BI Server. If you attempt to open a repository in offline mode while it is loaded into the Oracle BI Server, the repository opens in read-only mode. Only one Administration Tool session at a time can edit a repository in offline mode.

   5. In Physical layer, select an Oracle Fusion application, for example, oracle.apps.crm*, oracle.apps.fscrm*, oracle.apps.hcm*.

   6. Click the connection pool icon in the toolbar.

      
      Description of the illustration t2p_biadmin.gif
      
      

   7. In the Connection Pool dialog, update the new password in the Connection Pool dialog, and then click OK.

   8. Perform sub-steps e through g for other Oracle Fusion applications.

   For more information about the Oracle BI administration Tool, see the section "Before You Begin" in the Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition).

4. Upload the newly update repository publishing directory to the BIDomain domain. See the section "Configuring Repositories" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

Task 2   Refresh Global Unique Identifiers (GUIDs)

LDAP directories that contain the GUIDs should be fan-out replicas in both the source and the target environments.

Oracle BI EE source servers are configured against a source LDAP and the target servers against the corporate LDAP, but the source LDAP is not a fan-out copy of the corporate LDAP directory. A refresh of the LDAP GUIDs is needed.

After changing the directory server that is used as the data source for the authentication provider, it is best practice to update the user GUIDs. If the same user name exists in both directory servers (original and new), then the original user GUID might conflict with the user GUID that is contained in new directory server. A refresh forces the system to reference the user GUID that is contained in the new directory server. Authentication errors might result if the GUIDs are not refreshed and the system detects a mismatch for the user GUID.

The GUIDs that are stored in the Oracle BI Presentation Catalog or in the Oracle BI repository file can be resynchronized and refreshed as described in the following procedure. Before you begin this procedure, ensure that you are familiar with the information in "Manually Updating Oracle Business Intelligence Configuration Settings Not Normally Managed by Fusion Middleware Control" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

This procedure requires that you manually edit the configuration files to instruct Oracle BI Server and Oracle BI Presentation Services to refresh the GUIDs on restart. Once completed, you edit these files to remove the modification. For information about where to locate Oracle Business Intelligence configuration files, see the section that describes where configuration files are located, in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

Note:

Refreshing the GUIDs requires that you stop and restart the system components from the command line and not Fusion Middleware Control. This includes the Administration Server and Managed Servers. After the Administration Server is stopped, you cannot start it from Fusion Middleware Control because it is not available during this time.

To refresh the user GUIDs:

1. Open the NQSConfig.INI file for editing. For information, see "Where are Configuration Files Located?" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

2. Locate the setting FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = NO and change its value to YES.

3. Modify the instanceconfig.xml file to instruct Presentation Services to refresh GUIDs on restart. Edit the file to add the last line in the following instruction.

   <ps:Catalog xmlns:ps="oracle.bi.presentation.services/config/v1.1">
   <ps:UpgradeAndExit>false</ps:UpgradeAndExit>
   <ps:UpdateAccountGUIDs>UpdateAndExit</ps:UpdateAccountGUIDs>
   

4. From a terminal window, stop and restart the managed processes using the opmnctl parameters stopall and startall. You can use the parameter status to verify process status throughout.

   The following components are involved: Presentation Services, Oracle BI Server, Oracle BI Scheduler, Oracle BI Cluster Controller, and Oracle BI JavaHost.

   For information about using opmnctl commands, see "Using the OPMN command line to Start and Stop Oracle Business Intelligence System Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

5. Edit the NQSConfig.INI file to reset the FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = YES to NO and restart the Oracle BI Servers.

6. Remove, set to none, or comment out the last line added to the instanceconfig.xml file (that instructs Presentation Services to refresh GUIDs on restart, as specified in Step 3).

   <ps:Catalog xmlns:ps="oracle.bi.presentation.services/config/v1.1">
   <ps:UpgradeAndExit>false</ps:UpgradeAndExit>
   <ps:UpdateAccountGUIDs>none</ps:UpdateAccountGUIDs>
   

7. Restart Presentation Services for the instanceconfig.xml file that was updated.

8. Ensure that Oracle WebLogic Server and the system components are also running. If they are not running, then restart them.

   For information, see "Starting and Stopping the Oracle Business Intelligence Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

Task 3   Enable New Agents

If required, enable new agents. If new agents were created in the source environment, click each agent in the Oracle BI Presentation Services Catalog Manager (in the target environment) to enable it. For more information about enabling new agents, see the "Working with the Properties of Catalog Objects" section of the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

16.6.8.4 Moving Oracle Enterprise Scheduler Service

To complete the movement of Oracle Enterprise Scheduler Service (ESS) from a source environment to a target environment, you must move the custom PL/SQL procedures if you created them in the source environment.

Re-create the custom PLSQL procedures in the FUSION schema by using the PL/SQL job logic text file that you created in the source environment.

16.6.8.5 Moving Oracle SES

Source types of portal, email, and mailing list are not moved from the source Oracle SES instance to the target Oracle SES instance. If you purchased an additional Oracle SES license and want to enable search non-Fusion sources, you must create these data sources in the target Oracle SES instance manually using the Oracle SES Administration GUI in the target Oracle SES instance. For information, see the Oracle Secure Enterprise Search Administrator's Guide.

16.6.8.6 Moving the Oracle Global Order Promising Server Instance

The binary scripts move the Oracle home for Oracle Global Order Promising, used by Oracle Fusion Supply Chain Management, but they do not move the server instance from the source to the target environment. You must manually move the server instance.

Moving the server instance is based on the following assumptions:

• The Oracle home in fusionapps Middleware directory (FA_MW_HOME/gop) for Oracle Global Order Promising is properly moved from the source to the target environment.

• The SCMDomain domain is properly moved from the source to the target environment.

To move the server instance, follow the procedures in the following tasks:

• Task 1, "Stop the Servers in the Source Environment"

• Task 2, "Move the Oracle Global Order Promising Server Instance"

• Task 3, "Update the Oracle Global Order Promising Server Instance Settings"

• Task 4, "Start the Server Instance"

• Task 5, "Reregister Oracle Global Order Promising Instance"

Task 1   Stop the Servers in the Source Environment

Before you move the Oracle Global Order Promising server instance from the source to target environment, you must stop the following servers in the source environment:

• Managed Servers

• Administration Server

• Oracle Process Manager and Notification Server

You can stop the Managed Servers and the Administration Server with Oracle WebLogic Server Administration Console or with command line scripts:

stopManagedWebLogic.sh
stopWebLogic.sh

You can stop Oracle Process Manager and Notification Server (OPMN) with:

APPLICATIONS_CONFIG/instance/gop_1/bin/opmnctl stopall

For more information, see the "Starting and Stopping Oracle Fusion Middleware" chapter in the Oracle Fusion Middleware Administrator's Guide.

Task 2   Move the Oracle Global Order Promising Server Instance

Move the Oracle Global Order Promising server instance directory (APPLICATIONS_CONFIG/instance/gop_1) from the source to the corresponding location in the target environment.

Task 3   Update the Oracle Global Order Promising Server Instance Settings

Update the settings in the Oracle Global Order Promising server instance in the target environment by editing the following files:

• gop_1/bin/opmnctl

  • Update the Perl directive (first script line) with the correct Middleware home path. Make sure the Perl path does not exceed 128 characters.

  • Update the $OracleInstance and $OracleHome lines with the correct Middleware home path for the target environment.

• gop_1/config/OPMN/opmn/opmn.xml

  • Update the Oracle Global Order Promising server instance directory in the wallet-file path for the /opmn/notification-server/ssl element with the correct path in the target environment.

  • If necessary, update the local and remote OPMN ports for the /opmn/notification-server/port element.

• gop_1/config/OPMN/opmn/instance.properties

  Update adminPort, oracleHome, adminHost, and adminUsername.

• gop_1/config/OPMN/opmn/ports.prop

  • If necessary, update /opmn/remote_port and /opmn/local_port to reflect the values specified in opmn.xml.

  • Update the /GlobalOrderPromisingServer1/ListenPort to the Oracle Global Order Promising server port to be used on the target environment.

• gop_1/config/GOP/GlobalOrderPromisingServer1/gopServerConfig.xml

  Update the propertyList/port field with the Oracle Global Order Promising server port to be used on the target environment.

Task 4   Start the Server Instance

Start the OPMN server in the target environment by running the following command:

APPLICATIONS_CONFIG/instance/gop_1/bin/opmnctl startall

Task 5   Reregister Oracle Global Order Promising Instance

To reregister the Oracle Global Order Promising instance:

1. Make sure Administration Server for the SCMDomain domain is running.

   To start the Administration Server, see section "Start the Administration Servers" in Section 3.3.2.1.

2. Reregister the Oracle Global Order Promising instance with OPMN by running the following command:

   APPLICATIONS_CONFIG/instance/gop_1/bin/opmnctl registerinstance
   

16.6.8.7 Moving the Governance Risk and Controls Client Configuration

If you have custom provisioned Oracle Governance, Risk and Compliance Controls, use an Oracle Fusion Functional Setup Manager task in the target environment to move the Oracle Governance, Risk and Compliance Controls client configuration to the target Oracle Identity Manager server.

To move the GRC configuration:

1. Sign into Oracle Fusion Applications using a user account provisioned with an enterprise role that inherits the GRC Setup Management Duty role. For example, in the security reference implementation, the IT Security Manager and Application Implementation Consultant job roles inherit this duty role. Contact your security administrator to ensure your user account is provisioned appropriately.

2. In Oracle Fusion Functional Setup Manager, navigate to the Manage Application Access Controls task and select a GRC setup configuration.

   The Manage Application Access Controls task is included in the Define Governance, Risk and Performance Controls task list, which is visible under the Common Applications... task list only if the offering was configured to include the Governance, Risk and Compliance feature prior to the creation of the implementation project. You can also manually add the task to the implementation project.

3. Select the desired configuration detail (the one appropriate for the target environment). If none is appropriate, create a new configuration detail for the target environment. For information, see the Oracle Fusion Applications Information Technology Management, Implement Applications Guide.

4. Perform the Publish to OIM Server action using the configuration detail. This requires the connection information for the Oracle WebLogic Server instance that is hosting the Oracle Identity Manager server.

16.6.9 Applying Domain Configurations to Other Machines

The domain directory is local to each machine, and pasteConfig is performed only on the Administration Server. Subsequently, if the domain has multiple machines, you must re-create the local domain by using the Oracle WebLogic Server pack and unpack commands. For more information, see Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands.

Note:

If the Administration Server is using the shared storage, and the other Managed Servers on the Administration Server machine are using the local storage, then you must run the pack and unpack commands once even on the Admin Server machine to create the domain directory on the local storage.

16.7 Moving Functional Setup Data

Functional Setup Manager provides a single user interface for performing all tasks related to Oracle Fusion Applications setup after installation and helps a company's Application Implementation Consultant (or a user with this role) to easily move the setup data between instances to reduce implementation time.

Note:

An Application Implementation Manager (or a user with this role) can create configuration packages, but cannot submit the export or import processes, or upload or download them.

Rather than entering configuration data from scratch, customers can reuse and customize configuration packages and their associated setup data, which then can be exported from the source instance and imported into the target instance for any Oracle application delivered in Oracle Fusion Applications. For more information, see the "Importing and Exporting Setup Data" section in the Oracle Fusion Applications Information Technology Management, Implement Applications Guide.

Generic export and import comprises the following tasks:

• Task 1, "Create the Configuration Package"

• Task 2, "Export the Setup Data for a Configuration Package"

• Task 3, "Download the Configuration Package"

• Task 4, "Upload the Configuration Package"

• Task 5, "Import Data from a Configuration Package"

Task 1   Create the Configuration Package

Create the configuration package in the source environment by selecting an existing implementation project containing the setup data to be exported. The configuration package can contain only the setup task list, or it can contain both the setup task list and the setup data.

This process creates a configuration package and optionally selects only specific business objects or scope values to be exported. This process can be scheduled or run immediately.

To create a configuration package:

1. Sign in to Oracle Fusion Applications with a user account that is provisioned with the necessary role, such as the predefined Application Implementation Consultant role. Contact your security administrator for details.

2. In the Tasks pane, under the Setup Data Export and Import group, click Manage Configuration Packages.

3. From the Action menu, select Create.

4. From the Name list, select the source implementation project, then select Setup task list and setup data for the export option and click Next.

5. In Select Object for Export, select the setup task or list to include.

6. Click Submit to submit the configuration package to start the Export Setup Data process and proceed to Step 3 of Task 2.

   Each time a configuration package is submitted, a row is created for the process and the status is displayed. The Status links to a detailed display of the process results, including all the objects processed and their errors. The Setup Data Report icon links to a report containing details of the setup data exported to the configuration package.

   Alternatively, you can click Save and Close to save the configuration package definition and resume at a later time with Task 2.

Task 2   Export the Setup Data for a Configuration Package

You can run Export Setup Data process immediately or schedule it to run on a specific date and time.

You can also export the setup data for a configuration package several times. Each time you export the setup data, you create a different version that can be used for multiple purposes, such as backing up the implementation at specific times.

To export a configuration package:

1. In the Tasks pane, under the Setup Data Export and Import group, click Manage Configuration Packages.

2. Select the package you want to export and click Export Setup Data.

3. Click Next. Schedule the export process to run immediately, or schedule it to run at a specific time.

4. Monitor the status of the process until it completes.

Task 3   Download the Configuration Package

In order to import the setup data into a different instance from where the setup data was exported, you must first download the configuration package after a successful export. This configuration package is uploaded and imported into the instance where the import will be performed.

To download the package:

1. In the Tasks pane, under the Setup Data Export and Import group, click Manage Configuration Packages.

2. Scroll down to the Export and Import Processes table.

3. Select the desired target export row and click the icon in the Download column.

4. Select Download Configuration Package.

   This action downloads the structure and setup data associated with the configuration package, depending on the selections made when the configuration package was selected. This is the file that can be imported to another instance to replicate the setup data.

Task 4   Upload the Configuration Package

In order to move the setup data for an implementation to a target instance, you must first upload the configuration package to that target instance.

To upload the configuration package:

1. In the Tasks pane, under the Setup Data Export and Import group, click Manage Configuration Packages.

2. Click the Upload button, then select the package you want to upload.

3. Click the Get Details button and review the details.

4. Click Submit to upload the file.

   During the upload process, an implementation project is created. You can use this implementation project to understand the list of tasks used as the source of the configuration package.

   Once the configuration package is uploaded, you can review its details and reports before importing it. You can access these by clicking Download or View Setup Data Report in the Processes Detail table, or by selecting these options from the Actions dropdown list.

Task 5   Import Data from a Configuration Package

To import the configuration package:

1. In the Master Configuration Packages list of the search results, select the configuration package you want to import.

2. In the project details list, select the version that you want to import. In most cases, it is the one that you just uploaded.

   Note:

   There may be multiple versions of a configuration package. Select the version with the type Upload.

3. Click Import Setup Data.

   Identification information about the uploaded configuration package displays. You can verify the information and select how to process it.

4. Click Next to schedule the import process, or Submit to submit it to the queue immediately.

   Note:

   Clicking Next also gives you the option to submit the process to the queue immediately.

Once the import process is submitted, you can monitor its progress from the Manage Configuration Packages or Manage Export and Import Processes pages.

If the import-process status is "User Action Required," review the details, take the appropriate actions, and then resume the process.

Once the process completes, process results contains detailed information on the list of objects for which setup data was imported and any errors that may have occurred.

16.8 Completing Postmovement Tasks

After you move the Oracle Fusion Applications components across environments, you must complete the following tasks:

• Reconcile GUIDs security policies. See Section 16.8.1.

• Apply any necessary topology changes, such as scaling up or scaling out the topology. For information, see Section 15.5.

• Complete the Oracle RAC configuration in the target environment. See Section 16.8.2.

• Set up security. See Section 16.8.3.

• Start the Managed Servers as needed.

• Start a full index on all index schedules. For information, see Section 7.4.2.7.

16.8.1 Reconciling GUIDs

Since GUIDs are not preserved during movement to a target environment, you must reconcile the GUIDs in the security policies. See Section 4.4.3.

16.8.2 Completing the Oracle RAC Configuration in the Target Environment

After completing the movement process, you must complete the Oracle RAC configuration in the target environment for any of the following scenarios that apply:

• For non-RAC to RAC movement: After moving Oracle Fusion Applications components from a source environment with no Oracle RAC to a target environment configured with Oracle RAC, you must configure the target environment with Oracle RAC. For information, see Section 15.4.2.

• For RAC n instances to non-RAC movement: After completing the movement process, remove the Oracle RAC configuration from the target environment.

• For RAC m instances to RAC n instances movement, where the number of RAC instances in the source environment is less than or equal to the number of RAC instances in the target environment (m <= n): After completing the movement process, add any additional n-m generic data sources to the target environment. For information, see Section 15.5.3.2.

  For example, if the source environment contains three Oracle RAC instances, and the target environment contains four Oracle RAC instances, then you will have three generic data sources that are named mds-soa-rac1, mds-soa-rac2, and mds-soa-rac3. You must add one additional generic data source to the target environment.

• For RAC m instances to RAC n instances movement, where the number of Oracle RAC instances in the source environment is greater than the number of Oracle RAC instances in the target environment (m > n): After completing the movement process, remove the extra m - n generic data sources from the last Oracle RAC instance in the target environment.

  For example, if the source environment contains four Oracle RAC instances, and the target environment contains three Oracle RAC instances, then you will have four generic data sources that are named mds-soa-rac1, mds-soa-rac2, mds-soa-rac3, and mds-soa-rac4. The extra generic data source (mds-soa-rac4) points to the third Oracle RAC instance in the target environment (the third Oracle RAC instance will contain both mds-soa-rac3 and mds-soa-rac4). You must remove mds-soa-rac4 from the last Oracle RAC instance in the target environment.

16.8.3 Setting Up Security

After completing the movement process, you must set up security, such as configuring SSL and hardening. For information, see Section 4.7.

You must also enable the SSL configuration for Node Manager:

1. Turn on SSL by setting SecureListener=true in the NodeManager_Home/nodemanager.properties file.

2. Change the Node Manager type from Plain to SSL. In Oracle WebLogic Server Administration Console, navigate to Environment, then Machines, then machine_mame, then Node Manager, then Type.

3. Stop the Administration Server and Node Manager.

4. Restart the Administration Server and Node Manager.

   Make sure that the Node Manager status is Reachable.

16.9 Moving Components from a Production Environment to a Test Environment

It may be necessary to periodically bring production data into the test environment to conduct certain types of tests. For example, it might be useful to test Oracle Fusion Applications with realistic data in the following circumstances:

• Testing new functionality

• Testing bug fixes and code changes

• Testing previously unused functionality

• Testing upgrades

• Testing performance

• Training users

Before moving production data, consider the following:

• You must have a test environment that is similar to the production environment. The applications and configuration settings between the two environments must be the same, except for any environment specific values, such as host names and connection information.

• In addition to having a similar test environment, since the production data references real production users and applications policies, the identity store and policy store at the test environment must contain a copy of these objects.

• You must determine which database tables must be copied from the production environment to the test environment, based on the data you need for the tests.

• When moving data from the production environment to the test environment, you must mask all sensitive information in the copied data.

  Even when sensitive information is masked, you must use caution in granting access to this data in the test environment. In certain cases, you may not be able to mask out all sensitive data. For example, if you want to conduct heavy-duty payroll testing for validating new tax formulas, you may want to conduct the test with real payroll data.

To move components from a production environment to a test environment:

1. Create the test environment from production. See Section 16.9.1.

2. Move the Oracle Identity Management data from production to test. See Section 16.9.2.

3. Move application data from production to test, and mask it. See Section 16.9.3.

4. Create additional test users. See Section 16.9.4.

16.9.1 Creating the Test Environment from Production

You may already have a test environment that is similar to production. However, if it does not exist or it is significantly different from production, you must create one from the production environment. You can use the procedure described in Section 16.2 to create any target environment from a given source environment. To create a test environment from production, follow this procedure and treat production as the source environment and test as the target environment.

16.9.2 Moving the Required Oracle Identity Management Data

When you bring production application data to the test environment, you must also bring the Oracle Identity Management objects to which they refer. These include such objects as the enterprise users and roles, and application policies.

To move Oracle Identity Management data for Oracle Fusion Applications from a production environment to a test environment, complete the following procedures:

Note:

It is assumed that you have moved the Oracle Fusion Applications related artifacts for Oracle Identity Management from the source domain to the target domain. See Section 16.4.

1. Move the identity store. See Section 16.9.2.1.

2. Create system IDs. See Section 16.9.2.2.

3. Move the policy store. See Section 16.9.2.3.

16.9.2.1 Move the Identity Store

Move the identity store data by cloning the data using either the export and import operations or using replication.

Note:

When moving from production to test, the Global Unique Identifiers (GUIDs) must be retained as is. By default GUIDs are copied in the ldifwrite tool.

Depending on the deployment requirement, you can move the identity store by using either the LDIF export and import or the replication procedure.

16.9.2.1.1 Cloning Using Export and Import

To clone the identity store data using export and import:

1. Write all entries to a file.

   ldifwrite connect="srcOidDbConnectStr" baseDN=<dc=mycompany,dc=com> ldiffile="srcOid.ldif"
   

   This command writes all entries under the node indicated by <dc=mycompany,dc=com> to the file srcOid.ldif.

2. Move the file to the test Oracle Internet Directory file system.

3. In the test Oracle Internet Directory system, verify that there are no schema errors or bad entries.

   bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"
   

   If duplicated DistinguishedNames (DNs, which are common entries between the source and destination directories) are detected, review them to prevent unexpected results.

   Tip:

   Back up the test database. If the next steps fails (and corrupts the database), the database must be restored.

4. Load the data into the test Oracle Internet Directory.

   bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"
   

16.9.2.1.2 Cloning Using Replication

You can clone the identity store data using replication. For information, see the "Advanced Administration: Directory Replication" part in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

For security reasons, do not replicate the userpassword attribute between test and production.

16.9.2.2 Create the System Identities

System identities in the test environment are not necessarily the same as that of production environment. The test environment should already have these defined, and they should be in a functioning state. However, if necessary, you can create additional system identities. For information, see Task 1, "Create the System Identities".

Note:

Test users are required for managing the test environment. The test users can be created under a separate container under the same user search base, so that it becomes easier to track or clean up.

16.9.2.3 Move the Policy Store

The policy store in the test environment must have all the policies of the production environment. If the test environment is created from production, the test environment would have all the policies of the production environment. If the test environment was not created from production, then you must move the policy store data to the test environment.

Moving the policy store from a production environment to a test environment is based on the following assumptions:

• The policy store deployment mode is the same in the production and test environments.

• The schema required for the policy store is created.

• The LDAP schema in the back end directory is extended using the compare and reconcile of the entities in the schema.

• The contents of the policy domain container are to be moved using replication or copying of data between test and production.

Move the policy store from production to test using the same procedure for moving the policy store from test to production. See Section 16.4.2.

16.9.3 Moving Application Data from Production to Test

You must copy all the Oracle Fusion Applications data from production and mask the sensitive information before moving it to the test environment. For data model descriptions, see the product-specific documentation.

This section contains the following topics:

• Moving Application Data from a Production Environment to a Nonexistent Test Environment

• Moving Application Data from a Production Environment to an Existing Test Environment

Note:

The data masking tools operate on the Oracle Fusion Applications data in place and require the complete database. Since you would not mask the production database, you must make a copy of the production database.

You cannot bring the entire production database to the test environment because it contains environment specific data, so you must create an intermediate copy of the production database, where you would run the masking tools and then selectively copy data to the test database.

16.9.3.1 Moving Application Data from a Production Environment to a Nonexistent Test Environment

In this scenario, either the test environment does not exist or the production environment has deviated from the test in terms of patches, customizations, configuration changes, security changes, and so on.

1. Discard the application tier and the FUSION database at the test environment.

2. Install the database and create the FUSION database using Oracle Fusion Applications Repository Creation Utility (Applications RCU). See the Oracle Fusion Applications Installation Guide.

3. Drop the entire FUSION schema at the test environment and copy it from the production environment.

4. Drop the entire FUSION_DYNAMIC schema at the test environment and copy it from the production environment.

5. Copy the required technology stack repositories, such as Oracle Universal Content Management, Oracle Imaging and Process Management, and Oracle WebCenter from production.

6. Synchronize the test identity store and policy store with those of production.

7. Perform the complete movement procedure in the reverse direction.

8. Regenerate the Oracle Essbase cubes at the test environment.

9. If there is a test data warehouse, regenerate it.

16.9.3.2 Moving Application Data from a Production Environment to an Existing Test Environment

In this scenario, the test environment exists and it is an exact equivalent of the production environment in terms of patches, customizations, configuration changes, security settings, etc. The idea is to move only the required data and not go through the movement procedure in the reverse direction.

1. Copy the following data from production to test after dropping the corresponding schemas:

   • Entire FUSION schema

   • Entire FUSION_DYNAMIC schema

   • Required technology stack repositories, such as Oracle Universal Content Management, Oracle Imaging and Process Management, and Oracle WebCenter from production.

2. Synchronize the test identity store and policy store with those of production.

3. Update the Oracle Topology Manager tables so that all TM wirings are correctly set for the test environment.

4. Regenerate the Oracle Essbase cubes at the test environment.

5. If there is a test data warehouse, regenerate it.

16.9.4 Creating Additional Test Users

If necessary, create additional test users in the test environment.

If the test requires a test user to log in as a production user, then the user identity attributes must not be selected for masking. In addition, the password for the user must be reset to a known value in the test environment. In such a case, the copied data is not anonymous, even though the sensitive data could have been masked. Therefore, tight access control is required to make sure that confidentiality is protected.

16.10 A Case Study: Moving Oracle Fusion Supply Chain Management Components

This section provides a case study of moving Oracle Fusion Supply Chain Management components from a source environment to a target environment.

In this case study, the Oracle Fusion Supply Chain Management topology, shown in Table 16-30, represents a sample topology in the source environment. It does not include a comprehensive list of applications.

Table 16-30 Sample Oracle Fusion Supply Chain Management Topology

System Component/Tier/Domain	Host in the Domain	Applications, Managed Servers, and System Components Running on the Host
Web Tier	WebHost-1	OHS
Oracle Identity Management Tier	IdmHost-1	Oracle Identity Management components: Oracle Internet Directory Oracle Virtual Directory Oracle Access Manager Oracle Identity Manager Oracle Identity Federation
Mid Tier (BIDomain)	MidHost-1	Oracle BI EE applications: coreapplication_obips1 (bi_server1/bi_server2) coreapplication_obis1 (bi_server1/bi_server2) coreapplication_obisch1 (bi_server1/bi_server2) coreapplication_obijh1 (bi_server1/bi_server2) coreapplication_obicc1 (bi_server1/bi_server2) Oracle BI EE components: Oracle BI Server Oracle BI Presentation Services Oracle BI Cluster Controller Oracle BI Scheduler JavaHost Oracle Essbase server
Mid Tier (CommonDomain)	MidHost-2	ApplicationsCoreSetupApp (HelpPortalServer_1/HelpPortalServer_2) GrcSetupApp (HelpPortalServer_1/HelpPortalServer_2) HelpPortalApp (HelpPortalServer_1/HelpPortalServer_2) HomePageApp (HomePageServer_1/HomePageServer_2) SetupApp (SalesServer_1/SalesServer_2) SetupEssApp (ess_server1/ess_server2) TopologyManagerServices (FunctionalSetupServer_1/FunctionalSetupServer_1)
Mid Tier (CRMDomain)	MidHost-3	ContractManagementApp (ContractManagmentServer_1/ContractManagmentServer_2) ContractManagementEssApp (ess_server1/ess_server2) CrmCommonApp (CRMCommonServer_1/CRMCommonServer_2) CrmEssApp (ess_server1/ess_server2)
Mid Tier (FinancialDomain)	MidHost-4	FinancialCommonApp (FinancialCommonServer_1/FinancialCommonServer_2) FscmAnalyticsApps (FinancialAnalyticsServer_1/FinancialAnalyticsServer_2) LedgerApp (LedgerServer_1/LedgerServer_2) PayablesApp (PayablesServer_1/PayablesServer_2) ReceivablesApp (ReceivablesServer_1/ReceivablesServer_2)
Mid Tier (HCMDomain)	MidHost-5	HcmAnalyticsApp (HCMAnalyticsServer_1/HCMAnalyticsServer_2) HcmCoreApp (CoreProcessesServer_1/CoreProcessesServer_1) HcmCoreExternalApp (CoreProcesses_Server_1/CoreProcesses_Server_2) HcmCoreSetupApp (CoreSetupServer_1/CoreSetupServer_2) HcmEssApp (ess_server1/ess_server2)
Mid Tier (ProcurementDomain)	MidHost-6	ProcurementApp (ProcurmentServer_1/ProcurementServer_2) ProcurementEssApp (ess_server1/ess_server2) SupplierPortalApp (SupplierPortal_Server_1/SupplierPortal_Server_2)
Mid Tier (ProjectsDomain)	MidHost-7	ProjectsFinancialsApps (ProjectsFinancialsServer_1/ProjectsFinancialsServer_2) ProjectsFinancialsEssApp (ess_server1/ess_server2)
Mid Tier (SCMDomain)	MidHost-8	AdvancedPlanningApp (AdvancedPlanningServer_1/AdvancedPlanningServer_2) CostManagementApp (CostManagementServer_1/CostManagementServer_2) GlobalizationApp (GlobalizationServer_1/GlobalizationServer_2) LogisticsApp (LogisticsServer_1/LogisticsServer_2) LogisticsCommonApp (SCMCommonServer_1/SCMCommonServer_2) OrderOrchestrationApp (OrderOrchestrationServer_1/OrderOrchestrationServer_2) ProductManagementCommonApp (ProductManagementServer_1/ProductManagementServer_2) ScmEssApp (ess_server1/ess_server2) ProductManagementCommonApp (ProductManagementServer_1/ProductManagementServer_2)
Oracle Database Tier	DbHost-1

This case study describes the following steps for moving the Oracle Fusion Supply Chain Management components from a source environment to a target environment:

• Task 1, "Prepare the Source Environment"

• Task 2, "Prepare the Target Environment"

• Task 3, "Move Oracle Identity Management Domain Component Artifacts"

• Task 4, "Move the Binary Files"

• Task 5, "Set the System Properties"

• Task 6, "Move the Webgate Installation"

• Task 7, "Create the Configuration Archives"

• Task 8, "Extract the Move Plan"

• Task 9, "Modify the Move Plan"

• Task 10, "Apply the Configurations to the Target Environment"

• Task 11, "Completing the Component-Specific Configuration Move"

• Task 12, "Move the Functional Setup Data"

• Task 13, "Complete the Postmovement Tasks"

Task 1   Prepare the Source Environment

Before performing the full-movement tasks, make sure that the necessary preparations are in place in the source environment. For information, see Section 16.3.1.

Task 2   Prepare the Target Environment

Before performing the full-movement tasks, complete the necessary preparations in the target environment. For information, see Section 16.3.2.

Task 3   Move Oracle Identity Management Domain Component Artifacts

Move the Oracle Fusion Applications related artifacts for Oracle Identity Management for Oracle Identity Management from the source Oracle Identity Management domains to the target Oracle Identity Management domains. For information, see Section 16.4.

Task 4   Move the Binary Files

You must move the binary files of each Middleware home (fusionapps and webtier_mwhome) from the source environment to the target environment.

To move the binary files:

1. Using the copyBinary script, create a separate copy of each source Middleware home by copying the installed binaries and patches into an archive file. For more information, see Section 16.5.1.

2. Using the pasteBinary script, apply the archive containing the binary files of the source Middleware home to the target environment. For more information, see Section 16.5.2.

3. Move the dbclient installation. For information, see Section 16.5.3.

Task 5   Set the System Properties

Before you move the configurations of the Oracle WebLogic Server domains and the OHS instances that are part of the source environment to the target environment, you must set system properties for Oracle SES and Oracle Enterprise Scheduler Service. For information, see Section 16.6.2.

Task 6   Move the Webgate Installation

After moving the OHS instance home, you must move the Webgate installation. For information, see Section 16.6.3.

Task 7   Create the Configuration Archives

Creating a configuration archive copies the source Oracle WebLogic Server domain home, OHS instance home, and Node Manager configuration files into an archive file. You must create a separate configuration archive for each Oracle WebLogic Server domain and each OHS instance in the source environment.

To create the configuration archives, run the copyConfig script for the OHS instances, node managers, and Oracle BI EE components, and each of the following Oracle WebLogic Server domains:

• CRMDomain

• CommonDomain

• BIDomain

• HCMDomain

• FinancialDomain

• ProcurementDomain

• ProjectsDomain

• SCMDomain

For information about running copyConfig for Oracle WebLogic Server domains, see Section 16.6.4.1.

For information about running copyConfig for OHS instances, see Section 16.6.4.2.

You must also run copyConfig for Node Manager on each machine within the topology of the source environment. For information, see Section 16.6.4.3.

Task 8   Extract the Move Plan

Extracting the move plan consolidates into a single XML file the configuration settings of the source environment from the configuration archives, as well as from other configuration files specific to components such as SOA composite plans, adapter plans, and so on.

To extract the move plan, run the extractMovePlan script on the list of configuration archive locations, separated by comma.

In this case study, a total of thirteen configuration archives were created; each of the Oracle WebLogic Server domains (six archives for six domains), each of Node Manager (six archived for six node managers) and OHS instances.You must extract the configuration information from all thirteen configuration archives into a single move plan:

In this case study, a total of eighteen configuration archives were created; each of the Oracle WebLogic Server domains (eight archives for eight domains), each of Node Manager (eight archived for eight node managers), Oracle BI EE, and OHS instances.You must extract the configuration information from all eighteen configuration archives into a single move plan:

extractMovePlan.sh -javaHome USER_HOME/jrockit_160_20_D1.0.1-1705
                -archiveLoc /FSCM_T2P/FSCM_WebTier.jar,/FSCM_T2P/FSCM_CRMDomain.jar,/FSCM_T2P/FSCM_CommonDomain.jar,/FSCM_T2P/FSCM_BIDomain.jar,/FSCM_T2P/HCMDomain.jar,/FSCM_T2P/FSCM_FinancialDomain.jar,/FSCM_T2P/FSCM_ProcurementDomain.jar,/FSCM_T2P/FSCM_ProjectsDomain.jar,/FSCM_T2P/FSCM_SCMDomain.jar,/FSCM_T2P/CRMDomain_NodeManager.jar,/FSCM_T2P/CommonDomain_NodeManager.jar,/FSCM_T2P/BIDomain_NodeManager.jar,/FSCM_T2P/HCMDomain_NodeManager.jar,/FSCM_T2P/FinancialDomain_NodeManager.jar,/FSCM_T2P/ProcurementDomain_NodeManager.jar,/FSCM_T2P/ProjectsDomain_NodeManager.jar,/FSCM_T2P/SCMDomain_NodeManager.jar,/FSCM_T2P/FSCM_BIComponents.jar
                -planDirLoc /FSCM_T2P/move_plan
                -logDirLoc /FSCM_T2P/logs
                -optimizationHints fusionApps,sameSchemaNameSinglePassword

The eighteen configuration archive locations, separated by comma, are specified to create a single move plan called moveplan.xml or multiple archive move plans in /FSCM_T2P/move_plan.

For more information about extracting move plans, see Section 16.6.5.

Task 9   Modify the Move Plan

You must modify the move plan to specify properties (such as data source definitions, host names, port numbers, and end point addresses) for the target environment before you apply the copied configurations from the source environment to the target environment. For more information, see Section 16.6.6.

Task 10   Apply the Configurations to the Target Environment

Apply the copied configurations from the source environment to the target environment by running the pasteConfig script for each of the following Oracle WebLogic Server domains, OHS instances, and Oracle BI EE components separately, using the same move plan (moveplan.xml):

• CRMDomain

• CommonDomain

• BIDomain

• HCMDomain

• FinancialDomain

• ProcurementDomain

• ProjectsDomain

• SCMDomain

You must also run pasteConfig for Node Manager on each machine within the topology in the target environment. For more information, see Section 16.6.7.

Task 11   Completing the Component-Specific Configuration Move

You must move the component-specific configurations of the Oracle Fusion Middleware components.

For more information, see Section 16.6.8.

Task 12   Move the Functional Setup Data

Moving the functional setup data applies the setup configuration data of the source environment to the target environment. Move the functional setup data for the all the offerings. For information, see Section 16.7.

Task 13   Complete the Postmovement Tasks

After you move the Oracle Fusion Applications components across environments, you must complete various postmovement tasks. For information, see Section 16.8.