This chapter describes how to move Oracle Fusion Middleware from a test environment to a production environment. You can develop and test applications in a test environment, and then eventually roll out the test applications and, optionally, test data to your production 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 Test to a Production Environment
Moving Identity Management Components to a Production Environment
Moving Oracle Business Intelligence Components to a Production System
Moving Oracle Enterprise Content Management to a Production System
Considerations in Moving to and from an Oracle RAC Environment
See:
Section 20.6 for information about recovering from errors when you use the scripts described in this chapter.This chapter describes how to move installations from a test environment to a production environment.
Note:
The target environment must have the superuser or administrative user, with the same credentials, as the user at the source environment.After you complete the movement of the installation, you can modify the user on the target environment.
The general steps are:
If your environment uses a database, create a new database or copy the database from the test environment to the production environment.
Note that the database in the production environment must be the same type of database as in the test environment. For example, if the database in the test environment is an Oracle Database, the database in the production environment must be an Oracle Database.
Move a copy of the Middleware home from the test environment to the production environment using the copyBinary and pasteBinary commands, as described in Section 20.5.1.
Note:
The production environment must be on the same operating system as the test environment. Also, the operating system architecture must be the same in both environments. For example, both environment must be running 32-bit operating systems or 64-bit operating systems.
The target environment must have the superuser or administrative user as the user at the source environment. The user's password can be different; you specify it on the command line when you use the pasteBinary command.
After you complete the movement of the installation, you can modify the user on the target environment.
Move a copy of the configuration of components, as described in Section 20.5.2 and Section 20.5.3.
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.)
When you move the configuration of components, the script copyConfig handles only global data sources defined in each Oracle WebLogic Server domain. For application-level data sources, you must deploy the ADF application configured with the application-level data sources to a server in the target domain, and manually configure the data sources on the target domain.
If an external LDAP was used in the test environment, move security information, such as users and groups, the identity and policy stores, and credentials. (The default security information is moved when you move the configuration of components.)
Move other data, such as UMS user messaging preferences, data for Oracle WebCenter applications, or Oracle Web Cache configuration files. Modify any information that is specific to the new environment such as host name or ports.
The following topics describe how to move Identity Management from a test environment to a production environment:
In both scenarios, you have performed the following in the test 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 needed schemas using RCU.
Installed and configured Identity Management, including the following components:
Oracle Internet Directory
Oracle Virtual Directory
Oracle Directory Integration Platform
Oracle Identity Federation
Oracle Directory Services Manager
Oracle Platform Security
Oracle Web Services Manager
SSL
Oracle Identity Manager
Oracle Identity Management Navigation
Oracle Adaptive Access Manager
Oracle Access Manager 11g or Oracle Access Manager 10g
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. In addition, you may have made other configuration changes such as adding ACLs, changing schemas, the Listener configuration, server configuration, plug-ins, mappings, auditing, logging, and keystores.
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.
For Oracle Platform Security, created security policies and stored credentials in the Credential Store Framework (CSF). Oracle Platform Security is useful for applications such as ADF, WebCenter, and SOA Composite applications.
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 a production environment, you use trusted CA-signed certificates.)
In this scenario, you have installed Identity Management components, such as Oracle Internet Directory, Oracle Virtual Directory, and Oracle Directory Integration Platform, in a test environment and you want to move them to a production environment that does not exist.
To move this environment to a production environment, perform the following tasks:
Task 2, "Move the Middleware Homes and Domain Configuration to the New Production Environment"
Task 3, "Move Oracle Internet Directory to the New Production Environment"
Task 4, "Move Oracle Virtual Directory to a New Production Environment"
Task 5, "Move Oracle Directory Integration Platform to a New Production Environment"
Task 6, "Move Oracle Identity Federation to a New Production Environment"
Task 7, "Move Oracle Identity Manager to a New Production Environment"
Task 8, "Move Oracle Identity Navigator to a New Production Environment"
Task 9, "Move Oracle Access Manager 11g to a New Production Environment"
Task 10, "Move Oracle Access Manager 10g to a New Production Environment"
Task 11, "Move Oracle Adaptive Access Manager to a New Production Environment"
Task 12, "Move Audit Policies to a New Production Environment"
Task 13, "Move Oracle Platform Security to a New Production Environment"
Task 14, "Move Oracle Web Services Manager to a New Production Environment"
Some components, such as Oracle Internet Directory, Oracle Directory Integration Platform (which depends on Oracle Internet Directory), and Oracle Identity Federation, require a database.
You can create a duplicate database using the Oracle Database RMAN duplicate command. The duplicate database must be created with a different DBID than the source database, so that it functions entirely independently.
To move an Oracle Database, Release 11g, to the production system:
On the production system, 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 test environment, edit the tnsnames.ora file, adding an entry for the database on the production environment.
The following shows an example of the tnsnames.ora file. In the example, testDB is the database on the test environment and prodDB is the database on the production 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 test environment, edit the listener.ora file, adding an entry for the database on the production 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 production 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 test environment. The following command creates the password file:
orapwd password=password file=ORACLE_HOME/dbs/orapwproddb
In the production 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 production environment, set the ORACLE_SID environment variable to point to the production database if it is not already set. Then, start the database in NOMOUNT mode. For example:
SQL> STARTUP NOMOUNT PFILE='ORACLE_HOME/dbs/pfile'
To move the database from the test system to the production system, use RMAN.
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, which is available at:
http://www.oracle.com/technology/documentation/database.html
See Also:
The Oracle10g Database documentation to move a Release 10g Oracle DatabaseYou move all Identity Management Middleware homes to the production environment. To move a copy of the Middleware home and the domain configuration from the test environment to the production environment:
Move a copy of the Middleware home containing the Identity Management components from the test environment to the production environment using the copyBinary and pasteBinary scripts. See Section 20.5.1.
The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.
Move a copy of the configuration of each domain containing the Identity Management configuration, as described in Section 20.5.2 and Section 20.5.2.1. 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.
Moves Oracle Platform Security.
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.
Configures data sources.
Configures JMS resources.
Starts the Administration Server.
To move Oracle Internet Directory to a new production environment:
Move the Oracle Internet Directory configuration, as described in Section 20.5.3.2.
If you have configured Oracle Internet Directory replication in the test environment, you must reconfigure it again in the production environment after moving. The replication configuration is not moved from the test to the production 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 production environment:
Move the Oracle Virtual Directory configuration, as described in Section 20.5.3.3.
To move Oracle Directory Integration Platform to a new production system:
Move Oracle Internet Directory, as described in Task 3, "Move Oracle Internet Directory to the New Production Environment".
Oracle Directory Integration Platform profiles reside in Oracle Internet Directory. If you have correctly moved Oracle Internet Directory to the production system, the profiles are carried over to the production system.
If you configured SSL on the test environment, that configuration is not moved to the production environment. You must configure SSL on the production environment. See Section 6.5.4.3.
An Oracle Identity Federation setup involves different modules, such as the Credential Store Framework (CSF) for credentials, JPS authorization rules to access CSF and Audit, that are configured, and that you would need to move. Because of that, Oracle recommends that you install a new Oracle Identity Federation server, then configure the new instance, as opposed to be moving settings from the test environment to the production environment.
See Also:
Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation, in the section titled "Host Connection Properties," for a discussion of the Oracle Identity Federation server hostname.
You can use the Oracle Identity Manager Deployment Manager to move most metadata from a test environment to a production environment. The following table lists the entities that you can move using Deployment Manager:
Entities | Deployment Manager Category |
---|---|
Roles | Role |
Organizations | Organization |
Access Policies | Access Policy |
Attestation Processes | Attestation Process |
Authorization Policies | Authorization Policy |
User Metadata | User Metadata |
Roles and Org Metadata | Roles and Org Metadata |
Scheduled Tasks | Scheduled Task |
Scheduled Jobs | Job |
IT Resources | IT Resource |
Resource Objects | Resource |
Lookup Definitions | Lookup |
Process Forms | Process Form |
Provisioning Workflows and Adapters | Process |
Resource Forms | Resource Form |
Data Object Definitions | Data Object Definition |
Rules | Rule |
Notification Templates | Notification Template |
GTC Providers | GTC Provider |
Error Codes | Error Code |
System Properties | System Property |
EmailDef | Email Definition |
EventHandler | Event Handlers |
PasswordPolicy | Password Policy |
GenericConnector | Generic Connector |
ITResourceDef | IT Resource Definition |
Request Templates | Request Template |
Request Datasets | Request Dataset |
Approval Policies | Approval Policy |
To move Oracle Identity Manager to a new production environment:
On the test environment, use the Deployment Manager to export the metadata for the entities listed in the preceding table. In the wizard, select the entities' children and dependencies. See "Exporting Deployments" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager for information about how to export metadata.
The data is exported as .xml files.
On the production environment, use the Deployment Manager to import the metadata for the entities listed in the preceding table. See "Importing Deployments" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager for information about how to import metadata.
The Deployment Manager does not manage resource bundles, jars and plug-ins, and Custom Reconciliation Profiles.
Move the Approval Workflows, which are SOA composite applications, using JDeveloper:
Copy all of the files in the JDeveloper project from the test environment to the production environment, using any standard file transfer method.
In the application, change any calls to external systems to point to the systems in the production environment. For example, if the workflow uses an LDAP server in the test environment, change references to point to an LDAP server in the production environment.
Use JDeveloper to build the sca jar file from the SOA composite.
Deploy the SOA composite application on the production environment, using the SOA Deployment wizard in Fusion Middleware Control (see Section 10.5.1) or JDeveloper.
In the test environment, export localization resource bundles, as well as the following sets of plug-in code from the test environment:
Scheduled Task jars
Adapter Java tasks
Third-party jars
Other plug-in code jars
Take the following steps:
Edit the following script, which exports the entities into a zip file:
(UNIX) OIM_ORACLE_HOME/server/bin/exportMetadata.sh (Windows) OIM_ORACLE_HOME\server\bin\exportMetadata.bat
Edit the script to specify the following values:
CONTEXT: The URL of the application. For example, weblogic.jndi.WLInitialContextFactory.
EXPORT_LOCATION: The full path to the directory where the zip file is to be created.
TEMP_LOCATION_TO_EXTRACT: The full path to a directory where the files are to be stored temporarily before they are packaged into a zip file.
CONTROL_FILE: An XML file that controls what needs to be exported. You create the file, as described in Step b.
Create a control file to specify the types of entities to be exported. The following example shows a sample control file that specifies that all custom resource bundles, jar files, and plug-ins be exported:
<?xml version='1.0' encoding='UTF-8'?> <MigrationDetails Operation ="Export"> <entityDetails> <EntityType>CustomResourceBundles</EntityType> <FilteringCriteria> <Attribute> <Name>Resource_Type</Name> <Filter>*</Filter> </Attribute> </FilteringCriteria> </entityDetails> <entityDetails> <EntityType>Jars</EntityType> <FilteringCriteria> <Attribute> <Name>Jar_Type</Name><Filter>*</Filter> </Attribute> </FilteringCriteria> </entityDetails> <entityDetails> <EntityType>Plugins</EntityType> <FilteringCriteria> <Attribute> <Name>Type</Name><Filter>*</Filter> </Attribute> </FilteringCriteria> </entityDetails> </MigrationDetails>
Execute the script, specifying the user name, password, and JNDI URL when prompted. (The JNDI URL is the URL to connect to the application. For example, t3://hostname:port).
The script creates a zip file named exportPackage_timestamp.zip, which is created in the directory exportPackage_timestamp.
In the production environment, import localization resource bundles, as well as the sets of plug-in code from the test environment.
To import these entities, you use the following script, which exports the entities into a zip file:
(UNIX) OIM_ORACLE_HOME/server/bin/importMetadata.sh (Windows) OIM_ORACLE_HOME\server\bin\importMetadata.bat
Take the following steps:
Edit the following script, which imports the entities from the zip file created by the export operation:
(UNIX) OIM_ORACLE_HOME/server/bin/importMetadata.sh (Windows) OIM_ORACLE_HOME\server\bin\importMetadata.bat
Edit the script to specify the following values:
CONTEXT: The URL of the application. For example, weblogic.jndi.WLInitialContextFactory.
IMPORT_LOCATION: The full path to the directory where the zip file created by the export operation is located.
TEMP_LOCATION_TO_EXTRACT: The full path to a directory where the files in the zip file are to be extracted before they are imported.
Execute the script, specifying the user name, password, and JNDI URL when prompted. (The JNDI URL is the URL to connect to the application. For example, t3://hostname:port).
The script imports the data into the production environment.
Move any custom reconciliation profiles, as described in "Updating Reconciliation Profiles Manually" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager.
Use the WLST command exportMetadata
to export the custom reconciliation profiles from the test environment:
connect('username','password',JNDI-URL') exportMetadata(application='OIM', server='server_name', toLocation='directory', docs='path_to_reconciliation_profiles'
Copy the exported files to the production environment.
Use the WLST command importMetadata
to import the custom reconciliation profiles to the production environment:
connect('username','password',JNDI-URL') importMetadata(application='OIM', server='server_name', fromLocation='directory', docs='/**'
For connectors, if there are any changes to the forms that need the older versions of these forms to be upgraded with the new definition on the production environment, move the connectors, then run the Form Version Control (FVC) utility. For more information, see the section "Upgrading the Connector" of the Connector Patch Readme file. The Readme file is located in the top-level directory of the connector distribution media.
To move Oracle Identity Navigator to a new production 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.
Note:
The Administration Servers in both the test environment and the production environment must be started.To replicate the policy configuration information from the test system into the production system:
Install and configure Oracle Access Manager, specifying the information for the production environment, as described in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
Set the environment variable JAVA_HOME and add JAVA_HOME to the PATH.
Export the policies from the test system, using the following WLST command:
exportPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
Copy the policy file to the production environment.
Import the policies into the production environment, using the following command:
importPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
To replicate the configuration and the partner information from the test system to the production system, take the following steps:
Export the partner information from the test environment, using the following WLST command:
exportPartners(pathTempOAMPartnerFile='path_of_Temp_PartnerFile')
Copy the partner file to the production environment.
Import the partner information to the production environment, using the following WLST command:
importPartners(pathTempOAMPartnerFile='path_of_Temp_PartnerFile')
To move Oracle Access Manager 10g to a new production environment:
Move the Directory Server from the test environment to the production 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 production 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 test environment to the production environment), Oracle Access Manager inherits the policy and configuration data from the LDAP directory.
On the production system, 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 production 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 production 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 test system.
Click Modify. Then, add the host name and port for the production 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 production 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 production 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 test 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 test WebPass.
From the Identity System Console, select the System Configuration tab, then select Identity Server and delete the entry for the test Identity Server.
From the Access System Console, select the Access System Configuration tab, then select Access Server Configuration. Delete the entry for the test 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 production 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.
To move Oracle Adaptive Access Manager to a new production environment:
Install Oracle Adaptive Access Manager on the production environment, using the same installation and post-installation configuration steps that you used in the test environment.
Export snapshots from the test 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 production environment. Use the Oracle Adaptive Access Manager Administration console to import the contents of the zip file saved in step 2. See "System Snapshot Import/Export" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager for more information.
Manually update the production system 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 test environment and import them into the production 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 production 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 test system to production system. 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 Administration Console. See the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
Copy the following from the test environment to the production 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 test environment to the production environment.
Validate that the move was successful:
Log in to OAAM Admin console, as described in "OAAM Admin Console and Controls" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
Navigate to Policies and check that the rules and groups from the test environment exist in the production environment.
Navigate to the KBA module and check that the challenge questions in the test environment exist in the production environment.
Test the Web applications that have been configured for Oracle Adaptive Access Manager. The user should be redirected to registration and challenge flow.
To move audit policies to a new production environment, see the following topics in the Oracle Fusion Middleware Application Security Guide:
To move Oracle Platform Security to a new production environment, you migrate the policy store and credential store:
If the policy store on the test 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 test environment is not file-based, migrate the credential store, using the WLST command migrateSecurityStore
, as described in "Migrating Credentials with the Command migrateSecurityStore" 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 a new production environment:
Move Oracle Platform Security to the production system, as described in Task 13, "Move Oracle Platform Security to a New Production Environment".
Oracle Web Services Manager depends on Oracle Platform Security and Oracle Fusion Middleware Audit Framework. Oracle Web Services Manager uses Oracle Platform Security for the following:
Credential store: Oracle Web Services Manager stores client policy user name and password credentials and keystore passwords in the credential store.
Policy store: Oracle Web Services Manager permission-based authorization policies use Oracle Platform Security policy store to look up permissions.
Login modules: Oracle Web Services Manager uses Oracle Platform Security login modules for all of its authentication.
Keystore configuration. However, the keystores in the test and production environments are typically different.
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:
If you have custom-built policies, move those by copying the jar files from the test to the production environment. The jar files are located in the following directory:
DOMAIN_HOME/lib
For ADF BC and Oracle WebCenter 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.
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 test environment to the production environment:
ORACLE_HOME/modules/oracle.wsm.policies_11.1.1/wsm-seed-policies.jar
Move the keystore from the test environment to the production environment.
Because private keys differ between test and production environments, you do not need to move them.
Public keys, intermediate certificates, and root certificates can be moved. Use the Sun Microsystems java keytool export and import commands to move them.
After migration, review the certificates to see if they are applicable in the production environment based on the clients invoking the services.
If the encryption key alias for the production keystore is different than the test environment keystore, then you must update the rcpt-key-alias for all the policies that perform message protection in the policy configuration.
From Fusion Middleware Control, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies. Select the policy and click Edit. Update the alias.
See Also:
"Managing Horizontal Policy Migration" in the Oracle Fusion Middleware Security and Administrator's Guide for Web ServicesIn this scenario, you have installed Identity Management components, such as Oracle Internet Directory, Oracle Directory Integration Platform, and Oracle Web Services Manager, in a test environment and you want to move them to a production environment that already exists.
On the existing production system, you have installed and configured the components. You want to move an application from the test environment to the production environment while retaining its security-related configuration. This requires migrating application-specific data from the test Identity Management environment to the production Identity Management environment.
To move Identity Management to an existing production environment, perform the following tasks:
Task 1, "Move Oracle Internet Directory to an Existing Production Environment"
Task 2, "Move Oracle Access Manager 11g to an Existing Production Environment"
Task 3, "Move Oracle Access Manager 10g to an Existing Production Environment"
Task 4, "Move Oracle Adaptive Access Manager to an Existing Production Environment"
Task 5, "Move Oracle Identity Manager to an Existing Production Environment"
Task 6, "Move Oracle Identity Navigator to an Existing Production Environment"
Task 7, "Move Oracle Platform Security to an Existing Production Environment"
Task 8, "Move Oracle Web Services Manager to an Existing Production Environment"
To move Oracle Internet Directory to an existing production environment:
You may have configured Oracle Platform Security to use the users and groups in the test environment. To move the users and groups from the test environment, take the following steps:
Identify the Default Subscriber for the test Oracle Internet Directory instance by running the following command from the test 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 test Oracle Internet Directory instance by running the following command from the test 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 > users.ldif
Move the users into the production Oracle Internet Directory instance by running the following command from the production 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 test environment is set up as a staging environment to mimic the production environment, Oracle recommends that you set up one-way replication from the production Oracle Internet Directory to the test Oracle Internet Directory to ensure that any users or groups that exist in the production 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 test Oracle Internet Directory synchronized with the production and to replicate any users or groups that are added into production 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 test environment to the production environment, as described in Step 1. It also assumes that the orclGUIDs of the users at the test Oracle Internet Directory are identical to those in the production Oracle Internet Directory.
Take the following steps:
Retrieve the RADs from the test 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 > rads.ldif
Move the RADs into the production 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 scenario, you move incremental changes that you have made in the test environment to the production environment.
Note:
The Administration Servers in both the test environment and the production environment must be started.To replicate the policy configuration information from the test system into the production system:
Set the environment variable JAVA_HOME and add JAVA_HOME to the PATH.
Export the policies from the test system, using the following WLST command:
exportPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
Copy the policy file to the production environment.
Import the policies into the production environment, using the following WLST command:
importPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
To move Oracle Access Manager 10g to an existing production environment:
In the production environment, use the Oracle Access Manager OAMCfgTool to create the same policy domain for the application. Ensure that the following specify values for the production 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 test environment, make the same types of changes in the production environment.
To move Oracle Adaptive Access Manager to an existing production environment:
Export the necessary delta data from the test system to one or more zip files. You can export the following types of items: policies, rule conditions, patterns, configurable actions, transactions, entities, KBA questions, KBA validations, all group types including alert and action groups, and black list and white list groups used in rules. See Step 2 in Task 11, "Move Oracle Adaptive Access Manager to a New Production Environment" in Section 21.2.1.
Import the zip files created in Step 1 in the production system. See Step 3 in Task 11, "Move Oracle Adaptive Access Manager to a New Production Environment" in Section 21.2.1.
Manually update the production system 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 test environment and import them into the production 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 production 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 test system to production system. 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 test environment to the production 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 test environment to the production environment.
Copy the following from the test environment to the production environment: properties files, resource bundles, VAD images, and end user JSP screens.
Validate that the move was successful:
Login to OAAM Admin console, as described in "OAAM Admin Console and Controls" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
Navigate to Policies and check the existing group linking and check that newly added rules and groups from the test environment exist in the production environment.
Navigate to the KBA module and check that newly added challenge questions in the test environment exist in the production environment.
Test the Web applications that have been configured for Oracle Adaptive Access Manager. The user should be redirected to registration and challenge flow. The behavior should be the same as in the test environment.
To move Oracle Identity Manager to an existing production environment, follow the steps described in Section 21.2.1, Task 7, "Move Oracle Identity Manager to a New Production Environment".
To move Oracle Identity Navigator to an existing production environment, follow the steps in Section 21.2.1, Task 8, "Move Oracle Identity Navigator to a New Production Environment".
You must move all of the Oracle Platform Security policy and credential store information from the test environment to an existing production environment:
If the policy store on the test 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 test environment is not file-based, migrate the credential store, using the WLST command migrateSecurityStore
, as described in "Migrating Credentials with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.
Users and groups in the production 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 production 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 production environment:
Move policies for SOA Composite applications, WebCenter, or ADF applications, which are stored in the MDS Repository.
To do so using Fusion Middleware Control:
On the test 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 test 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 production environment.
On the production 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 test 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 production 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 test 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 test environment to the production environment.
In the production 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 test to the production 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 test environment to the production 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 application if they have changed since the application was first deployed in the production environment. For example, policy A was initially configured in the test environment with the BASIC 128 algorithm and attached to the HelloWorld application. The application was deployed to the production environment. Then, on the test environment, you changed policy A to use the Basic 129 algorithm.
Move any policy attachments for a JAX-WS application if they have changed since the application was first deployed.
The following topics describe how to move Oracle SOA Suite from a test environment to a production environment:
In both scenarios, you have performed the following in a test environment:
Installed Oracle WebLogic Server and created the Middleware home.
Created the required schemas in the test database using RCU.
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 a test environment.
Note:
The Oracle User Messaging Service (UMS) is used in SOA and BAM scenarios. The functionality and actions in both scenarios are similar, but there are small differences. In particular, for BAM, only the e-mail driver is supported, so the reconfiguration steps for UMS only apply to the e-mail driver. Also, BAM does not make use of the UMS User Preferences in this release. Hence, the userprefs migration in UMS migration does not apply to BAM. See Task 6 for details on moving UMS from a test to a production system.In this scenario, you have installed Oracle SOA Suite in a test environment as described in Section 21.3 and you want to move it to a production environment, which does not yet exist.
To move this environment to a new production environment, perform the following tasks:
Task 1, "Move the Middleware Home and Oracle SOA Suite and Perform the Initial Configuration"
Task 2, "Configure Security in the New Production Environment"
Task 3, "Move Human Workflow to the New Production Environment"
Task 4, "Move Oracle Business Activity Monitoring Data to the New Production Environment"
Task 5, "Move Oracle Business Process Management to the New Production Environment"
Task 6, "Move UMS-Related Details to the New Production Environment"
See Also:
Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for information about setting up an enterprise deployment for Oracle SOA SuiteTo move the Middleware home and perform the initial configuration on the production system:
Create a database and create the required schemas in the production database using RCU. See Oracle Fusion Middleware Repository Creation Utility User's Guide.
Move a copy of the Middleware home to the production environment using the copyBinary and pasteBinary scripts, as described in Section 20.5.1.
The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.
Move a copy of the domain containing the Oracle SOA Suite configuration, as described in Section 20.5.2 and Section 20.5.2.1. This step moves the configuration, including the domain, Administration Server, and Managed Servers. Moving the configuration also:
Moves SOA composite applications.
Moves Oracle Human Workflow attribute labels, flex field mappings, approval groups and standard views.
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 production 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.
Install and configure Identity Management components, such as Oracle Internet Directory.
For information about installing Identity Management components, see the Oracle Fusion Middleware Installation Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
For information about configuring users and groups in Oracle Internet Directory, see "Configuring Users and Groups in the Oracle Internet Directory and Oracle Virtual Directory Authentication Providers" in the Oracle Fusion Middleware Securing Oracle WebLogic Server.
Create any custom schemas used by your applications. For example, if your application uses a custom schema in the test environment, create the schema in the production environment.
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 production 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.
You must configure security. The steps you take depends on the configuration of your environment and application. The following steps assume that you are using Oracle Internet Directory, JKS certificates, Oracle Web Services Manager, and Oracle Platform Security:
If necessary, move users and groups to the production environment. For example, if you are using the Oracle Business Activity Monitoring or Human Workflow demo, move those users:
Export the users and groups from LDAP identity store on the test environment, using the ldapsearch command. This produces an ldif file that you later import into the LDAP identity store in the production 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 test environment into the production 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
Export any JKS certificates for B2B endpoints from the test environment to the production environment. Then, import them to the production environment. For information about exporting and importing JKS certificates, see Section 8.3.3.
If the security policies are stored in an external LDAP or database-based store, import the security policies, for example those that are related to the Human Workflow application roles, from the test environment to the production environment, as described in Task 7, "Move Oracle Platform Security to an Existing Production Environment" in Section 21.2.2.
If the credential policies are stored in an external LDAP or database-based store, import the credential store information from the test environment to the production environment, as described in Task 7, "Move Oracle Platform Security to an Existing Production Environment" in Section 21.2.2.
When you moved a copy of the domain from the test environment to the production environment, the scripts moved the following Human Workflow entities:
Attribute labels
Flex field mappings
Approval groups
Standard views
The scripts do not move the following:
User views
Rules
To move Human Workflow user views and roles to a new production environment:
Move Human Workflow user metadata, such as user views or vacation rules, from the test environment to the production environment, using the Data Migrator. The Data Migrator is available as an ant target that can be executed in the command line. It calls a properties file, migration.properties, that you create specifying the input parameters for the migration of data.
The migration.properties file contains the following input parameters:
operationType = {EXPORT | IMPORT} objectType = {VIEW | RULE | APPROVAL_GROUP | TASK_PAYLOAD_FLEX_FIELD_MAPPING} name = name of VIEW or APPROVAL_GROUP or TASK_PAYLOAD_FLEX_FIELD_MAPPING user = username of VIEW or RULE group = groupname for RULE grantPermission = {true | false} migrateAttributeLabel = {true | false} override = {true | false} skip = {true | false} migrateToActiveVersion = {true | false}
You use the following script:
ORACLE_HOME/bin/ant-t2p-worklist.xml
The command has the following format:
ant -f ant-t2p-worklist.xml -Dbea.home=BEA_HOME -Dsoa.home=SOA_HOME -Dmigration.properties.file=MIGRATION_PROPERTY_FILE_PATH -Dsoa.hostname=SOA_HOSTNAME -Dsoa.rmi.port=SOA_RMI_PORT -Dsoa.admin.user=SOA_ADMIN_USER -Dsoa.admin.password=SOA_ADMIN_PASSWORD -Drealm=REALM -Dmigration.file=MIGRATION_FILE -Dmap.file=MAP_FILE
For additional information about the migration utility, see "Using the User Metadata Migration Utility" in the Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.
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.
Create a migration.properties file to export user metadata for the worklist application (for example rules, user views, vacation rules) from the test environment. You can create the migration.properties file in any location. Note the following:
You can only export one type of data at a time.
When you are exporting data for a particular user or group, you must migrate them in separate operations.
For example, to export all rules for a given user, the migration.properties file would contain the following:
operationType = EXPORT
objectType = RULE
name = ALL
user = username
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false
Note that the parameter group
is left blank when you export rules for a given user.
To export all rules for a given group, the migration.properties file would contain the following:
operationType = EXPORT objectType = RULE name = ALL user = group = LoanAgentGroup grantPermission = true migrateAttributeLabel = false override = true skip = true migrateToActiveVersion = false
Note that the parameter user
is left blank when you export rules for a given group.
Export the data. The following example shows how to invoke the command and specify the parameters:
ant -f ant-t2p-worklist.xml -Dbea.home=/scratch/oracle/MW_HOME -Dsoa.home=/scratch/oracle/MW_HOME/AS11gR1SOA -Dmigration.properties.file=migration.properties -Dsoa.hostname=hostname -Dsoa.rmi.port=7001 -Dsoa.admin.user=weblogic -Dsoa.admin.password=password -Drealm=jazn.com -Dmigration.file=/tmp/export_all_userRules.xml -Dmap.file=/tmp/export_all_userRules_mapper.xml
Ensure that the application is deployed to the production system.
Create the migration.properties file to import user metadata for the worklist application to the production environment. Note the following:
You can only import one type of data at a time.
When you are importing data for a particular user or group, you must import them in separate operations.
For example, to import all rules for a given user, the migration.properties file would contain the following:
operationType = IMPORT
objectType = RULE
name = ALL
user = username
group =
grantPermission = true
migrateAttributeLabel = false
override = true
skip = true
migrateToActiveVersion = false
Note that the parameter group
is left blank when you import rules for a given user.
To import all rules for a given group, the migration.properties file would contain the following:
operationType = IMPORT objectType = RULE name = ALL user = group = LoanAgentGroup grantPermission = true migrateAttributeLabel = false override = true skip = true migrateToActiveVersion = false
Note that the parameter user
is left blank when you import rules for a given group.
Import the data to the production environment from the file export_all_userRules.xml, which you created in the previous steps. The following example shows how to invoke the command and specify the parameters:
ant -f ant-t2p-worklist.xml -Dbea.home=/scratch/oracle/MW_HOME -Dsoa.home=/scratch/oracle/MW_HOME/AS11gR1SOA -Dmigration.properties.file=migration.properties -Dsoa.hostname=hostname -Dsoa.rmi.port=7001 -Dsoa.admin.user=weblogic -Dsoa.admin.password=password -Drealm=jazn.com -Dmigration.file=/tmp/export_all_userRules.xml -Dmap.file=/tmp/export_all_userRules_mapper.xml
Note that if the data, such as rules and views, are attached to the user, then the user should be an available user in the production SOA server.
Deploy J2EE Human Task Forms, as you would deploy any .ear file. See Section 10.3.1 for more information.
If necessary, update the workflow notification configuration with production mail server and inbound and outbound e-mail accounts. See "Configuring Oracle User Messaging Service" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
To move Oracle Business Activity Monitoring to the new production environment:
On the test environment, 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, which is available at:http://www.oracle.com/technology/documentation/database.html
The Oracle BAM objects, such as reports, alerts, and data definitions from the test environment are exported.
Install and configure Oracle Internet Directory as the LDAP provider for BAM applications on the production environment, as described in Task 1, if you have not already done so.
Set up the Oracle Internet Directory Authenticator, if it was not set up in the test environment. (If it was set up in the test environment, moving the configuration moves the configuration to the production environment.)
From the Oracle WebLogic Server Administration Console, select Security Realms, then myrealm, then Providers.
A default Authenticator is configured for the realm.
Click New to add a new authenticator.
Enter a name for the provider, such as OIDAuthenticator
for a provider that authenticates the user to the Oracle Internet Directory.
For Type, select OracleInternetDirectoryAuthenticator.
Click OK.
On the Providers tab, click the newly created OIDAuthenticator.
For Control Flag, select Sufficient to indicate that if a user can be authenticated successfully by this authenticator, then it should accept that authentication and should not continue to invoke any additional authenticators.
Select the Provider Specific tab.
Enter the details of the LDAP provider.
Click Save.
In the Providers tab, reorder the authenticators so that the newly created authenticator is first.
Restart the Administration Server and the Managed Server.
Move BAM data and artifacts to the production environment:
Create the BAM JPS root context by importing the ldif file. The following shows a sample ldif file:
dn: cn=jpsroot_bam_test,dc=us,dc=oracle,dc=com cn: jpsroot_bam_test objectclass: top objectclass: orclcontainer
Move the BAM application policy and roles to LDAP using Fusion Middleware Control:
From the navigation pane, right-click the domain that contains Oracle Business Activity Monitoring and choose Security, then Security Provider Configuration.
Follow the steps in "Reassociating Domain Stores with Fusion Middleware Control" in the Oracle Fusion Middleware Application Security Guide.
Import the ORACLEBAM database schema that you exported from the test 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.
Modify the e-mail server configuration on the production environment, as described in "Configuring Oracle User Messaging Service" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
Restart the Oracle Business Activity Monitoring Managed Server.
To move Oracle Business Process Management to the new production environment, you move Oracle Business Process Management user metadata, such as organizations and dashboards, from the test environment to the production environment, using the 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.
Note that the migration tool does not move any user-specific configuration because users in the test and production 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
For Organizations, the following objects are moved to the production environment: Organizational Units, Roles, Calendars, Organization Role, and Extended User Properties.
For Dashboards, data with the BAM_WIDGET data type in the BPMUserApplicationData table is moved to the production environment.
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 Organizations and Dashboard:
Create a configuration file to export Organizations. (You pass that file to the ant command.)
The following shows a sample configuration file that exports Organizations:
<?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://hostname:port</serverURL> <adminUserLogin>admin_username</adminUserLogin> <adminUserPassword>admin_password</adminUserPassword> <realm>jazn.com</realm> </serverEndPoint> </sourceEndPoint> <targetEndPoint> <fileEndPoint> <migrationFile>/tmp/bpm_organization.xml</migrationFile> </fileEndPoint> </targetEndPoint> <operation>EXPORT</operation> <object>ORGANIZATION</object> <objectDetails> <login>username</login> <password>password</password> <identityContext>jazn.com</identityContext> <organization/> </objectDetails> </testToProductionMigrationConfiguration>
In the configuration file, you must specify the values for the test environment in the following elements:
migrationFile: This element specifies the file that was generated by the export operation.
serverURL: The SOA server URL
adminUserLogin
adminUserPassword
objectDetails: Update the login and password elements.
Export Organizations, using the following command:
ant -f ant-t2p-workspace.xml -Dbea.home=BEA_HOME -Dbpm.home=BPM_HOME -Dbpm.t2p.migration.config=ORG_MIGRATION_CONFIG_FILE
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://hostname: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> </userApplicationData> </objectDetails> </testToProductionMigrationConfiguration>
In the configuration file, you must specify the values for the test environment in the following elements:
serverURL: The SOA server URL
adminUserLogin
adminUserPassword
migrationFile. Note that this element specifies the file that was generated by the export operation.
objectDetails: Update the login and password elements.
userApplicationData: Update 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 Organization and Dashboards:
Create a configuration file to import Organizations. (You pass that file to the ant command.)
The following shows a sample configuration file that imports Organizations:
<?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_organization.xml</migrationFile> </fileEndPoint> </sourceEndPoint> <targetEndPoint> <serverEndPoint> <serverURL>t3://hostname:port</serverURL> <adminUserLogin>admin_username</adminUserLogin> <adminUserPassword>admin_password</adminUserPassword> <realm>jazn.com</realm> </serverEndPoint> </targetEndPoint> <operation>IMPORT</operation> <object>ORGANIZATION</object> <objectDetails> <login>username</login> <password>password</password> <identityContext>jazn.com</identityContext> <organization/> </objectDetails> </testToProductionMigrationConfiguration>
In the configuration file, you must update the following elements with the values for the production environment:
migrationFile: This element specifies the file that was generated by the export operation.
serverURL: The SOA server URL
adminUserLogin
adminUserPassword
objectDetails: Update the login and password elements.
Import Organizations, using the following command:
ant -f ant-t2p-workspace.xml -Dbea.home=BEA_HOME -Dbpm.home=BPM_HOME -Dbpm.t2p.migration.config=ORG_MIGRATION_CONFIG_FILE
Create a configuration file to import Dashboards. The format is the same as for Organizations, except that you substitute the following lines:
<sourceEndPoint> <fileEndPoint> <migrationFile>/tmp/bpm_dashboard.xml</migrationFile> </fileEndPoint> </sourceEndPoint> <targetEndPoint> <serverEndPoint> <serverURL>t3://hostname: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> </userApplicationData> </objectDetails> </testToProductionMigrationConfiguration>
In the configuration file, you must update the following elements with the values for the production environment:
serverURL: The SOA server URL
adminUserLogin
adminUserPassword
migrationFile. Note that this element specifies the file that was generated by the export operation.
objectDetails: Update the login and password elements.
userApplicationData: Update 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
To move UMS details to the new production environment:
Configure the required UMS drivers in the production environment.
Use Fusion Middleware Control to configure the User Messaging Service drivers with production driver information.
Use the WLST command deployUserMessagingDriver
to deploy multiple drivers similar to the test environment.
Note:
To see different options for deploying additional drivers, executehelp('deployUserMessagingDriver')
at the wls:/offline>
prompt.Re-create any custom-created business terms in the production environment. This step is essential in order to use the same set of User Preferences filter settings in the production environment, and to ensure that filters built with custom business terms are functional.
Restart the production environment to apply the changes.
Move the User Messaging preferences from the test environment to the production environment:
In the test environment, run the following WLST command to download the User Messaging preferences from the backend database to the specified .xml file:
wls:/offline> manageUserMessagingPrefs(operation='download', filename='/tmp/userprefs-dump.xml', url='t3://localhost:8001', username='username', password='password')
Note:
In this example, 8001 is the Managed Server port on which UMS is running. Replace it with the appropriate value.Copy the /tmp/userprefs-dump.xml file to the production environment.
In the production environment, run the following WLST command to upload the User Messaging preferences from file to the backend database:
wls:/offline> manageUserMessagingPrefs(operation='upload', filename='/tmp/userprefs-dump.xml', url='t3://localhost:8001', username='username', password='password')
Note:
In the example, 8001 is the Managed Server port on which UMS is running. Replace it with the appropriate value.Observe the message displayed for successful upload. Exit the WLST command line tool.
Note:
To see different options for performing download and upload operations, executehelp('manageUserMessagingPrefs')
at the wls:/offline>
prompt. Please note that user devices provisioned in the LDAP store are dynamic. The assumption is that both the test and production environments point to the same LDAP store or you reconfigured it to use the same set of information.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.
During the pasteConfig operation, SSL is disabled. In addition, custom keystores are not created in the production environment. Take the following steps:
Enable SSL, as described in Section 6.5.
Create custom keystores, as described in Section 8.3.3.1.
In this scenario, you have a working production environment and want to test changes in your applications or configuration before rolling those changes into the production environment. In the test environment, you have the same environment as described in Section 21.3.
To move Oracle SOA Suite to an existing production system:
Move any changes that you have made to Oracle SOA Suite:
If you have added users and groups in the test environment or modified security policies or credentials, follow the steps in Task 2 in Section 21.3.1 to move them to the production environment.
If you have modified EJBs or Plain Old Java Objects (POJOs) in the test environment that support the composite references, move them to the production 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 test environment, move them to the production 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 production 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 test environment, move those changes to the production environment.
Note that if you export selective agreements using the tpanames parameter, you must import each zip file individually.
Move Oracle B2B system configuration parameters by using the Oracle B2B interface to configure the properties. See "Configuring System Parameters" in the Oracle Fusion Middleware User's Guide for Oracle B2B for details.
Move other configuration properties by using the B2B command line, as described in "Setting Properties of b2b-config" in the Oracle Fusion Middleware User's Guide for Oracle B2B.
Move the B2B agreements and trading partners to the production environment:
Export the data from the test 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 production 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 production 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 test environment, move them to the production environment.
To move Oracle Business Process Management to the existing production environment, you move Oracle Business Process Management user metadata, such as organizations and dashboards, from the test environment to the production environment, using the 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.
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 Organizations and Dashboards:
Create a configuration file to export Organizations. (You pass that file to the ant command.)
The following shows a sample configuration file that exports Organizations:
<?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://hostname:port</serverURL> <adminUserLogin>admin_username</adminUserLogin> <adminUserPassword>admin_password</adminUserPassword> <realm>jazn.com</realm> </serverEndPoint> </sourceEndPoint> <targetEndPoint> <fileEndPoint> <migrationFile>/tmp/bpm_organization.xml</migrationFile> </fileEndPoint> </targetEndPoint> <operation>EXPORT</operation> <object>ORGANIZATION</object> <objectDetails> <login>username</login> <password>password</password> <identityContext>jazn.com</identityContext> <organization/> </objectDetails> </testToProductionMigrationConfiguration>
In the configuration file, you must specify the values for the test environment in the following elements:
migrationFile: This element specifies the file that was generated by the export operation.
serverURL: The SOA server URL
adminUserLogin
adminUserPassword
objectDetails: Update the login and password elements.
Export Organizations, using the following command:
ant -f ant-t2p-workspace.xml -Dbea.home=BEA_HOME -Dbpm.home=BPM_HOME -Dbpm.t2p.migration.config=ORG_MIGRATION_CONFIG_FILE
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://hostname: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> </userApplicationData> </objectDetails> </testToProductionMigrationConfiguration>
In the configuration file, you must specify the values for the test environment in the following elements:
migrationFile: This element specifies the file that was generated by the export operation.
serverURL: The SOA server URL
adminUserLogin
adminUserPassword
objectDetails: Update the login and password elements.
userApplicationData: Update 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 Organization and Dashboards:
Create a configuration file to import Organizations. (You pass that file to the ant command.)
The following shows a sample configuration file that imports Organizations:
<?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_organization.xml</migrationFile> </fileEndPoint> </sourceEndPoint> <targetEndPoint> <serverEndPoint> <serverURL>t3://hostname:port</serverURL> <adminUserLogin>admin_username</adminUserLogin> <adminUserPassword>admin_password</adminUserPassword> <realm>jazn.com</realm> </serverEndPoint> </targetEndPoint> <operation>IMPORT</operation> <object>ORGANIZATION</object> <objectDetails> <login>username</login> <password>password</password> <identityContext>jazn.com</identityContext> <organization/> </objectDetails> </testToProductionMigrationConfiguration>
In the configuration file, you must update the following elements with the values for the production environment:
migrationFile: This element specifies the file that was generated by the export operation.
serverURL: The SOA server URL
adminUserLogin
adminUserPassword
objectDetails: Update the login and password elements.
Import Organizations, using the following command:
ant -f ant-t2p-workspace.xml -Dbea.home=BEA_HOME -Dbpm.home=BPM_HOME -Dbpm.t2p.migration.config=ORG_MIGRATION_CONFIG_FILE
Create a configuration file to import Dashboards. The format is the same as for Organizations, except that you substitute the following lines:
<sourceEndPoint> <fileEndPoint> <migrationFile>/tmp/bpm_dashboard.xml</migrationFile> </fileEndPoint> </sourceEndPoint> <targetEndPoint> <serverEndPoint> <serverURL>t3://hostname: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> </userApplicationData> </objectDetails> </testToProductionMigrationConfiguration>
In the configuration file, you must update the following elements with the values for the production environment:
migrationFile: This element specifies the file that was generated by the export operation.
serverURL: The SOA server URL
adminUserLogin
adminUserPassword
objectDetails: Update the login and password elements.
userApplicationData: Update 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
Move any BAM data that has changed:
Export BAM artifacts from the test environment using the icommand, which is located in the following directory:
(UNIX) ORACLE_HOME\bam\bin\icommand.sh (Windows) ORACLE_HOME\bam\bin\icommand.bat
For example:
icommand -cmd export -type dataobject -all 1 -PERMISSIONS 1 -OWNER 1 -file dataobject.xml icommand -cmd export -type folder -all 1 -PERMISSIONS 1 -OWNER 1 -file folder.xml icommand -cmd export -type report -all 1 -file reports.xml icommand -cmd export -type rule -all 1 -file rules.xml icommand -cmd export -type ems -all 1 -file ems.xml icommand -cmd export -type eds -all 1 -file eds.xml
In addition to exporting all artifacts of a particular type, you can export individual artifacts. For more information about using the icommand to export artifacts, see "Export" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Export the BAM users from the LDAP identity store on the test environment, using the ldapsearch command. This produces an ldif file that you later import into the LDAP identity store in the production 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 BAM data and artifacts into the production environment:
Deactivate the rules that are set up by default, using Oracle BAM Architect. See "To change the activity status of an alert rule" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
If you have not already done so, set up the LDAP security provider and make it the default provider, as described in Step 2 and Step 3 in Task 4, "Move Oracle Business Activity Monitoring Data to the New Production Environment".
Import the BAM users from the ldif file that you exported from the test environment into the LDAP provider, such as Oracle Internet Directory, on the production environment. (ORACLE_HOME is the Oracle home for Identity Management.)
ORACLE_HOME/bin/ldapadd -h production_oid_host -p production_oid_port -D "cn=orcladmin" -w production_orcladmin_passwd -vf ldif_filename
Move the BAM application policy and roles to LDAP using Fusion Middleware Control:
From the navigation pane, right-click the domain that contains Oracle BAM and choose Security, then Security Provider Configuration.
Follow the steps in "Reassociating Domain Stores with Fusion Middleware Control" in the Oracle Fusion Middleware Application Security Guide.
Import the Oracle BAM artifacts using the icommand, which is located in the following directory:
(UNIX) ORACLE_HOME\bam\bin\icommand.sh (Windows) ORACLE_HOME\bam\bin\icommand.bat
For example:
icommand -cmd import -file dataobject.xml -UPDATELAYOUT 1 -MODE UPDATE -CONTINUEONERROR icommand -cmd import -file folder.xml -MODE OVERWRITE -PRESERVEOWNER icommand -cmd import -file reports.xml -MODE OVERWRITE -PRESERVEOWNER icommand -cmd import -file ems.xml -MODE OVERWRITE icommand -cmd import -file eds.xml -MODE OVERWRITE
Start the BAM server.
Move Oracle User Messaging Service data:
Configure the required UMS drivers in the production environment.
Note:
While moving Oracle User Messaging Service to an existing production 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 test instance.Use Fusion Middleware Control to configure the User Messaging Service drivers with production driver information.
Use the WLST command deployUserMessagingDriver
to deploy multiple drivers similar to the test environment.
Note:
To see different options for deploying additional drivers, executehelp('deployUserMessagingDriver')
at the wls:/offline>
prompt.Re-create any custom-created business terms in the production environment. This step is essential in order to use the same set of User Preferences filter settings in the production environment, and to ensure that filters built with custom business terms are functional.
Restart the production environment to apply the changes.
Move the User Messaging preferences from the test environment to the production 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 test environment.
Newly created or modified user devices and filters in the test environment must be created or modified using the following URL in the production 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.
The following topics describe how to move Oracle WebCenter from a test environment to a production environment:
In both scenarios, you have performed the following in a test environment:
Installed Oracle WebLogic Server.
Installed Oracle WebCenter.
Created the required schemas in the test database using RCU.
Installed and configured Oracle SOA Suite.
Configured Oracle WebCenter using the Configuration Wizard. You created a domain and Managed Servers and configured Oracle WebCenter Spaces, Oracle WebCenter Portlets, Oracle Discussions, Oracle WebCenter Wiki and Blog Server.
Installed and configured Oracle Universal Content Management.
Installed Identity Management components, such as Oracle Internet Directory, Oracle Identity Federation, and Oracle Access Manager.
Configured Group Spaces.
Configured Oracle WebCenter 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.
Created and deployed custom WebCenter applications.
Created instance data in the WebCenter Spaces application, including creating a group space based on a Community of Interest template, and provisioned services. In addition, created some roles and assigned new members to the roles.
In this scenario, you have installed Oracle WebCenter in a test environment as described in Section 21.4 and you want to move it to a production environment, which does not yet exist. You move WebCenter Spaces applications and custom WebCenter Framework applications.
To move Oracle WebCenter to a new production environment, perform the following tasks:
Task 1, "Install and Configure Oracle WebCenter in the Production Environment"
Task 2, "Export WebCenter Spaces Applications and Required Data from the Test Environment"
Task 3, "Export Custom WebCenter Framework Applications from the Test Environment"
Task 4, "Import WebCenter Spaces Data and Application to the Production Environment"
Task 5, "Import Custom WebCenter Framework Applications to the Production Environment"
Install and configure Oracle WebCenter in the production environment:
Create the required schemas in the production database using RCU. See Oracle Fusion Middleware Repository Creation Utility User's Guide.
Move a copy of the Middleware home to the production environment, as described in Section 20.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.
Because Oracle Universal Content Management requires a Web server, move the Oracle HTTP Server, as described in Section 21.5.1.1.
Move copy of the domain containing the Oracle WebCenter configuration, as described in Section 20.5.2. This step moves the configuration, including the domain, Administration Server, and Managed Servers. In addition, it:
Associates WebCenter Spaces with an external identity store.
For WebCenter Spaces and WebCenter Framework, creates authenticators for Identity Management in Oracle WebLogic Server.
For WebCenter Spaces and WebCenter Framework, reassociates the policy and credential store.
For WebCenter Spaces, moves application producer data.
For WebCenter Spaces, moves portlet customization, personalizations, and metadata from the test environment to the production environment.
Moves the data for the policy and credential store from the test environment to the production environment.
Moves the custom Oracle WebCenter Framework application metadata from the test environment to the production environment.
Starts the Administration Server.
Export WebCenter Spaces applications and data required for the applications from the test environment:
If necessary, export the required data for WebCenter Spaces applications, including the LDAP identity store, the Content Server, and the Discussion Forum.
Typically, the production environment LDAP identity store may already be populated with users and groups. Take the following steps only if you need to export users, groups, and passwords from the test environment.
Export the users, groups, and passwords from LDAP identity store, using the ldapsearch command. This produces an ldif file that you later import into the LDAP identity store in the production 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=ldap_user" -w test_ldap_passwd -b "cn=users,dc=example,dc=com" -s subtree "objectclass=*" "*" orclguid -L > my_users.ldif
Export Oracle Content Server, executing 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 user; exit; ORACLE_HOME/bin/expdp "sys/password@connect_id as sysdba" schemas=prefix_OCSERVER directory=directory dumpfile=filename
See Also:
The chapters on Oracle Data Pump in the Oracle Database Utilities, which is available at:http://www.oracle.com/technology/documentation/database.html
Export the Discussion Forum using the Oracle Database export utility (ORACLE_HOME is the Oracle home for the Oracle Database):
ORACLE_HOME/bin/export "sys/password@connect_id as sysdba" OWNER=prefix_DISCUSSIONS FILE=/tmp/df.dmp statistics=none
Refer to "Exporting and Importing WebCenter Spaces Applications for Data Migration" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter for more information.
Move Oracle SOA Suite from the test environment to the production environment, as described in Section 21.3.
Export Portlet customization, personalizations, and metadata from the test environment, using the following command:
exportPortletClientMetadata(appName='app_name', fileName='filename', exportPersonalizations=1)
For detailed syntax, see "exportPortletClientMetadata" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Export the WebCenter Spaces application by using the following WLST commands:
connect('username','password','t3://hostname:port') exportWebCenterApplication(appName,fileName, exportCustomizations=true, exportSecurity=true, exportData=true)
Refer to "Exporting and Importing Custom WebCenter Applications for Data Migration" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter for details.
To export custom WebCenter Framework applications from the test environment:
Export Portlet customizations, personalizations, and metadata from the test environment, using the following command:
exportPortletClientMetadata(appName='app_name',fileName='filename', exportPersonalizations=1)
For detailed syntax, see "exportPortletClientMetadata" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Export the WebCenter Framework application data from the test database, 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 user; exit; ORACLE_HOME/bin/expdp "sys/password@connect_id as sysdba" schemas=prefix_WEBCENTER directory=directory dumpfile=filename
For information about the CREATE OR REPLACE DIRECTORY command, see "CREATE DIRECTORY" in the Oracle Database SQL Language Reference.
For information about the expdp command, refer to the chapters on Oracle Data Pump in Oracle Database Utilities, which is available at:
http://www.oracle.com/technology/documentation/database.html
Export Oracle Content Server, executing 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 user; exit; ORACLE_HOME/bin/expdp "sys/password@connect_id as sysdba" schemas=prefix_OCSERVER directory=directory dumpfile=filename
See Also:
The chapters on Oracle Data Pump in the Oracle Database Utilities, which is available at:http://www.oracle.com/technology/documentation/database.html
Export the Discussion Forum using the Oracle Database export utility (ORACLE_HOME is the Oracle home for the Oracle Database):
ORACLE_HOME/bin/export "sys/password@connect_id as sysdba" OWNER=prefix_DISCUSSIONS FILE=/tmp/df.dmp statistics=none
Migrate the external LDAP-based policy store, using the WLST command migrateSecurityStore
, as described in "Migrating Policies with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.
Migrate the external LDAP-based credential store, using the WLST command migrateSecurityStore
, as described in "Migrating Credentials with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.
To import the WebCenter Spaces data and application to the production environment:
If necessary, import users, groups, and passwords by importing the ldif file that you exported from the test environment in Task 2 into the production environment.
Typically, the production environment LDAP identity store may already be populated with users and groups. Use the following command only if you need to export users, groups, and passwords from the test environment and want to import them into the production environment. (ORACLE_HOME is the Oracle home for Identity Management.)
ORACLE_HOME/bin/ldapaddmt -h production_oid_host -p production_oid_port -D "cn=ldap_user" -w "production_ldap_passwd" -r -f ldif_filename
Refer to "Exporting and Importing Custom WebCenter Applications for Data Migration" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter for more information.
Import the Oracle Content Server data to the production database, using the file you exported in Task 2. Execute 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 user; exit; ORACLE_HOME/bin/impdp "sys/password@connect_id as sysdba" remap_schema=testprefix_OCSERVER:prod_prefix_OCSERVER DIRECTORY=directory dumpfile=filename TABLE_EXISTS_ACTION=REPLACE
Copy the following directories from the test system to the production system. You can use tar to compress the files from the test system and restore them on the production system:
WebCenter_ORACLE_HOME/ucm/vault WebCenter_ORACLE_HOME/ucm/weblayout
Connect to the production database using SQLPlus. (ORACLE_HOME is the Oracle home for the production database.)
ORACLE_HOME/bin/sqlplus "sys/password as sysdba"
Drop the target user:
drop user prefix_DISCUSSIONS cascade;
Create the target user:
create user prefix_DISCUSSIONS identified by password default tablespace prefix_IAS_DISCUSSIONS temporary tablespace prefix_IAS_TEMP;
Grant connect and resource privileges to the user and exit from SQLPlus:
grant connect,resource to prefix_DISCUSSIONS;
exit;
Import the Discussion Forum data into the production database. You import the file that you exported from the test database in Task 2. (ORACLE_HOME is the Oracle home for the production database.)
ORACLE_HOME/bin/imp "sys/password@connect_id as sysdba" FROMUSER=testprefix_DISCUSSIONS TOUSER=prod_prefix_DISCUSSIONS FILE=filename statistics=none
Import the WebCenter Spaces application by using the following WLST commands:
connect('username','password','t3://hostname:port') importWebCenterApplication(appName='appName', fileName='fileName')
Refer to "Exporting and Importing Custom WebCenter Applications for Data Migration" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter for details.
Import Portlet customization, personalizations, and metadata to the production environment, using the following command:
importPortletClientMetadata(appName='app_name', fileName='filename')
For detailed syntax, see "importPortletClientMetadata" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Note:
If you are using the embedded Oracle WebLogic Server LDAP identity store, see "Managing Security" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.Although secure, the embedded LDAP identity store is not a production-class store and should be replaced with an external LDAP-based identity store, such as Oracle Internet Directory, for enterprise production environments.
See Also:
"Exporting and Importing WebCenter Portal Applications for Data Migration" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter for more informationTo import custom WebCenter Framework applications to the production environment:
Import Portlet customizations and metadata from file you exported in Task 3 to the production environment, using the following WLST command:
importPortletClientMetadata(appName='app_name',fileName='filename')
Import the data from the database, 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 user; exit; ORACLE_HOME/bin/impdp "sys/password@connect_id as sysdba" REMAP_SCHEMA=test_prefix_WEBCENTER:prod_prefix_WEBCENTER DIRECTORY=directory dumpfile=filename TABLE_EXISTS_ACTION=REPLACE
Import Content Server, if you have not already done so in Task 4, Step 2.
Import the Discussion Forum, if you have not already done so in Task 4, Step 3.
If you have not already done so, import the LDAP identity, policy, and credential stores. Import the ldif file that you exported from the test environment in Task 2 into the production 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
Migrate the external LDAP-based policy store, using the WLST command migrateSecurityStore
, as described in "Migrating Policies with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.
Migrate the external LDAP-based credential store, using the WLST command migrateSecurityStore
, as described in "Migrating Credentials with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.
During the pasteConfig operation, SSL is disabled. In addition, custom keystores are not created in the production environment. Take the following steps:
Enable SSL, as described in Section 6.5.
Create custom keystores, as described in Section 8.3.3.1.
In this scenario, you have a working production environment with Oracle WebCenter installed and configured and you want to test changes in your applications or configuration before rolling those changes into the production environment. For example, you have modified a WebCenter Spaces application, you want to deploy a newer version of a WebCenter Framework application, or you have modified existing security policies or configuration.
To move the changes to an existing production environment, perform the following tasks:
Task 1, "Export Oracle WebCenter Spaces Data from the Test Environment"
Task 2, "Import Group Spaces Data to the Production Environment"
Task 3, "Export WebCenter Group Space Template from the Test Environment"
Task 4, "Import WebCenter Group Space Template from the Test Environment"
To export Oracle WebCenter Spaces data from the test environment:
Export Oracle WebCenter Spaces data from Discussion Forum, using the Oracle Database export utility:
ORACLE_HOME/bin/export "sys/password@connect_id as sysdba" $discussions_schema/$discussions_password file=discussions_forumid.dmp log=jive_forumid.log TABLES=jiveforum,jiveThread,jivemessage,jiveForumProp,jiveQuestion,jiveAnswer, jiveGateway rows=y STATISTICS=None QUERY=\"WHERE forumid \= $forumid\"
Export the Oracle WebCenter Spaces data from Wiki, using the owc_wiki_export.sql script. The script is located in the following directory:
ORACLE_HOME/wikiserver/owc-wiki/WEB-INF/classes
Use the following commands:
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" create or replace directory WC_PUMP_DIR as 'path'; grant read,write on DIRECTORY WC_PUMP_DIR to user; @owc_wiki_export.sql
Export the Group Space from the test environment:
Login to WebCenter Spaces with administrative privileges.
Click the Administration link at the top of the application.
Click the Group Spaces tab.
Click the Group Spaces subtab.
Select the group space required by highlighting the row in the table.
From the Change State drop down, select Offline.
Click Save.
Click Export in the toolbar.
To import Group Spaces data to the production environment:
Import Group Space data into the Discussion Forum data into the production database. You import the file that you exported from the test database in Task 1. (ORACLE_HOME is the Oracle home for the production database.)
ORACLE_HOME/bin/impdp "sys/password@connect_id as sysdba" file=filename log=df_category.log ignore=y STATISTICS=None FROMUSER=test_prefix_DISCUSSIONS TOUSER=prod_prefix_DISCUSSIONS
imp sys/passwd@dbhost file=T2PTEST_category.dmp log=df_category.log ignore=y STATISTICS=None FROMUSER=TEST_DISCUSSIONS TOUSER=PROD_DISCUSSIONS imp sys/passwd@dbhost file=T2PTEST_forumid.dmp log=df_forumid.log ignore=y STATISTICS=None FROMUSER=TEST_DISCUSSIONS TOUSER=PROD_DISCUSSIONS imp sys/passwd@dbhost file=T2PTEST_forumid_perm.dmp log=df_forumid_perm.log ignore=y STATISTICS=None FROMUSER=TEST_DISCUSSIONS TOUSER=PROD_DISCUSSIONS
Import Group Space data into Wiki using the owc_wiki_import.sql script. Edit the script, adding the following line before the line DBMS_DATAPUMP.start_job(dp_handle)
:
DBMS_DATAPUMP.METADATA_REMAP(dp_handle,'REMAP_SCHEMA','source','target');
Create the directory WC_PUMP_DIR in the production environment.
Copy the file that you generated when you exported the data from the database in Task 1, to the WC_PUMP_DIR in the production environment.
Run the script:
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" @owc_wiki_import.sql
Import the Group Space to the production environment:
Login to WebCenter Spaces with administrative privileges.
Click the Administration link at the top of the application.
Click the Group Spaces tab.
Click the Group Spaces subtab.
Select the group space required by highlighting the row in the table.
From the Change State drop down, select Offline.
Click Save.
Click Import in the toolbar and select the exported archive.
Import Group Space data from the Content Server, by using WebDAV to drag the folders under the Group Spaces in the test environment to Group Spaces in the production environment.
To export the Group Space template from the test environment:
Login to WebCenter Spaces with administrative privileges.
Click the Administration link at the top of the application.
Click the Group Spaces tab.
From the Group Spaces tab, select Templates.
Click Export in the toolbar.
To import the Group Space template to the production environment:
Login to WebCenter Spaces with administrative privileges.
Click the Administration link at the top of the application.
Click the Group Spaces tab.
From the Group Spaces tab, select Templates.
Click Import in the toolbar, and select the exported archive.
In this scenario, you have installed Oracle HTTP Server and Oracle Web Cache in a test environment and you want to move them to a production environment.
The following topics describe how to move the Web tier from a test environment to a production environment:
The following topics describe how to move the Web tier to a new production environment:
In this scenario, you have installed Oracle HTTP Server in a test environment and you want to move it to a production environment, which does not yet exist. In the test 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 scenario, the Oracle Access Manager Access Servers are not in the test environment. They reside on a separate production system. However, WebGate is running in the test environment.
To move this environment to a new production environment, perform the following tasks:
Note that if Oracle HTTP Server is used by WebGate, you must first move Oracle Access Manager to the production environment, as described in Section 21.2.1, Task 9 or Task 10, depending on your version of Oracle Access Manager.
In the production environment, move the binary files and create the Oracle instance and one or more Oracle HTTP Server component instances:
Move a copy of the Middleware home containing Oracle HTTP Server.to the production environment, as described in Section 20.5.1. The Oracle homes in the Middleware home are also moved.
Move the Oracle HTTP Server configuration, as described in Section 20.5.3.1. This step moves the configuration, including the Oracle instances. In addition, it:
Updates the Listen address and the name of the virtual host.
Configures SSL, if it was configured in the test environment.
Updates the httpd.conf file with new values for the environment and topology directives, such as host name, 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 production environment.
Configures SSL for mod_wl_ohs, if SSL is configured for mod_wl_ohs.
Configures mod_osso, if it was configured in the test environment.
Configures PL/SQL, if it was configured in the test environment.
Configures mod_osso, if it was configured in the test environment.
Updates audit.config.xml, if any changes were made to it in the test environment.
Updates component-log.xml, if any changes were made to it in the test 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 scenario, you have installed Oracle Web Cache in a test environment and you want to move it to a production environment, which does not yet exist. In the test 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.
To move this environment to a new production environment, perform the following tasks:
In the production environment, move the binary files and create the Oracle instances and Oracle Web Cache instances:
Move a copy of the Middleware home containing Oracle Web Cache to the production environment, as described in Section 20.5.1. The Oracle homes in the Middleware home are also moved.
Create the Oracle instances and the Oracle Web Cache instances.
To create the Oracle instances and Oracle Web Cache instances using the Oracle Universal Installer, take the following steps:
Run the following script:
(UNIX) ORACLE_HOME/common/bin/config.sh (Windows)ORACLE_HOME\common\bin\config.bat
Follow the instructions in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier.
To create the instances and components using the command line, take the following steps:
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 -adminPassword 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 test 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 production environment is different from the password at the test environment:
Copy the value of the PASSWORDHASH attribute of the <USER TYPE="INVALIDATION"> element from the webcache.xml file for the production 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 production 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 production environment.
For each <CACHE> element in webcache.xml, change the following, substituting the values that correspond to the host where the production 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 production 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 production 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 production system:
(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 test environment to the corresponding production 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 test environment to the corresponding production 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 test environment to the production 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 test environment for either an SSL-enabled listen address or an OSwallet, or both, export the wallets from the test environment and import them at the production environment. For information about exporting and importing wallets, see Section 8.4.4.
In this scenario, you have a working production environment and want to test changes in your applications or configuration before rolling those changes into the production environment.
For Oracle HTTP Server, see Section 21.5.2.1.
For Oracle Web Cache, perform Task 2 in Section 21.5.1.2.
To move Oracle HTTP Server to an existing production environment, you update the configuration:
Copy any custom contents, such as contents that have been changed or added to the htdocs directory, to the production 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 production environment. Then, copy auditconfig.xml from the test environment to the corresponding production 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 production environment. Then, copy the file, which is located in the following directory, from the test environment to the production environment:
ORACLE_INSTANCE/diagnostics/logs/OHS/ohs_component_name
In this scenario, you have installed Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle Business Intelligence Discoverer, in a test environment and you want to move it to a production environment.
The following topics describe how to move these components from a test environment to a production environment:
In both scenarios, you have performed the following in a test environment:
Installed a database to be used for these components.
Created schemas needed by the components, using RCU.
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 and new templates.
Created 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 scenario, you have installed Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle Business Intelligence Discoverer in a test environment and you want to move the components to a production environment that does not exist.
Although this section describes how to move all of the components to a production environment, you can choose to move only some of them.
To move this environment to a new production environment, perform the following tasks:
Task 1, "Copy the Database to the New Production Environment"
Task 3, "Move Oracle Portal to the New Production Environment"
Task 4, "Move Oracle Forms Services to the New Production Environment"
Task 6, "Move Oracle Business Intelligence Discoverer to the New Production Environment"
Move the database to the production system by using the Oracle Database RMAN utility.
For detailed steps, see the Oracle Database Backup and Recovery User's Guide, which is available at:
http://www.oracle.com/technology/documentation/database.html
See Appendix D for the schemas used by each component.
To install and configure the components:
Move a copy of the Middleware home, as described in Section 20.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.
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.3.4.
For Oracle Portal, specify the credentials to connect to Oracle Internet Directory at the Configure Components screen.
To move Oracle Portal configuration to a new production environment:
Create a transport set on the test 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 test environment, as described in "Exporting Data" in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.
On the production environment, create a database link to the test 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 first 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, the contents of the transport set must first be moved to the transport set tables on the target system. You do this by acquiring the transport set from the test 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 test environment to the LDAP directory in the production 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 test system. 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 production system, 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 test environment file to the production 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 WebCenter or Oracle Portal is moved from test to production 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 production environment:
Stop the processes running in the Oracle instance and stop the Managed Servers in the production 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, and PLX) from the test environment to the production 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 production environment. Instead, add the location to the default.env file.
Move the application-related data from the test environment to a database in the production environment using database migration tools.
Create entries in the SQL*Net configuration files to refer to the database in the production environment.
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 test environment to Oracle Internet Directory in the production environment. See Step 3 in Task 3, "Move Oracle Internet Directory to the New Production Environment" in Section 21.2.1.
Copy any customizations in the following files that you want to maintain from the test environment file to the production environment file:
Type of File | Location |
---|---|
Forms application configuration |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config/formsweb.cfg
|
Forms server configuration |
DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/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 test environment to the production 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
|
Forms applications .ear |
ORACLE_HOME/forms/j2ee/formsapp.ear
|
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_HOME\bin\frmbld.bat ORACLE_HOME\bin\frmcmp.bat ORACLE_INSTANCE\bin\frmplsqlconv.bat ORACLE_INSTANCE\bin\frmxmlsg.bat ORACLE_INSTANCE\bin\frmcmp_batch.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 production 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 made customizations to the Forms Java EE application .ear file, such as overriding the default Forms servlet access URL, custom deploy the Forms Java EE application .ear file and create servlet aliases similar to test environment in the Forms Java EE application web.xml file.
To move Oracle Reports to the production environment:
For the following Oracle Reports Server configuration files, merge changes made from the test environment to the production environment files. Note that you cannot just copy the files from the test environment to the production 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/ReportsServer/server_name/jdbcpds.conf ORACLE_INSTANCE/config/ReportsServer/server_name/xmlpds.conf ORACLE_INSTANCE/config/ReportsServer/server_name/textpds.conf ORACLE_INSTANCE/config/ReportsServer/server_name/rwnetwork.conf ORACLE_INSTANCE/config/ReportsServer/server_name/component-logs.xml ORACLE_INSTANCE/config/ReportsServer/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/ReportsTools/rwbuilder.conf ORACLE_INSTANCE/config/ReportsTools/rwnetwork.conf ORACLE_INSTANCE/config/ReportsTools/jdbcpds.conf ORACLE_INSTANCE/config/ReportsTools/xmlpds.conf ORACLE_INSTANCE/config/ReportsTools/textpds.conf ORACLE_INSTANCE/config/ReportsTools/component-logs.xml ORACLE_INSTANCE/config/ReportsTools/logging.xml |
Reports Bridge configuration |
ORACLE_INSTANCE/config/ReportsBridge/bridge_name/rwbridge.conf ORACLE_INSTANCE/config/ReportsBridge/bridge_name/rwnetwork.conf ORACLE_INSTANCE/config/ReportsBridge/bridge_name/component-logs.xml ORACLE_INSTANCE/config/ReportsBridge/bridge_name/loggin.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 test environment to the production environment files. Note that you cannot just copy the files from the test environment to the production 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/uTk2Motif.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 test environment, create these in the production environment using opmnctl.
For resources related to Oracle Reports Server, take the following actions:
Copy any fonts used in the test environment from the directory specified by environment variable REPORTS_FONT_DIRECTORY to production environment. By default, they are in ORACLE_INSTANCE/reports/fonts.
Move the Common UNIX Printing System (CUPS) printing configuration to the production 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 test environment to the production environment.
Deploy JSP Web reports to the production environment in the following location:
DOMAIN_HOME/servers/WLS_REPORTS/stage/reports/reports/web.war
Move Reports-specific data tables that are referred to in the RDF files to the database in the production 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 production environment:
ORACLE_INSTANCE/reports/cache
For Reports scheduled job information, copy the server data (server_name.dat) file to the following location in production 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 test environment and the production 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 production environment.
If the job repository or job status repository is configured in the database, you must create the same schemas in the production environment database and move the data:
Use the following script:
ORACLE_HOME/reports/admin/sql/rw_job_repos.sql
Move any data from the test database for the schemas RW_JOBS, RW_SERVER_JOB_QUEUE, and RW_SERVER_QUEUE to production 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 test environment to Oracle Internet Directory in the production environment. See Step 3 in Task 3, "Move Oracle Internet Directory to the New Production Environment".
If you used JAZN-XML-based identity and policy store in the test environment, move them to the LDAP in the production 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 WLST command migrateSecurityStore
, as described in "Migrating Credentials with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.
Move any database proxy users to the production database using database cloning tools.
If any Reports plug-ins are registered, copy the corresponding .jar files to the production environment and add the path to the files to the environment variable REPORTS_CLASSPATH.
To move Oracle BI Discoverer to the new production environment:
If you have modified the default user preferences, copy the following files from the test environment to the production 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 test environment to the production environment:
DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_11.1.1.3.0/configuration/configuration.xml DOMAIN_HOMEconfig/fmwconfig/servers/WLS_DISCO/applications/discoverer_11.1.1.3.0/configuration/configuration-preview.xml
In the configuration.xml file, change the values of the following elements to reflect the production environment:
applicationURL
oracleInstance
discovererComponentName
If you have changed the server configuration files, copy the following file from the test environment to the production environment:
ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml
Copy the following file from the test environment to the production environment:
ORACLE_INSTANCE/config/OHS/ohs_name/moduleconf/module_disco.conf
Change the values of the following elements to reflect the production environment:
WebLogicCluster. Valid only if a cluster exists.
WebLogicHost
WebLogicPort
Copy the following files from the test environment to the production environment:
DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/base-descktop.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/blstyles.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/dc-blaf-review.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/dc-blaf.xsd DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/dc-blaf.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/minimal-desktop.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/minimal-pda.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/oracle-desktop.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/oracle-pda.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/pocketPC.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/simple-desktop.xss DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/swan-desktop.xss
Copy some or all of the files in the following directory, depending on which files you use:
DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/discoverer.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 test environment to the production environment:
ORACLE_HOME/network/admin/tnsnames.ora
Move the DISCOVERER schema from the test environment to the production 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 test and production, you do not need to move the data.
Move the EUL data from the test environment to the production environment:
Create the EUL user and an empty EUL on the production 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 test database by using the Discoverer Administrator to export the schema from the test database and import it into the database in the production 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 test environment to the production environment:
Install the catalog in the production 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 production 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 test database and import it into the database in the production 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 test Discoverer metadata repository to the production 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 production 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 production environment as in the test environment.
In this scenario, you have installed Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle Business Intelligence Discoverer in a test environment and you want to move the components to a production environment that already exists.
To move to an existing production environment, perform the following tasks:
Task 1, "Move Oracle Portal to an Existing Production Environment"
Task 2, "Move Oracle Forms Services to an Existing Production Environment"
Task 3, "Move Oracle Reports to an Existing Production Environment"
Task 4, "Move Oracle Business Intelligence Discoverer to an Existing Production Environment"
This scenario assumes that you have made changes to Oracle Portal in the test 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 production environment, take the steps described in Task 3, "Move Oracle Portal to the New Production Environment" in Section 21.6.1.
To move Oracle Forms Services to the existing production environment:
Copy the Oracle Forms Services application files (FMX, MMX, and PLX) from the test environment to the production 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 production 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 production environment, take the same steps as described in Task 5, "Move Oracle Reports to the New Production System" in Section 21.6.1.
In this scenario, you primarily use the test environment to create EULs for developing a business area without compromising the performance of production systems.
To move Oracle BI Discoverer to an existing production environment:
Move the configuration files that are listed in Steps 1 and 5 in Task 6, "Move Oracle Business Intelligence Discoverer to the New Production Environment".
Move the DISCOVERER schema from the test environment to the production 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 test and production, you do not need to move the data.
Move the EUL schema from the test environment to the production environment by using the Oracle database export and import utilities to export the schema from the test database and import it into the database in the production environment.
Note that the user names and schema names must be the same in the production environment as in the test environment.
This section describes the steps for moving Oracle Business Intelligence from a test environment to a production 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 test to production considerations for the repository.The following scenarios assume that you have already installed and configured Oracle Business Intelligence components in a test environment and that you want to move them to either a new or an existing production environment:
If you are applying patches to an existing production 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.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.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 a test environment to a new production environment.
This scenario assumes that you have already installed and configured Oracle Business Intelligence components in a test environment and that you want to move them to a new production environment. The steps for moving to a new production environment are identical to the migration process.
To move Oracle Business Intelligence components to a new production environment, perform the following tasks:
Task 3, "Extract the Archive into the New Production Environment"
Task 4, "Create a BI Domain in the New Production Environment"
Task 5, "Configure Security in the New Production Environment"
Task 8, "Copy and Scale Out to New Cluster Hosts in the Production Environment"
Task 9, "(Optional) Refresh Global Unique Identifiers (GUIDs)"
Task 10, "Enable New Agents and Oracle BI Publisher Scheduled Jobs"
Task 12, "(Optional) Move Oracle Business Intelligence Related Applications"
Patch the test environment, and test the environment until it is ready.
For information, see Oracle Fusion Middleware Patching Guide.
If you are trying new configuration settings, then note down the changes that you made so that they can be replicated.
Copy the Middleware home containing the Oracle BI EE components from the test environment using the copyBinary script, as described in Section 20.3.1.
In the test environment, use the Administration Tool and the Oracle BI Server XML API to perform a patch merge of the test repository file (.rpd) with the production file.
See "Performing Patch Merges" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for more information.
Copy the archive file (created in Task 1, "Patch and Move the Test Environment") from the test environment to the production environment.
Copy the following files to the production environment:
UNIX:
ORACLE_COMMON_HOME/bin/pasteBinary.sh ORACLE_HOME/jlib/cloningclient.jar
Windows:
ORACLE_COMMON_HOME\bin\pasteBinary.cmd
ORACLE_HOME\jlib\cloningclient.jar
Ensure that JDK 1.6.4 or later or JRockit (which is installed with the Oracle Business Intelligence installer) is installed in the production environment.
Use the pasteBinary script to recreate the Middleware home in the new production environment, as described in Section 20.3.1.
For information, see Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence.
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, policies, 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 Production Environment"
Oracle WebLogic Server: See Oracle Fusion Middleware Securing Oracle WebLogic Server
Oracle Platform Security Services: See Oracle Fusion Middleware Application Security Guide
Copy the repository file (.rpd) to the production environment.
Zip the entire Oracle BI Presentation Catalog in the test environment (using zip).
Unzip the catalog in the new production environment.
For information, see Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Use Fusion Middleware Control to set the catalog location in the production environment.
For information, see "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Use Fusion Middleware Control in the new production environment to upload the repository file (.rpd).
For information, see "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" in 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 file. The file might contain data source connection information from the test environment that must be changed to the production environment connection settings.
See "Moving from Test to Production Environments" in Oracle Fusion Middleware Integrator's Guide for Oracle Business Intelligence Enterprise Edition for information about performing this step using the Oracle BI Server XML API.
(Optional) Make the production repository file read-only by selecting Disallow Online RPD Updates in the Performance tab of the Capacity Management page in Fusion Middleware Control.
Copy the archive file (created in Task 1, "Patch and Move the Test Environment") 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.3.1.
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.
You do not normally refresh GUIDs in the LDAP directory (identity store users) between test and production environments, because the LDAP directories that contain the GUIDs should be fan-out replicas in both the test and the production environments. Possible scenarios for refreshing are described in the following list:
Oracle Business Intelligence test servers and production servers are both configured against the corporate LDAP directory.
There is no need to refresh LDAP GUIDs.
Oracle Business Intelligence test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is a fan-out replica of the corporate LDAP directory.
There is no need to refresh LDAP GUIDs.
Oracle Business Intelligence test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is not a fan-out copy of the corporate LDAP directory.
A refresh of the LDAP GUIDs is needed. For information, see Section 21.7.4.
If new agents were created in the test environment, click each agent in the Oracle BI Presentation Services Catalog Manager (in the production environment) to enable it.
Oracle BI Publisher reports are stored in the Oracle BI Presentation Catalog and so existing reports and new reports that are created in the test environment should be available.
In a production environment, Oracle WebLogic Server administrators should create JNDI connections (to be used by Oracle BI Publisher reports), using the same names as in the test environment. The connections should point to the production databases instead of the test databases. In this way, all reports automatically point to the production environment databases, instead of test environment databases, without any modification.
Ensure that you move the static content that relates to external systems to the production environment, including the following files: JPG files in dashboards, Oracle Web Services Manager policy files, Action Framework files, and other policy files that specify how to communicate with external systems.
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 Oracle BI for Microsoft Office) to the new production environment. For information, see the appropriate sections for these applications (where available).
Validate that the production system accurately represents the test system.
This section describes the steps for moving Oracle Business Intelligence from a test environment to an existing production environment when there are few patches to apply. (See Section 21.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 a test environment and that you want to move them to an existing production environment.
To move Oracle Business Intelligence components to an existing production environment when there are few patches to apply, perform the following tasks:
Task 1, "Patch the Test and Existing Production Environments"
Task 2, "Deploy the Test Repository File to the Existing Production Environment"
Task 3, "Deploy the Test Oracle BI Presentation Catalog to the Existing Production 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 test environment as required, and test until ready.
Patch the existing production environment to the same level as the test 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 test environment, use the Administration Tool and the Oracle BI Server XML API to perform a patch merge of the test repository file (.rpd) with the production file.
You must complete this task only if you are moving to an existing production environment and have made changes to the RPD file in the test 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 production environment to upload the RPD file to use.
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 test environment that must be changed to the production environment connection settings.
See "Moving from Test to Production Environments" in the Oracle Fusion Middleware Integrator's Guide for Oracle Business Intelligence Enterprise Edition for information about performing this step using the Oracle BI Server XML API.
(Optional) Make the production 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 test catalog into the production catalog as follows:
Open two Catalog Manager windows: one with the test catalog and another with the production catalog.
Selectively copy and paste the folders that you want from the test catalog into the production catalog.
Note: If you copy and paste folders where the same content has been changed in the test or production environments, then the test content overwrites the production 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 production 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 test and production environments, because the LDAP directories that contain the GUIDs should be fan-out replicas in both the test and the production environments. Possible scenarios for refreshing are described in the following list:
Oracle Business Intelligence test servers and production servers are both configured against the corporate LDAP directory.
There is no need to refresh LDAP GUIDs.
Oracle Business Intelligence test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is a fan-out replica of the corporate LDAP directory.
There is no need to refresh LDAP GUIDs.
Oracle Business Intelligence test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is not a fan-out copy of the corporate LDAP directory.
A refresh of the LDAP GUIDs is needed. For information, see Section 21.7.4.
If new agents were created in the test environment, then click each agent in the Oracle BI Presentation Services Catalog Manager (in the production environment) to enable it.
Oracle BI Publisher reports are stored in the Oracle BI Presentation Catalog and so existing reports and new reports created in the test environment should be available.
In a production environment, Oracle WebLogic Server administrators should create JNDI connections (to be used by Oracle BI Publisher reports), using the same names as in the test environment. The connections should point to the production databases instead of the test databases. In this way, all reports automatically point to the production environment databases, instead of test environment databases, without any modification.
Ensure that you move the static content that relates to external systems to the production environment, including the following files: JPG files in dashboards, Oracle Web Services Manager policy files, Action Framework files, and other policy files that specify how to communicate with external systems.
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 Oracle BI for Microsoft Office) to the existing production environment. For information, see the appropriate sections for these applications (where available).
Validate that the production system accurately represents the test system.
This section describes the steps for moving Oracle Business Intelligence from a test environment to an existing production environment when there are many patches to apply.
The following scenarios assume that you have already installed and configured Oracle Business Intelligence components in a test environment and that you want to move them to an existing production environment.
Use one of the following strategies to move Oracle Business Intelligence components to an existing production environment when there are many patches to apply:
Moving to an Existing Production Environment When New Hardware Is Available
Moving to an Existing Production Environment When New Hardware Is Not Available
Perform the following tasks to move Oracle Business Intelligence components to an existing production environment when there are many patches to apply and new hardware is available:
Task 1, "Follow the Steps for Moving to a New Production Environment"
Task 2, "Switch Users from the Existing Production Environment to the New One"
Task 3, "Remove the Existing Production Environment and Prepare It for the Next Patch"
Complete the steps in Section 21.7.1 for moving to a new production environment.
These steps include merging the new test RPD file and catalog with those in the existing production environment. Ideally you merge once and resolve the issues while users continue using the existing environment. When the files are correct, you lock the production 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 production 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 production 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 production 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 production environment.
For more information, see the Fusion Middleware Control Help system.
Patch the host in the production 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 8, "Copy and Scale Out to New Cluster Hosts in the Production Environment" in Section 21.7.1.
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.
Note:
Refreshing the GUIDs requires that you stop and restart the system components from the command line and not Fusion Middleware Control. This includes the Administration Server and Managed Servers. After the Administration Server is stopped, you cannot start it from Fusion Middleware Control because it is not available during this time.To refresh the user GUIDs:
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 to add the last line in the following instruction.
<ps:Catalog xmlns:ps="oracle.bi.presentation.services/config/v1.1"> <ps:UpgradeAndExit>false</ps:UpgradeAndExit> <ps:UpdateAccountGUIDs>UpdateAndExit</ps:UpdateAccountGUIDs>
From a terminal window, stop and restart the managed processes using the opmnctl
parameters stopall
and startall
. You can use the parameter status
to verify process status throughout.
The following components are involved: Presentation Services, Oracle BI Server, Oracle BI Scheduler, Oracle BI Cluster Controller, and Oracle BI JavaHost.
For information about using opmnctl
commands, see "Using the OPMN command line to Start and Stop Oracle Business Intelligence System Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Edit the NQSConfig.INI file to reset the FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = YES
to NO
and restart the Oracle BI Servers.
Remove, set to none
, or comment out the last line added to the instanceconfig.xml file (that instructs Presentation Services to refresh GUIDs on restart, as specified in Step 3).
<ps:Catalog xmlns:ps="oracle.bi.presentation.services/config/v1.1"> <ps:UpgradeAndExit>false</ps:UpgradeAndExit> <ps:UpdateAccountGUIDs>none</ps:UpdateAccountGUIDs>
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.
The following topics describe how to move Oracle Real-Time Decisions (Oracle RTD) from a test environment to a new production environment:
Moving Oracle Real-Time Decisions to a New Production Environment
Moving Oracle Real-Time Decisions to an Existing Production Environment
To move the environment to a production environment, perform the following tasks:
Task 1, "Move the Middleware Home and Perform the Initial Configuration"
Task 2, "Install Oracle RTD Clients (If Used) on the Production Environment"
Task 4, "Edit Additional Oracle RTD Components for Production"
To move the Middleware home and Oracle RTD software and perform the initial configuration:
Create the required schemas in the production database using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
Move a copy of the Middleware home, as described in Section 20.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.
If your environment includes Oracle BI EE and you have already moved Oracle BI EE to a new production environment, as described in Section 21.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.
Configure Oracle RTD and create a domain using the Configuration Wizard. See "Configuring Oracle RTD After Installation" in the Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions. For the purposes of this configuration, follow the steps for configuring Oracle RTD after a Software Only install.
The following are important factors to consider in the setup and configuration of the production system:
When using the Repository Configuration Utility (RCU), connection pools must reflect database connections specific to the production environment.
During the configuration of custom roles and security settings, the setup parameters must be modified to reflect settings for the production environment.
For more details, see the Security chapter in Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.
Any performance tuning parameters defined in the test environment should also be re-created in the production environment. This includes performance parameters both at the application server and database levels.
If used for the integration of Oracle RTD to a customer's front-end applications, Oracle RTD clients must be installed in the production 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 production architecture.
Move Oracle RTD Inline Services that exist on the test environment to the production environment:
Moving Inline Services to the production 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, via 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 production 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 test and production 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 test and production 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 production environment should be configured to point to the production database.
Additional tasks that you may need to perform with Oracle RTD include the following:
Creating and configuring the model snapshot tables.
The Oracle RTD model snapshot tables can be created in the production environment in two ways, 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 production 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 a production 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 production follows the same steps as outlined for a full product test to production move.
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.
The following topics describe how to move Oracle Enterprise Content Management Suite to a production environment:
Moving Oracle Enterprise Content Management Suite to a New Production Environment
Moving Oracle Enterprise Content Management Suite to an Existing Production Environment
In both scenarios, you have performed the following in the test environment:
Installed a database to be used for required schemas.
Created needed schemas 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 Enterprise Content Management Suite.
If Oracle Imaging and Process Management uses Workflow or Oracle Application Extension Framework (AXF), installed and configured Oracle SOA Suite.
Configured Oracle Universal Content Management.
Configured Oracle Imaging and Process Management.
If Oracle I/PM uses Oracle Universal Content Management 10g repository, ensure that the repository was manually configured for Oracle I/PM.
Configured Oracle Universal Records Management.
Defined several definitions, such as Connections, Applications, Searches, and Inputs for Oracle I/PM.
Installed and configured Identity Management components, such as Oracle Internet Directory.
To move Oracle Enterprise Content Management Suite to a new production environment, perform the following tasks:
Task 1, "Create a New Database and Populate It with Schemas"
Task 2, "Move the Middleware Home and the Oracle Enterprise Content Management Suite Configuration"
Task 3, "Modify Oracle Information Rights Management Settings"
Task 4, "Move Oracle Universal Content Management to a New Production Environment"
Task 5, "Move Oracle Imaging and Process Management to a New Production Environment"
Task 6, "Move Oracle Universal Records Management to a New Production Environment"
Note that in a production system, Oracle Enterprise Content Management Suite 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 create the database and populate it with the necessary schemas:
Create a new database on the production system.
Create the required schemas in the production database using RCU. See the Oracle Fusion Middleware Repository Creation Utility User's Guide.
Take the following steps to move the Middleware home and perform the initial configuration:
Move a copy of the Middleware home using the copyBinary and pasteBinary scripts, as described in Section 20.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.
Move the configuration of Oracle Enterprise Content Management Suite by using the copyConfig, extractMovePlan, and pasteConfig scripts as described in Section 20.5.2.
This step copies the configuration of Oracle Enterprise Content Management Suite components. It copies the domain directory, the Administration Server, and Managed Servers. It also:
Modifies information about the database that contains Oracle IRM metadata.
Copies the Oracle I/PM sample input files, if they are in the domain directory.
Copies the BPEL credentials.
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.
If you are using an Oracle UCM 10g repository, ensure that Full-Text is configured correctly on the production Oracle UCM system, if configured on the test Oracle UCM 10g system.
Note that if you are using an Oracle UCM 10g server, it is not configured when you move the Oracle Enterprise Content Management Suite. you must install it, similar to the way you installed it in the test environment, using the procedures described in the Oracle Universal Content Management page at:
http://www.oracle.com/technology/products/content-management/ucm/index.html
You need to modify some Oracle IRM settings in the new production 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 test 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 Installation Guide for Oracle Enterprise Content Management Suite.
If the production environment is not using the same LDAP store as the test environment, migrate the users from the test environment to the production environment. See "Reassociating the Identity Store with an External LDAP Authentication Provider" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.
To move Oracle Universal Content Management to a new production environment:
Export the OCS database schema from the test 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 production database.
Import the OCS database schema that you exported from the test 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 a new database to hold the new search collection.
To set up an Oracle Secure Enterprise Search instance and configure it for Oracle UCM on the production system:
Install Oracle Secure Enterprise Search as described in the Oracle Secure Enterprise Search Installation and Upgrade Guide.
Create a new data source to connect to Oracle Secure Enterprise Search. See Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server.
Oracle recommends that you use the same data source name as in the test environment.
On the Oracle Universal Content Management 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 Fusion Middleware System Administrator's Guide for Content Server.
If you configured the IntradocDir, WeblayoutDir, and VaultDir directories to be outside of the domain structure, copy the directories to the production environment.
In the production environment, modify the following file, updating the entries for IntradocDir, WeblayoutDir, VaultDir, and IdcHomeDir:
DOMAIN_HOME/bin/intradoc.cfg
This step is not necessary if the directory structures of the production environment is the same as the test environment.
On the production system, delete the following file:
IntradocDir/data/contenttracker/config/sct.cfg
The file is regenerated when you restart the server.
Modify the following file, updating the HttpServerAddress to reflect the correct address:
instance_dir/config/config.cfg
To use the new production system as a template and replicate it in multiple production systems, you follow the procedures in Task 2, "Move Oracle Universal Content Management to an Existing Production Environment", except that you must also change the parameters IDC_Name, InstanceMenuLabel, InstanceDescription, HttpServerAddress, and AutoNumberPrefix in the following file:
instance_dir/config/config.cfg
You may also need to change the parameters MailServer and SysAdminAddress.
Note that no Oracle I/PM data is migrated in this procedure. Data migrated with Oracle UCM will not be accessible from production Oracle I/PM system.
Before you begin this procedure, if you use Workflow Integration or Oracle Application Extension Framework (AXF), you have:
Installed and configured Oracle SOA Suite and moved its test environment to the production environment, as described in Section 21.3.1.
Configured Oracle I/PM, extending the SOA domain, as described in "Extending an Existing Domain" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.
To move Oracle I/PM to the new production environment:
Start the Administration Server and the Oracle I/PM Managed Server.
Ensure that the Oracle UCM 11g Managed Server is running, or, if you are using Oracle UCM 10g, that the Oracle UCM 10g services are running.
If you have moved Oracle Internet Directory to the production environment, export Oracle I/PM users and groups from the test environment.
The user who logs in first to an Oracle I/PM Managed Server is provisioned with full security throughout the server. It is easier to reassociate the identity store for Oracle I/PM with an external LDAP authentication provider before the first user logs in, completes the configuration of the Oracle I/PM Managed Server, and connects it to the Oracle UCM repository.
Export the users and groups from LDAP identity store on the test environment, using the ldapsearch command. This produces an ldif file that you later import into the LDAP identity store in the production 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"
Export the system definitions from the test environment.
Note the following:
This procedure does not transfer any documents from the test environment to the production environment. This procedure only moves the structure defined by the applications, inputs, and searches.
The documents reside within the supporting Oracle UCM repository. Oracle I/PM does not recognize any documents that were transferred using Oracle UCM test-to-production procedures or database utilities. The documents will not be accessible from Oracle I/PM. Use Oracle I/PM to upload new documents into the Oracle UCM repository.
Log into the test system as administrator to export the definitions, using the following URL:
http://hostname:16000/imaging
Expand Tools, then select Export Definitions.
For Export Comments, enter any comments, then click Next.
Select the applications to export, then click Next.
Select the searches to export. All dependent applications for each search are included in the export. Click Next.
Select the inputs to export. All dependent applications for each input are included in the export. Click Next.
Review your selections for accuracy, then click Next.
If you need to make any changes, select the appropriate type of definition at the top of the page, such as Applications, and correct the selections. Then, select the Summary at the top of the page.
Select Create Export File.
Depending on your browser, a dialog box is displayed allowing you to open or save the file. The file is saved to the location you specify.
If the sample files are outside the domain directory, copy the files from the test environment to the production environment. The location of the files is specified in the Oracle I/PM MBean SampleDirectory.
For information about the Oracle I/PM MBeans, see "Oracle I/PM MBeans" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management. For more information about using Input sample files to create input definitions, see "Creating Input Definitions" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.
If you have moved Oracle Internet Directory to the production environment, import users and groups into the LDAP identity store on the production environment by importing the ldif file that you exported from the test environment into the production 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
Enable SSL, as described in "System Security" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.
If a non-default wallet was used at the test environment for either an SSL-enabled listen address or an OSwallet, or both, export the wallets from the test environment and import them at the production environment. For information about exporting and importing wallets, see Section 8.4.4.
Configure connections on the production environment. Before you can import the applications into the production environment, you must set up the Oracle I/PM system connection objects that establish links to Oracle UCM repository and Workflow servers in the production environment. If the connections in the production environment are named the same as in the test environment, the imported definitions link correctly without further action.
If the names are different, you can select the desired connection name using the using the Oracle I/PM import tool.
Modify configuration settings. You use Fusion Middleware Control to modify the system MBean values, which control the execution of Oracle I/PM. If any MBean values need to be changed, follow the procedures in "Configuring the AgentUser and GDFontPath MBeans" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.
If the Work Manager configuration for the Input Agents does not already specify values for the production environment, update the configuration, as described in "Changing Oracle WebLogic Server Work Manager Settings" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.
If the Work Manager configuration for the Workflow Agents does not already specify values for the production environment, update the configuration, as described in "Changing WebLogic Server Work Manager Settings" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.
Note that User preferences are not migrated. Users must reconfigure their preferences on the production Oracle I/PM system.
Import the system definitions to the production environment.
Log into the production environment system as administrator to import the definitions, using the following URL:
http://hostname:16000/imaging
Expand Tools, then select Import Definitions.
For File Location, click Browse, and browse to the location of the file you exported from the test environment in step 4.
When you select the file, the File Date, and File Comments fields are populated.
Click Next.
From each table, select the applications, inputs, and searches, to be imported.
Selecting the Plus sign (+), shows the description for the definition. Selecting the pull down for the repository allows you to place each definition in any of the defined repository connections.
Click Next.
In the validation phase, you can see the status of each definition and you can select Document Security, Storage Policy, Workflow, and Full-Text options. See "Import Definitions: Validate Imports Page" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.
If any of the definitions are marked by a red X, the definition cannot be imported. Some of the likely causes are:
For search and input definitions, a required application was not imported.
The security checks failed.
The connection specified by the application does not exist.
The Workflow validation failed.
Correct any problems. When all the definitions are valid, select Submit.
If the validation is successful, the changes are committed. If there are errors, the page shows new exceptions. Correct any errors and click Submit.
Move the Oracle Application Extension Framework (AXF) configuration database:
Export the following tables from the test database schema and insert them into the production database schema:
AXF_ACTIONS
AXF_ACTION_MENU
AXF_ACTION_PARAMETERS
AXF_COMMANDS
AXF_ENUM_ITEMS
AXF_ENUM_TYPES
AXF_METADATA_ATTRIBUTES
AXF_METADATA_BLOCKS
AXF_SOLUTIONS
AXF_SOLUTION_ATTRIBUTES
AXF_SOLUTION_PARAMETERS
AXF_XPATH_NAMESPACES
AXF_XPATH_ATTRIBUTES
Modify the Workflow Connection information to point the connection to the production Workflow system.
If you are using a different Workflow Connection name in the production environment,update the PARAMETER_VALUE column. Using the Workflow connection created in step 9, update the PARAMETER_VALUE column for the BPEL_CONNECTION row in the AXF_SOLUTION_ATTRIBUTES table using your preferred SQL utility:
UPDATE AXF_SOLUTION_ATTRIBUTES SET PARAMETER_VALUE = '<ConnectionName>' WHERE PARAMETER_KEY = 'BPEL_CONNECTION'
If you have created any SOA Composites for an AXF solution in the test environment, deploy those versions of composites in the production environment, as described in the AXF11g Solution Template Guide.
If you cannot retrieve documents from the IPM Viewer, you must change the permissions for the following file:
DOMAIN_HOME/oracle/imaging/imaging-server/ixTransformer
To move Oracle Universal Records Management to a new production environment:
On the test environment, export the configuration settings, such as retention schedule, security classifications, and triggers, as described in "Exporting an Archive" in the Oracle Fusion Middleware Administrator's Guide for Universal Records Management.
Copy the archive to the production environment.
Import the archive to the production environment, as described in "Importing an Archive" in the Oracle Fusion Middleware Administrator's Guide for Universal Records Management.
In this scenario, you have installed Oracle Enterprise Content Management Suite components, such as Oracle Information Rights Management, in a test environment and you want to move them to a production environment that already exists.
On the existing production system, you have installed and configured the components. You want to move an application from the test environment to the production Oracle Enterprise Content Management Suite environment.
To move Oracle Enterprise Content Management Suite to an existing production environment, perform the following tasks:
Task 1, "Move Oracle Information Rights Management to an Existing Production Environment"
Task 2, "Move Oracle Universal Content Management to an Existing Production Environment"
Task 3, "Move Oracle Imaging and Process Management to an Existing Production Environment"
Task 4, "Move Oracle Universal Records Management to an Existing Production Environment."
Organizations that run a proof of concept or pilot (test) deployment can copy the operational service into a production environment and continue to use all existing test content, contexts, and rights.
The IRM server URL (for example protocol_schema:\\hostname:port\irm_desktop) is sealed into test content. Therefore, this value must not change on moving from test to production. For this reason, make sure you consider the following points when installing the test deployment:
Configure SSL in the test deployment because switching from the HTTP protocol in the test system to the HTTPS protocol in the production system would prevent test-sealed content from working in a production system.
Use a generic host name such as irm.example.com for the test deployment rather than a machine-specific host name such as mytestdeploymachine.example.com.
After the test to production installation has been completed, the DNS entries for domain name can be switched from the test server to the production system. If needed, you can use port redirection to ensure that the test deployment IRM Server URL points to the production environment deployment.
To move a test deployment into a production environment:
If the production database is different from the test database, you should back up the Oracle IRM schema. Restore the backup into the production database.
Copy the Oracle IRM keystore set up during the test installation to the production 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 test 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 "Setting Passwords for the Keystore" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.
Copy the Oracle IRM configuration file, irm-config.xml, which is usually located in the following directory, from the test environment to the production environment:
DOMAIN_HOME/config/fmwconfig
Because the test environment configuration may contain test-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 test environment keystore. The following is the suggested location of the file:
DOMAIN_HOME/config/fmwconfig
If the production environment is not using the same user store as the test environment, migrate the users from the test environment to the production environment. See "Reassociating the Identity Store with an External LDAP Authentication Provider" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.
To move Oracle Universal Content Management to an existing production 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 test environment to the production environment, export archives from the test environment and then import them into the production environment, as described in "Managing Imports and Exports" in the Oracle Fusion Middleware Administrator's Guide for Universal Records Management.
To move Oracle Imaging and Process Management from a test environment to an existing production environment, you use the same steps as described in Task 5, "Move Oracle Imaging and Process Management to a New Production Environment". However, note the following about updating definitions on the production environment:
When you import a definition from the test environment to the existing production 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 test environment, you much manually delete it in the production 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 production environment, open the Managed Inputs folder and select the input that you want to import.
Select Toggle On-Line.
To move Oracle URM to an existing production environment:
On the test environment, export any configuration settings that have changed, as described in "Exporting an Archive" in Oracle Fusion Middleware Administrator's Guide for Universal Records Management.
Copy the archive to the production environment.
Import the archive to the production environment, as described in "Importing an Archive" in Oracle Fusion Middleware Administrator's Guide for Universal Records Management.
The following topics describe how to move Oracle Data Integrator from a test environment to a production environment:
Moving Oracle Data Integrator to a New Production Environment
Moving Oracle Data Integrator Scenarios to an Existing Production Environment
In both scenarios, you have performed the following in a test environment:
Installed Oracle WebLogic Server and created the Middleware home for the Java components.
Created the required schemas in the test database using RCU.
Installed Oracle Data Integrator.
Configured and deployed Oracle Data Integrator Java components using the Configuration Wizard. The Java components can connect and use the test repositories.
Configured the standalone agents. The standalone agents can connect and use the test repositories.
Configured the logical and physical architecture in the topology. The connection of the data servers must be tested from the Studio as well as from any Physical Agent.
Configured the security by defining the users and the privileges.
Declared the Open Tools used by the Scenarios.
Deployed one or more development (packages) or run-time (scenarios) artifacts in the repositories.
Changed some configuration settings. For example, you may have changed the data server configuration to match the test environment.
In this scenario, you have installed Oracle Data Integrator in a test environment and you want to move it to a production environment which does not yet exist.
To move Oracle Data Integrator to a new production environment, perform the following tasks:
Task 1, "Install the Software and Perform the Initial Configuration"
Task 3, "Move the Work Repository Content to the Production Environment"
Task 4, "Change the Settings for the Production Environment"
To install the software and perform the initial configuration on the production system:
Create the required master and work repositories schemas in the production 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 production environment are created with unique IDs across your entire organization, including your development and test repositories. Also make sure that the production work repository is created with the same type as the test repository (For example, if the test work repository is created as a development repository, the production work repository must also be created as a development repository).
Install Oracle Data Integrator:
If you are using Java components, move a copy of the Middleware home from the test environment to the production environment, as described in Section 20.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.
If you have performed a standalone installation of Oracle Data Integrator (that is, you did not install any Java components), install Oracle Data Integrator with the same components in the production environment.
Create a domain containing Oracle Data Integrator:
If you are using Java components, move a copy of the domain containing Oracle Data Integrator from the test environment to the production environment, as described in Section 20.5.2.
If you have performed a standalone installation of Oracle Data Integrator, configure Oracle Data Integrator and create a domain using the Configuration Wizard, as described in "Configure a WebLogic Domain" in the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator.
Configure the Oracle Data Integrator standalone agents required in the production environment. See "Configuring the Standalone Agent" in the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator.
To move the topology to the new production environment:
Export the topology from the test master repository using Oracle Data Integrator Studio. See "Export/Import the Topology and Security Settings" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Import the topology into the production master repository using Oracle Data Integrator Studio. See "Export/Import the Topology and Security Settings" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator. Use the Synonym Mode INSERT_UPDATE for this import.
To move the work repository content to the new production environment:
Export the work repository content from the test work repository using Oracle Data Integrator Studio. See "Exporting and Importing a Work Repository" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Import the work repository content into the production work repository using Oracle Data Integrator Studio. See "Exporting and Importing a Work Repository" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Change the following settings in the production environment:
Topology settings: It is usually recommended to use different contexts for test and production environments, and switch the context to schedule or run scenarios in a given environment. Using a single context forces you to modify the physical architecture configuration (for example, the host name of the data servers) when moving to production.
If you are using different Oracle Data Integrator contexts for your test and production environments, and the physical architecture is already defined for the production environment, review this physical architecture before proceeding. See "Setting-up the Topology" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
If you are using a single context for both the environments, then you must review and change the following items in the physical architecture in the production master repository:
Physical Agents: Change the host, port, and Web application context (for Java EE Agent) to match the configuration of the production environment.
Data Servers: Change the data server connection information (JDBC, JNDI, data source name) to match the configuration of the production environment.
Physical Schemas: The schemas (including file folder location) defined for the data servers must match the configuration of the production environment.
Scheduling: If you are using different Oracle Data Integrator contexts for your test and production environments, and schedules are only defined to run in the test context, you must change these schedules in the production work repository to execute them in the production context. See "Scheduling Scenarios" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
If you are using a single context for both the environments, then existing schedules do not need to be modified.
If scenario schedules are not defined in the test environment, you can create them in the production environment.
Restart the standalone and Java EE agents in the production environment. These agents start processing the scheduled scenarios.
In this scenario, you have a number of new or regenerated scenarios in a test environment and you want to move them to a production environment that already exists.
Note:
Scenarios already deployed in the production environment should be regenerated before being moved in the production environment. They should not be deleted then generated.On the existing production system, you have installed and configured the components as described in Section 21.10.1. You want to move the data integration scenarios from the test environment to the production Oracle Data Integrator environment.
To move Oracle Data Integrator scenarios to an existing production environment, perform the following tasks:
Perform this task if the topology in the test environment was modified or added for the new scenarios.
To move topology updates to an existing production system:
Export updated and new physical and logical topology items (data servers, schemas, agents) from the test master repository using Oracle Data Integration Studio. See "Exporting and Importing Objects" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Import updated and new physical and logical topology items (data servers, schemas, agents) into the production master repository using Oracle Data Integration Studio. See "Exporting and Importing Objects" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Update the Open Tools definitions and declare the new ones.
To move Oracle Data Integrator scenarios to an existing production system:
Export the new and regenerated scenarios from the test work repository using Oracle Data Integrator Studio. You can export them using single scenario export or multiple scenario export, or you can export all scenarios in a given project or folder. See "Exporting Scenarios" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Import the new or regenerated scenarios in the production work repository using Oracle Data Integrator Studio. Use the Synonym Mode INSERT_UPDATE for this import. See "Importing Scenarios in Production" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Change the schedules in the production work repository to execute the new scenarios in the production context. See "Scheduling Scenarios" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
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 test environment that is not an Oracle RAC environment to a production 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 test environment to the production environment.
Then, you configure your production environment for Oracle RAC, as described in the Oracle Fusion Middleware High Availability Guide, especially "Considerations for High Availability Oracle Database Access."
If you are moving from a test environment that uses Oracle RAC to a production 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 production environment.
If you are moving from a test environment that uses Oracle RAC to a production environment that uses Oracle RAC, but you have more Oracle RAC instances in the production environment, the move plan will have one entry for a multi data source (for example, mds-soa). In addition, it will have multiple entries for generic data sources. For example, if you have three Oracle RAC instances on the test 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 production environment. You update the move plan to point the generic data sources to the first three generic data sources in the production environment.
Then, you can add an additional data source, as described in Section 10.2.1.1.
If you are moving from a test environment that uses Oracle RAC to a production environment that uses Oracle RAC, but you have fewer Oracle RAC instances in the production environment, the move plan will have one entry for a multi data source (for example, mds-soa). In addition, it will have multiple entries for generic data sources. For example, if you have four Oracle RAC instances on the test 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 production environment. You update the move plan to point the first three generic data sources to the three generic data sources in the production environment. You point the last generic data source to the third generic data source.