21Moving from a Test to a Production Environment

This chapter describes how to move Oracle Fusion Middleware from a source environment, such as a test environment, to a target environment, such as a production environment. You can develop and test applications in a source environment, and then eventually roll out the test applications and, optionally, test data to your target environment. You can also use this approach for testing and rolling out upgrades.

21.1 Introduction to Moving Oracle Fusion Middleware Components

You can move Oracle Fusion Middleware components from a source environment to a target environment.

Moving Oracle Fusion Middleware components minimizes the amount of work that would otherwise be required to reapply all the customization and configuration changes made in one environment to another. You can install, configure, customize, and validate Oracle Fusion Middleware in a source environment. Once the system is stable and performs as desired, you can create the target environment by moving a copy of the components and their configurations from the source environment, instead of redoing all the changes that were incorporated into the source environment.

If you have an existing target environment, you can move any modifications of the source environment, such as customizations, to the target environment.

21.2Overview of Procedures for Moving from a Source to a Target Environment

This section describes the general steps in moving installations from a source environment to a target environment.

Move a copy of the Middleware home for the component or suite from the source environment to the target environment using the copyBinary and pasteBinary scripts, as described in Section 21.3.4.

Move a copy of the configuration of components, as described in Section 21.3.5 or Section 21.3.6. In most cases, you use the copyConfig, extractMovePlan, and pasteConfig scripts.

Move other data, such as data for Oracle WebCenter Portal applications, or Oracle Web Cache configuration files. Modify any information that is specific to the new environment such as host name or ports. See Section 21.4 for information specific to each component.

21.3 Common Procedures for Moving to a Target Environment

Many of the Oracle Fusion Middleware components use some of the same procedures to move from a source environment to a target environment. Note, however that not all components use all or some these procedures. You must follow the procedures in Section 21.4 for your particular component.

This section describes the common procedures and contains the following topics:

In the scripts used in these procedures and in the move plans, you often need to provide files containing passwords. To generate a file that contains an obfuscated password, use the obfuscatePassword script, which is described in Section 20.2.1.12.

21.3.1 Preparing the Source Environment

The procedures in this chapter assume that you have installed and configured Oracle Fusion Middleware on the source environment, including some or all of the following:

Installed one or more databases to be used by Oracle Fusion Middleware components such as Identity Management, Oracle SOA Suite, or Oracle WebCenter Portal.

This can include creating the desired LDAP trees and entries, in particular, users and groups for Oracle Internet Directory, creating adapters to data sources for Oracle Virtual Directory, creating policies for Oracle Web Services Manager. In addition, it can include configuring self-signed certificates for SSL. (In the target environment, you use trusted CA-signed certificates.)

Deployed one or more applications or SOA Composite applications. The applications may have internal and external references.

Note that all Oracle homes in the Middleware home on the source environment must be registered in the same Oracle inventory. If you have installed multiple components under the same Middleware home, but used different Oracle inventory locations, the scripts are not able to detect all of the Oracle homes.

To work around this issue, take the following steps:

Create a new oraInst.loc pointing to the inventory to which you want to register, using the following commands:

Attach the Oracle Home to the new inventory by passing new oraInst.loc created in step 1:

./attachHome.sh -invPtrLoc new_oraInst_loc_location

Do this for every Oracle home in the Middleware home.

Set the necessary dependencies between Oracle homes if required (for example most Oracle homes depend on oracle_common). The dependencies are required when you uninstall. You can check the existing dependencies from the old inventory by checking the file oraInventory/ContentsXML/inventory.xml. The following shows an example of the file:

21.3.2 Preparing the Target Environment

To use the procedures in this chapter, your target environment must meet the following prerequisites:

You must use the cloningclient.jar file and movement scripts that are compatible with the version of the Middleware home and components that you want to copy. The procedures in this chapter presume that you are using the current version of the cloningclient.jar file and movement scripts.

The target environment must be on the same operating system as the source environment. Also, the operating system architecture must be the same in both environments. For example, both environments must be running 32-bit operating systems or 64-bit operating systems.

All Oracle homes in the Middleware home must be either all 32 bit or all 64 bit. The operation does not support a mix of 32-bit and 64-bit Oracle homes.

When you execute the scripts, you must specify a matching Java home. That is, if the Oracle homes are 64 bit, you must specify a 64-bit Java home. If the Oracle homes are 32 bit, you must specify a 32-bit Java home.

The target environment must have the same superuser or administrative user as the user at the source environment. The user's password can be different if you are using an external LDAP; you specify it on the command line when you use the pasteConfig script. After you complete the movement of the installation, you can modify the user on the target environment.

The database in the target environment must be the same type of database as in the source environment. For example, if the database in the source environment is an Oracle Database, the database in the target environment must be an Oracle Database. The database on the target environment should be the same version as on the source environment.

If the database is not tuned correctly, the copyConfig and pasteConfig operations can incur 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 database for the import of the MDS tables. Also run statistics against the target database by executing the following procedure:

21.3.3 Installing the Database on the Target Environment

Note that the database in the target environment must be the same type of database as in the source environment. For example, if the database in the source environment is an Oracle Database, the database in the target environment must be an Oracle Database. The database on the target environment should be the same version as on the source environment.

You have the following options, depending on the components in your environment:

Install a new database. You must use this for all components, except Oracle Internet Directory. Take the following steps:

Create any custom schemas used by your applications. For example, if your application uses a custom schema in the source environment, create the schema in the target environment.

For moving Oracle Internet Directory, create a duplicate database using the Oracle Database RMAN duplicate command. The duplicate database must be created with a different DBID than the source database, so that it functions entirely independently.

To create a duplicate Oracle Database, Release 11g, in the target environment:

Stop the Identity Management processes in the source environment.

On the target environment, install the Oracle Database software, but do not create a database. To do this, select Install Database Software only in the Select Configuration Option screen.

On the source environment, edit the tnsnames.ora file, adding an entry for the database on the target environment.

The following shows an example of the tnsnames.ora file. In the example, testDB is the database on the source environment and prodDB is the database on the target environment.

In the target environment, create a password file in the ORACLE_HOME/dbs directory. The sys password must be the same as the password for the sys account in the database in the source environment. The following command creates the password file:

orapwd password=password file=ORACLE_HOME/dbs/orapwproddb

In the target environment, create a parameter file (pfile) in the ORACLE_HOME/dbs directory. The file should contain only the DB_NAME parameter. For example:

DB_NAME=prodDB

In the target environment, set the ORACLE_SID environment variable to point to the target database if it is not already set.

On Windows, create the instance using the oradim command. For example:

RMAN automatically copies the server parameter file to the destination host, starts the auxiliary instance with the server parameter file, copies all necessary database files and archived redo logs over the network to the destination host, and recovers the database. Finally, RMAN opens the database with the RESETLOGS option to create the online redo logs.

21.3.4 Moving the Middleware Home and the Binary Files

You can move a copy of the Middleware home to the target environment using the copyBinary and pasteBinary scripts:

The copyBinary script prepares the source and creates an archive. It also records the file permissions of the Middleware home and the Oracle homes within the Middleware home.

The archive contains the Oracle WebLogic Server home and all of the Oracle homes in the Middleware home.

The pasteBinary script checks to see that the prerequisites are met at the destination. It extracts the files from the archive file, registers the Oracle homes with the Oracle inventory and registers the WebLogic Server home with the Middleware home.

The script then restores the file permissions and relinks any files if necessary.

Note the following:

The copyBinary and pasteBinary scripts do not carry over all the dependencies of the source Middleware home, WebLogic Server home, and Oracle homes, such as loadable modules or application-specific libraries to the target home, because the scripts proceed by copying the Middleware home and the entire source WebLogic Server home and Oracle homes to the destination Middleware home. Any files outside the source WebLogic Server or Oracle home are not automatically copied. Hence, any applications that refer to files outside the source WebLogic Server or Oracle home may not work properly in the target home.

The Oracle home that is copied as a part of the Middleware home contains only the binary files.

When you copy a Middleware home, only the read-only portions of the Middleware home are copied. Any user configuration files, such as the user_projects directory, are excluded from the archive. The WebLogic Server domain is not copied. (Use the copyConfig and pasteConfig scripts to copy the domain.)

You cannot move a Middleware Home if its path is a symbolic link.

To move the Middleware home:

On Windows, at the source, stop the Administration Server and any Managed Servers running in the Middleware home. In addition, stop any Java or WebLogic processes. (On UNIX, you do not need to stop the servers.)

At the source, execute the copyBinary script, which copies the Middleware home and the WebLogic Server home and the Oracle homes contained within the Middleware home. If there are no Oracle homes in the source Middleware home, no Oracle homes are present in the archive.

Do not copy the other scripts, such as pasteConfig. Those scripts are generated when you extract the files, as in step 6.

On Linux and UNIX, if the target system does not contain any installed Oracle products, you must create an oraInst.loc file, specifying a group whose members are given access to write to the Oracle inventory (oraInventory), and where you want to put Oracle inventory. For example, the oraInst.loc file could contain the following:

inst_group=dba
inventory_loc=/scratch/oracle1/oraInventory

Then, if the location is not the default location (/etc/oraInst.loc.), use the -invPtrLoc option to the pasteBinary script to specify the location of the oraInst.loc file.

At the target, extract the files from the archive using the pasteBinary script, See Section 20.2.1.2 for the syntax of the pasteBinary script.

Note:

If the parent directory for the Middleware home does not exist, the pasteBinary script creates the directory.

Note that the actual directory for the Middleware home (for example, MW_Home_prod) cannot exist.

For example, to apply the archive to the directory /scratch/oracle/MW_Home_prod, use the following command:

The Middleware home is extracted to /scratch/oracle/MW_Home_prod and the WebLogic Server home and all of the Oracle homes are extracted under it with the same names as that of the source Oracle home names.

If you used a custom inventory location (using the invPtrLoc parameter) in the pasteBinary script, you must run the following script as root: at the end of pasteBinary operation.

ORACLE_HOME/oracleRoot.sh

At the target, delete the Node Manager directory and the files in it. The default location of the directory is:

21.3.5 Moving the Configuration of Java Components

You can move a copy of the domain configuration for Java components, such as Oracle SOA Suite, using the copyConfig, extractMovePlan, and pasteConfig scripts. This step moves a copy of the configuration, including the domain, the Administration Server and Managed Servers. Then, it starts the Administration Server. You also move a copy of the Node Manager configuration.

Because, in most cases, the user-specific data is not the same in the target environment as in the source environment, this process does not move user-specific data.

Note:

By default, during the copyConfig and pasteConfig operations, the following, which specify the maximum heap size and the maximum permanent generation space, are set:

-Xmx512m -XX:MaxPermSize=256m

You can modify the values using the T2P_JAVA_OPTIONS parameter of the copyConfig and pasteConfig scripts.

