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.
This chapter includes the following topics:
Overview of Procedures for Moving from a Source to a Target Environment
Considerations in Moving to and from an Oracle RAC Environment
Note:
The procedures in this chapter for Oracle WebCenter Portal and Oracle WebCenter Content are valid for Release 11.1.1.8. For all other components, the procedures are valid for Release 11.1.1.7.
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.
This section describes the general steps in moving installations from a source environment to a target environment.
The general steps are:
Prepare your source environment. See Section 21.3.1.
Prepare your target environment. See Section 21.3.2.
If your environment uses a database, create a new database or copy the database from the source environment to the target environment. See Section 21.3.3.
Move Oracle Identity Management to the target environment. See Section 21.4.1.
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.
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:
Note:
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.
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.
Created the needed schemas in the source environment using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
Installed Oracle WebLogic Server and created the Middleware home.
Installed and configured Identity Management.
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.)
Installed and configured Oracle Fusion Middleware components such as Oracle SOA Suite or Oracle WebCenter Portal.
Configured security policies.
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:
cat oraInst.loc
inventory_loc=new_oraInst_loc_location
inst_group=g900
Detach the Oracle Home from its current inventory:
cd ORACLE_HOME/oui/bin ./detachHome.sh -invPtrLoc ORACLE_HOME/oraInst.loc
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:
<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2013, Oracle. All rights reserved. -->
<!-- Do not modify the contents of this file by hand. -->
<VERSION_INFO>
<SAVED_WITH>11.1.0.9.0</SAVED_WITH>
<MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="OH339778486" LOC="/scratch/oracle/11gMW/oracle_common" TYPE="O" IDX="1">
<REFHOMELIST>
<REFHOME LOC="/scratch/oracle/11gMW/Oracle_WC1"/>
</REFHOMELIST>
</HOME>
<HOME NAME="OH299443989" LOC="/scratch/oracle/11gMW/Oracle_WC1" TYPE="O"
IDX="2">
<DEPHOMELIST>
<DEPHOME LOC="/scratch/oracle/11gMW/oracle_common"/>
</DEPHOMELIST>
</HOME>
</HOME_LIST>
<COMPOSITEHOME_LIST>
</COMPOSITEHOME_LIST>
</INVENTORY>
Run the following command to set up dependencies. Note that this is not mandatory for the movement scripts to work, but is needed when you uninstall.
./runInstaller -updateHomeDeps
"HOME_DEPENDENCY_LIST={/scratch/oracle/11gMW/Oracle_WC1:/scratch/oracle/11gMW/
oracle_common}" -invPtrLoc ~/oraInst.loc
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:
BEGIN
dbms_stats.gather_schema_stats(ownname => 'prefix_MDS',
METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO',
CASCADE => TRUE, ESTIMATE_PERCENT => NULL);
END;
In the procedure, prefix_MDS is the MDS schema name for your installation.
Many components, such as Oracle Internet Directory, Oracle SOA Suite, and Oracle WebCenter Portal, require a database.
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 can install a new database or you can copy the database from the source environment:
Install a new database. You can use this for most components, except Oracle Internet Directory. Take the following steps:
Install and configure the database software.
Create the required schemas in the target database using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
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.
Create a duplicate database using the Oracle Database RMAN duplicate command. Use this method if you are moving Oracle Internet Directory. 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.
testDB =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = 192.168.1.1)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = testDB)
)
)
prodDB=
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = 192.168.2.4)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = prodDB)
)
)
On the source environment, edit the listener.ora file, adding an entry for the database on the target environment.
The following shows the added entry:
LISTENER_mts =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = 192.168.2.4)
(PORT = 1521)(IP = FIRST))
)
)
SID_LIST_LISTENER_mts =
(SID_LIST =
(SID_DESC =
(SID_NAME = prodDB)
(ORACLE_HOME = /scratch/oracle/test)
)
)
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:
oradim -new -sid sid -intpwd password -startmode auto -pfile 'ORACLE_HOME\database\pfile'
Start the database in NOMOUNT mode. For example:
SQL> STARTUP NOMOUNT PFILE='ORACLE_HOME/dbs/pfile'
To move the database from the source environment to the target environment, use RMAN on the target environment.
The following shows an example of using RMAN to duplicate the database.
RMAN DUPLICATE TARGET DATABASE TO prodDB FROM ACTIVE DATABASE SPFILE NOFILENAMECHECK;
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.
For detailed steps, see the Oracle Database Backup and Recovery User's Guide.
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.
The copyBinary script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/copyBinary.sh (Windows) ORACLE_COMMON_HOME\bin\copyBinary.cmd
See Section 20.2.1.1 for the syntax of the copyBinary script.
For example, to copy a Middleware home that is located at /scratch/Oracle /Middleware1, use the following command:
copyBinary.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/mw_copy.jar
-sourceMWHomeLoc /scratch/Oracle/Middleware1
-invPtrLoc /scratch/oracle/oraInst.loc
If you are copying the Middleware home to a different host, copy the archive file to that system.
Copy the pasteBinary script and the cloningclient.jar file to the target system and ensure that they have execute permission. See Section 20.2 for the locations of the files.
The pasteBinary script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/pasteBinary.sh (Windows) ORACLE_COMMON_HOME\bin\pasteBinary.cmd
The cloningclient.jar file is located in:
(UNIX) ORACLE_COMMON_HOME/jlib/cloningclient.jar (Windows) ORACLE_COMMON_HOME\jlib\cloningclient.jar
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:
pasteBinary.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/mw_copy.jar
-targetMWHomeLoc /scratch/oracle/MW_Home_prod
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
The copyBinary and pasteBinary scripts copy and paste any domain directories that are in the Oracle home, but not under the user_projects directory. These domain directories are not properly configured, so that they are not functional.
Delete the domain directories from the target before you run the pasteConfig command, which will recreate properly configured domain directories on the target environment, as described in Section 21.3.5.
At the target, delete the Node Manager directory and the files in it. The default location of the directory is:
WL_hOME/common/nodemanager
You will move the Node Manager configuration in Section 21.3.5, Step 10.
You can move a copy of the domain configuration for Java components, such as Oracle WebCenter Portal, 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.
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.
The copyConfig script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/copyConfig.sh (Windows) ORACLE_COMMON_HOME\bin\copyConfig.cmd
See Section 20.2.1.3 for the syntax of the copyConfig script.
For example, to copy the configuration of the Oracle SOA Suite domain named SOA_domain1 in the Middleware home /scratch/Oracle/Middleware1, use the following command:
copyConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/soa.jar
-sourceDomainLoc /scratch/oracle/config/domains/WC_domain1
-sourceMWHomeLoc /scratch/Oracle/Middleware1
-domainHostName example.com
-domainPortNum 8001
-domainAdminUserName domain_admin_username
-domainAdminPasswordFile /scratch/admin/passwd.txt
-logDirLoc /tmp/logs
If you are copying the domain configuration to a different host, copy the archive file to that system.
At the source, extract the move plan from the archive, using the extractMovePlan script.
The extractMovePlan script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/extractMovePlan.sh (Windows) ORACLE_COMMON_HOME\bin\extractMovePlan.cmd
See Section 20.2.1.7 for the syntax of the extractMovePlan script.
For example:
extractMovePlan.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/wc.jar
-planDirLoc /tmp/Oracle/t2p_plans/wc
Note:
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.
(UNIX) ORACLE_COMMON_HOME/bin/obfuscatePassword.sh (Windows) ORACLE_COMMON_HOME\bin\obfuscatePassword.cmd
The script prompts you to enter the password and the location where the password file is to be written.
At the target, if the -opssDataExport parameter was set to true during the copyConfig operation (it is set to true by default), you must set the following environment variable, which sets the initial and maximum heap size:
CONFIG_JVM_ARGS "-Xmx2048M -Xms2048M"
At the target, extract the files from the archive using the pasteConfig script
The pasteConfig script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/pasteConfig.sh (Windows) ORACLE_COMMON_HOME\bin\pasteConfig.cmd
See Section 20.2.1.8 for the syntax of the script.
For example, to apply the archive to the Middleware home /scratch/Oracle/Middleware1, use the following command:
pasteConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/wc.jar
-movePlanLoc /tmp/Oracle/t2p_plans/wc/moveplan.xml
-targetDomainLoc /scratch/oracle/config/domains/WC_domain1
-targetMWHomeLoc /scratch/Oracle/Middleware1/
-domainAdminPasswordFile /scratch/pwd_dir/pass.txt
If the Node Manager is configured at the source, move the Node Manager:
At the source, copy the Node Manager configuration, by executing the copyConfig script.
The copyConfig script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/copyConfig.sh (Windows) ORACLE_COMMON_HOME\bin\copyConfig.cmd
See Section 20.2.1.6 for the syntax of the script. For example, use the following command:
copyConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/nm.jar
-sourceNMHomeLoc /scratch/Oracle/Middleware/wlserver_10.3/common/nodemanager
-logDirLoc /tmp/logs
If you are copying the Node Manager to a different host, copy the archive file to that system.
At the source, extract the move plan from the archive, using the extractMovePlan script.
The extractMovePlan script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/extractMovePlan.sh (Windows) ORACLE_COMMON_HOME\bin\extractMovePlan.cmd
See Section 20.2.1.7 for the syntax of the extractMovePlan script.
For example:
extractMovePlan.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/nm.jar
-planDirLoc /tmp/Oracle/t2p_plans/nm
Edit the move plan, modifying the properties to reflect the values for the target environment. See Table 20-13 to find the list of properties for Node Manager.
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.
(UNIX) ORACLE_COMMON_HOME/bin/obfuscatePassword.sh (Windows) ORACLE_COMMON_HOME\bin\obfuscatePassword.cmd
The script prompts you to enter the password and the location where the password file is to be written.
At the target, extract the files from the archive using the pasteConfig script.
The pasteConfig script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/pasteConfig.sh (Windows) ORACLE_COMMON_HOME\bin\pasteConfig.cmd
See Section 20.2.1.11 for the syntax of the script.
For example, use the following command:
pasteConfig -javaHome USER_HOME/jrockit_160_17_R28.0.0-679/
-archiveLoc /tmp/nm.jar
-targetNMHomeLoc /scratch/Oracle/Middleware1/wlserver_10.3/common/nodemanager
-targetMWHomeLoc /scratch/Oracle/Middleware1
-movePlanLoc /tmp/Oracle/t2p_plans/nm/moveplan.xml
-silent true
When you complete this task, you need to perform additional steps for each component, as described in Section 21.4.
You can move and Oracle instance and system components, such as Oracle HTTP Server, Oracle Internet Directory, Oracle Virtual Directory, and Oracle BI EE, in one of the following ways:
In both cases, you use the copyConfig, extractMovePlan, and pasteConfig scripts. The only difference is in the options that you pass to the scripts.
You can move the entire Oracle instance, including the configuration of all of the system components within that instance.
Take the following steps:
At the source, execute the copyConfig script.
The copyConfig script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/copyConfig.sh (Windows) ORACLE_COMMON_HOME\bin\copyConfig.cmd
See Section 20.2.1.4 for the syntax of the script.
For example, to copy the Oracle instance located in /scratch/Oracle/Middleware1/webtier_1, use the following command:
copyConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-sourceInstanceHomeLoc /scratch/Oracle/Middleware1/webtier_1
If you are copying the component to a different host, copy the archive file to that system.
At the source, extract the move plan from the archive, using the extractMovePlan script.
The extractMovePlan script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/extractMovePlan.sh (Windows) ORACLE_COMMON_HOME\bin\extractMovePlan.cmd
See Section 20.2.1.7 for the syntax of the extractMovePlan script.
For example:
extractMovePlan.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-planDirLoc /tmp/Oracle/t2p_plans/ohs
Edit the move plan, modifying the properties for the particular components to reflect the values for the target environment:
For Oracle HTTP Server, see Table 20-21.
For Oracle Internet Directory, see Table 20-22.
For Oracle Virtual Directory, see Table 20-23.
For Oracle BI EE, see Table 20-25.
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.
(UNIX) ORACLE_COMMON_HOME/bin/obfuscatePassword.sh (Windows) ORACLE_COMMON_HOME\bin\obfuscatePassword.cmd
The script prompts you to enter the password and the location where the password file is to be written.
At the target, extract the files from the archive using the pasteConfig script.
The pasteConfig script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/pasteConfig.sh (Windows) ORACLE_COMMON_HOME\bin\pasteConfig.cmd
See Section 20.2.1.9 for the syntax of the script.
For example, to apply the archive to the Oracle instance webtier_2, use the following command:
pasteConfig.sh -javaHome /scratch/Oracle/Middleware/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-movePlanLoc /tmp/Oracle/t2p_plans/ohs/moveplan.xml
-targetOracleHomeLoc /scratch/Oracle/Middleware/Oracle_WebTier
-targetInstanceHomeLoc /scratch/Oracle/Middleware/webtier_2
-targetInstanceName webtier_2
-domainHostName myhost
-domainPortNum 7001
-domainAdminUserName domain_admin_username
-domainAdminPasswordFile domain_admin_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.
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.
The copyConfig script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/copyConfig.sh (Windows) ORACLE_COMMON_HOME\bin\copyConfig.cmd
See Section 20.2.1.5 for the syntax of the script.
For example, to copy the Oracle HTTP Server instance named ohs1 in the Oracle instance located in /scratch/Oracle/Middleware1/webtier_1, use the following command:
copyConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-sourceInstanceHomeLoc /scratch/Oracle/Middleware1/webtier_1
-sourceComponentName ohs1
If you are copying the component to a different host, copy the archive file to that system.
At the source, extract the move plan from the archive, using the extractMovePlan script.
The extractMovePlan script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/extractMovePlan.sh (Windows) ORACLE_COMMON_HOME\bin\extractMovePlan.cmd
See Section 20.2.1.7 for the syntax of the extractMovePlan script.
For example:
extractMovePlan.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-planDirLoc /tmp/Oracle/t2p_plans/ohs
Edit the move plan, modifying the properties for the particular components to reflect the values for the target environment:
For Oracle HTTP Server, see Table 20-21.
For Oracle Internet Directory, see Table 20-22.
For Oracle Virtual Directory, see Table 20-23.
For Oracle BI EE, see Table 20-25.
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.
(UNIX) ORACLE_COMMON_HOME/bin/obfuscatePassword.sh (Windows) ORACLE_COMMON_HOME\bin\obfuscatePassword.cmd
The script prompts you to enter the password and the location where the password file is to be written.
At the target, extract the files from the archive using the pasteConfig script. To apply the archive for an individual component, add the -targetComponentName option.
The pasteConfig script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/pasteConfig.sh (Windows) ORACLE_COMMON_HOME\bin\pasteConfig.cmd
See Section 20.2.1.10 for the syntax of the script.
For example, to apply the archive to the Oracle instance webtier_2 and name the target Oracle HTTP Server instance ohs_cl, use the following command:
pasteConfig.sh -javaHome /scratch/Oracle/Middleware/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/ohs1.jar
-movePlanLoc /tmp/Oracle/t2p_plans/ohs/moveplan.xml
-targetOracleHomeLoc /scratch/Oracle/Middleware/Oracle_WebTier
-targetInstanceHomeLoc /scratch/Oracle/Middleware/webtier_2
-targetInstanceName webtier_2
-targetComponentName ohs_cl
-domainHostName myhost
-domainPortNum 7001
-domainAdminUserName domain_admin_username
-domainAdminPasswordFile domain_admin_password_file
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.
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 the LDAP store is an Oracle Internet Directory LDAP store and 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:
ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Users,dc=us"
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.)
ORACLE_HOME/bin/ldapaddmt -h production_oid_host -p production_oid_port -D "cn=orcladmin" -w "production_orcladmin_passwd" -r -f ldif_filename
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:
Moving Identity Management Components to a Target Environment
Moving Oracle Hyperion Enterprise Performance Management System to a Target Environment
The following topics describe how to move Identity Management from the source environment to the target environment:
In both cases, you have performed the following in the source environment:
Installed a database to be used for Identity Management components such as Oracle Internet Directory, Oracle Directory Integration Platform (which depends on Oracle Internet Directory,) and Oracle Identity Federation.
Created the needed schemas in the source environment using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
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.
For Oracle Access Manager 11g, set up authentication with corresponding WebGates configured in the Web tier of the protected applications. The Oracle Access Manager configuration data resides in a file and the policy and configuration data resides in a database, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
For Oracle Platform Security, created security policies and stored credentials in the Credential Store Framework (CSF).
For Oracle Web Services Manager, created Oracle Web Services Manager policies. These policies are also attached to Web services and clients.
For SSL, configured self-signed certificates. (In the target environment, you use trusted CA-signed certificates.)
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 2, "Perform Prerequisite Task for Oracle Access Manager"
Task 3, "Move Oracle Internet Directory to the New Target Environment"
Task 4, "Move Oracle Virtual Directory to a New Target Environment"
Task 5, "Move Oracle Directory Integration Platform to a New Target Environment"
Task 6, "Move Oracle Access Manager 11g to a New Target Environment"
Task 7, "Move Oracle Access Manager 10g to a New Target Environment"
Task 8, "Move Oracle Identity Federation to a New Target Environment"
Task 9, "Move Oracle Adaptive Access Manager to a New Target Environment"
Task 10, "Move Oracle Identity Navigator to a New Target Environment"
Task 12, "Move Oracle Web Services Manager to a 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.
For Oracle Access Manager, if required, perform the prerequisite task, as described in Task 2, "Perform Prerequisite Task for Oracle Access Manager".
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.
Configures Oracle Identity Federation. For optional tasks that you may take in certain situations, see Task 4, "Move Oracle Identity Federation to an Existing Target Environment".
Moves Oracle Platform Security Services. The policy and credential stores are moved as part of the copyConfig and pasteConfig operations.
If you are using Oracle Web Services Manager, move audit policies as described in Task 11, "Move Audit Policies to a New Target Environment".
Moves Oracle Web Services Manager and any policies that are stored in the MDS Repository or deployment plans, and any custom policies that are stored in DOMAIN_HOME/lib. To move policies that are not stored in the MDS Repository, see Task 12, "Move Oracle Web Services Manager to a New Target Environment".
Configures data sources.
Configures JMS resources.
Starts the Administration Server.
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
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:
OID Cloning: Error cleaning replication agreements OID Cloning: Error deleting replication dn OID Cloning: Error updating orclreplicaid
If you do, take the following steps:
Run the following command:
ORACLE_HOME/ldap/bin/remtool -pcleanup
When prompted, enter the Oracle Internet Directory host, non-SSL port, and the ODS schema password.
Perform an ldapsearch on the root dn for the orclreplicaid value. Use the following command:
ORACLE_HOME/bin/ldapsearch -p port -h host -b "" -s base "(objectclass=*)" orclreplicaid
Using the value obtained in Step b, perform an ldapdelete, deleting the following dns from Oracle Internet Directory:
cn=replication dn, orclreplicaid=<replicaid>, cn=replication configuration orclreplicaid=<replicaid>, cn=replication configuration
For example:
ldapdelete -p port -h host "cn=replication dn, orclreplicaid=replicaid, cn=replication configuration"
Set the orclreplicaid value in the root entry to 0. For example:
ORACLE_HOME/bin/ldapmodify -p port -h host -f file.ldif
The ldif file contains the following:
dn: changetype: modify replace: orclreplicaid orclreplicaid: 0
Restart Oracle Internet Directory.
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.
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.
To move Oracle Directory Integration Platform to a new target environment:
Move Oracle Internet Directory, as described in Task 3.
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.
When you move the configuration of the domain, update the move plan properties in Table 20-34 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.
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:
"Installing the Identity Server" in the Oracle Access Manager Installation Guide.
"Installing WebPass" in the Oracle Access Manager Installation Guide.
After installation, take the following steps:
Start the server.
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.
Click Save.
From the Access System Configuration tab, select Access Gate Configuration. Then, select the relevant Access Gate.
In the Details for AccessGate page, click Modify.
Change the Hostname and Port, specifying the host name and port of the target Web server.
Change the Preferred HTTP Host, specifying the host name variation that you added in Step c.
Associate the WebGate to the newly added target Access Server, as described in "Associating AccessGates and WebGates with Access Servers" in the Oracle Access Manager Access Administration Guide.
Disable the WebGate temporarily. From the Access System Console, select the Access System Configuration tab, then select AccessGate Configuration. Click Go to search. From the results, select an AccessGate. Then, click Modify. Click Disabled. Then, click Save.
You enable it after you install the Access Server.
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.
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.
Delete old trusted partner:
In Fusion Middleware Control, navigate to the Oracle Identity Federation instance.
Select Administration, then Federations.
Select the provider and click Delete.
Regenerate the metadata and reregister the provider, as described in "Provider-specific Metadata" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
Optionally, regenerate the server key. See the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation for information about regenerating the keys.
In most cases, you do not need to take any additional steps. If you need to change the Security and Trust, or Authentication Mechanisms, take the following steps:
If you need to change or add partners, see "Add Trusted Providers" and "Delete Trusted Providers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
If you need to change the HTTP basic authentication, update the user name and password:
In Fusion Middleware Control, from the target menu on the OIF page, choose Administration, then Federations.
Select a Trusted Provider and click Edit. Update HTTP Authentication Username and HTTP Authentication Password. Then, confirm the password.
Click Apply.
Start the Managed Servers, as described in Section 4.2.3.
When you move the configuration of the domain, update the move plan properties in Table 20-35 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.
To move Oracle Identity Navigator to a new target environment:
On the target system, configure a proxy, as described in "Configuring a Proxy to Access News Feeds" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Navigator.
To move audit policies to a new target environment, see the following topics in the Oracle Fusion Middleware Application Security Guide:
To move Oracle Web Services Manager to a new target environment:
Migrate audit policies, as described in "Migrating Audit Policies" in the Oracle Fusion Middleware Application Security Guide.
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.
See Also:
"Managing Horizontal Policy Migration" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services
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:
Task 1, "Move Oracle Internet Directory to an Existing Target Environment"
Task 2, "Move Oracle Access Manager 11g to an Existing Target Environment"
Task 3, "Move Oracle Access Manager 10g to an Existing Target Environment"
Task 4, "Move Oracle Identity Federation to an Existing Target Environment"
Task 5, "Move Oracle Adaptive Access Manager to an Existing Target Environment"
Task 6, "Move Oracle Identity Navigator to an Existing Target Environment"
Task 7, "Move Oracle Platform Security to an Existing Target Environment"
Task 8, "Move Oracle Web Services Manager to an Existing Target Environment"
To move Oracle Internet Directory to an existing target environment:
You may have configured Oracle Platform Security to use the users and groups in the source environment. To move the users and groups from the source environment, take the following steps:
Identify the Default Subscriber for the source Oracle Internet Directory instance by running the following command from the source Oracle home:
ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Common,cn=Products,cn=OracleContext" -s base "objectclass=*" orcldefaultsubscriber
This query returns a value for the attribute orcldefaultSubscriber. The value is used in following steps as default_subscriber.
Retrieve the users from the source Oracle Internet Directory instance by running the following command from the source Oracle home:
ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port -D "cn=orcladmin" -w "test_orcladmin_passwd" -L -b "cn=users, default_subscriber" -s sub "objectclass=*" * orclguid > ldif_filename
Move the users into the target Oracle Internet Directory instance by running the following command from the target Oracle home:
ORACLE_HOME/bin/ldapaddmt -h production_oid_host -p production_oid_port -D "cn=orcladmin" -w "production_orcladmin_passwd" -r -f ldif_filename
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.
For information about fan-out replication, see the following sections in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory:
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.
Take the following steps:
Retrieve the RADs from the source Oracle Internet Directory instance using the following command:
ORACLE_HOME/bin/ldapsearch -h test_oid_host -w test_orcladmin_passwd -p test_oid_port -D "cn=orcladmin" -L -b "cn=Extended Properties,cn=OracleContext, default_subscriber" -s sub "objectclass=*" * orclguid > ldif_filename
Move the RADs into the target Oracle Internet Directory instance using the following command:
ORACLE_HOME/bin/ldapaddmt -h production_oid_host -p production_oid_port -D "cn=orcladmin" -w "production_orcladmin_passwd" -r -f ldif_filename
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 this procedure, you move incremental changes that you have made in the source environment to the target environment.
Note:
The Administration Servers in both the source environment and the target environment must be started.
To replicate the policy configuration information from the source environment into the target environment:
Set the environment variable JAVA_HOME and add JAVA_HOME to the PATH.
Export the policies from the source environment, using the following WLST command:
exportPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
Note that you must run the WLST commands in this task from the following directory:
Identity_Mgmt_ORACLE_HOME/common/bin
For example, the following command generates the file oam_policy.xml:
exportPolicy(pathTempOAMPolicyFile='/tmp/oam_policy.xml')
Edit the oam_policy.xml policy file to change the host and port identifiers to the values for the target environment. These are specified in the <host-identifiers> section of the file.
Copy the policy file to the target environment.
Import the policies into the target environment, using the following WLST command:
importPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
For example:
importPolicy(pathTempOAMPolicyFile='/tmp/oam_policy.xml')
Export the partner information from the source environment, using the following WLST command:
exportPartners(pathTempOAMPartnerFile='path_of_Temp_PartnerFile')
For example, the following command generates the file oam_partner.xml:
exportPartners(pathTempOAMPartnerFile='/tmp/oam_partner.xml')
Copy the partner file to the target environment.
Import the partner information to the target environment, using the following WLST command:
importPartners(pathTempOAMPartnerFile='path_of_Temp_PartnerFile')
For example:
importPartners(pathTempOAMPartnerFile='/tmp/oam_partner.xml')
The following directory on the target system now contains the partner artifacts that were generated for the migrated partners.
DOMAIN_HOME/output
Copy the partner artifacts, ObAccessClient.xml and logout.html, to the partner Oracle HTTP Server and update with values for the target environment, if necessary.
Update the mod_wl_ohs.conf file with the URI, host, and port of WebLogic Server where the application is deployed. For example:
WebLogicHost=example.com|WebLogicPort=18357
Restart the partner Oracle HTTP Server.
See Also:
"Delta-Replication" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service
To move Oracle Access Manager 10g to an existing target environment:
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.
To move Oracle Identity Federation to an existing 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:
java weblogic.WLST extractPartnerMetadataAndProperties.py providerID outputFilePrefix
Two files are created: outputFilePrefix_metadata.xml and outputFilePrefix_properties.txt.
Copy the files to the target system.
On the target environment, import the partner metadata and configuration properties by running the following script:
java weblogic.WLST setPartnerMetadataAndProperties.py outputFilePrefix_metadata.xml outputFilePrefix_properties.txt description
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
If you made any other configuration changes in the source environment that you want to replicate in the target environment, make those changes. See the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation for more information.
To move Oracle Adaptive Access Manager to an existing target environment:
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.
Manually re-create the KBA logic, OTP logic, and policy set overrides using the Oracle Adaptive Access Manager Admin Console. See the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
Copy the following from the source environment to the target environment: properties files, resource bundles, and end user JSP screens. These items are located in the oaam_extensions shared library.
Copy the VAD images, which are in a custom jar, from the source environment to the target environment.
Copy the following from the source environment to the target environment: properties files, resource bundles, VAD images, and end user JSP screens.
To move Oracle Identity Navigator to an existing target environment:
In the test environment, use the WLST command exportMetadata to export the Oracle Identity Navigator metadata from the test environment:
connect('username','password',JNDI-URL')
exportMetadata(application='oinav', server='server_name',
toLocation='directory'
The format of the JNDI URL is: t3://admin_server_host:admin_server_port.
In the production environment, use the WLST command importMetadata to import the Oracle Identity Navigator metadata to the production environment:
connect('username','password',JNDI-URL')
importMetadata(application='oinav', server='server_name',
fromLocation='directory'
Restart Administration Server and the Managed Servers, as described in Section 4.2.
Note that you do not need to configure the identity store and policy store if they have already been configured.
If you have made changes in the policy store, credential store, users, and groups, and you want to move them from the source environment to an existing target environment:
If the policy store on the source environment is not file-based, migrate the policy store, using the WLST command migrateSecurityStore, as described in "Migrating Policies with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.
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.
To move Oracle Web Services Manager to an existing target environment:
Move policies for SOA Composite applications, WebCenter Portal, or ADF applications, which are stored in the MDS Repository.
To do so using Fusion Middleware Control:
On the source environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.
Select a policy, then click Export to File.
The policy is copied to a file on the source environment.
Click Save File, then OK.
Navigate to the location on your local directory to which you want to save the file and update the file name as desired. Click Save.
Copy the file to the target environment.
On the target environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.
Click Import from File. Browse to the file and click OK.
On source environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.
Click Web Services Assertion Templates in the upper right corner of the page.
Click Export to File.
Click Save File, then OK.
Navigate to the location on your local directory to which you want to save the file and update the filename as desired. Click Save.
On the target environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.
Click Import from File. Browse to the file and click OK.
Click Web Services Assertion Templates in the upper right corner of the page.
Click Import from File. Browse to the file and click OK.
To move policies using WLST:
From the source environment, execute the following WLST commands:
exportMetadata(application='wsm-pm',server='server_name', docs='/assertiontemplates/assert_template_name', toLocation='/tmp/owsmexport/') exportMetadata(application='wsm-pm',server='server_name', docs='/policies/policy_name',toLocation='/tmp/owsmexport/')
Copy the /tmp/owsmexport directory from the source environment to the target environment.
In the target environment, execute the following WLST commands:
importMetadata(application='wsm-pm',server='server_name', docs='/assertiontemplates/assert_template_name'', fromLocation='/tmp/owsmexport/') importMetadata(application='wsm-pm',server='server_name', docs='/policies/policy_name',fromLocation='/tmp/owsmexport/')
If you have custom-built policies, move those by copying the jar files from the source to the target environment. The jar files are located in the following directory:
DOMAIN_HOME/lib
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.
The following topics describe how to move Oracle SOA Suite from the source environment to the target environment:
In both cases, you have performed the following in the source environment:
Installed Oracle WebLogic Server and created the Middleware home.
Created the needed schemas in the source environment using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
Installed Oracle SOA Suite.
Configured Oracle SOA Suite using the Configuration Wizard.
If required for your environment, installed and configured Identity Management components, such as Oracle Internet Directory, Oracle Platform Security, and Oracle Web Services Manager.
Configured security policies.
Deployed one or more applications or SOA Composite applications. The applications have internal and external references.
Changed some configuration settings. For example, you may have changed something in the config directory, in MDS, or another data source.
Optionally, configured Oracle WebLogic Server dependent artifacts for Oracle Business Activity Monitoring, such as:
BAM Adapter
Data sources for the database or JMS
Configured and populated the identity store for Oracle Business Activity Monitoring users.
Set up UMS and all required subcomponents, configured UMS drivers and user preferences in the source environment.
See Also:
Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for information about setting up an enterprise deployment for Oracle SOA Suite
To move Oracle SOA Suite to a new target environment, perform the following tasks:
Task 1, "Move the Database, Middleware Home and Perform the Initial Configuration"
Task 5, "Deploy B2B Agreements to the New Target Environment"
Task 6, "Move Oracle Business Activity Monitoring Data to the New Target Environment"
Task 7, "Move Oracle Business Process Management to the New Target Environment"
Task 8, "Move Oracle User Messaging Service to the New Target Environment"
Task 9, "Move Oracle Service Bus to a New Target Environment"
To move the database and Middleware home and perform the initial configuration:
Move or create the database and the schemas, as described in Section 21.3.3.
Note that for Oracle Service Bus, the source database can be any database supported by Oracle Service Bus. However, the target database must be a database supported by RCU.
Move Identity Management components, as described in Section 21.4.1.
Move the Middleware home and binary files, as described in Section 21.3.4.
If the SOA cluster migration is defined as a database data source, you must create the leasing schema, as described in "Setting Up the User and Tablespace for the Server Migration Leasing Table" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite.
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:
Execute the following commands:
cd DOMAIN_HOME/config/fmwconfig/servers tar cvf umsconfig_server_name.tar server_name/applications/usermessaging*
Copy the tar files to the host containing the Administration Server.
Extract the tar files to the corresponding location on the host containing the Administration Server.
During the subsequent pasteConfig operation, these directories will be copied to the Administration Server host on the target system.
Move the configuration, as described in Section 21.3.5.
For Oracle Service Bus, note the following:
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:
-additionalParams osb.configuration.passphrase.file=/scratch/passwd/osb_passwd
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:
export USER_MEM_ARGS="-Xms512m -Xmx1536m -XX:CompileThreshold=8000 -XX:PermSize=512m -XX:MaxPermSize=512m"
When you move the configuration, the pasteConfig script copies the configuration of the domain, including the Administration Server and Managed Servers. In addition, that step:
Moves SOA composite applications.
Moves Oracle Business Activity Monitoring
Moves Oracle Human Workflow attribute labels, flex field mappings, approval groups and standard views.
Moves Oracle Service Bus.
Reassociates the security store to an LDAP or database-based store, based on the values provided in move plan.
Moves Oracle Platform Security.
Moves Oracle Web Services Manager, any policies that are stored in the MDS Repository or deployment plans, and any custom policies that are stored in DOMAIN_HOME/lib.
Deploys applications in the target environment.
Configures adapters, such as the database adapters, AQ adapters, JMS adapters. Note, however, that you must edit the deployment plan of any adapters before you use the pasteConfig script.
Configures data sources.
Configures JMS resources.
Starts the Administration Server.
Configure users and groups, as described in Section 21.3.7.
See Also:
Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for information about setting up an enterprise deployment for Oracle SOA Suite
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.
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.
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.
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.
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):
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" create or replace directory directory as 'path'; grant read,write on DIRECTORY directory to oraclebam; exit; ORACLE_HOME/bin/expdp userid=oraclebam/bam@connect_id directory=directory dumpfile=orabam.dmp schemas=oraclebam logfile=oraclebam_date.log
See Also:
"Overview of Oracle Data Pump" and other chapters on Oracle Data Pump in Oracle Database Utilities
The Oracle BAM objects, such as reports, alerts, and data definitions, from the source environment are exported.
At the target, import the ORACLEBAM database schema that you exported from the source environment, using the following commands (ORACLE_HOME is the Oracle home for the Oracle Database):
ORACLE_HOME/bin/impdp userid=system/password dumpfile=ORACLEBAM.DMP remap_schema=oraclebam:oraclebam TABLE_EXISTS_ACTION=replace ORACLE_HOME/bin/sqlplus "sys/password as sysdba" alter user oraclebam account unlock; alter user oraclebam identified by bam;
Note that impdp may report the following errors:
ORA-00959: tablespace <source tablespace> does not exist.
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.
To move Oracle Business Process Management to the new target environment:
To create organizational units, see "Managing Organizational Units in Process Workspace" in the Oracle Fusion Middleware Getting Started With Installation for Oracle WebLogic Server.
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.
You use the following script:
ORACLE_HOME/bin/ant-t2p-workspace.xml
The command has the following format:
ant -f ant-t2p-workspace.xml
-Dbea.home=BEA_HOME
-Dbpm.home=BPM_HOME
-Dbpm.t2p.migration.config=MIGRATION_CONFIG_FILE
Take the following steps:
Ensure that the PATH environment variable contains the required JAVA_HOME and ANT_HOME environment variables and that they point to the locations within the Oracle SOA Suite installation.
Export dashboards:
Create a configuration file to export dashboards:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testToProductionMigrationConfiguration
xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config"
xmlns:ns2="http://xmlns.oracle.com/bpm/common"
override="true" skip="true">
<sourceEndPoint>
<serverEndPoint>
<serverURL>t3://host:port</serverURL>
<adminUserLogin>admin_username</adminUserLogin>
<adminUserPassword>admin_password</adminUserPassword>
<realm>jazn.com</realm>
</serverEndPoint>
</sourceEndPoint>
<targetEndPoint>
<fileEndPoint>
<migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
</fileEndPoint>
</targetEndPoint>
<operation>EXPORT</operation>
<object>DASHBOARD</object>
<objectDetails>
<login>username</login>
<password>password</password>
<identityContext>jazn.com</identityContext>
<userApplicationData>
<ownerId>username/ownerId>
<option>CUSTOMLAYOUT</option>
</userApplicationData>
</objectDetails>
</testToProductionMigrationConfiguration>
In the configuration file, you must specify the values for the source environment in the following elements:
serverURL: The SOA server URL.
adminUserLogin: The Administration user name.
adminUserPassword: The password for the Administration user.
migrationFile. The file that was generated by the export operation.
objectDetails: The login and password elements.
userApplicationData: The ownerID element.
Export dashboards, using the following command:
ant -f ant-t2p-workspace.xml
-Dbea.home=BEA_HOME
-Dbpm.home=BPM_HOME
-Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE
Import dashboards:
Create a configuration file to import dashboards:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testToProductionMigrationConfiguration
xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config"
xmlns:ns2="http://xmlns.oracle.com/bpm/common"
override="true" skip="true">
<sourceEndPoint>
<fileEndPoint>
<migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
</fileEndPoint>
</sourceEndPoint>
<targetEndPoint>
<serverEndPoint>
<serverURL>t3://host:port</serverURL>
<adminUserLogin>admin_username</adminUserLogin>
<adminUserPassword>admin_password</adminUserPassword>
<realm>jazn.com</realm>
</serverEndPoint>
</targetEndPoint>
<operation>IMPORT</operation>
<object>DASHBOARD</object>
<objectDetails>
<login>username</login>
<password>password</password>
<identityContext>jazn.com</identityContext>
<userApplicationData>
<ownerId>username/ownerId>
<option>CUSTOMLAYOUT</option>
</userApplicationData>
</objectDetails>
</testToProductionMigrationConfiguration>
In the configuration file, you must update the following elements with the values for the target environment:
serverURL: The SOA server URL.
adminUserLogin: The Administration user name.
adminUserPassword: The password for the Administration user.
The password will be encrypted when you first run the ant-t2p-workspace.xml tool.
migrationFile. The file that was generated by the export operation.
objectDetails: The login and password elements.
The password will be encrypted when you first run the ant-t2p-workspace.xml tool.
userApplicationData: The ownerID element.
Import dashboards, using the following command:
ant -f ant-t2p-workspace.xml
-Dbea.home=BEA_HOME
-Dbpm.home=BPM_HOME
-Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE
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.
Re-create the domain directory for the remote Managed Servers by using the Oracle WebLogic Server pack and unpack commands. For more information, see Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands.
Delete the following directories in the Administration Server host for each remote server:
MW_HOME/user_projects/domains/domain_name/config/fmwconfig/servers/server_name/applications/usermessaging*
A remote server is a server that is not on the same host as the Administration Server.
Note that for Oracle Service Bus, you must have specified particular options, as described in Step 6 in Task 1, "Move the Database, Middleware Home and Perform the Initial Configuration". Confirm that you have performed the following:
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.
Update the configuration for Oracle Coherence, as described in "Configuring Oracle Coherence for the Oracle Service Bus Result Cache" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite.
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.
To move Oracle SOA Suite to an existing target environment:
Task 1, "Move Oracle SOA Suite Changes to an Existing Target Environment"
Task 2, "Move Oracle B2B Changes to an Existing Target Environment"
Task 3, "Move Oracle Business Process Management Changes to an Existing Target Environment"
Task 4, "Move Oracle Business Activity Monitoring Data to an Existing Target Environment"
Task 5, "Move Oracle User Messaging Service Data to an Existing Target Environment"
Task 6, "Move Oracle Service Bus to an Existing Target Environment"
To move any changes that you have made to Oracle SOA Suite:
If you have added users and groups in the source environment, follow the steps in Section 21.3.7 to move them to the target environment.
If you have modified EJBs or Plain Old Java Objects (POJOs) in the source environment that support the composite references, move them to the target environment:
To deploy EJB Modules, see "Deploy EJB Modules" in the Oracle WebLogic Server Administration Console Online Help.
To deploy Enterprise Applications, see "Working with Enterprise Applications" in the Oracle WebLogic Server Administration Console Online Help.
If you have made any changes to Human Workflow in the source environment, move them 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.
If you have modified any information in the configuration plans, copy those changes to the target environment. For more information about configuration plans, see "Moving SOA Composite Applications to and from Development, Test, and Production Environments" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
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:
ant -f ant-b2b-util.xml b2bexport -Dtpanames="Acme_GC_Agreement1,
GC_Acme_Agreement1" -Dactive=true -Dexportfile="/tmp/export.zip"
Import the data to the target environment. The following example imports the elements in the file /tmp/export.zip:
ant -f ant-b2b-util.xml b2bimport -Dlocalfile=true
-Dexportfile="/tmp/export.zip"
For more information about these commands, see "B2B Command Line Tools" in the Oracle Fusion Middleware User's Guide for Oracle B2B.
Configure B2B agreement external endpoints with target locations and credentials, as described in "Configuring Channels" in the Oracle Fusion Middleware User's Guide for Oracle B2B.
If your Oracle B2B environment has been configured with Java callouts, manually move the callout library. See "Managing Callouts" in the Oracle Fusion Middleware User's Guide for Oracle B2B.
Deploy the B2B agreements, as described in "Deploying an Agreement" in the Oracle Fusion Middleware User's Guide for Oracle B2B.
If you have made any changes to Oracle Business Process Management in the source environment, re-create them or move them to the target environment:
To create organizational units, see "Managing Organizational Units in Process Workspace" in the Oracle Fusion Middleware Getting Started With Installation for Oracle WebLogic Server.
To move dashboards, as described in Task 7, "Move Oracle Business Process Management to the New Target Environment" in Section 21.4.2.1.
Changes to BAM can include, but are not limited to:
Data object definitions
Actual data in data objects
Report definitions
External data source definitions
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.
To move Oracle User Messaging Service data:
Configure the required UMS drivers in the target environment.
Note:
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.
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).
The following topics describe how to move Oracle WebCenter Portal from the source environment to the target environment:
In both cases, you have performed the following in the source environment:
Installed Oracle WebLogic Server.
Installed Oracle WebCenter Portal.
Created the needed schemas in the source environment using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
Installed and configured Oracle SOA Suite.
Configured Oracle WebCenter Portal using the Configuration Wizard. You created a domain and Managed Servers for WebCenter Portal products.
Configured a domain for
Installed and configured Oracle WebCenter Content.
Installed Identity Management components, such as Oracle Internet Directory, Oracle Identity Federation, and Oracle Access Manager.
Configured Oracle WebCenter Portal to use LDAP and created some users and groups in the embedded LDAP or an LDAP store.
Created the required Oracle Platform Security Services policies in the policy store.
Created the required user credentials in the credential store.
Used Portal Builder to build one or more portals, or used JDeveloper to create and deploy your own Portal Framework application, or both.
To move Oracle WebCenter Portal to a new target environment, perform the following tasks:
Task 1, "Move the Database, Middleware Home, and Perform the Initial Configuration"
Task 2, "Move Discussions Server Data to the Target Environment (Optional)"
Task 3, "Move Oracle WebCenter Portal Data to the Target Environment (Optional)"
Task 4, "Move Oracle WebCenter Content Documents and Folders Associated with Portal (Optional)"
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:
Move or create the database, as described in Section 21.3.3.
Move Identity Management components, as described in Section 21.4.1.
Move the Middleware home and binary files, as described in Section 21.3.4.
Move Oracle HTTP Server (a requirement for Oracle WebCenter Content), as described in Section 21.4.6.1.1.
Move the configuration, as described in Section 21.3.5.
Note that when you move the configuration, the pasteConfig script copies the configuration of the domain, including the Administration Server and Managed Servers. In addition, that step:
Creates authenticators for Identity Management in Oracle WebLogic Server.
Reassociates the policy and credential store.
Moves WebCenter Portal application metadata from the source environment to the target environment.
Starts the Administration Server.
If your Oracle WebCenter Portal application uses the Discussions 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:
expdp "sys/password@connect_id as sysdba" OWNER=src_prefix_DISCUSSIONS DUMPFILE=dumpFileName.dmp STATISTICS=none schemas=src_prefix_DISCUSSIONS directory=directory dumpfile=filename schemas=src_prefix_DISCUSSIONS_CRAWLER directory=directory dumpfile=filename
Import the discussion server data:
Shut down the target discussions server.
Go to the ORACLE_HOME/bin directory of the database where WebCenter Portal's discussions server schema is installed, and connect to the database using sqlplus as sysdba:
ORACLE_HOME/bin/sqlplus "sys/password@serviceid as sysdba"
Drop the target user and create a new user:
drop user trgt_prefix_DISCUSSIONS cascade; create user trgt_prefix_DISCUSSIONS identified by password default tablespace trgt_prefix_IAS_DISCUSSIONS temporary tablespace name_IAS_TEMP;
Grant connect and resource to the user:
grant connect,resource, create view to trgt_prefix_DISCUSSIONS;
Exit SQLPlus:
exit;
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:
impdp \"sys/password@serviceid as sysdba\" remap_schema=src_prefix_DISCUSSIONS:trgt_prefix_DISCUSSIONS remap_schema=src_prefix_DISCUSSIONS_CRAWLER:trgt_prefix_DISCUSSIONS_CRAWLER remap_tablespace=source_tablespace:target_tablespace exclude=user DUMPFILE=dumpFileName STATISTICS=none
If you want to move Oracle WebCenter Portal data such as portals, portal templates, as well as data associated with events, lists, links, tags, and people connections, to the target environment:
Export WebCenter Portal data from the source database, using the following commands from the ORACLE_HOME/bin (UNIX) and the ORACLE_HOME\bin (Windows) directories, where ORACLE_HOME is the Oracle home for the Oracle Database:
sqlplus "sys/password as sysdba" create or replace directory directory as 'path'; exit;
expdp "sys/password@connect_id as sysdba" schemas=prefix_WEBCENTER directory=directory dumpfile=filename
Import WebCenter Portal data to the target database, using the file you exported in Step 1. Execute the following commands, where ORACLE_HOME is the Oracle home for the Oracle Database:
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" create or replace directory directory as 'path'; exit;
ORACLE_HOME/bin/impdb "sys/password@connect_id as sysdba" DIRECTORY=directory dumpfile=filename TABLE_EXISTS_ACTION=REPLACE
If you moved WebCenter Portal 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 portals or portal templates to an existing target environment, refer to:
"Deploying Portals" in the Oracle Fusion Middleware Administering Oracle WebCenter Portal.
"Deploying Portal Templates" in the Oracle Fusion Middleware Administering Oracle WebCenter Portal.
To propagate changes to Portal Framework applications built using JDeveloper to an existing target environment, refer to "Using the Propagation Tool to Propagate From Staging to Production" in the Oracle Fusion Middleware Developing Portals with Oracle WebCenter Portal and Oracle JDeveloper.
The following topics describe how to move Oracle WebCenter Content to the target environment:
In both cases, you have performed the following in the source environment:
Installed a database to be used for required schemas.
Created the needed schemas in the source environment using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
Installed Oracle WebLogic Server and created the Middleware home.
Installed and configured Oracle WebCenter Content.
Configured Oracle WebCenter Content.
Configured Oracle WebCenter Content: Imaging.
If Imaging uses Oracle Universal Content Management 10g repository, ensure that the repository was manually configured for Imaging.
If Oracle WebCenter Content: Imaging uses Workflow or Oracle Application Extension Framework (AXF), installed and configured Oracle SOA Suite.
Configured Oracle WebCenter Content UI, including creating a domain.
Configured Oracle WebCenter Content: Records.
Configured Oracle WebCenter Content Capture.
Defined several definitions, such as Connections, Applications, Searches, and Inputs for Imaging.
Installed and configured Identity Management components, such as Oracle Internet Directory.
To move Oracle WebCenter Content to a new target environment, perform the following tasks:
Task 1, "Move the Database, Middleware Home, and Perform the Initial Configuration"
Task 2, "Configure Full-Text for Oracle Universal Content Management 10g"
Task 3, "Modify Oracle Information Rights Management Settings"
Task 4, "Move Oracle WebCenter Content to a New Target Environment"
Task 5, "Move Oracle WebCenter Content: Imaging to a New Target Environment"
Task 6, "Move Oracle WebCenter Content: Records to a New Target Environment"
Task 7, "Move Oracle WebCenter Content: Inbound Refinery to a New Target Environment"
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:
Oracle Internet Directory
Oracle Virtual Directory
A third-party LDAP Server
To move the database and the Middleware home, and perform the initial configuration, including moving the Oracle WebCenter Content domain and the Oracle WebCenter Content UI domain.
Move or create the database, as described in Section 21.3.3.
Move Identity Management components, as described in Section 21.4.1.
Note that because Oracle WebCenter Content: Imaging uses Oracle Internet Directory, you need to move users and groups into the LDAP identity store on the target system.
Move the Middleware home and binary files, as described in Section 21.3.4.
Move the configuration, as described in Section 21.3.5.
Note the following:
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. Although this is the default, Oracle does not recommend using this option because it moves test data, which might not be appropriate for your environment.
init: This option initializes a new Content Server or Records instance in the target system. It does not move data.
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:
Admin_Server_domain_home/ucm/cs/bin/intradoc.cfg Admin_Server_domain_home/ucm/urm/bin/intradoc.cfg Admin_Server_domain_home/ucm/ibr/bin/intradoc.cfg
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:
Admin_Server_domain_home/ucm/cs/bin/intradoc.cfg Admin_Server_domain_home/ucm/urm/bin/intradoc.cfg Admin_Server_domain_home/ucm/ibr/bin/intradoc.cfg
Note that in a high-availability setting where you have multiple WebCenter Content hosts, edit the file on each host.
When you use the copy option, the pasteConfig script copies the configuration of the domain, including the Administration Server and Managed Servers. In addition, that step:
Copies the configuration, including the modified settings, of Oracle WebCenter Content and its components.
Copies the Imaging sample input files, if they are in the domain directory.
Copies the BPEL credentials.
Moves Oracle WebCenter Capture.
Moves Oracle Web Services Manager policies.
Sets the Listen address for the Managed Server that contains Oracle Application Extension Framework (AXF).
Starts the Administration Server and Managed Servers.
For the Oracle WebCenter Content server and Oracle WebCenter Content: Records, the init option copies the following initialization properties from the source system:
IDC_Name IDC_Id InstanceMenuLabel InstanceDescription IntradocServerPort IdcCommandServerHost SocketHostAddressSecurityFilter HttpServerAddress HttpRelativeWebRoot UseSSL MailServer SysAdminAddress IsAutoNumber AutoNumberPrefix AdditionalRegisteredComponents AdditionalEnabledComponents
Move the configuration of the domain containing the WebCenter Content UI, as described in Section 21.3.5.
Configure users and groups, as described in Section 21.3.7.
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:
http://www.oracle.com/technetwork/middleware/content-management/overview/index.html
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:
connect('username', 'password', 'localhost:7001')
deleteCred('IRM', 'keystore:keystore_filename')
deleteCred('IRM', 'key:irm.jks:oracle.irm.wrap')
For the key, you use the keystore file name stored in the template.
Create a new keystore, as described in "Configuring the Keystore for Oracle IRM" in the Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content.
If the target environment is not using the same LDAP store as the source environment, migrate the users from the source environment to the target environment. See "Reassociating the Identity Store with an External LDAP Authentication Provider" in the Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content.
If you selected the init option in the move plan, the only step you need to take is Step 3, but you need to do that only if your environment has a full text search solution using external databases.
If you selected the copy option in the move plan, take the following steps:
Export the OCS database schema from the source environment, using the following command (ORACLE_HOME is the Oracle home for the Oracle Database):
ORACLE_HOME/bin/expdp \"sys/password as sysdba\" schemas=test_env_schema_name directory=directory dumpfile=ucm.dmp
Make sure that the dumpfile is in a location that can be accessed by the target database.
Import the OCS database schema that you exported from the source environment, using the following commands (ORACLE_HOME is the Oracle home for the Oracle Database):
ORACLE_HOME/bin/impdp \"sys/password as sysdba\" remap_schema=test_env_schema_name:prod_env_schema_name directory=directory dumpfile=ucm.dmp TABLE_EXISTS_ACTION=REPLACE
For a system that has a full text search solution using external databases, set up Oracle Secure Enterprise Search and configure it for WebCenter Content on the target system:
Install Oracle Secure Enterprise Search as described in the Oracle Secure Enterprise Search Installation and Upgrade Guide.
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.
Configured Imaging, extending the SOA domain, as described in "Extending an Existing Domain" in the Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content.
To complete the movement of Imaging to the new target environment:
Start the Administration Server and the Imaging Managed Server.
Move the Oracle Application Extension Framework (AXF) configuration database:
If you have installed the EBS adapter as part of AXF, export the following tables from the source EBS database schema and insert them into the target database schema:
AXF_COMMAND_PARAMETERS
AXF_COMMANDS
AXF_CONFIGS
AXF_FND_MAP
AXF_PROPERTIES
Modify the AXF_CONFIGS table in the EBS schema to point to the solution endpoint in the target AXF system, using the following command:
UPDATE AXF_CONFIGS SET SOLUTIONENDPOINT = 'AXFConnectionURL'
If you selected the init option in the move plan, you do not need to take any additional steps.
If you selected the copy option in the move plan, take the following steps:
Export the Records database schema (prefix_urmserver) from the source environment, using the following command (ORACLE_HOME is the Oracle home for the Oracle Database):
ORACLE_HOME/bin/expdp \"sys/password as sysdba\" schemas=test_env_schema_name directory=directory dumpfile=urm.dmp
Make sure that the dumpfile is in a location that can be accessed by the target database.
Import the Records database schema that you exported from the source environment, using the following commands (ORACLE_HOME is the Oracle home for the Oracle Database):
ORACLE_HOME/bin/impdp \"sys/password as sysdba\" remap_schema=test_env_schema_name:prod_env_schema_name directory=directory dumpfile=urm.dmp TABLE_EXISTS_ACTION=REPLACE
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.3.
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.
Start the Managed Server, as described in Section 4.2.3.
In this procedure, you have installed Oracle WebCenter Content components in the source environment and you want to move them to the target environment that already exists.
To move Oracle WebCenter Content to an existing target environment, perform the following tasks:
Task 1, "Move Oracle Information Rights Management to an Existing Target Environment"
Task 2, "Move Oracle WebCenter Content to an Existing Target Environment"
Task 3, "Move Oracle WebCenter Content: Imaging to an Existing Target Environment"
Task 4, "Move Oracle WebCenter Content: Records to an Existing Target Environment."
Task 5, "Move Oracle WebCenter Content Capture to an Existing Target Environment"
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:
connect("username", "password", "t3://adminServerHost:adminServerPort")
createCred("IRM", "keystore:irm.jks", "dummy", "secureproductionpassword")
createCred("IRM", "key:irm.jks:oracle.irm.wrap", "dummy", "secureproductionpassword")
For more information, see "Adding Passwords for the Keystore" in the Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content.
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:
DOMAIN_HOME/config/fmwconfig
If the target environment is not using the same user store as the source environment, migrate the users from the source environment to the target environment. See "Reassociating the Identity Store with an External LDAP Authentication Provider" in the Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content.
To move Oracle WebCenter Content to an existing target environment:
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.
To move Oracle WebCenter Content: Imaging from the source environment to an existing target environment, you use the same steps as described in Task 5, "Move Oracle WebCenter Content: Imaging to a New Target Environment". However, note the following about updating definitions on the target environment:
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.
Select Toggle On-Line.
To move Records to an existing target environment:
On the source environment, export any configuration settings that have changed, as described in "Exporting an Archive" in Oracle WebCenter Content Administrator's Guide for Records.
Copy the archive to the target environment.
Import the archive to the target environment, as described in "Importing an Archive" in Oracle WebCenter Content Administrator's Guide for Records.
To move Oracle WebCenter Content Capture to an existing target environment, you can use WLST commands to export artifacts from the source environment and import them into the target environment.
See "Performing Advanced Functions" in Oracle Fusion Middleware Administering Oracle WebCenter Capture.
The section describes how to move Oracle Hyperion Enterprise Performance Management System components to the target environment.
In this procedure, you have performed the following in the source environment:
Installed a database to be used for required schemas.
Created the needed schemas in the source environment using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
Installed Oracle WebLogic Server and created the Middleware home.
Installed and configured Oracle Hyperion Enterprise Performance Management components.
To move Oracle Hyperion Enterprise Performance Management to the target environment, perform the following tasks:
Task 1, "Move the Database, Middleware Home, and Perform the Initial Configuration"
Task 3, "Move Oracle Hyperion Calculation Manager to a Target Environment"
Task 4, "Move Oracle Hyperion Financial Reporting to a Target Environment"
Task 5, "Move Oracle Hyperion Provider Services to a Target Environment"
Task 6, "Move Oracle Hyperion Smart View to a Target Environment"
To move the database and Middleware home, and perform the initial configuration:
Move or create the database, as described in Section 21.3.3.
Move Identity Management components, as described in Section 21.4.1.
Move the Middleware home and binary files, as described in Section 21.3.4.
Move the configuration, as described in Section 21.3.5.
Configure users and groups, as described in Section 21.3.7.
For Oracle Essbase, only configuration settings need to be moved from the source environment to the target environment. For example, copy essbase.cfg from the source to the target environment:
ORACLE_INSTANCE/Essbase/essbaseserver1/bin/essbase.cfg
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).
You can export Oracle Hyperion Financial Reporting content from the source environment and import it into the target environment:
Export Financial Reporting report content from the source environment:
Log in to the source environment.
Select File, and then Export.
Navigate to and select the content or directory that you want to move to the target environment.
Export the selected content or directory to the local file system.
Import Financial Reporting report content into the target environment:
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.
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.
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.
To associate private connections:
Select Smart View, then Open, and then Smart View Panel.
Select Private Connections.
Enter the Provider Services URL: for example:
https://host.example.com/aps/SmartView
Log in to Oracle Hyperion Provider Services.
Select the Oracle Essbase application and log in.
Select the Oracle Essbase application, right-click, and select Add to Private Connections.
Enter the connection name or use the default name, and click OK.
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.
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.
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:
The following topics describe how to move the Web tier 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:
Task 1, "Move Oracle Access Manager If It Uses Oracle HTTP Server"
Task 2, "Move the Middleware Home and Perform the Initial Configuration"
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
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.
Configures WebGate if you are using Oracle Access Manager.
Start the processes in the Oracle instance:
ORACLE_INSTANCE/bin/opmnctl stopall ORACLE_INSTANCE/bin/opmnctl startall
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.
Configured the Oracle Web Cache instances as a Oracle Web Cache cluster.
Created a site and configured site-to-server mapping.
Configured Oracle Web Cache to have an SSL-enabled listening address.
Configured caching rules, and defined filters for request filtering.
Note:
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.
In that case, you can omit Task 1.
To move this environment to a new target environment, perform the following tasks:
In the target environment, move the binary files and create the Oracle instances and Oracle Web Cache instances:
Move the Middleware home and binary files, as described in Section 21.3.4.
Create the Oracle instances and the Oracle Web Cache instances:
From the command line, go the following directory:
(UNIX) ORACLE_HOME/opmn/bin (Windows) ORACLE_HOME\opmn\bin
Create the Oracle instances, using the opmnctl createinstance command. For example:
opmnctl createinstance -oracleInstance /scratch/Oracle/Middleware/inst1
-adminHost hostname -adminPort 7001
This command creates the Oracle instance and, by default, registers the instance with the Oracle WebLogic Server Administration Server.
Create the Oracle Web Cache instances, using the opmnctl createcomponent command. For example:
opmnctl createcomponent -componentType WebCache
-oracleInstance /scratch/Oracle/Middleware/inst1
-componentName webcache1
Register the Oracle instances, along with all of its components, with the Administration Server, using the opmnctl registerinstance command. For example:
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPasswordFile 'file_with_weblogic_admin_password' -oracleInstance ORACLE_INSTANCE_dir -oracleHome ORACLE_HOME_dir -instanceName Instance_name -wlserverHome Middleware_Home
For each Oracle Web Cache instance, take the following steps:
Copy the webcache.xml file, which is located in the following directory, from the source environment to a temporary location:
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
Make the following changes to webcache.xml in the temporary location:
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:
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
If any changes have been made to auditconfig.xml, copy the following file from the source environment to the corresponding target environment.
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name/auditconfig.xml (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name\auditconfig.xml
If any changes have been made to component-log.xml, first, edit the file to update the log path, and then copy the file from the source environment to the corresponding target environment.
If any changes have been made to the Oracle Web Cache error pages, which are located in the following directory, copy the error pages from the source environment to the target environment location:
(UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name/files (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name\files
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.
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.
For Oracle HTTP Server, see Section 21.4.6.2.1.
For Oracle Web Cache, perform Task 2 in Section 21.4.6.1.2.
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
This section describes the steps for moving Oracle Business Intelligence from the source environment to the target environment.
See Also:
"Managing the Repository Lifecycle in a Multiuser Development Environment" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for detailed information about the life cycle for the Oracle Business Intelligence repository, including source to target considerations for the repository.
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.
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:
Task 1, "Move the Database, Middleware Home, and Perform the Initial Configuration"
Task 4, "Move the Configuration of the Oracle BI Enterprise Edition Components"
Task 5, "Copy and Scale Out to New Cluster Hosts in the Target Environment"
Task 6, "Enable New Agents and Oracle BI Publisher Scheduled Jobs"
Task 8, "(Optional) Move Oracle Business Intelligence Related Applications"
To move the database and Middleware home, and perform the initial configuration:
Move or create the database, as described in Section 21.3.3.
Move Identity Management components, as described in Section 21.4.1.
Move the Middleware home and binary files, as described in Section 21.3.4.
Move the configuration of the domain and Node Manager, as described in Section 21.3.5.
Note that when you move the configuration of the domain, the pasteConfig script copies the configuration of the domain, including the Administration Server and Managed Servers.
Configure users and groups, as described in Section 21.3.7.
In the source environment, use the Administration Tool and the Oracle BI Server XML API to perform a patch merge of the source repository file (.rpd) with the target file.
See "Performing Patch Merges" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for more information.
Configure security if you use something other than the default Oracle WebLogic Server LDAP. For information, see Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.
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:
Oracle Internet Directory: See Task 3, "Move Oracle Internet Directory to the New Target Environment" in Section 21.4.1.1.
Oracle WebLogic Server: See "Migrating Security Data" in Oracle Fusion Middleware Securing Oracle WebLogic Server.
Oracle Platform Security Services: See Oracle Fusion Middleware Application Security Guide.
You move the configuration of the following Oracle BI EE components using the copyConfig, extractMovePlan, and pasteConfig scripts:
Oracle BI server
Oracle BI Presentation Services
Oracle BI Cluster Controller
Oracle BI Scheduler
JavaHost
Oracle Essbase server, if it is installed in your environment
To move the configuration of the components:
At the source Middleware home, execute the copyConfig script for the Oracle BI EE Oracle instance
The copyConfig script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/copyConfig.sh (Windows) ORACLE_COMMON_HOME\bin\copyConfig.cmd
See Section 20.2.1.5 for the syntax of the script.
The following shows the copyConfig command to move the Oracle instance containing the Oracle BI EE components. Note the additionalParams option, which is needed for Oracle Essbase.
copyConfig.sh -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-logDirLoc /tmp/logs
-archiveLoc /tmp/bi_archive/biconfig.jar
-sourceInstanceHomeLoc /scratch/Oracle/Middleware1/instances/instance1
-additionalParams essbaseServerUserName=Administrator,essbaseServerPassword=/scratch/arc_loc/pwd.txt
If you are copying the component to a different host, copy the archive file to that system.
Extract the move plan from the archive for the Oracle instance using the extractMovePlan script.
The extractMovePlan script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/extractMovePlan.sh (Windows) ORACLE_COMMON_HOME\bin\extractMovePlan.cmd
See Section 20.2.1.7 for the syntax of the extractMovePlan script.
For example:
extractMovePlan.cmd -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/bi_archive/biconfig.jar
-planDirLoc /tmp/Oracle/t2p_plans/bi
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.
The pasteConfig script is located in:
(UNIX) ORACLE_COMMON_HOME/bin/pasteConfig.sh (Windows) ORACLE_COMMON_HOME\bin\pasteConfig.cmd
See Section 20.2.1.10 for the syntax of the script.
The following shows the pasteConfig command to move the Oracle instance containing the Oracle BI EE components.
pasteConfig.cmd -javaHome /scratch/Oracle/Middleware1/jrockit_160_20_D1.1.0-18
-archiveLoc /tmp/bi_archive/biconfig.jar
-targetOracleHomeLoc /scratch/Oracle/Middleware/Oracle_BI1
-targetInstanceHomeLoc /scratch/Oracle/Middleware/instances/instance1
-targetInstanceName instance1
-movePlanLoc /tmp/Oracle/t2p_plans/bi_plan.xml
-domainHostName example.com
-domainPortNum 7001
-domainAdminUserName domain_admin_username
-domainAdminPasswordFile /tmp/pass/bi_password.txt
Note that the Oracle instance name in the target environment must be the same as the name in the source environment.
Copy the archive file (created in Task 1, "Move the Database, Middleware Home, and Perform the Initial Configuration") to the new cluster host.
Copy the following files to the new cluster host:
UNIX:
ORACLE_COMMON_HOME/bin/pasteBinary.sh ORACLE_HOME/jlib/cloningclient.jar
Windows:
ORACLE_COMMON_HOME\bin\pasteBinary.cmd
ORACLE_HOME\jlib\cloningclient.jar
Use the pasteBinary script to copy the Middleware home to the new cluster host, as described in Section 20.2.1.2.
Note: You must use exactly the same Middleware home name on the new cluster host that is used on the master host.
Use Fusion Middleware Control to scale out to the new cluster host.
For information, see "Using Fusion Middleware Control to Scale System Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Repeat the previous steps for each new cluster host.
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.
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.
For information on configuring for different types of actions, see "Configuring the Action Framework" in Oracle Fusion Middleware Integrator's Guide for Oracle Business Intelligence Enterprise Edition.
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.
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:
Task 2, "Deploy the Source Repository File to the Existing Target Environment"
Task 3, "Deploy the Source Oracle BI Presentation Catalog to the Existing Target Environment"
Task 4, "(Optional) Refresh Global Unique Identifiers (GUIDs)"
Task 5, "Enable New Agents and Oracle BI Publisher Scheduled Jobs"
Task 7, "(Optional) Move Oracle Business Intelligence Related Applications"
A patch applies a collection of bug fixes to an existing environment and includes new binary files and metadata updates.
Patch the source environment as required, and test.
Patch the existing target environment to the same level as the source environment on the master host and on all cluster hosts.
Note: Patching also includes non-Oracle Business Intelligence patches and one-off patches.
For information, see "Patching Oracle Business Intelligence Systems" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
In the source environment, use the Administration Tool and the Oracle BI Server XML API to perform a patch merge of the source repository file (.rpd) with the target file.
You must complete this task only if you are moving to an existing target environment and have made changes to the RPD file in the source environment.
See "Performing Patch Merges" in the Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for more information.
Use Fusion Middleware Control in the target environment to upload the RPD file.
For information, see "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
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.
Note:
You can also use the BIServerT2PProvisioner.jar utility to change and encrypt connection pool passwords in a repository. See "Using the BIServerT2PProvisioner.jar Utility to Change Connection Pool Passwords" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for more information.
(Optional) Make the target repository file read-only by selecting Disallow Online RPD Updates in the Performance tab of the Capacity Management page in Fusion Middleware Control.
Drag and drop new or updated folders from the source catalog into the target catalog as follows:
Open two Catalog Manager windows: one with the source catalog and another with the target catalog.
Selectively copy and paste the folders that you want from the source catalog into the target catalog.
Note: If you copy and paste folders where the same content has been changed in the source or target environments, then the source content overwrites the target content.
For information, see the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Use Fusion Middleware Control in the existing target environment to specify the location of the new catalog.
For information, see "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
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.
The GUIDs that are stored in the Oracle BI Presentation Catalog or in the RPD file can be resynchronized and refreshed as described in the following procedure. Before you begin this procedure, ensure that you are familiar with the information in "Manually Updating Oracle Business Intelligence Configuration Settings Not Normally Managed by Fusion Middleware Control" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
This procedure requires that you manually edit the configuration files to instruct Oracle BI Server and Oracle BI Presentation Services to refresh the GUIDs on restart. Once completed, you edit these files to remove the modification. For information about where to locate Oracle Business Intelligence configuration files, see the section that describes where configuration files are located, in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
To refresh the user GUIDs:
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:
<Catalog> <!--UpgradeAndExit>false</UpgradeAndExit--> <UpdateAccountGUIDs>UpdateAndExit</UpdateAccountGUIDs> </Catalog>
Stop and restart the managed processes using the opmnctl command with the parameters stopall and startall. You can use the parameter status to verify process status throughout.
The following components are involved: Presentation Services, Oracle BI Server, Oracle BI Scheduler, Oracle BI Cluster Controller, and Oracle BI JavaHost.
For information about using opmnctl commands, see "Using the OPMN command line to Start and Stop Oracle Business Intelligence System Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Edit the NQSConfig.INI file to reset the FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = YES to NO and restart the Oracle BI Servers.
Comment out the line added in Step 3 and remove the commenting from the original line so that it reads as shown in the following example:
<Catalog> <UpgradeAndExit>false</UpgradeAndExit> <!--UpdateAccountGUIDs>UpdateAndExit</UpdateAccountGUIDs--> </Catalog>
Restart Presentation Services for the instanceconfig.xml file that was updated.
Ensure that Oracle WebLogic Server and the system components are also running. If they are not running, then restart them.
For information, see "Starting and Stopping the Oracle Business Intelligence Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
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.
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.
For information on configuring for different types of actions, see "Configuring the Action Framework" in Oracle Fusion Middleware Integrator's Guide for Oracle Business Intelligence Enterprise Edition.
Move Oracle Business Intelligence related applications (such as Calculation Manager, Financial Reporting, and Oracle BI for Microsoft Office) to the existing target environment. For information, see Section 21.4.5.
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:
Moving Oracle BI EE to an Existing Target Environment When New Hardware Is Available
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 available:
Task 1, "Follow the Steps for Moving to a New Target Environment"
Task 2, "Switch Users from the Existing Target Environment to the New One"
Task 3, "Remove the Existing Target Environment and Prepare It for the Next Patch"
Complete the steps in Section 21.4.7.1 for moving to a new target environment.
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.
Use a load balancer such as Oracle Web Cache to redirect users from a standard URL to the new target environment.
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.
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.
Patch the host in the target environment. Doing so imposes less downtime on users than having to patch multiple cluster hosts.
For information, see the Oracle Fusion Middleware Patching Guide.
Deinstall all the Oracle Business Intelligence software on the cluster hosts. For information, see the Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence.
Complete the tasks beginning with Task 5, "Copy and Scale Out to New Cluster Hosts in the Target Environment" in Section 21.4.7.1.
The following topics describe how to move Oracle Real-Time Decisions (Oracle RTD) from the source environment to a new target environment:
Moving Oracle Real-Time Decisions to a New Target Environment
Moving Oracle Real-Time Decisions to an Existing Target Environment
To move the environment to the target environment, perform the following tasks:
Task 1, "Move the Database, Middleware Home, and Perform the Initial Configuration"
Task 2, "Install Oracle RTD Clients (If Used) on the Target Environment"
Task 4, "Edit Additional Oracle RTD Components for the Target"
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.
Move the configuration, as described in Section 21.3.5.
Note that when you move the configuration, the pasteConfig script copies the configuration of the domain, including the Administration Server and Managed Servers.
If used for the integration of Oracle RTD to a customer's front-end applications, Oracle RTD clients must be installed in the target environment, according to the setup steps outlined in the Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.
Configuration of client parameters should reflect values specific to the target architecture.
Move Oracle RTD Inline Services that exist on the source environment to the target environment:
Moving Inline Services to the target environment can be performed in two ways:
Command-line deployment: For more information, see the chapter "Command Line Deployment of Inline Services" in Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.
Decision Studio deployment: For information about Oracle RTD deployment in Decision Studio, see the chapter "Deploying, Testing, and Debugging Inline Services" in Oracle Fusion Middleware Platform Developer's Guide for Oracle Real-Time Decisions.
Note:
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.
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.
After the target environment has been created, typical Oracle RTD incremental changes include the following:
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.
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.
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 both cases, you have performed the following in the source environment:
Installed a database to be used for these components.
Created the needed schemas in the source environment using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
For Oracle BI Discoverer, installed an additional database to be used for the End User Layer (EUL), Discoverer catalog, and OLAP catalog.
Installed Oracle WebLogic Server and created a Middleware home.
Installed and configured Identity Management, including Oracle Internet Directory and Oracle Single Sign-On, and a database for Identity Management data.
Installed and configured Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle BI Discoverer.
For Oracle Portal:
Created users and groups and assigned page access permissions to the groups.
Created new page groups, new templates, and new pages, and added contents, such as items and portlets, to the pages.
Customized pages, layouts, items, and portlets.
Registered producers (database, Web, and WSRP) and customized the portlet from the producers.
Registered external applications.
Set up Forms applications.
Configured Oracle Reports instances and created connections to the database.
For Oracle BI Discoverer:
For Discoverer Plus, created a new workbook with parameters, calculations, conditions, and totals. Saved the workbook.
For Discoverer Viewer, opened the workbook created in Discoverer Plus and performed some formatting, sorting, exporting, and drilling.
For Discoverer Plus OLAP, created a new workbook in Discoverer Plus OLAP with custom members, custom expressions, and saved selections. Saved the workbook.
For Viewer OLAP, opened the workbook created in Discoverer Plus OLAP and performed some operations such as exporting, linking and unlinking layouts.
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:
Task 1, "Move the Database, Middleware Home and Perform the Initial Configuration"
Task 3, "Move Oracle Forms Services to the New Target Environment"
Task 5, "Move Oracle Business Intelligence Discoverer to the New Target Environment"
To move the database and Middleware home, and perform the initial configuration:
Move or create the database and the schemas, as described in Section 21.3.3.
Move the Middleware home and binary files, as described in Section 21.3.4.
Configure the components, as described in the Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer. For Oracle Portal, this includes installing Oracle Internet Directory and Oracle Single Sign-On Release 10.1.4.3.
For Oracle Portal, specify the credentials to connect to Oracle Internet Directory at the Configure Components screen.
To move the Oracle Portal configuration to a new target environment:
Create a transport set on the source instance that contains the list of page groups to be moved. For information about creating a transport set, see "Creating Transport Sets" in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.
Export the data from the source environment, as described in "Exporting Data" in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.
On the target environment, create a database link to the source environment, as described in "Creating a Database Link" in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.
Before moving data from a source portal, you must register the portal. Once registered, the source portal can be selected and used to specify the data source in the Transport Sets. See "Register a Source Portal" in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.
Before importing your objects, you must move the contents of the transport set to the transport set tables on the target system. You do this by acquiring the transport set from the source environment, using the registered database link described in Step 1. For information about acquiring the transport set, see "Moving Data to the Target System" in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.
Import the data, as described in "Import in Oracle Portal" in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.
Move users and groups from the LDAP directory in the source environment to the LDAP directory in the target environment, as described in "Migrating Users and Groups" in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.
Import the external applications list using the SSOMig utility:
Run ssomig in export mode on the source environment. The command creates a dump file. For example:
ssomig -export -s orasso -p orasso_schema_password -c tns_alias_for_sso_schema -log_d directory_where_dump_needs_to_be_created -log_f ssomig.log -d ssomig.dmp
Run ssomig in import mode on the target environment, specifying the dump file created in the previous step. For example:
ssomig -import -overwrite -s orasso -p orasso_schema_password -c tns_alias_for_sso_schema -d ssomig.dmp -log_d directory_where_dump_is_located -discoforce
For the following files, copy any customizations that you want to maintain from the source environment file to the target environment file:
DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/portal_plsql.conf DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/portal_dads.conf DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/appConfig.xml
If you modified any configuration files, restart the Managed Server WLS_PORTAL.
Note that when Oracle Portal is moved from source to target using export and import, portlet customizations are included in transport set. You do not need to take any additional steps.
To move Oracle Forms Services to a new target environment:
Stop the Oracle instances processes and the Oracle Forms Services Managed Servers in the target environment, using the following commands:
ORACLE_INSTANCE/bin/opmnctl stopall DOMAIN_NAME/bin/stopManagedWebLogic.sh managed_server_name admin_url username password
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.
Create the relevant target database entries in the SQL*Net configuration file, tnsnames.ora.
Forms applications have single sign-on user names and passwords mapped to the database connect strings. This information is stored in Oracle Internet Directory. Move the Forms RAD data from Oracle Internet Directory in the source environment to Oracle Internet Directory in the target environment. See Step 3 in Task 1, "Move Oracle Internet Directory to an Existing Target Environment" in Section 21.4.1.
Copy any customizations in the following files that you want to maintain from the source environment file to the target environment file:
| Type of File | Location |
|---|---|
|
Forms application configuration |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_version/config/formsweb.cfg |
|
Forms server configuration |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_version/config/default.env |
|
Forms HTML template |
ORACLE_INSTANCE/config/FormsComponent/forms/server/base.htm ORACLE_INSTANCE/config/FormsComponent/forms/server/basejpi.htm |
|
WebUtil configuration |
ORACLE_INSTANCE/config/FormsComponent/forms/server/webutil.cfg
|
|
WebUtil HTML template |
ORACLE_INSTANCE/config/FormsComponent/forms/server/webutiljpi.htm ORACLE_INSTANCE/config/FormsComponent/forms/server/webutilbase.htm |
|
Forms OHS directives configuration |
ORACLE_INSTANCE/config/OHS/OHS_name/moduleconf/forms.conf |
If you modified the Oracle HTTP Server forms.conf file, restart Oracle HTTP Server:
ORACLE_INSTANCE/bin/opmnctl restartproc ias-component=ohs_name
Copy the following files from the source environment to the target environment:
| Type of File | Location |
|---|---|
|
Forms application configuration client-side downloadable pluggable contents |
These files are user customizations such as images and are in a location accessible to a Web browser. |
|
Forms trace configuration |
ORACLE_INSTANCE/config/FormsComponent/forms/server/ftrace.cfg
|
|
Any customized Forms Java EE applications .ear file |
ORACLE_HOME/forms/j2ee
|
|
JVM Controllers configuration |
ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm/jvmcontrollers.cfg
|
|
FMA configuration |
ORACLE_INSTANCE/config/FormsComponent/forms/search_replace.properties ORACLE_INSTANCE/config/FormsComponent/forms/converter.properties |
|
Forms utilities-specific configuration wrapper shell scripts |
UNIX: ORACLE_INSTANCE/bin/frmbld.sh ORACLE_INSTANCE/bin/frmcmp.sh ORACLE_INSTANCE/bin/frmplsqlconv.sh ORACLE_INSTANCE/bin/frmxmlsg.sh ORACLE_INSTANCE/bin/frmcmp_batch.sh ORACLE_INSTANCE/bin/frmf2xml.sh ORACLE_INSTANCE/bin/frmxml2f.sh ORACLE_INSTANCE/bin/frmxmlv.sh Windows: ORACLE_INSTANCE\bin\frmplsqlconv.bat ORACLE_INSTANCE\bin\frmxmlsg.bat ORACLE_INSTANCE\bin\frmf2xml.bat ORACLE_INSTANCE\bin\frmxml2f.bat ORACLE_INSTANCE\bin\frmxmlv.bat |
For the Forms utilities-specific configuration wrapper shell scripts, replace any occurrences of the Oracle home and Oracle instance with the details for the target environment.
Start the components in the instance and start the Managed Server, using the following commands:
ORACLE_INSTANCE/bin/opmnctl startall DOMAIN_NAME/bin/startManagedWebLogic.sh managed_server_name admin_url
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.
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.
| Type of File | Location |
|---|---|
|
Reports standalone server configuration |
ORACLE_INSTANCE/config/ReportsServerComponent/server_name/rwserver.conf ORACLE_INSTANCE/config/ReportsServerComponent/server_name/jdbcpds.conf ORACLE_INSTANCE/config/ReportsServerComponent/server_name/xmlpds.conf ORACLE_INSTANCE/config/ReportsServerComponent/server_name/textpds.conf ORACLE_INSTANCE/config/ReportsServerComponent/server_name/rwnetwork.conf ORACLE_INSTANCE/config/ReportsServerComponent/server_name/component-logs.xml ORACLE_INSTANCE/config/ReportsServerComponent/server_name/logging.xml |
|
Reports in-process server and servlet configuration |
DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/cgicmd.dat DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/rwservlet.properties DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/rwserver.conf DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/jdbcpds.conf DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/xmlpds.conf DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/textpds.conf DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/rwnetwork.conf DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/logging.xml DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/logmetadata.xml DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/jazn-data.xml |
|
Reports Tools configuration |
ORACLE_INSTANCE/config/ReportsToolsComponent/ReportsTools/rwbuilder.conf ORACLE_INSTANCE/config/ReportsToolsComponent/ReportsTools/rwnetwork.conf ORACLE_INSTANCE/config/ReportsToolsComponent/ReportsTools/jdbcpds.conf ORACLE_INSTANCE/config/ReportsToolsComponent/ReportsTools/xmlpds.conf ORACLE_INSTANCE/config/ReportsToolsComponent/ReportsTools/textpds.conf ORACLE_INSTANCE/config/ReportsToolsComponent/ReportsTools/component-logs.xml ORACLE_INSTANCE/config/ReportsToolsComponent/ReportsTools/logging.xml |
|
Reports Bridge configuration |
ORACLE_INSTANCE/config/ReportsBridgeComponent/bridge_name/rwbridge.conf ORACLE_INSTANCE/config/ReportsBridgeComponent/bridge_name/rwnetwork.conf ORACLE_INSTANCE/config/ReportsBridgeComponent/bridge_name/component-logs.xml ORACLE_INSTANCE/config/ReportsBridgeComponent/bridge_name/logging.xml |
|
Reports shell scripts |
(UNIX) ORACLE_INSTANCE/config/reports/bin/rw*.sh (Windows) ORACLE_INSTANCE\config\reports\bin\rw*.bat (UNIX) ORACLE_INSTANCE/config/reports/bin/reports.sh (Windows) ORACLE_INSTANCE\config\reports\bin\reports.bat (UNIX) ORACLE_INSTANCE/config/reports/bin/namingservice.sh (Windows) ORACLE_INSTANCE\config\reports\bin\namingservice.bat |
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.
| Type of File | Location |
|---|---|
|
JPS configuration |
DOMAIN_HOME/config/fmwconfig/jps-config.xml DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml |
|
Forms and Reports common files |
Font setup, aliasing, subsetting, embedding: ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/uifont.ali Printer configuration (UNIX only): ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/uiprint.txt Toolkit configuration, encoding (UNIX only): ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/Tk2Motif.rgb PPD files (UNIX only): ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon//tk/admin/PPD/* AFM files (UNIX only): ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/AFM/* |
If you created additional Oracle Reports Server component instances in the source environment, create these in the target environment using opmnctl.
For resources related to Oracle Reports Server, take the following actions:
Copy any fonts used in the source environment from the directory specified by environment variable REPORTS_FONT_DIRECTORY to target environment. By default, they are in ORACLE_INSTANCE/reports/fonts.
Move the Common UNIX Printing System (CUPS) printing configuration to the target environment, if applicable.
For more information about using CUPS with Oracle Reports, see "Enhanced Printing on Linux Using CUPS" in the Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services.
For Reports definition files and data tables, take the following actions:
Copy the reports files, such as RDF, JSP, REP, and XML files, used in the source environment to the target environment.
Deploy JSP Web reports to the target environment in the following location:
DOMAIN_HOME/servers/WLS_REPORTS/tmp/_WL_user/reports_version/uxabaw/web.war
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:
ReportsServer_hostname_instanceName rep_wls_reports_hostname_instanceName
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.
Move any user and reports server security policy information. See "Securing Oracle Reports" in the Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services.
If you use Oracle Internet Directory as the identity and policy store, move the Forms RAD data from Oracle Internet Directory in the source environment to Oracle Internet Directory in the target environment. See Step 3 in Task 1, "Move Oracle Internet Directory to an Existing Target Environment" in Section 21.4.1.
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.
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:
ORACLE_INSTANCE/config/PreferenceServer/disco-comp-name/.reg_key.dc ORACLE_INSTANCE/config/PreferenceServer/disco-comp-name/pref.txt ORACLE_INSTANCE/config/PreferenceServer/disco-comp-name/defaults.txt
If you have changed the Oracle BI Discoverer settings, copy following files from the source environment to the target environment:
DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/configuration.xml DOMAIN_HOMEconfig/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/configuration-preview.xml
In the configuration.xml file, change the values of the following elements to reflect the target environment:
applicationURL
oracleInstance
discovererComponentName
If you have changed the server configuration files, copy the following file from the source environment to the target environment:
ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml
Copy the following file from the source environment to the target environment:
ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf/module_disco.conf
In the file, change the values of the following elements to reflect the target environment:
WebLogicCluster. Valid only if a cluster exists.
WebLogicHost
WebLogicPort
Copy the following files from the source environment to the target environment:
DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/base-descktop.xss DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/blstyles.xss DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/blaf.xss DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/dc-blaf-preview.xsd DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/dc-blaf-preview.xss DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/dc-blaf.xsd DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/dc-blaf.xss minimal-desktop.xss DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/minimal-pda.xss DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/oracle-desktop.xss DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/oracle-pda.xss DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/pocketPC.xss DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/simple-desktop.xss DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/swan-desktop.xss DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/f6k79t/configuration/styles/version.txt
Copy some or all of the files in the following directory, depending on which files you use:
DOMAIN_HOME/servers/WLS_DISCO/tmp/_WL_user/discoverer_version/51oeh7/war/custom_logos
The files that are used are listed in the configuration.xml file.
To use the same database service entries, copy the following file from the source environment to the target environment:
ORACLE_HOME/network/admin/tnsnames.ora
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 data from the source environment to the target environment:
Create the EUL user and an empty EUL on the target database. See "How to Create an End User Layer in a New Database User" in the Oracle Fusion Middleware Administrator's Guide for Oracle Business Intelligence Discoverer.
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:
ORACLE_ HOME/discoverer/util/eul5_id.sql
For more information, see "Creating and Maintaining End User Layers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Business Intelligence Discoverer.
Move the catalog data from the source environment to the target environment:
Install the catalog in the target OLAP database, using the following command:
java -classpath d4o.jar oracle.dss.d4o.administration.D4OCommand install -h hostname -po port -sid sid -su "sys as sysdba" -sp password -p d4osys-password -t users
Authorize users in the target OLAP database, using the following command:
java -classpath d4o.jar oracle.dss.d4o.administration.D4OCommand authorize -h hostname -po port -sid sid -p d4osys-password -u user
Export the Discoverer catalog from the source database and import it into the database in the target environment by using the OLAP command utility. For more information see "Using the Discoverer Plus OLAP Command Line Utility to Manage the Discoverer Catalog" in the Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Discoverer.
Move Portlet data from the source Discoverer metadata repository to the target Discoverer metadata repository:
Use the Oracle Database export and import utilities.
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:
Task 1, "Move Oracle Portal to an Existing Target Environment"
Task 2, "Move Oracle Forms Services to an Existing Target Environment"
Task 3, "Move Oracle Reports to an Existing Target Environment"
Task 4, "Move Oracle Business Intelligence Discoverer to an Existing Target Environment"
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.
To move Oracle Portal to an existing target environment, take the steps described in Task 2, "Move Oracle Portal to the New Target Environment" in Section 21.4.9.1.
To move Oracle Forms Services to the existing target environment:
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.
Restart the components:
ORACLE_INSTANCE/bin/opmnctl stopall ORACLE_INSTANCE/bin/opmnctl startall
To move Oracle Reports to an existing target environment, take the same steps as described in Task 4, "Move Oracle Reports to the New Target Environment" in Section 21.4.9.1.
In this procedure, you primarily use the source environment to create EULs for developing a business area without compromising the performance of target environments.
To move Oracle BI Discoverer to an existing target environment:
Move the configuration files that are listed in Steps 1 and 5 in Task 5, "Move Oracle Business Intelligence Discoverer to the New Target Environment" in Section 21.4.9.1.
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.
The following topics describe how to move Oracle Data Integrator from the source environment to the target environment:
In both cases, you have performed the following in the source environment:
Installed Oracle WebLogic Server and created the Middleware home for the Java components.
Created the needed schemas in the source environment using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
Installed Oracle Data Integrator.
Configured and deployed Oracle Data Integrator Java components using the Configuration Wizard. The Java components can connect and use the source repositories.
The source environment should be fully functional in terms of Oracle Data Integrator agents in Oracle WebLogic Server and have a working repository.
In this procedure, you have installed Oracle Data Integrator in the source environment and you want to move it to a target environment which does not yet exist.
To move Oracle Data Integrator to a new target environment, perform the following tasks:
Task 1, "Move the Database, Middleware Home, and Perform the Initial Configuration"
Task 3, "Restart the Java EE Agents in the Target Environment"
To move the database, Middleware home, and perform the initial configuration on the target environment:
Create the required master and work repositories schemas in the target database using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
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:
./copyConfig.sh -javaHome /private/Middleware/jrockit_160_26_D1.2.0-5 -archiveLocation /tmp/ar.jar -sourceMWHomeLoc /private/Middleware -sourceDomainLoc /scratch/oracle/config/domains/base_domain -domainHostName host1.example.com -domainPortNo 7001 -domainAdminUserName weblogic -domainAdminPasswordFile /tmp/wls_pswd.txt -additionalParams odiCustomArg=/private/t2p/odiCustomArg.xml
The file odiCustomArg.xml is the configuration file. A sample file is located in:
MW_HOME/ODI_Oracle_Home/clone/provision/odiCustomArg.xml
The configuration file that you pass to the script contains the connection information for all Oracle Data Integrator master repositories. The following shows a sample configuration file:
<?xml version="1.0" encoding="UTF-8" ?> <config> <jps-config-path>/ODI_HOMEoracledi/client/odi/bin/odi-jps-config-jse.xml</jps-config-path> <masterRepositories> <masterRepository> <driver>oracle.jdbc.OracleDriver</driver> <url>jdbc:oracle:thin:@localhost:1521:sid/example.com</url> <schema>odi_master_11g</schema> <schema_password_file>/tmp/all_pswd.txt</schema_password_file> <supervisor>SUPERVISOR</supervisor> <supervisor_password_file>/tmp/sup_pswd.txt</supervisor_password_file> </masterRepository> <masterRepository> .....content for 2nd master repository </masterRepository> </masterRepositories> </config>
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.
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:
Physical Agents: Change the host, port, and Web application context (for Java EE Agent) to match the configuration of the target environment.
Data Servers: Change the data server connection information (JDBC, JNDI, data source name) to match the configuration of the target environment.
Physical Schemas: The schemas (including file folder location) defined for the data servers must match the configuration of the target environment.
Restart the Java EE agents in the target environment. These agents start processing the scheduled scenarios.
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.
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:
Follow the steps in Section 21.3.1 through Section 21.3.4.
Execute the copyConfig and extractMovePlan scripts on the host containing the Administration Server, as described in Section 21.3.5.
Execute the pasteConfig script on the target host for the Administration Server, as described in Section 21.3.5.
Invoke the pack command (in managed mode) on the target Administration Server host for the Managed Servers that are on different hosts.
Invoke the unpack command on the target hosts for the Managed Servers.
For more information about pack and unpack, see Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands
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.
Then, you configure your target environment for Oracle RAC, as described in the Oracle Fusion Middleware High Availability Guide, especially "Considerations for High Availability Oracle Database Access."
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).
Then, you can add an additional data source, as described in Section 10.2.2.1.
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 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:
-invPtrLoc custom_inventory_pointer_location
-invPtrLoc oracle_common/oraInst.loc
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.
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:
Stop all processes related to the domain.
Delete the following directories:
MW_HOME/user_projects/domains/domain_name MW_HOME/user_projects/applications/domain_name
Drop the schemas and re-create them using RCU.
In addition, if the Oracle Platform Security reassociation failed:
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 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:
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size: '10000080' bytes exceeds the configured maximum of: '10000000' bytes for protocol: 't3'.
You use the T2P_JAVA_OPTIONS environment variable, as described in Section 20.2, to pass the -Dweblogic.MaxMessageSize=20000000 property to both the copyConfig and pasteConfig scripts.
When you use the pasteConfig operation when Oracle B2B inbound/outbound dispatcher is configured, you may receive the following error:
oracle.mds.exception.MDSRuntimeException: java.sql.SQLException: Data Source mds-soa does not exist. Data Source mds-soa does not exist.
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.)
Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment.
Click Servers. The Summary of Servers page appears.
Select the server.
Select the Server Start tab.
In the Arguments field, enter the following parameters:
-Dtangosol.coherence.wkan=hostname -Dtangosol.coherence.localhost=hostname -Dtangosol.coherence.localport=localport_number -Dtangosol.coherence.wka1.port=port_number_for_Coherence
Click Save and Activate Changes.
Start the server.