Notes:

When you move the configuration of a component, the scripts replicate the topology of the source. For example, if the source domain contains Managed Servers server_1 and server_2 on Host A and Managed Servers server_3 and server_4 on Host B, you must specify a similar relationship between Managed Servers and hosts at the target. (You specify the hosts for each Managed Server in the move plan.)

The domain directory is local to each machine. The pasteConfig script is performed only on the Administration Server domain directory. Subsequently, if the Managed Servers are not in the same directory as the Administration Server, you must re-create the domain directory for those Managed Servers by using the Oracle WebLogic Server pack and unpack commands. See Section 21.5.

To move a copy of the domain configuration and Node Manager configuration:

At the source, make sure that the Administration Server and all Managed Servers are started.

At the source, copy the domain configuration by executing the copyConfig script.

You must extract a new move plan each time you use the copyConfig script even if no changes have been made to the source environment. The pasteConfig scripts checks that the move plan and archive match. If they do not, the script returns an error.

Edit the move plan, modifying the properties to reflect the values for the target environment. See Table 20-12 to find the list of properties for the type of component you are moving.

If you are moving only one domain in an environment that contains more than one domain, in the move plan, remove the entries for the domains that you are not moving.

Copy the edited move plan to the target. (During the pasteConfig operation, you specify the location using the -movePlanLoc option.)

At the target, run the following script to generate obfuscated password files required by the move plan. Run the script for each password file.

Note that the Oracle instance name must be unique in the domain. If you are applying the archive of the Oracle instance to the same domain, use the -targetInstanceName option to specify a different name for the instance.

When you complete this task, you need to perform additional steps for each component, as described in Section 21.4.

21.3.6.2 Moving an Individual System Component

You can move the configuration of an individual system component within an Oracle instance.

Take the following steps:

At the source, execute the copyConfig script. Copying an individual component, is similar to copying an Oracle instance, except that you add the -sourceComponentName option.

Note that the Oracle instance name must be unique in the domain and the component name must be unique in the Oracle instance. If you are applying the archive of the Oracle instance to the same domain, use the -targetInstanceName and -targetComponentName options to specify a different name for the instance and component.

When you complete this task, you need to perform additional steps for each component, as described in Section 21.4.

21.3.7 Configuring Users and Groups

You must configure security in the new target environment. The steps you take depends on the configuration of your environment and application.

The target environment LDAP identity store may not use the same users and groups as the source environment, or it may already be populated with users and groups. Take the following steps only if you need to move users, groups, and passwords from the source environment to the target environment:

Export the users and groups from LDAP identity store on the source environment, using the ldapsearch command. This produces an ldif file that you later import into the LDAP identity store in the target environment. The ldapsearch command is located in the ORACLE_HOME/bin directory of the Identity Management components. For example:

Import the ldif file that you exported from the source environment into the target environment, using the ldapaddmt command, as shown in the following example. (ORACLE_HOME is the Oracle home for Identity Management.)

21.4 Moving Oracle Fusion Middleware Components

The following sections describe the steps you must take to move Oracle Fusion Middleware components. In many cases, the steps use the common procedures described in Section 21.3. All components require additional steps as described in the following topics:

Installed and configured Identity Management, including some or all of the following components: Oracle Internet Directory, Oracle Virtual Directory, Oracle Web Services Manager, or Oracle Adaptive Access Manager.

For Oracle Internet Directory, created the desired LDAP trees and entries, in particular, users and groups.

For Oracle Virtual Directory, created adapters to various data sources, such as LDAP and databases, and you may have configured a Local Store Adapter (LSA) to create local LDAP data, which resides in the local file system.

For Oracle Directory Integration Platform, created synchronization profiles to various targets. These profiles are in the form of LDAP entries residing in Oracle Internet Directory.

For Oracle Identity Federation, configured various trusted identity providers and service providers.

21.4.1.1 Moving Identity Management to a New Target Environment

In this procedure, you have installed Identity Management components, such as Oracle Internet Directory, Oracle Virtual Directory, and Oracle Directory Integration Platform, in the source environment and you want to move them to the target environment that does not exist.

Note:

Oracle does not support the movement of Oracle Identity Manager, either through the movement scripts or manual steps. In addition, if Oracle Identity Manager is part of the source environment of other components, the movement scripts for that environment will fail.

Perform the following tasks, depending on which components you use. Note that Task 1 is required for all components.

Task 1 Move the Database, Middleware Homes, and Domain Configuration to the New Target Environment

You move the database, a copy of all Identity Management Middleware homes, and the domain configuration to the target environment, using the following steps:

Move or create the database and the schemas, as described in Section 21.3.3.

Move a copy of the Middleware home containing the Identity Management components from the source environment to the target environment using the copyBinary and pasteBinary scripts, as described in Section 21.3.4.

Move a copy of the configuration of each domain containing the Identity Management configuration, as described in Section 21.3.5. This step moves the configuration, including the domain, Administration Server, and Managed Servers. Moving the configuration also:

Reassociates the security store to an LDAP or database-based store, based on the values provided in move plan.

If you have modified an Oracle Access Manager server port number using the Oracle Access Manager console, that port number is not modified in config.xml. To work around this issue, edit the following file to modify the port number:

DOMAIN_HOME/config/config.xml

Task 3 Move Oracle Internet Directory to the New Target Environment

To move Oracle Internet Directory to a new target environment:

Move the Oracle Internet Directory configuration by moving the configuration of the Oracle instance, as described in Section 21.3.6.

Note the following:

If an Oracle Internet Directory component is copied with the same database credentials as the source component, the name of the target OID component should be different than the source component to avoid conflicts in the OID schema.

If an Oracle Internet Directory component is copied with different database credentials from the source component, the name of the target Oracle Internet Directory component should be the same as the source component.

Under certain conditions, you may see the following errors when you run the copyConfig and pasteConfig scripts:

If you have configured Oracle Internet Directory replication in the source environment, you must reconfigure it again in the target environment after moving. The replication configuration is not moved from the source to the target environment. See "Setting Up Replication" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Task 4 Move Oracle Virtual Directory to a New Target Environment

To move Oracle Virtual Directory to a new target environment:

Move the Oracle Virtual Directory configuration by moving the configuration of the Oracle instance, as described in Section 21.3.6.

If you have already moved the Oracle instance that contains Oracle Virtual Directory, you do not need to take this step.

Note that, during the pasteConfig operation, if you have not provided a password file for the Oracle Virtual Directory adapter or you specify an incorrect location for the password file in the move plan, the adapter configuration is not changed and the script returns the following message:

Password file is either not provided or invalid for adapter adapter_name. Nothing will be changed for this adapter configuration.

Oracle Directory Integration Platform profiles reside in Oracle Internet Directory. If you have correctly moved Oracle Internet Directory to the target environment, the profiles are carried over to the target environment.

If you configured SSL on the source environment, that configuration is not moved to the target environment. You must configure SSL on the target environment. See Section 6.5.4.3.

Task 6 Move Oracle Access Manager 11g to a New Target Environment

When you move the configuration of the domain, update the move plan properties in Table 20-33 to use values for the target environment. However, note the following:

Although you can specify the production host and port in the move plan, you must manually re-register the partners.

For Webgate, the script generates the obAccessclient.xml file, but you must manually copy this file to the agent at the following location:

WebGate_instance_dir/webgate/config

For mod_osso, you must copy the osso.conf file to the following location in the Middleware home in which Oracle HTTP Server has been installed:

MW_HOME/instances/instance1/config/OHS/ohs1/osso/

When Oracle Access Manager is integrated with Oracle Adaptive Access Manager, you should manually regenerate the partner key.

When Oracle Access Manager is integrated with Oracle Identity Federation, you should manually regenerate the partner key.

If Oracle Access Manager is integrated with Oracle Adaptive Access Manager, update the challengeURL for the Authentication Scheme in the Oracle Access Manager configuration. See "Viewing or Editing a Authentication Scheme" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service

The passwords (in CSF) and the server key remain same for source and target. For Oracle Access Manager, if the target server key has to be different from the source, you must regenerated it after you move the domain configuration.

Moving the configuration of the domain moves the Oracle Access Manager configuration to the target environment.

Task 7 Move Oracle Access Manager 10g to a New Target Environment

To move Oracle Access Manager 10g to a new target environment:

Move the Directory Server from the source environment to the target environment. That is, migrate the o=oblix node. See "Preparing the New Directory Server Instance" in the Oracle Access Manager Installation Guide.

Remove the entries that are associated with the Identity Server, Policy Manager, and Access Servers. The entries are under the following:

obcontainerId=DBAgents,<Configuration DN>

Do not delete the container (obcontainerId=DBAgents).

Install and configure Oracle Access Manager, specifying the LDAP information for the target environment, as described in the Oracle Access Manager Installation Guide.

Oracle Access Manager stores policy and configuration data in the LDAP directory. If the LDAP directory is correctly configured (for example if you have correctly moved Oracle Internet Directory from the source environment to the target environment), Oracle Access Manager inherits the policy and configuration data from the LDAP directory.

On the target environment, install the Identity Server and WebPass using new identifiers. For more information, see:

Complete the identity system browser setup. See "Setting Up the Identity System" in the Oracle Access Manager Installation Guide.

Install the Policy Manager, as described in "Installing the Policy Manager" in the Oracle Access Manager Installation Guide. However, do not update the schema because you already updated it when you moved the Directory Server. Do not configure the authentication scheme because it already exists in the Directory Server.

Note:

After setting up the target Policy Manager, when you log in as the Oracle Access Manager Administrator, you may get the following error:

There was a problem obtaining the user ID. One possible reason for this is a time difference between the Identity System and Access Systems (Policy Manager and Access System Console).

To fix this, from the LDAP, delete the cookie encryption key (without changing the CPResponseEncryptionKey) under the o=oblix node, and restart the Identity Server. Note that you should make a backup of the cookie encryption entry into an ldif file before deletion.

Complete the browser setup from the Access System Console, adding the Access Server with a new identifier. See "Creating an Access Server Instance in the System Console" in the Oracle Access Manager Installation Guide for more information.

Also see "About the Access Server and Installation" in the Oracle Access Manager Installation Guide for additional information.

This scenario reuses the existing WebGate identifier for the target WebGates. Take the following steps:

Navigate to the Access System Console and select the Access System Configuration tab.

Select Host Identifiers. On the List all host identifiers page, select the host identifier that is used by the source environment.

Click Modify. Then, add the host name and port for the target Web server to the Hostname variations field.

Note:

Resources may become unprotected if you have the same host and port in multiple host identifiers.

Ensure that only the host identifier used in the policy domain has the host:port in its definition. Remove host:port from other host identifiers.

Install the Access Server using the new identifier that you used while creating the WebGates. See "Installing the Access Server" in the Oracle Access Manager Installation Guide.

Install the new WebGate. See "Installing the WebGate" in the Oracle Access Manager Installation Guide.

Verify entries and delete entries related to the source environment:

From the Identity System Console, select the System Configuration tab, then select Directory Profiles. Verify that the respective Directory Profiles are associated with the new Identity Server, Access Server, and Policy Manager.

From the Identity System Console, select the System Configuration tab, then select Webpass and delete the entry for the source WebPass.

From the Identity System Console, select the System Configuration tab, then select Identity Server and delete the entry for the source Identity Server.

From the Access System Console, select the Access System Configuration tab, then select Access Server Configuration. Delete the entry for the source environment Access Server.

From the Identity System Console, select the System Configuration tab, then select Password Policy. If the host and port are set for Password Change Redirect URL, change them to point to the new Identity Server.

From the Access System Console, select the Access System Configuration tab, then select Authentication Management. Select the authentication scheme for which Challenge redirect is set. Modify Challenge Redirect to specify the host and port of the new Web server, if the new authentication WebGate is installed.

From the Access System Console, select the Access System Configuration tab, then select Authentication Management. Select the authentication scheme for which a password policy is configured. Change the obWebPassURLprefix (if it exists) to accommodate the new host and port of the target Web server on which WebPass is installed, if WebPass and WebGate reside on different Web servers.

For more information, see "Configuring Password Policies" in the Oracle Access Manager Identity and Common Administration Guide.

Task 8 Move Oracle Identity Federation to a New Target Environment

When you use the copyConfig and pasteConfig scripts, as described in step 4 in Task 1, and modified the move plan as described in Table 20-24, the following are configured with values for the target environment:

The load balancer host and port and the SOAP port.

The service provider ID URL

The identity provider ID URL

The data stores

The Authentication Engines

The Service Provider Integration Modules

To complete the movement of Oracle Identity Federation:

Start the Managed Servers.

If, when you use Fusion Middleware Control and you receive a message that Oracle Identity Federation is not running although it is actually running, you must update the monitoring user name to be able to make configuration changes using Fusion Middleware Control:

Navigate to the Agent-Monitored Target configuration page, as described in Section I.3.1.3.

Select the Oracle Identity Federation icon.

On the Configuration page, update the WebLogic Monitoring Username and WebLogic Monitoring Password.

When you move the configuration of the domain, update the move plan properties in Table 20-34 to use values for the target environment.

If Oracle Adaptive Access Manager is integrated with Oracle Access Manager, after you have moved the configuration of Oracle Adaptive Access Manager, update the redirect URL:

Log in to the Oracle Access Manager console:

https://hostname.com:7001/oamconsole

In the Policy Configuration tab, select the Authentication Scheme.

Change the Challenge Redirect URL to the value for the target system.

The passwords in the Credential Store Framework remain the same for the target environment as for the source environment. If you want the passwords to be different in the target environment, you must regenerate them on the target environment.

Move policies that are not stored in the MDS Repository. For ADF BC and Oracle WebCenter Portal policy attachments, migrate them, as described in "Managing Application Migration Between Environments" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

For other policy attachments, the attachments are moved with the application if you use the Oracle WebLogic Server cloning feature.

21.4.1.2 Moving Identity Management to an Existing Target Environment

In this procedure, you have installed Identity Management components, such as Oracle Internet Directory, Oracle Directory Integration Platform, and Oracle Web Services Manager, in the source environment and you want to move them to the target environment that already exists.

On the existing target environment, you have installed and configured the components. You want to move an application from the source environment to the target environment while retaining its security-related configuration. This requires migrating application-specific data from the source Identity Management environment to the target Identity Management environment.

To move Identity Management to an existing target environment, perform the following tasks:

Specify the -r argument to move data and resolve conflicts. The ldif_filename is the file you obtained in the previous step.

If the source environment is set up as a staging environment to mimic the target environment, Oracle recommends that you set up one-way replication from the target Oracle Internet Directory to the source Oracle Internet Directory to ensure that any users or groups that exist in the target environment are available in the fan-out replica, which can be used to test applications. Fan-out replication also provides the capability to keep the source Oracle Internet Directory synchronized with the target and to replicate any users or groups that are added into target on real-time basis.

If you use Oracle Forms Services or Oracle Reports, move Resource Access Descriptors (RAD). This procedure assumes that you have moved the Default Subscriber from the source environment to the target environment, as described in Step 1. It also assumes that the orclGUIDs of the users at the source Oracle Internet Directory are identical to those in the target Oracle Internet Directory.

Specify the -r argument to move data and resolve conflicts. The ldif_filename is the file you obtained in the previous step.

Note that this command generates the file add.log in the directory where you run it. Check the add.log file for errors encountered during RADs migration. If there are any errors, fix the errors and rerun the command.

In the target environment, use the Oracle Access Manager OAMCfgTool to create the same policy domain for the application. Ensure that the following specify values for the target environment:

web_domain (The Host identifier is derived from this entry)
protected_uris="uri1,uri2,uri3"
app_agent_password=password to be provisioned for the WebGate
ldap_host=hostname_of_LDAP_server
ldap_port=port_of_LDAP_server
ldap_userdn=DN_of_LDAP_Admin_User
ldap_userpassword=password_of_LDAP_Admin_User
oam_aaa_host=host_of_OAM_server
oam_aaa_port=port_of_OAM_server

If you are using a uris_file to specify the protected and public URIs in a file, review the file to ensure that you are listed the corrected URIs.

If you made other changes to the Oracle Access Manager entities, such as the policy domain, in the source environment, make the same types of changes in the target environment.

Set up the WLST environment on both the source and target environments as described in "Setting up the WLST Environment" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.

On the source environment, extract the partner metadata and configuration properties by running the following script:

If you have removed a partner from the source environment, remove it from the target environment, as described in "Delete Trusted Providers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation

Export snapshots from the source environment. Use the Oracle Adaptive Access Manager Administration console to export the configuration to a zip file. See "System Snapshot Import/Export" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager for more information.

You can export the following types of items:

Policies

Rule conditions

Patterns

Configurable actions

Transaction definitions

Entities

KBA questions

KBA validations

All group types, including alert and action groups, and black list and white list groups used in rules

Import snapshots into the target environment. Use the Oracle Adaptive Access Manager Administration console to import the contents of the zip file saved in step 1. See "System Snapshot Import/Export" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager for more information.

Manually update the target environment for the following items, when necessary:

Because snapshot export and import only copies action and alert group types, you must export the group members from the source environment and import them into the target environment.

To export the groups, see "Exporting a Group" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

To import the groups into the target environment, see "Importing a Group" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

Use the oaam_extensions shared library to package the configurable actions jar.

Manually copy any items customized in the OAAM server, such as headers, footers, cascading style sheets (CSS), and JavaScript, from the source environment to target environment. These items are located in the oaam_extensions shared library.

If the credential store on the source environment is not file-based, migrate the credential store, using the script migrateSecurityStore, as described in "Migrating Credentials Manually" in the Oracle Fusion Middleware Application Security Guide.

Users and groups in the target LDAP may differ from that in the LDAP. There is a mapping between Oracle Platform Security application roles and LDAP roles. While the application roles may remain the same, the mapping to LDAP groups can be changed to map to the corresponding LDAP group in the target environment. See "Managing Application Roles" in the Oracle Fusion Middleware Application Security Guide.

If you are using Oracle Web Services Manager, migrate audit policies, as described in "Migrating Audit Policies" in the Oracle Fusion Middleware Application Security Guide.

Oracle WebLogic Server JAX-WS applications use policies stored in wsm-seed-policies.jar instead of in MDS. Move these policies by copying the following file from the source environment to the target environment:

ORACLE_HOME/modules/oracle.wsm.policies_11.1.1/wsm-seed-policies.jar

You can also use the Oracle WebLogic Server Administration Console to move these policies.

Move any policy attachments for a SOA, ADF, or WebCenter Portal application if they have changed since the application was first deployed in the target environment. For example, policy A was initially configured in the source environment with the BASIC 128 algorithm and attached to the HelloWorld application. The application was deployed to the target environment. Then, on the source environment, you changed policy A to use the Basic 129 algorithm.

Move any policy attachments for JAX-WS applications if they have changed since the application was first deployed.

21.4.2 Moving Oracle SOA Suite to a Target Environment

The following topics describe how to move Oracle SOA Suite from the source environment to the target environment:

For Oracle User Messaging Service, if there are remote servers in the test environment and you do not use shared disks, take the following steps on each remote server that contains Oracle User Messaging Service configuration:

When you use the copyConfig script, you must pass it the -additionalParams option, with the key osb.configuration.passphrase.file and the key value specifying the absolute path to the file containing the passphrase. For example:

If you do not specify this option, the exported configuration will not be password protected.

Before you run the pasteConfig script, if you want to change any values for the target environment, update the Oracle Service Bus configuration file, as described in the chapter "Customization" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

When you use the pasteConfig script, by default it uses the default JVM options. For Oracle Service Bus, you must pass other JVM options to avoid an Out-of-Memory error. Use the USER_MEM_ARGS environment variable to pass the options. For example:

Create directory structures for any inbound or outbound files. For example, if you are using a file adapter that reads an inbound file from the /tmp/inbound_msg directory and writes outbound files to the /tmp/outbound_msg directory, create those directories on the target environment. Similarly, if Oracle B2B is using a listening channel that reads inbound messages from the /tmp/inbound directory and writes outbound messages to the /tmp/outbound directory, create those directories.

Task 3 Export JKS Certificates

Export any JKS certificates for B2B endpoints from the source environment to the target environment. Then, import them to the target environment. For information about exporting and importing JKS certificates, see Section 8.3.3.

Task 4 Move Human Workflow to the New Target Environment

When you moved a copy of the domain from the source environment to the target environment, the scripts moved the following Human Workflow entities:

Attribute labels

Flex field mappings

Approval groups

Standard views

Given that the movement scripts do not move user-specific artifacts, the following are not moved:

User views

User and group workflow rules

In most cases, the user-specific data is not the same in the target environment as in the source environment. However, if you want to move the user views and rules from the source environment to the target environment, see "Moving Human Workflow Data from a Test to a Production Environment" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

Task 5 Deploy B2B Agreements to the New Target Environment

Oracle B2B is moved to the target environment when you execute the movement scripts. However, you must take the following additional steps:

During the execution of the movement scripts, the B2B agreements are not deployed. Deploy the B2B agreements, as described in "Deploying an Agreement" in the Oracle Fusion Middleware User's Guide for Oracle B2B.

Enable the listening channel:

Log into the B2B console and select the Administration tab, then, Listening Channel.

Select the listening channel.

Select the Channel Attributes tab. Then, select Enable Channel.

Click Save.

Task 6 Move Oracle Business Activity Monitoring Data to the New Target Environment

The copyConfig and pasteConfig scripts move Oracle Business Activity Monitoring to the new target environment.

If you want to move Oracle BAM objects, such as reports, alerts, and data definitions, from the ORACLEBAM database schema:

At the source, export the ORACLEBAM database schema, using the following commands (ORACLE_HOME is the Oracle home for the Oracle Database):

You can fix this error by creating the tablespace in the import database before the import or use REMAP_TABLESPACES to change the tablespace referenced in the table definition to a tablespace in the import database.

You may see failure with restoring index statistics if you use an Oracle database version earlier than 11.2.0.2. You can work around this issue by rebuilding the index statistics after import.

Task 7 Move Oracle Business Process Management to the New Target Environment

To move Oracle Business Process Management to the new target environment:

To move dashboards, use the ant-t2p-workspace.xml migration tool. The migration tool is available as an ant target that can be executed in the command line. It calls a configuration file that you create specifying the input parameters for the migration of data, as described in this task.

This script moves dashboards data with the BAM_WIDGET data type in the BPMUserApplicationData table to the target environment.

Note that the migration tool does not move any user-specific configuration because users in the source and target environments would not be same.

Task 8 Move Oracle User Messaging Service to the New Target Environment

The copyConfig and pasteConfig scripts move Oracle User Messaging Service to the new target environment.

However, if there are remote servers in the target environment and you do not use shared disks, the UMS directories you moved to the source Administration Server host, in Task 1, Step 5, must now be removed from the target Administration Server. Note, this cleanup must done after the domain is packed to be installed on the remote servers.

To complete the movement of Oracle Service Bus to a new target environment:

If you did not change any values in the Oracle Service Bus configuration file before you ran the pasteConfig script, you can change any values using the Oracle Service Bus console, as described in the chapter "Customization" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.

21.4.2.2 Moving Oracle SOA Suite to an Existing Target Environment

In this procedure, you have a working target environment and want to test changes in your applications or configuration before rolling those changes into the target environment. In the source environment, you have the same environment as described in Section 21.4.2.

If you have made any changes to Oracle B2B in the source environment, move those changes to the target environment.

Note that if you export selective agreements using the tpanames parameter, you must import each zip file individually.

To move Oracle B2B system changes:

Move Oracle B2B system configuration parameters by using the Oracle B2B interface to configure the properties. See "Configuring B2B System Parameters" in the Oracle Fusion Middleware User's Guide for Oracle B2B for details.

Move the B2B agreements and trading partners to the target environment:

Export the data from the source environment. The following example exports multiple deployed and active agreements:

You can export them using the ICommand utility. For more information about using the icommand to export artifacts, see "Using ICommand" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

While moving Oracle User Messaging Service to an existing target environment configured against an LDAP Store, only use the Userprefs-UI option to change User Preferences. Using the WLST command manageUserMessagingPrefs is not recommended as it may not correctly migrate identity-store backed device preferences that have been removed from the source instance.

Use Fusion Middleware Control to configure the User Messaging Service drivers with target driver information.

Use the WLST command deployUserMessagingDriver to deploy multiple drivers similar to the source environment.

Note:

To see different options for deploying additional drivers, execute help('deployUserMessagingDriver') at the wls:/offline> prompt.

Re-create any custom-created business terms in the target environment. This step is essential in order to use the same set of User Preferences filter settings in the target environment, and to ensure that filters built with custom business terms are functional.

Restart the target environment to apply the changes.

Move the User Messaging preferences from the source environment to the target environment. Filters cannot be updated or appended to an existing filter set. You must do one of the following:

Delete the entire filter set and upload a new set if there are changes made to the filter set in the source environment. See "Deleting a Filter" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

Create or modify user devices and filters in the source environment using the following URL in the target environment:

http://host:port/sdpmessaging/userprefs-ui

Test the UMS drivers for send and receive capabilities for supported drivers.

Test the successful upload of user messaging preferences by invoking the http://host:port/sdpmessaging/userprefs-ui URL. Log in as the desired user and validate that the messaging channels and filters are identical to those in the test environment. Alternatively, send and receive messages that are expected to be delivered based on the User Messaging preferences.

Task 6 Move Oracle Service Bus to an Existing Target Environment

For information about moving Oracle Service Bus to an existing target environment, see the chapter "Customization" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus. This chapter describes how to change environment values that differ between domains. Environment values are certain predefined fields in the configuration data whose values are very likely to change when you move your configuration from one domain to another (for example, from test to production).

21.4.3 Moving Oracle WebCenter Portal to a Target Environment

The following topics describe how to move Oracle WebCenter Portal from the source environment to the target environment:

Note that if the source environment includes portlet producers that are not being used, the portlet producer connection details are moved without the associated registrations and therefore, you must manually register those portlet producers in the target. When you register the portlet producers in the target, do not use the source connection names as they will conflict with the connections moved by this procedure.

To move the database and Middleware home, and perform the initial configuration:

If your Oracle WebCenter Portal application uses the Discussion service, move the discussion server data from the source environment to the target environment:

Export the discussion server data 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:

Import the discussion server data, using the Oracle Database import 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:

If you want to move Spaces application data such as spaces, space templates, and service-related data for lists, links, tags, people connections, to the target environment:

Export Spaces 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:

If you moved Spaces application data, as described in Task 3, or you want to move documents previously uploaded through Document service task flows to the target environment, move the Oracle WebCenter Content data, as described in Section 21.4.4.

In this procedure, you have a working target environment with Oracle WebCenter Portall installed and configured and you want to test changes in your applications or configuration before rolling those changes into the target environment.

Take the following steps:

To move changes to individual spaces or space templates to an existing target environment, refer to:

Note that in a target environment, Oracle WebCenter Content applications need to use an external Lightweight Directory Application Protocol (LDAP) authentication provider rather than the Oracle WebLogic Server embedded LDAP server, which is part of the default configuration. You reassociate the identity store for your application with one of the following external LDAP authentication providers before you complete the configuration of a Managed Server, before you connect a Managed Server to a repository, and before the first user logs in to the application:

For the Oracle WebCenter Content server or Oracle WebCenter Content: Records, you have two options for moving the component:

copy: This option copies the entire source system, including configuration and data, to the target system.

init: This option initializes a new Content Server or Records instance in the target system.

You specify the copy or init option in the move plan, in the MoveType configProperty, as described in Table 20-30. Then, you modify the properties listed in that configGroup.

If the Administration Server and the component servers (WebCenter Content server, Records server, and Inbound Refinery servers) are on separate hosts and the domain home is not on a shared disk, take the following steps:

Before you run the copyConfig script, create soft links for each of the following:

Admin_Server_domain_home/ucm/cs
to
Content_Server_domain_home/ucm/cs

Admin_Server_domain_home/ucm/urm
to
URM_Server_domain_home/ucm/urm

Admin_Server_domain_home/ucm/ibr
to
IBR_Server_domain_home/ucm/ibr

Check the value of IntradocDir in the following files to make sure that the path is mounted and accessible from the Administration Server host:

Note that in a high-availability setting where you have multiple WebCenter Content hosts, you can create the soft link to any WebCenter Content host.

If you are using the copy option and the IntradocDir is not a subdirectory of the Admin_Server_domain_home/ucm directory, take the following steps on the target system, before you run the pasteConfig script:

Mount the IntradocDir on the Administration Server host. Modify the move plan, specifying the path of the IntradocDir for WebCenter Content server, Records, and Inbound Refinery on the Administration Server host.

After you run the pasteConfig script, update the following file to specify the location of the IntradocDir on the WebCenter Content server host:

If you are using an Oracle Universal Content Management 10g repository, ensure that Full-Text is configured correctly on the target Oracle UCM system, if configured on the source Oracle Universal Content Management 10g system.

Note that if you are using an Oracle Universal Content Management 10g server, it is not configured when you move the Oracle WebCenter Content. you must install it, similar to the way you installed it in the source environment, using the procedures described in the Oracle Universal Content Management page at:

To move Oracle IRM, you need to modify some Oracle IRM settings in the new target environment:

Set up SSL. For Oracle IRM, SSL should be enabled so that Oracle IRM Desktop does not show prompts to accept certificates when it contacts the Managed Server. The certificate used must be trusted by Microsoft Internet Explorer on computers running Oracle IRM Desktop. Follow the standard SSL setup instructions for Oracle WebLogic Server, as described in "Configuring SSL" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

Each Oracle IRM installation requires access to a keystore with installation specific keys. The unpacked domain may have a keystore. If it does and if the Content Tracker component is enabled and being used in their source environment., delete this keystore, clear the passwords details, and create a new keystore:

Delete the keystore file. By default, the keystore is located in the following directory:

DOMAIN_HOME/config/fmwconfig

By default, the file name is irm.jks. It may be named differently or use a different type, depending on the template used.

Keystore passwords are stored in the credential store. If passwords have been set in the template domain, clear the passwords using the following WLST commands:

If you selected init in the move plan, on the Oracle WebCenter Content Post Configuration page, choose External Full Text Search, and enter the name of the data source. See "Configuring Oracle SES and Oracle UCM" in the Oracle WebCenter Content System Administrator's Guide for Content Server.

If you configured the IntradocDir, WeblayoutDir, VaultDir, and UserProfilesDir directories to be outside of the domain structure, copy the directories to the target environment.

Restart the Administration Server and the Managed Server, as described in Section 4.2.

Note that when you use the copy mode with Oracle WebCenter Content, Imaging data is moved. However, if you have created instances within SOA, those instances are not moved, because the Oracle SOA Suite procedures do not move this data.

Before you begin this procedure, if you use Workflow Integration or Oracle Application Extension Framework (AXF), make sure that you have:

Installed and configured Oracle SOA Suite and moved its source environment to the target environment, as described in Section 21.4.2.1.

To complete the movement of Oracle WebCenter Content: Inbound Refinery to a new target environment:

If you configured the IntradocDir, WeblayoutDir, VaultDir, and UserProfilesDir directories to be outside of the domain structure, copy the directories to the target environment.

If you have set up third-party software to convert certain types of content, additional steps may be required. The third-party software could include FlipFactory to convert video, Microsoft Office to perform native conversion for Office documents, or Adobe Distiller to convert PDF files. If you have installed this software, note the following:

You must install the software on the target system.

Oracle recommends that you install the third-party software and fonts at the exact same absolute path on the target system as they are on the source system. This ensures that Inbound Refinery is properly configured at the start up of the target system.

If you do not install the third-party software and fonts at the exact same absolute path, you must perform the same manual steps to configure the software on the target system as you did on the source system.

Do not submit any jobs that require the software before you complete the configuration. Otherwise, the conversion will fail.

Organizations that run a proof of concept or pilot (source) deployment can copy the operational service into the target environment and continue to use all existing source content, contexts, and rights.

The IRM server URL (for example protocol_schema:\\hostname:port\irm_desktop) is sealed into source content. Therefore, this value must not change on moving from source to target. For this reason, make sure you consider the following points when installing the source deployment:

Configure SSL in the source deployment because switching from the HTTP protocol in the source environment to the HTTPS protocol in the target environment would prevent source-sealed content from working in the target environment.

Use a generic host name such as irm.example.com for the source deployment rather than a machine-specific host name such as mytestdeploymachine.example.com.

After the source to target installation has been completed, the DNS entries for domain name can be switched from the source server to the target environment. If needed, you can use port redirection to ensure that the source deployment IRM Server URL points to the target environment deployment.

To move the source deployment into the target environment:

If the target database is different from the source database, you should back up the Oracle IRM schema. Restore the backup into the target database.

Copy the Oracle IRM keystore set up during the source installation to the target environment. This is typically called irm.jks. This file is usually located in the following directory:

DOMAIN_HOME/config/fmwconfig

The Oracle IRM Java EE application needs a password for the keystore copied in the previous step and each key stored in that keystore. If the passwords are not specified, the Oracle IRM Java EE application will not be able to retrieve the keys.

To switch to using more secure passwords than those used in the source environment, use the keytool command line to change the passwords before proceeding. See the keytool Help for syntax.

With secure passwords in place, use WLST commands to specify these passwords to the Oracle IRM Java EE application. The following example connects to an Administration Server and sets the keystore credentials:

Copy the Oracle IRM configuration file, irm-config.xml, which is usually located in the following directory, from the source environment to the target environment:

DOMAIN_HOME/config/fmwconfig

Because the source environment configuration may contain source-specific settings, you should review the contents of the file. You can use Fusion Middleware Control, WLST, or you can edit the configuration file, irm-config.xml. To use Fusion Middleware Control, expand the navigation tree and click IRM. From the IRM menu, choose Administration, then General Settings. The following settings may need to be changed:

Privacy URL: A URL to a page hosting the Oracle IRM usage privacy policy for the installation. There is no default value, so typically you do not need to alter this setting after unpacking a domain. The default behavior is to show the built-in privacy page.

Status Page Redirection: An optional URL to a page hosting alternative Oracle IRM Desktop status pages. There is no default value, so typically you do not need to alter this setting after a domain is unpacked. The default behavior is to use the built-in status pages.

Keystore location: The path should reflect the location of the restored source environment keystore. The following is the suggested location of the file:

Select the Configuration Templates option from the Migration Options or from the top menu on any Migration screen.

From Actions, select Create New Template.

For Server Config, select SearchIndexEngineName.

For Content Metadata, select the text fields that you want to export.

For Content Profile Rules, select the rules that you want to export.

For Personalization Data, select the profiles that you want to export.

From Action, select Save.

From Action, select Export.

Click Configuration Bundles.

On the Configuration Bundles page, select the bundle you created when you exported the data. Then, from Action, select Download.

If you are using Records Manager for UCM and you want to perform incremental migrations from the source environment to the target environment, export archives from the source environment and then import them into the target environment, as described in "Managing Imports and Exports" in the Oracle WebCenter Content Administrator's Guide for Records.

When you import a definition from the source environment to the existing target environment and the definition has the same name as an existing definition, the original definition is overwritten. The following rules apply to importing existing definitions:

If an application deletes a field, it is not imported if the any of the existing search or input definitions refer to the deleted field.

If a search or input definition references a field that is not in the currently defined in the application, the definition is not imported.

You cannot delete definitions through the export and import process. If you delete a search in the source environment, you must manually delete it in the target environment using the Manage Search functions.

You cannot import an input definition if there is an existing definition with the same name and that input definition is online. To import the definition, you must first place the definition offline:

On the target environment, open the Managed Inputs folder and select the input that you want to import.

To move Oracle Hyperion Calculation Manager from the source environment to the target environment, do one of the following:

Back up the repository

Since the Calculation Manager schema does not change, you can use the same repository with the new Calculation Manager environment. All pre-existing Calculation Manager objects and other related information are available in the new environment.

Export/import allocation rules and rule sets

Export Calculation Manager rules and rule sets from the source environment (in Calculation Manager, select File, and then Export) and then import them back into the target environment (in Calculation Manager, select File, and then Import).

Notes:

Use only one (not both) of the above options to move from the source environment to the target environment. Use the option that makes the most sense for your environment. The export/import option is simpler; however, backing up the repository saves more information in the database.

Rules that have already been deployed to Fusion GL and have since been modified in Calculation Manager will not be handled by Calculation Manager. (Calculation Manager does not keep versions of rules).

Log in to the target environment and select File, then Import, and then Financial Reporting.

Browse to the target location where you want to import the Financial Reporting report content, and select the local file to which you saved the exported content.

Note:

Oracle Hyperion Financial Reporting annotations and scheduler output cannot be migrated from the source environment to the target environment.

Task 5 Move Oracle Hyperion Provider Services to a Target Environment

Oracle Hyperion Provider Services artifacts need to be copied from source environment to the target environment.

To move Provider services when it is used by Smart View:

Use the Smart View client to manually add any Oracle Essbase servers created in the source server to the target server.

Copy the following file to the target environment:

ORACLE_INSTANCE/products/Essbase/aps/bin/essbase.properties

From Smart View, re-create any Cube views created under the source environment in the target environment.

To move Provider Services when it is used by the Oracle Essbase Java API:

If the default Java API preferences are changed in the essbase.properties file on the Java API client program configuration, then copy essbase.properties to the target environment.

Task 6 Move Oracle Hyperion Smart View to a Target Environment

Because Oracle Hyperion Smart View for Office is a client side application, spreadsheets and other Microsoft Office documents created with source servers must be associated with target server connections. You can point an existing report from source to target if the metadata remains the same.

To associate shared connections:

Open the existing report.

The location of existing reports depends on where you stored the reports when you first created them.

In Excel with Smart View installed, select Smart View, then Options, and then Advanced.

Change the Shared Connections URL to the new connection URL; for example:

https://host.example.com/workspace/SmartViewProviders

Select Smart View, then Open, then Smart View Panel, then Shared Connections, and do one of the following:

If Essbase Server is not listed, click Create New Connection.

If Essbase Server is listed, enter the user name and password, and click Connect.

From the drop-down list, select Essbase Server.

From the drop-down list, select Locate worksheet connection.

The connection is created under cube.

Select the connection and right-click to connect.

Click Refresh.

For ad-hoc analysis, you need to connect to a new server and choose to maintain POV. To do this, select Reuse sheet contents and POV when prompted.

Associate the connection (SVC, then Open, and then Active Connection) and select the connection. Click OK to confirm the message.

Click Refresh.

For ad-hoc analysis, you need to connect to a new server and choose to maintain POV. Select Reuse sheet contents and POV when prompted.

Task 7 Move Oracle EPM Workspace to a Target Environment

When you move Oracle Enterprise Performance Management Workspace information from the source environment to the target environment, the system settings and user preferences must be manually migrated. Any changes to server settings and user preferences must be made in the target system. See "Administering EPM Workspace" in the Oracle Enterprise Performance Management Workspace, Fusion Edition Administrator's Guide.

21.4.6 Moving the Web Tier to a Target Environment

In this procedure, you have installed Oracle HTTP Server and Oracle Web Cache in the source environment and you want to move them to the target environment.

The following topics describe how to move the Web tier from the source environment to the target environment:

21.4.6.1.1 Moving Oracle HTTP Server to a New Target Environment

In this procedure, you have installed Oracle HTTP Server in the source environment and you want to move it to the target environment, which does not yet exist. In the source environment, you have:

Installed Oracle HTTP Server.

Created an Oracle instance and one or more Oracle HTTP Server component instances.

Registered the Oracle instance and the Oracle HTTP Server component instances, with an existing JRF-enabled Oracle WebLogic Server Administration Server if you want to manage the components with Fusion Middleware Control.

Configured mod_wl_ohs to route requests to one or more virtual hosts.

Configured SSL for one or more virtual hosts.

Configured Oracle Single Sign-On.

Configured mod_plsql.

Configured mod_oradav.

In addition, you may be using Oracle Access Manager. In this procedure, the Oracle Access Manager Access Servers are not in the source environment. They reside on a separate target environment. However, WebGate is running in the source environment.

To move this environment to a new target environment, perform the following tasks:

If Oracle HTTP Server is used by WebGate, you must first move Oracle Access Manager to the target environment, as described in Section 21.4.1, Task 6 or Task 7, depending on your version of Oracle Access Manager.

Note the following:

The WebGateInstalldir property and references to this path are updated in the webgate.conf file.

The WebGate directory must be in the following directory:

Oracle_Instance/config/OHS/ohs_component_name

Task 2 Move the Middleware Home and Perform the Initial Configuration

To move the Middleware home and perform the initial configuration:

Move the Middleware home and binary files, as described in Section 21.3.4.

Move the configuration. You can choose to:

Move the Oracle instance and all of the components in that particular Oracle Instance, as described in Section 21.3.6.1.

Move the Oracle instance and only one component in that particular Oracle instance, as described in Section 21.3.6.2.

This step moves the configuration. In addition, it:

Updates the Listen address and the name of the virtual host.

Configures SSL, if it was configured in the source environment.

Updates the httpd.conf file with new values for the environment and topology directives, such as host name and IP address.

Updates the WebLogicHost, WebLogicPort, or WebLogicCluster directives in the mod_wl_ohs.conf file with the host name, IP address, and port number for the target environment.

Configures SSL for mod_wl_ohs, if SSL is configured for mod_wl_ohs.

Configures mod_osso, if it was configured in the source environment.

Configures PL/SQL, if it was configured in the source environment.

Configures mod_osso, if it was configured in the source environment.

Updates audit.config.xml, if any changes were made to it in the source environment.

Updates component-log.xml, if any changes were made to it in the source environment.

21.4.6.1.2 Moving Oracle Web Cache to a New Target Environment

In this procedure, you have installed Oracle Web Cache in the source environment and you want to move it to the target environment, which does not yet exist. In the source environment, you have:

Installed Oracle Web Cache.

Configured two or more Oracle instances, each containing an Oracle Web Cache instance.

Registered the Oracle instances and the Oracle Web Cache instances with an existing JRF-enabled Oracle WebLogic Server Administration Server, if you want to manage the components with Fusion Middleware Control.

If you have already moved the entire Oracle instance, as described in Section 21.3.6.1, any Oracle Web Cache instance is already moved. For example, if you moved Oracle HTTP Server, and chose to move the entire Oracle instance and that Oracle instance contains Oracle Web Cache, Oracle Web Cache is moved along with Oracle HTTP Server.

If the Web Cache Administration password at the target environment is different from the password at the source environment:

Copy the value of the PASSWORDHASH attribute of the <USER TYPE="INVALIDATION"> element from the webcache.xml file for the target environment Web Cache instance and replace the current value of the corresponding PASSWORDHASH attribute in this temporary webcache.xml.

Copy the value of the PASSWORDHASH attributes of the <USER TYPE="MONITORING"> element from the webcache.xml file for the target environment Web Cache instance and replace the current value of the corresponding PASSWORDHASH attribute in this temporary webcache.xml.

Update the NAME and PORT attributes of each <HOST> and <VIRTUALHOSTMAP> elements with the new host name or IP address and port number of the origin servers at the target environment.

For each <CACHE> element in webcache.xml, change the following, substituting the values that correspond to the host where the target environment Oracle Web Cache instance is located:

Update the NAME, ORACLE_HOME and HOSTNAME attributes.

Search for and replace the Oracle instance path.

Note: Update this information on one Oracle Web Cache instance at a time. Do not do a global search and replace, because other Oracle Web Cache instances might be configured in a different Oracle instance running at a different path.

For each <LISTEN> element, update IPADDR (if it is configured other than ANY) and PORT (if Oracle Web Cache uses different ports at the target environment).

Update the wallet location (if different) for a SSL-enabled listen address. The wallet location is specified within the <WALLET> element for each SSL listen port.

Update the USERID and GROUPID attributes of the <IDENTITY> element.

In the <OSWALLET> element, update the wallet location (if different on the target environment) for the original servers. This is the wallet used by Oracle Web Cache to talk to an SSL-enabled origin server).

Copy the edited webcache.xml to the following location on the target environment:

If a non-default wallet was used at the source environment for either an SSL-enabled listen address or an OSwallet, or both, export the wallets from the source environment and import them at the target environment. For information about exporting and importing wallets, see Section 8.4.4.

21.4.6.2 Moving the Web Tier to an Existing Target Environment

In this procedure, you have a working target environment and want to test changes in your applications or configuration before rolling those changes into the target environment.

To move Oracle HTTP Server to an existing target environment, you update the configuration:

Copy any custom contents, such as contents that have been changed or added to the htdocs directory, to the target environment Oracle HTTP Server.

If any changes have been made to auditconfig.xml, which is located in the following directory, make a backup copy of the file in the target environment. Then, copy auditconfig.xml from the source environment to the corresponding target environment:

ORACLE_INSTANCE/config/OHS/ohs_component_name/auditconfig.xml

If any changes have been made to component-log.xml, make a backup copy of the file in the target environment. Then, copy the file, which is located in the following directory, from the source environment to the target environment:

ORACLE_INSTANCE/diagnostics/logs/OHS/ohs_component_name

21.4.7 Moving Oracle Business Intelligence to a Target Environment

This section describes the steps for moving Oracle Business Intelligence from the source environment to the target environment.

The following procedures assume that you have already installed and configured Oracle Business Intelligence components in the source environment and that you want to move them to either a new or an existing target environment:

If you are applying patches to an existing target environment, the steps you take depend on how many patches you need to apply. If there are few patches, you use the steps in Section 21.4.7.2, which apply the patches to the master host and all cluster hosts in the environment. If there are many patches to apply, consider using the steps in Section 21.4.7.3, which apply the patches to one host and use different means to propagate that to the other hosts, depending on whether or not new hardware is available.

21.4.7.1 Moving Oracle Business Intelligence to a New Target Environment

This section describes the steps for moving Oracle Business Intelligence from the source environment to a new target environment.

This procedure assumes that you have already installed and configured Oracle Business Intelligence components in the source environment and that you have patched the source environment, if necessary, and tested the environment. You want to move them to a new target environment.

To move Oracle Business Intelligence components to a new target environment, perform the following tasks:

For information about migrating security data (for example, users, groups, and roles), see the appropriate documentation for your authentication provider. The following list provides sources for various components:

Edit the move plan, modifying the properties to reflect the values for the target environment. See Table 20-25 for the properties to change.

Note that for Oracle Essbase, you must specify valid file locations, disk volume customization locations, and the Oracle Essbase administration user name and password. Otherwise, you will receive an error.

Copy the edited move plan to the target. (During the pasteConfig operation, you specify the location using the -movePlanLoc option.)

At the target, extract the files from the archive using the pasteConfig script.

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.

Because Oracle BI Publisher reports are stored in the Oracle BI Presentation Catalog, existing reports and new reports that are created in the source environment should be available.

In a target environment, Oracle WebLogic Server administrators should create JNDI connections (to be used by Oracle BI Publisher reports), using the same names as in the source environment. The connections should point to the target databases instead of the source databases. In this way, all reports automatically point to the target environment databases, instead of source environment databases, without any modification.

Task 7 Update Links to External Systems

To ensure that you move the static content that relates to external systems to the target environment, edit the Action Framework configuration file and ensure that the endpoints refer to relevant resources in the target system.

Move Oracle Business Intelligence related applications (such as Calculation Manager, Financial Reporting, and Oracle BI for Microsoft Office) to the new target environment. For information, see Section 21.4.5.

21.4.7.2 Moving Oracle Business Intelligence to an Existing Target Environment When There Are Few Patches to Apply

This section describes the steps for moving Oracle Business Intelligence from the source environment to an existing target environment when there are few patches to apply. (See Section 21.4.7.3 if you have many patches to apply).

The following steps assume that you have already installed and configured Oracle Business Intelligence components in the source environment and that you want to move them to an existing target environment.

To move Oracle Business Intelligence components to an existing target environment when there are few patches to apply, perform the following tasks:

If necessary, use the Administration Tool or the Oracle BI Server XML API to update connection pool and database settings in the repository. The RPD file might contain data source connection information from the source environment that must be changed to the target environment connection settings.

See "Moving from Test to Production Environments" in the Oracle Fusion Middleware XML Schema Reference for Oracle Business Intelligence Enterprise Edition for information about performing this step using the Oracle BI Server XML API.

You do not normally refresh GUIDs in the LDAP directory (identity store users) between source and target environments, because the LDAP directories that contain the GUIDs should be fan-out replicas in both the source and the target environments. Possible scenarios for refreshing are described in the following list:

Oracle Business Intelligence source servers and target servers are both configured against the corporate LDAP directory.

There is no need to refresh LDAP GUIDs.

Oracle Business Intelligence source servers are configured against a source LDAP and the target servers against the corporate LDAP, but the source LDAP is a fan-out replica of the corporate LDAP directory.

There is no need to refresh LDAP GUIDs.

Oracle Business Intelligence 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. Follow the procedures in this section.

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.

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.

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

Modify the instanceconfig.xml file to instruct Presentation Services to refresh GUIDs on restart. Edit the file and find the following section:

<Catalog>
<UpgradeAndExit>false</UpgradeAndExit>
</Catalog>

Comment out the <UpgradeAndExit> element and add an <UpdateAccountGUIDs> element in the same section, as shown in the following example:

If new agents were created in the source environment, then click each agent in the Oracle BI Presentation Services Catalog Manager (in the target environment) to enable it.

Because Oracle BI Publisher reports are stored in the Oracle BI Presentation Catalog, existing reports and new reports created in the source environment should be available.

In the target environment, Oracle WebLogic Server administrators should create JNDI connections (to be used by Oracle BI Publisher reports), using the same names as in the source environment. The connections should point to the target databases instead of the source databases. In this way, all reports automatically point to the target environment databases, instead of source environment databases, without any modification.

Task 6 Update Links to External Systems

Ensure that you move the static content that relates to external systems to the target environment, as described in the following steps:

Copy the Action Framework configuration file from its location on the source system to the same location on the target system. In addition, the ActionFramework configuration file might contain policy elements that refer to files in the same directory as the configuration file. Copy these files to the same location on the target system.

Edit the Action Framework configuration file and ensure that the endpoints refer to relevant resources in the target system.

21.4.7.3 Moving Oracle Business Intelligence Components to an Existing Target Environment When There are Many Patches to Apply

This section describes the steps for moving Oracle Business Intelligence from the source environment to an existing target environment when there are many patches to apply.

The following procedures assume that you have already installed and configured Oracle Business Intelligence components in the source environment and that you want to move them to an existing target environment.

Use one of the following strategies to move Oracle Business Intelligence components to an existing target environment when there are many patches to apply:

These steps include merging the new source RPD file and catalog with those in the existing target environment. Ideally you merge once and resolve the issues while users continue using the existing environment. When the files are correct, you lock the target environment and repeat the merge to access the latest changes.

Task 2 Switch Users from the Existing Target Environment to the New One

Use a load balancer such as Oracle Web Cache to redirect users from a standard URL to the new target environment.

Task 3 Remove the Existing Target Environment and Prepare It for the Next Patch

Shut down the existing environment and deinstall all software. When needed, you can apply the next patchset to this host, and the sequence can start all over again.

21.4.7.3.2 Moving Oracle BI EE to an Existing Target Environment When New Hardware Is Not Available

Perform the following tasks to move Oracle Business Intelligence components to an existing target environment when there are many patches to apply and new hardware is not available:

Use the Capacity Management tab of the Scalability page in Fusion Middleware Control in the target environment to scale back system components to apply only to the first host in the list. This scaling makes it much easier to patch the existing target environment.

For more information, see the Fusion Middleware Control Help system.

Task 2 Patch the Host in the Target Environment

Patch the host in the target environment. Doing so imposes less downtime on users than having to patch multiple cluster hosts.

To move the database, Middleware home, and Oracle RTD software and perform the initial configuration:

Move or create the database and the required schemas, as described in Section 21.3.1.

Move the a copy of the Middleware home and binary files, as described in Section 21.4.1.

If your environment includes Oracle BI EE and you have already moved Oracle BI EE to a new target environment, as described in Section 21.4.7.1, you do not need to take this step because the binary files for Oracle RTD were moved as well those for Oracle BI EE.

Prior to moving an Inline Service, if changes have been made to the Inline Service used by the Oracle RTD server, for example, through the Decision Center, you should first download the latest Inline Service version to Decision Studio before redeploying to the production environment.

When moving Inline Services from one environment to another, note the following areas that may also need editing within the Inline Service:

Calls to third party APIs and third party JAR files.

Any addition of new jar files must be put into the corresponding location in the new environment.

Calls to third party web services.

Location paths, web service parameters, and so on, if different in the new environment, need to be modified.

References to custom tables, such as location, user names, and passwords, within the Inline Service, if different in the production environment, must be edited before redeploying.

References to the data sources, if different in the target environment, should be edited before deploying. This includes modifying the data sources for dynamic choices, if used.

References to any debugging code (logInfo statements, logTrace statements, and so on) that may not be desired in the new environment should be commented out or removed in the Inline Service before redeploying.

For Inline Services that include external objects, such as dynamic choices or external rules, the following considerations apply:

For dynamic choices:

If dynamic choices are part of the Inline Service configuration, you must re-create both the data and the tables that store the dynamic choices, if the source and target environment do not share the same source.

Data source elements in the Inline Service also need to be modified as appropriate.

For external rules:

If external rules are part of the Inline Service configuration, you must re-create both the data and the tables that store the rule data if the source and target environment do not share the same source.

Data source elements in the Inline Service need to be modified as appropriate.

In addition, the external rule editor used in the target environment should be configured to point to the target database.

Task 4 Edit Additional Oracle RTD Components for the Target

Additional tasks that you may need to perform with Oracle RTD include the following:

Creating and configuring the model snapshot tables:

You can create the Oracle RTD model snapshot tables in the target environment in two ways: using RCU or the tool sdexec/SDDBTool, which is provided with the installation.

RCU creates the necessary snapshot tables in the same schema as the Oracle RTD platform tables, while sdexec/SDDBTool allows you to create the tables in another location.

After the model snapshot tables are created, use the Enterprise Manager console to configure the settings needed to populate the tables. For details, see the chapter "Setting Up and Using Model Snapshots" in the Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

Modifying the loadgen files.

If you have created loadgen files that will also be used in the target environment, you must modify the following parameters according to the new environment (each must be modified within the specific loadgen configuration file):

ClientHttpEndpoints.properties files

Inline Service name (if changed)

Path references to data files if used as inputs to a loadgen script

Path to the loadgen log file

Modifying batch processing files.

If using the RTD Batch module, you should also pay attention to any data sources referenced in the batch files that are environment specific and modify the files accordingly.

Because each specific patch addresses unique functional enhancements and known bugs, you should always refer to the release notes that come with each patch for specific instructions on how to apply it.

Task 2 Update Inline Services

For incremental Inline Service changes, moving the Inline Service to the target follows the same steps as outlined for a moving the full product source environment to the target environment.

Task 3 Update Data Sources

If additional data sources are to be added incrementally to an Inline Service, refer to the "Configuring Data Access" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

In these procedures, you have installed Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle Business Intelligence Discoverer in the source environment and you want to move them to the target environment.

The following topics describe how to move these components from the source environment to the target environment:

In this procedure, you have installed Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle Business Intelligence Discoverer in the source environment and you want to move the components to the target environment that does not exist.

Although this section describes how to move all of the components to the target environment, you can choose to move only some of them.

To move this environment to a new target environment, perform the following tasks:

Copy the Oracle Forms Services application files (fmx, mmx, obx and plx) from the source environment to the target environment. The location of the files may be specified in the Forms environment configuration file, default.env.

Note that if the files are in a shared network location, you do not need to copy them to the target environment. Make sure the network path exists and is accessible in the target environment.

Move the application-related data from the source environment to a database in the target environment using database migration tools.

If you had overridden the default context root or Forms servlet alias in the source environment, copy the customized Forms EE application ear file to the target environment and redeploy it. Refer to "Using Oracle Forms Services with the HTTP Listener and Oracle WebLogic Server" of the Oracle Fusion Middleware Forms Services Deployment Guide for details on custom deployment of the Forms Java EE application.

Task 4 Move Oracle Reports to the New Target Environment

To move Oracle Reports to the target environment:

For the following Oracle Reports Server configuration files, merge changes made from the source environment to the target environment files. Note that you cannot just copy the files from the source environment to the target environment, because they may have environment-specific information such as Oracle home and Oracle instance names or locations and port numbers.

For the following Oracle Fusion Middleware configuration files, which are related to Oracle Reports Server configuration files, merge changes made from the source environment to the target environment files. Note that you cannot just copy the files from the source environment to the target environment, because they may have environment-specific information such as Oracle home and Oracle instance names or locations and port numbers.

Move Reports-specific data tables that are referred to in the RDF files to the database in the target environment using database migration tools, such as the Oracle Database export and import utilities.

For Reports job-related configuration files, take the following actions:

Copy Reports Server cache files to the following location in the target environment:

ORACLE_INSTANCE/reports/cache

For Reports scheduled job information, copy the server data (server_name.dat) file to the following location in target environment:

ORACLE_INSTANCE/reports/server

Note that because the server name is generated automatically when it is created and the .dat file is named with the server name, the name of the .dat file differs between the source environment and the target environment. Depending on whether it is a standalone server or an in-process server, the name takes one of the following forms:

Change the name of the file to reflect the host name and Oracle instance name in the target environment.

If the job repository or job status repository is configured in the database, you must create the same schemas in the target environment database and move the data:

Use the following script:

ORACLE_HOME/reports/admin/sql/rw_job_repos.sql

Move any data from the source database for the schemas RW_JOBS, RW_SERVER_JOB_QUEUE, and RW_SERVER_QUEUE to target database using database migration tools, such as the Oracle Database export and import utilities.

If you used JAZN-XML-based identity and policy store in the source environment, move them to the LDAP in the target environment. You can use the WLST command migrateSecurityStore, as described in "Migrating Policies with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.

Migrate the credential store, using the script migrateSecurityStore, as described in "Migrating Credentials Manually" in the Oracle Fusion Middleware Application Security Guide.

Move any database proxy users to the target database using database cloning tools.

If any Reports plug-ins are registered, copy the corresponding .jar files to the target environment and add the path to the files to the environment variable REPORTS_CLASSPATH.

Task 5 Move Oracle Business Intelligence Discoverer to the New Target Environment

To move Oracle BI Discoverer to the new target environment:

If you have modified the default user preferences, copy the following files from the source environment to the target environment:

Move the EUL schema from the source database by using the Discoverer Administrator to export the schema from the source database and import it into the database in the target environment. For more information, see "About Using the Discoverer Export Wizard and Import Wizard" in the Oracle Fusion Middleware Administrator's Guide for Oracle Business Intelligence Discoverer.

Run the eul5_id.sql script to give the new EUL a unique reference number. Then, grant the entire Discoverer end user community access to the EUL. The script is located in:

Note that you may need to perform the import multiple times to ensure that parent tables are populated before child tables. Use the following order to avoid SQL errors: PTM5_PARTITION, PTM5_PORTLET, PTM5_VERSION, PTM5_INSTANCE, PTM5_SCHEDULE, PTM5_CACHE,PTM5_CUSTOMINFO.

Modify the Portlet Provider URL in the Portal to point to the new target setup.

Move PStore data:

Delete the default encryption key from the table WWSSO_PS_CONFIGURATION_INFO_T.

Move the PStore data for the Discoverer metadata repository using Oracle Database export and import utilities.

Note that the user names and schema names must be the same in the target environment as in the source environment.

In this procedure, you have installed Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle Business Intelligence Discoverer in the source environment and you want to move the components to the target environment that already exists.

To move to an existing target environment, perform the following tasks:

This procedure assumes that you have made changes to Oracle Portal in the source environment, such as adding pages, adding content to pages, creating new users and groups, and assigning page access permissions for newly created pages to new users and groups.

Copy the Oracle Forms Services application files (FMX, MMX, and PLX) from the source environment to the target environment. The location of the files may be specified in the Forms environment configuration file, default.env.

Note that if the files are in a shared network location, you do not need to copy them to the target environment. Instead, add the location to the default.env file.

Make any necessary configuration changes as described in "Deploying Your Application" in the Oracle Fusion Middleware Forms Services Deployment Guide.

Move the DISCOVERER schema from the source environment to the target environment. You can use the Oracle Database export and import utilities to move the schema.

Note that if you choose to use the same database for source and target, you do not need to move the data.

Move the EUL schema from the source environment to the target environment by using the Oracle database export and import utilities to export the schema from the source database and import it into the database in the target environment.

Note that the user names and schema names must be the same in the target environment as in the source environment.

21.4.10 Moving Oracle Data Integrator to a Target Environment

The following topics describe how to move Oracle Data Integrator from the source environment to the target environment:

Make sure that both the work and master repositories in the target environment are created with unique IDs across your entire organization, including your development and source repositories. Also make sure that the target work repository is created with the same type as the source repository (For example, if the source work repository is created as a development repository, the target work repository must also be created as a development repository).

Move the configuration of Oracle Data Integrator and its repository from the source environment to the target environment using the copyConfig and pasteConfig scripts, as described in Section 21.3.5.

When you run the copyConfig script, note the following:

You must pass a configuration file to the copyConfig script. You pass this using the -additionalParams option. For example:

The previous example shows the default location of the jps-config file. If you have a version of the file that you use to connect to ODI Studio, you can use the location of that file. Alternatively, you can use the jps-config file in the following location, but, in that case, you must configure the LDAP entries and uncomment the default section of the file:

ODI_DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml

Note that when you move the configuration, the pasteConfig script copies the configuration of the domain, including the Administration Server and Managed Servers.

Task 2 Review the Settings for the Target Environment

The movement scripts update the physical architecture in the target environment according to the information you specified in the move plan. Review the following items in the physical architecture in the target environment before proceeding:

In this procedure, you have a number of new or regenerated scenarios in the source environment and you want to move them to the target environment that already exists.

The movement scripts support repeated runs to the target environment. To overwrite the target environment with the latest source environment follow the process in Section 21.4.10.1, but take one of the following actions:

If the repository is in internal authentication mode, supply the supervisor password in move plan before running the pasteConfig script.

If the repository is in external authentication mode, change it to internal authentication mode and supply the supervisor password in move plan before running the pasteConfig script.

21.5 Considerations in Moving to and from Multihost Environments

The domain directory is local to each machine. The pasteConfig script is performed only on the Administration Server domain directory. Subsequently, if the Managed Servers are not in the same directory as the Administration Server, you must re-create the domain directory for those Managed Servers by using the Oracle WebLogic Server pack and unpack commands. Take the following steps:

21.6 Considerations in Moving to and from an Oracle RAC Environment

If you are moving your environment to or from an Oracle Real Application Cluster (Oracle RAC) environment, note the following:

If you are moving from a source environment that is not an Oracle RAC environment to a target environment that uses Oracle RAC, the move plan will have one entry for a generic data source (for example mds-soa.) You update the move plan to point to one of the Oracle RAC instances and complete the move from the source environment to the target environment.

Multi data sources are moved to the target environment, even though they are not listed in the move plan.

If you are moving from a source environment that uses Oracle RAC to a target environment that does not use Oracle RAC, the move plan will have multiple entries for generic data sources. For example, if you have four Oracle RAC instances, you will have four generic data sources that are named mds-soa-rac1 through mds-soa-rac4. You update the move plan to point all generic data sources to the single non-RAC instance in the target environment.

If you are moving from a source environment that uses Oracle RAC to a target environment that uses Oracle RAC, but you have more Oracle RAC instances in the target environment, the move plan will have multiple entries for generic data sources. For example, if you have three Oracle RAC instances on the source environment, you will have three generic data sources that are named mds-soa-rac1 through mds-soa-rac3. You have four Oracle RAC instances in the target environment. You update the move plan to point the generic data sources to the first three generic data sources in the target environment.

If you are moving from a source environment that uses Oracle RAC to a target environment that uses Oracle RAC, but you have fewer Oracle RAC instances in the target environment, the move plan will have multiple entries for generic data sources. For example, if you have four Oracle RAC instances on the source environment, you will have four generic data sources that are named mds-soa-rac1 through mds-soa-rac4. You have three Oracle RAC instances in the target environment. You update the move plan to point the first three generic data sources to the three generic data sources in the target environment. You point the last generic data source to the third generic data source. (The third Oracle RAC instance will contain both mds-soa-rac3 and mds-soa-rac4).

21.7 Limitations in Moving from Source to Target

Note the following limitations and restrictions:

The target environment must be on the same operating system as the source environment. Also, the operating system architecture must be the same in both environments. For example, both environments must be running 32-bit operating systems or 64-bit operating systems.

The target environment must have the same superuser or administrative user as the user at the source environment. The user's password can be different if you are using an external LDAP; you specify it on the command line when you use the pasteConfig script. After you complete the movement of the installation, you can modify the user on the target environment.

The source and the target environment must use the same encoding. For example, if the source environment uses the encoding ja_JP.utf8 locale and the target environment uses the encoding ja_JP locale, some file names may not be handled correctly in the target.

When you move the configuration of a component, the scripts replicate the topology of the source. For example, if the source domain contains Managed Servers server_1 and server_2 on Host A and Managed Servers server_3 and server_4 on Host B, you must specify a similar relationship between Managed Servers and hosts at the target. (You specify the hosts for each Managed Server in the move plan.)

All Oracle homes in the Middleware home must be registered in the same Oracle inventory. If you have installed multiple components under the same Middleware home, but used different Oracle inventory locations, the scripts are not able to detect all of the Oracle homes. See Section 21.3.1 to work around this issue.

If the source Oracle WebLogic Server machine is specified as unix-machineType in the config.xml file, the copyConfig script fails with the error CLONE-20408. To work around this problem:

Stop the Administration Server.

Change the machine type in the following file on the source environment:

DOMAIN_HOME/config/config.xml

In the following line in the file, remove xsi:type="unix-machineType":

If a custom application uses an internal data source (for example, the application was created and deployed with an internal data source using JDeveloper), the internal data source is not migrated during the pasteConfig operation.

To work around this, create an external data source in the domain, modify the application to use that data source, and deploy the application again.

If you are applying the archive of a Middleware home on a host that does not yet have Oracle Fusion Middleware installed, the host must have JDK 1.6.04 or higher installed. In addition, the PATH, CLASSPATH, and JAVA_HOME environment variables must point to the JDK.

If the source Middleware home uses a JDK that is external to the Middleware Home, the pasteBinary operation must also use an external JDK.

The JDK used in the source and target must be the same type. For example, if the source uses JRockit, the target must use JRockit.

If there is not enough space in the temporary directory when you are moving an entity, an error is returned, noting the space needed. To work around this problem, specify a different location for the temporary directory by using the T2P_JAVA_OPTIONS environment variable as described in Section 20.2.

When you use the pasteBinary script to move a Web Tier installation, you may receive the following error:

SEVERE : Jun 14, 2011 12:35:27 AM - SEVERE - CLONE-20901 Unable to restorepermission of a few files of the Oracle home

You can ignore this message, because the files are not needed.

If you have moved your environment and executed the pasteBinary script using a custom inventory location (using the invPtrLoc parameter) and you want to upgrade the target environment, you must invoke runInstaller with one of the following arguments:

Oracle does not support the movement of Oracle Identity Manager, either through the movement scripts or manual steps. In addition, if Oracle Identity Manager is part of the source environment of other components, the movement scripts for that environment will fail.

21.8 Recovering from Test to Production Errors

When you execute the pasteBinary or pasteConfig scripts and enter incorrect information in the move plan, the scripts return an error. In some cases, the scripts may have partially completed the paste operation. To recover, take the following actions, depending on the script that returned the error:

On Windows if you are using the Sun JDK, the copyBinary, pasteBinary, copyConfig, or pasteConfig operations may fail with the following error:

java.nio.channels.OverlappingFileLockException

In this case, use the T2P_JAVA_OPTIONS to set the system property sun.nio.ch.disableSystemWideOverlappingFileLockCheck as shown in the following example:

set T2P_JAVA_OPTIONS=
-Dsun.nio.ch.disableSystemWideOverlappingFileLockCheck=true

Then, retry the operation.

If the pasteBinary script returns an error while moving the Middleware home directory at the target:

Delete the target Middleware home.

Remove the Oracle home entry from the Oracle inventory, if it is present.

For Windows, remove the shortcut for the Middleware home and Oracle home.

The copyConfig script requires that all servers be running, but that they are idle, so that no directories are being modified. If a server is not idle, the copyConfig script reports that the cloning operation completed successfully and the copyConfig error log file will remain at 0 bytes. However, the copyConfig standard log file will contain an error regarding writing to the packed_domain.jar. That error will cause the pasteConfig process to fail.

To work around this issue, wait for a short period of time, then retry the copyConfig operation again.

If the pasteConfig script returns an error while moving Java components:

For an LDAP store, delete the domain node or specify a different value in the move plan.

For a database-based store, drop the schema and re-create it using RCU.

If the pasteConfig script returns an error while moving system components:

Deinstall the instance.

If you cannot deinstall the instance, stop all processes related to that instance and delete the Oracle instance.

If the machine is specified as unix-machineType in the config.xml file, the pasteConfig script fails with the error CLONE-20408. To work around this problem, change the machine type in the following file:

DOMAIN_HOME/config/config.xml

In the following line in the file, remove xsi:type="unix-machineType":

<machine xsi:type="unix-machineType">
<name>machine_name</name>

For example:

<machine>
<name>machine_name</name>

If you encounter an out-of-memory error when you are using the pasteConfig script, you can work around this in one of the following ways:

Increase the JVM heap size: Use the option -Xmx for maximum heap size, and -Xms for initial heap size. For example:

CONFIG_JVM_ARGS="-Xms512m -Xmx1024m"

Often, the Oracle WebLogic Server domain directory structure contains some large, unnecessary files, such as large older log files. You can delete these files, then run the copyConfig and pasteConfig scripts again.

If you encounter the following error when you are using the copyConfig script for a Oracle SOA Suite installation, use the T2P_JAVA_OPTIONS environment variable to increase the message size:

In this situation, after the failure, kill the Managed Server process and manually restart the Managed Server.

If you receive an error when you attempt to start the Oracle SOA Suite Managed Server, you must modify system parameters using the Administration Console after you run the pasteConfig script. (Note that the pasteConfig script sets these system parameters with temporary values.)

On Windows, at the source Middleware home, stop the Administration Server and any Managed Servers running in the Middleware home. (On UNIX, you do not need to stop the servers.)

At the source Middleware home, execute the copyBinary script, which copies the WebLogic Server home and the Oracle homes contained within the Middleware home. If there are no Oracle homes in the source Middleware home, no Oracle homes are present in the archive.

For example, to copy a Middleware home that is located at /scratch/Oracle /Middleware1, use the following command:

The Middleware home is extracted to /scratch/oracle/MW_Home_prod and the WebLogic Server home and all of the Oracle homes are extracted under it with the same names as that of the source Oracle home names.

If you used a custom inventory location (using the invPtrLoc parameter) in the pasteBinary script, you must run the following script as root: at the end of pasteBinary operation.

ORACLE_HOME/oracleRoot.sh

Task 2 Move the Domain Configuration

To move a copy of the domain configuration and Node Manager configuration:

At the source Middleware home, make sure that the Administration Server and all Managed Servers are started.

At the source, execute the copyConfig script to copy the domain configuration.

For example, edit the host and port numbers for all properties, updating the properties with the correct values for the target environment.

Edit the adapters deployment plan files, which are located in the following directory:

move_plan_dir/adapters

(The location is specified in the move plan, under the configGroup Adapter.)

If you only have the Fusion Order Demo configured, the files are:

FileAdapter_plan.xml

JmsAdapter_plan.xml

OracleBamAdapter_plan.xml

If you updated other adapters, those files will be located in the adapter directory.

For each file, edit the <config-root> element to specify the location of the adapters configuration plan on the target. For example, modify the following line to specify the location of the adapters configuration plan files on the target.

Edit the Composites configuration plan files, which are located in the following directory:

move_plan_dir/composites

The location is specified in the move plan, under the configProperty Config Plan Location. For more information about Composites configuration plan files, see "Introduction to a Configuration Plan File" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

The files are:

B2BX12OrderGateway_1.0_soaFusionOrderDemo.xml

In this file, update the host and Managed Server port in the URLs in the location attribute to specify the values for the target. For example:

Copy the edited move plan, adapters deployment plan files, and the Composites configuration plan files to the target. (During the pasteConfig operation, you specify the location of the move plan using the -movePlanLoc option.)

At the target, extract the files from the archive using the pasteConfig script, which is described in Section 20.2.1.8. The pasteConfig scripts creates the domain and deploys all the configurations and composites.

For example, to apply the archive to the Middleware home /scratch/Oracle/Middleware1, use the following command:

You must explicitly deploy theOracle B2B agreements. (See "Deploying an Agreement" in the Oracle Fusion Middleware User's Guide for Oracle B2B for more information.)

To deploy the Oracle B2B agreements and enable the listening channel:

Log in to the Oracle B2B console, by entering the following URL, and providing the user name and password:

http://host:8001/b2bconsole

Deploy the Oracle B2B agreements

Select the Administration tab, then the Deploy tab.

Use the search parameters to find the agreement you want to deploy and click Search.

Highlight one or more agreements and click Deploy.

Enable the listening channel:

Select the Administration tab, then the Listening Channel tab, and then the Channel Attributes tab.

Select the channel and click Enable.

Task 4 Validate the Fusion Order Demo

To validate the Fusion Order Demo:

For more information about running Fusion Order Demo, see "Running Fusion Order Demo" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

Access the Store Front from the following URL:

http://hostname:port/StoreFrontModule/faces/home.jspx

In the example, hostname is the DNS name or IP address of the Oracle WebLogic Server for Oracle SOA Suite and port is the address of the port, for example, port 8001, on which the Store Front module is deployed.

You begin the order process by browsing the product catalog. When you click Add next to a product, the site updates the shopping cart region to display the item.

Begin the order process by browsing the product catalog. Click Add under the Tre 650 Phone/PDA for $299.99.

Click Checkout and log in using ngreenbe and welcome1 in the Username and Password fields.

Provide the shipping and invoice details.

Click Logout.

Scripting on this page enhances content navigation, but does not change the content in any way.