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 Activity Monitoring to a Production Environment
Moving Oracle User Messaging Service to a Production Environment
This chapter describes how to move the following types of installations from a test environment to a production environment:
Oracle Fusion Middleware Identity Management components including Oracle Internet Directory, Oracle Directory Integration Platform, and Oracle Virtual Directory.
Oracle SOA Suite
Oracle WebCenter
Web Tier components, which are Oracle HTTP Server and Oracle Web Cache
Oracle Fusion Middleware Classic components, including Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle Business Intelligence Discoverer.
The general steps are:
Install and configure the production environment with the components that you need.
Migrate security information, such as users and groups, the identity and policy stores, and credentials.
Migrate other data, such as UMS user messaging preferences, data for Oracle WebCenter applications, Oracle Web Cache configuration files. Modify any information that is specific to the new environment such as host name or ports.
Deploy applications.
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 Access Manager, Release 10.1.4.3, which is used for authentication
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 key stores.
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, set up authentication with corresponding WebGates configured in the Web tier of the protected applications. The Oracle Access Manager configuration policy and configuration data resides in an LDAP directory.
For Oracle Platform Security, created an Oracle WebLogic Server domain and used Oracle Platform Security to create security policies and to store 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 an Oracle WebLogic Server domain and 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 Oracle Internet Directory to a New Production Environment"
Task 3, "Move Oracle Virtual Directory to a New Production Environment"
Task 4, "Move Oracle Directory Integration Platform to a New Production System"
Task 5, "Move Oracle Identity Federation to a New Production Environment"
Task 6, "Move Oracle Access Manager to a New Production Environment"
Task 7, "Move Audit Policies to a New Production Environment"
Task 8, "Move Oracle Platform Security to a New Production Environment"
Task 9, "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 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'
On the test system, run the following command:
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.
See Also:
To migrate a Release 10g Oracle Database, see the Oracle Database documentationTo move Oracle Internet Directory to a new production environment:
Clone the Middleware home containing Oracle Internet Directory. See Section 19.5.1. The Oracle homes in the Middleware home are also cloned.
Clone Oracle Internet Directory. See Section 19.5.2.
If you have configured Oracle Internet Directory replication in the test environment, you must reconfigure it again in the production environment after cloning. Replication configuration is not migrated 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:
Clone the Middleware home containing Oracle Virtual Directory. See Section 19.5.1. The Oracle homes in the Middleware home are also cloned.
Clone Oracle Virtual Directory. See Section 19.5.3.
To move Oracle Directory Integration Platform to a production system:
Install and configure Oracle WebLogic Server, creating a Middleware home, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
Install and configure Oracle Internet Directory, as described in Task 2, "Move Oracle Internet Directory to a New Production Environment".
Install and configure Oracle Directory Integration Platform, specifying the information for the production environment, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
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.
An Oracle Identity Federation setup involves different modules, such as the Credential Store Framework (CSF) for credentials, JPS authorization rules to access CSF, Audit, that are configured, and that you would need to migrate. 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.
For information, see Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
To move Oracle Access Manager to a production system:
Install and configure Oracle WebLogic Server, creating a Middleware home, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
Migrate 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 Administration 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 migrated 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 will 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 audit policies to a new production environment, see the following topics in the Oracle Fusion Middleware Security Guide:
To move Oracle Platform Security to a production environment, you migrate the policy store and credential store:
Migrate the policy store, using the WLST command migrateSecurityStore, as described in "Migrating Policies with the Command migrateSecurityStore" in the Oracle Fusion Middleware 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 Security Guide.
If you are using Oracle Web Services Manager, migrate audit polices, as described in "Migrating Audit Policies" in the Oracle Fusion Middleware Security Guide.
To move Oracle Web Services Manager to a production environment:
Move Oracle Platform Security to the production system, as described in Task 8, "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 polices, as described in "Migrating Audit Policies" in the Oracle Fusion Middleware Security Guide.
Migrate policies stored in the MDS Repository:
From the test environment, execute the following WLST commands:
exportMetadata(application='wsm-pm',server='server_name', docs='/assertiontemplates/**',toLocation='/tmp/owsmexport/') exportMetadata(application='wsm-pm',server='server_name', docs='/policies/**',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:
deleteMetadata(application='wsm-pm',server='server_name', docs='/assertiontemplates/**') deleteMetadata(application='wsm-pm',server='server_name', docs='/policies/**') importMetadata(application='wsm-pm',server='server_name', docs='/assertiontemplates/**',fromLocation='/tmp/owsmexport/') importMetadata(application='wsm-pm',server='server_name', docs='/policies/**',fromLocation='/tmp/owsmexport/')
If you have custom-built policies, migrate 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
If you have policy attachments, the attachments are migrated 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. Migrate policies stored in wsm-seed-policies.jar, 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
Migrate the keystore from the test environment to the production environment.
Because private keys differ between test and production environments, they do not need to be migrated.
Public keys, intermediate certificates, and root certificates can be migrated. Use the Sun Microsystems java keytool export and import commands to migrate 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.
In 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 Platform Security to an Existing Production Environment"
Task 3, "Move Oracle Web Services Manager to an Existing Production Environment"
Task 4, "Move Oracle Access 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. If you want to migrate 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 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
Migrate 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 migrate 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:
"Setting Up a One-Way, Two-Way, or Multimaster LDAP-Based Replication Agreement by Using the Replication Wizard in Fusion Middleware Control"
Migrate Resource Access Descriptors (RAD), if you use Oracle Forms Services or Oracle Reports. This procedure assumes that you have migrated 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 the production Oracle Internet Directory.
Take the following steps:
Retrieve the RADs from the test Oracle Internet Directory instance, by running 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
Migrate the RADs into the production Oracle Internet Directory instance, by running 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 migrate 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.
You must move all of the Oracle Platform Security policy and credential store information from the test environment to an existing production environment:
Migrate the policy store, using the WLST command migrateSecurityStore, as described in "Migrating Policies with the Command migrateSecurityStore" in the Oracle Fusion Middleware 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 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 Security Guide.
If you are using Oracle Web Services Manager, migrate audit polices, as described in "Migrating Audit Policies" in the Oracle Fusion Middleware Security Guide.
To move Oracle Web Services Manager to an existing production environment:
Migrate 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 filename 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 do so 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, migrate 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. Migrate policies stored in wsm-seed-policies.jar, 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 migrate these policies.
Migrate 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.
Migrate any policy attachments for a JAX-WS application if they have changed since the application was first deployed.
In this scenario, you have created a policy domain for the application in the test environment. To migrate that to the 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 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.
The following topics describe how to move Oracle SOA Suite from a test environment to a production environment:
In both scenarios, you have the 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.
Installed and configured Identity Management components, such as Oracle Internet Directory, Oracle Platform Security, and Oracle Web Services Manager.
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.
In this scenario, you have installed Oracle SOA Suite in a test environment as described in Section 20.3 and you want to move it to a production environment, which does not yet exist.
To move this environment to a production environment, perform the following tasks:
Task 1, "Install the Software and Perform the Initial Configuration"
Task 2, "Configure Resource Adapters, Data Sources, and JMS Resources"
Task 3, "Configure Security in the New Production Environment"
Task 4, "Deploy Applications That Support Composite References in the New Production Environment"
Task 5, "Migrate Composite Deployments to the New Production Environment"
Task 6, "Move Human Workflow to the New Production Environment"
See Also:
See the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for information about setting up an enterprise deployment for Oracle SOA SuiteTo install the software and perform the initial configuration on the production system:
Install Oracle WebLogic Server. See "Install Oracle WebLogic Server and Create the Middleware Home" in Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.
Create the required schemas in the production database using RCU. See Oracle Fusion Middleware Repository Creation Utility User's Guide.
Install Oracle SOA Suite. See "Installation Instructions" in Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.
Configure Oracle SOA Suite and create a domain using the Configuration Wizard. See "Configuring Oracle SOA Suite" in Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.
Install and configure Identity Management components, such as Oracle Internet Directory, Oracle Platform Security, and Oracle Web Services Manager.
For information about installing Identity Management components, see Oracle Fusion Middleware Installation Guide for Oracle SOA 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.
To configure resource adapters, data sources, and JMS:
To configure database adapters, see "Deployment" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
To configure AQ adapters, see "Configuring the Data Sources in the Oracle WebLogic Server Administration Console" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
To configure JMS adapters, see "Using the Adapter Configuration Wizard to Configure Oracle JMS Adapter" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
For more information about configuring these resources using the Administration Console, see the following topics in the Oracle WebLogic Server Administration Console Online Help.
Configure Resource Adapters
Configure JDBC Data Sources
Configure JMS System Modules and Add JMS Resources
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:
Set up the jpsroot node in Oracle Internet Directory:
Create an LDIF file with the following contents:
dn: cn=jpsroot_soa_domain,dc=us,dc=oracle,dc=com cn: jpsroot_soa_domain objectclass: top objectclass: orclcontainer
Add the node with the directory, using the following command. (ORACLE_HOME is the Oracle home for Identity Management.)
ORACLE_HOME/bin/ldapadd -h oidhost -p oidport -D cn=orcladmin -w "oid Adminpassword" -vf filename.ldif
If necessary, migrate users and groups to the production environment. For example, if you are using the Human Workflow demo, migrate 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" "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 7.3.3.
Migrate Oracle Web Services Manager policies, which are stored in the MDS Repository:
From the test environment, execute the following WLST commands:
exportMetadata(application='wsm-pm',server='server_name', docs='/assertiontemplates/**',toLocation='/tmp/owsmexport/') exportMetadata(application='wsm-pm',server='server_name', docs='/policies/**',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:
deleteMetadata(application='wsm-pm',server='server_name', docs='/assertiontemplates/**') deleteMetadata(application='wsm-pm',server='server_name', docs='/policies/**') importMetadata(application='wsm-pm',server='server_name', docs='/assertiontemplates/**',fromLocation='/tmp/owsmexport/') importMetadata(application='wsm-pm',server='server_name', docs='/policies/**',fromLocation='/tmp/owsmexport/')
If you have custom-built policies, migrate 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
If you have policy attachments, the attachments are migrated with the application if you use the Oracle WebLogic Server cloning feature.
Import security policies that are related to the Human Workflow application roles from the test environment to the production environment, as described in Task 2, "Move Oracle Platform Security to an Existing Production Environment" in Section 20.2.2.
Import the credential store information from the test environment to the production environment, as described in Task 2, "Move Oracle Platform Security to an Existing Production Environment" in Section 20.2.2.
If your composite application refers to EJBs or Plain Old Java Objects (POJOs), deploy those applications:
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.
As you move projects from one environment to another (for example, from testing to production), you typically must modify several environment-specific values, such as JDBC connection strings and host names of various servers. Configuration plans enable you to modify these values using a single text (XML) file called a configuration plan. The configuration plan is created in either Oracle JDeveloper or with WebLogic Scripting Tool (WLST) commands. During process deployment, the configuration plan is used to search the SOA project for values that must be replaced to adapt the project to the next target environment.
For information about migrating composite deployments and using 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.
To move Human Workflow:
Migrate Human Workflow user metadata, such as views, flex field mappings, or vacation rules, from the test environment to the production environment, using the Human Workflow User Config 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 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, views, flex field mappings, vacation rules) from the test environment. You can create the migration.properties file in any location. Note the following:
You can migrate only non-protected flex field mappings.
You can migrate only "protected" attribute labels.
You can only export one type of data at a time.
When you are migrating data for a particular user or group, you must migrate them in separate operations.
You must export attribute labels before you export flex field mappings.
To export attribute labels, use the following values in the migration properties file:
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING migrateAttributeLabel = true
To export flex field mappings, use the following values in the migration properties file:
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING migrateAttributeLabel = false
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 migrating data for a particular user or group, you must migrate them in separate operations.
You must import attribute labels before you import flex field mappings.
To import attribute labels, use the following values in the migration properties file:
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING migrateAttributeLabel = true
To import flex field mappings, use the following values in the migration properties file:
objectType = TASK_PAYLOAD_FLEX_FIELD_MAPPING migrateAttributeLabel = false
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 9.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.
To move Oracle B2B to a new production environment:
Migrate 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.
Migrate 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 migrate 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.
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 20.3.
To move Oracle SOA Suite to the existing production system:
Migrate any software patches from the test environment to the production environment by cloning the Middleware home, including its Oracle homes, as described in Section 19.5.1.
Follow the steps in Task 2 in Section 20.3.1, modifying existing resource adapters, data sources, and JMS resources, if any changes have been made in the test environment and those changes need to be migrated to the production environment.
If you have added users and groups in the test environment or modified security policies or credentials, follow the steps in Task 3 in Section 20.3.1 to migrate them to the production environment.
If you have modified EJBs or POJOs in the test environment that support the composite references, follow the steps Task 4 in Section 20.3.1 to migrate them to the production environment.
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 Human Workflow in the test environment, follow the steps Task 6 in Section 20.3.1 to migrate them to the production environment.
If you have made any changes to Oracle B2B in the test environment, follow the steps in Task 7 in Section 20.3.1 to migrate them to the production environment.
Note that if you export selective agreements using the tpanames parameter, you must import each zip file individually.
The following topics describe how to move Oracle Business Activity Monitoring from a test environment to a production environment:
Moving Oracle Business Activity Monitoring to a New Production Environment
Moving Oracle Business Activity Monitoring to an Existing Production Environment
In both scenarios, you have performed the following in the 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 and Oracle Business Activity Monitoring.
Configured Oracle SOA Suite and Oracle Business Activity Monitoring using the Configuration Wizard.
Optionally configured Oracle WebLogic Server dependent artifacts, such as:
BAM Adapter
Data sources for the database or JMS
Configured and populated the identity store for Oracle Business Activity Monitoring users.
Configured security policies.
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 email driver is supported, so the reconfiguration steps for UMS only apply to the email 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 Section 20.5 for details on moving UMS from a test to a production system.In this scenario, you have installed Oracle Business Activity Monitoring in a test environment as described in Section 20.4 and you want to move it to a production environment, which does not yet exist.
Perform the following tasks:
Task 1, "Export BAM Data and Artifacts from the Test Environment"
Task 2, "Install the Software and Perform the Initial Configuration"
Task 4, "Migrate BAM Data and Artifacts to the New Production Environment"
On the test environment, take the following steps:
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:
The "Overview of Oracle Data Pump" and other chapters on Oracle Data Pump in the Oracle Database Utilities, which is available at:http://www.oracle.com/technology/documentation/database.html
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
To install the software and perform the initial configuration:
Install Oracle WebLogic Server. See "Install Oracle WebLogic Server and Create the Middleware Home" in Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.
Create the required schemas in the production database using RCU. See Oracle Fusion Middleware Repository Creation Utility User's Guide.
Install Oracle SOA Suite and Oracle Business Activity Monitoring. See "Installation Instructions" in Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.
Configure Oracle SOA Suite and Oracle Business Activity Monitoring and create a domain using the Configuration Wizard. See "Configuring Oracle SOA Suite" in Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.
Set up the LDAP provider for BAM applications on the production environment:
Install and configure Oracle Internet Directory.
For information about installing Oracle Internet Directory, see Oracle Fusion Middleware Installation Guide for Oracle SOA 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.
Set up the Oracle Internet Directory Authenticator:
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.
Migrate BAM data and artifacts to the production environment:
Create the BAM JPS root context by importing the ldiff file. The following shows a sample ldiff file:
dn: cn=jpsroot_bam_test,dc=us,dc=oracle,dc=com cn: jpsroot_bam_test objectclass: top objectclass: orclcontainer
Migrate 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 Oracle Fusion Middleware Security Guide.
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
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.
If you are using BAM sensors, which are automatically deployed as part of a composite, deploy the composite, as described in Task 5, "Migrate Composite Deployments to the New Production Environment" in Section 20.3.1.
Modify the email 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.
Restart the Oracle Business Activity Monitoring Managed Server.
To move Oracle Business Activity Monitoring to an existing production environment, perform the following tasks:
Task 1, "Export BAM Data and Artifacts from the Test Environment"
Task 2, "Migrate BAM Data and Artifacts to the Production Environment "
Export data and artifacts from the test environment:
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
To migrate data and artifacts to 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 Task 3, "Set Up the LDAP Provider" in Section 20.4.2.
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
Migrate 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 Oracle Fusion Middleware 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
If you are using BAM sensors, deploy the composite, as described in Task 5, "Migrate Composite Deployments to the New Production Environment" in Section 20.3.1.
Start the BAM server.
In these scenarios, you have installed Oracle User Messaging Service (UMS) in a test environment and you want to move it to a new production environment. The first example shows how to move the full UMS install from a test to a new production environment; the second example shows how to merge certain UMS (delta) changes from a test to an existing production environment.
In this scenario, you have set up UMS and all required sub-components, have configured UMS drivers and user preferences in a test environment, and want to establish it in a production environment that does not exist.
To migrate UMS details to the 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.
Migrate the User Messaging preferences from the test environment to the production environment:
Go to the test machine.
Run the following WLST commands 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='weblogic', password='password')
wls:/offline> exit()
Note:
In this example,weblogic is a sample Oracle WebLogic Server administrator user name. Replace it with the real value in your environment. 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 machine.
Go to production machine.
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='weblogic', password='password')
Note:
In the above sample'weblogic' is a sample Oracle WebLogic Server administrator user name. Replace it with the real value in your environment. 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 will be reconfigured to use the same set of information.Follow these steps to validate the production environment:
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.
In this scenario, you have an existing production environment into which you want to move UMS. In this case, you are validating your UMS changes as you merge them into your existing production environment.
Any configuration change must be applied to both test and production environments.
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.
Migrate 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 http://host:port/sdpmessaging/userprefs-ui URL in the production environment.
Follow these steps to validate the production environment:
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 the 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 the 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 20.6 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, "Export WebCenter Spaces Applications and Required Data from the Test Environment"
Task 2, "Export Custom WebCenter Framework Applications from the Test Environment"
Task 3, "Install and Configure Oracle WebCenter in the Production Environment"
Task 4, "Import WebCenter Spaces Data and Application to the Production Environment"
Task 5, "Import Custom WebCenter Framework Applications to the Production Environment"
Export WebCenter Spaces applications and data required for the applications from the test environment:
Export the required data for WebCenter Spaces applications, including the LDAP identity store, the Content Server, Discussion Forum, Wiki.
Export the users and groups 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=orcladmin" -w "test_orcladmin_passwd" "cn=Users,dc=us
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
Export the Wiki 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_WIKI directory=directory dumpfile=filename
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.
Migrate Oracle SOA Suite from the test environment to the production environment, as described in Section 20.3.
If you want to move all application producer data:
Export the producers using the WSRP and JPDK migration utilities, as described in "Additional Portlet Configuration" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.
Run the migration tool for WebClipping. For example:
java -classpath ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wce.jar: ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wcptg.jar: ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wcwebdb.jar: ORACLE_HOME/oui/jlib/http_client.jar: ORACLE_HOME/wlserver_10.3/server/ext/jdbc/oracle/11g/ojdbc5.jar oracle.webclipping.util.RepositoryMigrationTool -sourceUsername prefix_PORTLET -sourcePassword password -sourceDatabase{ host:port:sid } -destUsername prefix_PORTLET -destPassword password -destDatabase { host:port:sid }
Note that you should enter the command on one line.
Export the WebCenter Spaces application by using the following WLST commands (ORACLE_HOME refers to the Oracle WebCenter Oracle home):
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 the applications' metadata that is stored in the MDS Repository from the source partition to a directory on the file system, using the WLST exportMetadata command. (ORACLE_HOME refers to the Oracle WebCenter Oracle home.)
exportMetadata(application='app_name', server='server_name', toLocation='directory', docs='/**')
Export Portlet customizations and metadata from the test environment, using the following command:
exportProducerMetadata(appName='app_name',fileName='filename')
Export 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/expdp "sys/password@connect_id as sysdba" schemas=prefix_WEBCENTER 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
Install and configure Oracle WebCenter in the production environment:
Install Oracle WebLogic Server and create the Middleware home. See "Install Oracle WebCenter and Create the Middleware Home" in Oracle Fusion Middleware Installation Guide for Oracle WebCenter.
Create the required schemas in the production database using RCU. See Oracle Fusion Middleware Repository Creation Utility User's Guide.
Because Oracle Universal Content Management requires a Web server, install and configure Oracle HTTP Server, as described in the Oracle Fusion Middleware Installation Guide for Web Tier.
Install Oracle WebCenter, including Oracle Universal Content Management. See "Installing Oracle WebCenter" in Oracle Fusion Middleware Installation Guide for Oracle WebCenter.
Configure Oracle WebCenter and create a domain using the Configuration Wizard. In the Select Domain Source page, select all components. (JRF is automatically selected.) See "Configuring Oracle WebCenter" in Oracle Fusion Middleware Installation Guide for Oracle WebCenter.
Associate WebCenter Spaces with an external identity store. See "Configuring the Identity Store" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
To import the WebCenter Spaces data and application to the production environment:
Import the LDAP identity store, policy, and credential store:
Create authenticators for Identity Management in Oracle WebLogic Server. See "Reassociating the Identity Store with an External LDAP" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
Import the ldif file that you exported from the test environment in Task 1 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
Reassociate the policy and credential store using the following command:
connect('weblogic','weblogic', 'host:port')
reassociateSecurityStore(domain="domain_name",
admin="cn=admin_name",password="password",
ldapurl="ldap://ldap_host:ldap_port",
servertype="OID",jpsroot="cn=root_node")
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 Content Server:
Import the Oracle Content Server data to the production database, using the file you exported in Task 1. 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
Import the Discussion Forum:
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 1. (ORACLE_HOME is the Oracle home for the production database.)
ORACLE_HOME/bin/impdp "sys/password@connect_id as sysdba" FROMUSER=testprefix_DISCUSSIONS TOUSER=prod_prefix_DISCUSSIONS FILE=filename statistics=none
Import the Wiki. (ORACLE_HOME is the Oracle home for the production 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_WIKI:prod_prefix_WIKI DIRECTORY=directory DUMPFILE=filename TABLE_EXISTS_ACTION=REPLACE
If you want to move all application producer data:
Export the producers using the WSRP and JPDK migration utilities, as described in "Additional Portlet Configuration" in the Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.
Run the migration tool for WebClipping. For example:
java -classpath ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wce.jar: ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wcptg.jar: ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wcwebdb.jar: ORACLE_HOME/oui/jlib/http_client.jar: ORACLE_HOME/wlserver_10.3/server/ext/jdbc/oracle/11g/ojdbc5.jar oracle.webclipping.util.RepositoryMigrationTool -sourceUsername test_prefix_PORTLET -sourcePassword password -sourceDatabase{ host:port:sid } -destUsername prod_prefix_PORTLET -destPassword password -destDatabase { host:port:sid }
Note that you should enter the command on one line.
Import the WebCenter Spaces application by using the following WLST commands (ORACLE_HOME refers to the Oracle WebCenter Oracle home):
connect('username','password','t3://hostname:port')
exportWebCenterApplication(appName,fileName,
exportCustomizations=true, exportSecurity=true, exportData=true)
Export the WebCenter Spaces application by using the following WLST commands (ORACLE_HOME refers to the Oracle WebCenter Oracle home):
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.
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 Applications for Data Migration" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter for more information.To import custom WebCenter Framework applications to the production environment:
Import the applications' metadata from the file you exported in Task 2, to the MDS Repository on the production system, using the WLST importMetadata command. (ORACLE_HOME refers to the Oracle WebCenter Oracle home.)
importMetadata(application='app_name', server='server_name', fromLocation='directory', docs='/**')
Import Portlet customizations and metadata from file you exported in Task 2 to the production environment, using the following WLST command:
importProducerMetadata(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
If you have not already done so, import the LDAP identity, policy, and credential stores:
Create authenticators for Identity Management in Oracle WebLogic Server. See "Reassociating the identity store with an External LDAP" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
Import the ldif file that you exported from the test environment in Task 1 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
Reassociate the policy and credential store using the following WLST commands:
connect('weblogic','weblogic', 'host:port')
reassociateSecurityStore(domain="domain_name",
admin="cn=admin_name",password="password",
ldapurl="ldap://ldap_host:ldap_port",
servertype="OID",jpsroot="cn=root_node")
Migrate the credential and policy store:
Copy the following file and name it jps-config-cred.xml:
DOMAIN_HOME/config/fmwconfig/jps-config.xml
In the copy of the file, make a copy of the element <serviceInstance provider="ldap.policystore.provider" name="policystore.ldap"> and change the name to policystore.ldap.s.
Edit the <serviceInstance> element for policystore.ldap.s, change the domain name value, the jpsroot value, and ldap url value to the source value. For example:
<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap.s">
<property value="OID" name="policystore.type"/>
<property value="bootstrap" name="bootstrap.security.principal.key"/>
<property value="cn=test_domain" name="oracle.security.jps.farm.name"/>
<property value="cn=jpsroot_webcenter_test" name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://hostname:port" name="ldap.url"/>
</serviceInstance>
Make a copy of the element <serviceInstance provider="ldap.credentialstore.provider" name="credstore.ldap"> and change the name to credstore.ldap.s.
Edit the <serviceInstance> element for creditstore.ldap.s, change the domain name, jpsroot, and ldap url value to the source value. For example:
serviceInstance provider="ldap.credentialstore.provider" name="credstore.ldap.s">
<property value="bootstrap" name="bootstrap.security.principal.key"/>
<property value="cn=t2ptest_domain" name="oracle.security.jps.farm.name"/>
<property value="cn=jpsroot_webcenter_test" name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://hostname:port" name="ldap.url"/>
</serviceInstance>
Make a copy of the element <jpsContext name="default"> and change the name to source.
Edit the <jpsContext name="default"> element, and remove the reference to idstore.ldap. The following shows the result:
<jpsContext name="default"> <serviceInstanceRef ref="keystore"/> <serviceInstanceRef ref="audit"/> <serviceInstanceRef ref="policystore.ldap"/> <serviceInstanceRef ref="credstore.ldap"/> </jpsContext>
Make a copy of the element <jpsContext name="default"> and change the name to source.
Edit the <jpsContext name="source"> element, change the values for policystore and credstore to point to the source created in steps b to e.
<jpsContext name="source"> <serviceInstanceRef ref="keystore"/> <serviceInstanceRef ref="audit"/> <serviceInstanceRef ref="policystore.ldap.s"/> <serviceInstanceRef ref="credstore.ldap.s"/> </jpsContext>
Find the name of the source folder using the ldapsearch utility:
ORACLE_HOME/bin/ldapsearch -h test_host -p port -D "cn=admin_name" -w "password" -b "" -s sub "cn=application name-*"
The folder name shown in the results is in the form: application name-nnnn. For example, CustomApp-1646.
Find the name of the destination folder using the ldapsearch utility:
ORACLE_HOME/bin/ldapsearch -h prod_host -p port -D "cn=admin_name" -w "password" -b "" -s sub "cn=application name-*"
The folder name shown in the results is in the form: application name-nnnn. For example, CustomApp-1646.
Import the credential store using the following JPS WLST command:
migrateSecurityStore(type="folderCred", configFile="MW_HOME/user_projects/domains/domain_name/config/fmwconfig/jps-config-cred.xml", src="source",dst="default",overWrite="true", srcFolder="source_ folder", dstFolder="destination_folder")
Find the full name of the application using the ldapsearch utility:
ORACLE_HOME/bin/ldapsearch -h test_host -p port -D "cn=admin_name" -w "password" -b "" -s sub "orclapplicationcommonname=application name*"
The application name is returned in the line beginning with cn=. For example:
cn=CustomApp#V2
Import the policy store using the following JPS WLST command:
migrateSecurityStore(type="appPolicies", configFile="MW_HOME/user_projects/domains/domain_name/config/fmwconfig/jps-config-cred.xml", src="source" ,dst="default",overWrite="true", srcApp="full_source_ application name", dstApp="full_dest_application name")
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:
To export Group Spaces data from the test environment:
Export Group 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 Group 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.
Copy the file that you generated when you exported the data from the database in Task 1, to the WC_PUMP_DIR production environment.
Run the script:
ORACLE_HOME/bin/sqlplus "sys/password as sysdba" @owc_wiki_import.sql
Import 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 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.
The following topics describe how to move the Web tier 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. 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 production environment, perform the following tasks:
In the production environment, install the binary files using cloning and create the Oracle instance and one or more Oracle HTTP Server component instances:
Clone the Middleware home containing Oracle HTTP Server. See Section 19.5.1. The Oracle homes in the Middleware home are also cloned.
Create the Oracle instance and the Oracle HTTP Server instance, using either the Oracle Universal Installer or the opmnctl command line:
To create the instances and components 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 Oracle Fusion Middleware Installation Guide for Web Tier.
To create the instances and components using the opmnctl 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 one or more 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 one or more Oracle HTTP Server component instances, using the opmnctl createcomponent. For example:
opmnctl createcomponent -componentType OHS
-oracleInstance /scratch/instances/inst1 -componentName ohs1
Update Oracle HTTP Server:
Make a backup copy of the httpd.conf file in the production environment. Then, copy httpd.conf, which is located in the following directory, as well as any non-default include file, from the test environment to a production environment:
(UNIX) INSTANCE_HOME/config/OHS/ohs_name (Windows) INSTANCE_HOME\config\OHS\ohs_name
In the production environment, edit the httpd.conf file, making the following changes:
Update the Listen directive with the new host name or IP address and port (if the production environment Oracle HTTP Server is using a different port).
Update the VirtualHost directive, if the host name, IP address, or port number is defined, with the new values for the production environment.
Update any other non-default directives that were configured at the test environment and have topological (host name, IP address, port number) or other machine-specific information.
Copy any custom contents, such as contents that have been changed or added to the htdocs directory, to the production environment Oracle HTTP Server.
Optionally, configure SSL:
Make a backup copy of the ssl.conf file in the production environment. Then, copy ssl.conf, which is located in the following directory, from the test environment to the production environment:
ORACLE_INSTANCE/config/OHS/component_name
At the production environment, edit the ssl.conf file, updating the virtual host listen address, if the host name, IP address, or port number is defined, with the new values for the production environment.
If the non-default wallet was used at the test environment:
Export the wallet from the test environment and import it at the production environment. For information about exporting and importing wallets, see Section 7.4.4.
Update the wallet location (if changed) in the ssl.conf file at the production environment.
If you are using mod_wl_ohs:
Make a backup copy of the mod_wl_ohs.conf file in the production environment. Then, copy the mod_wl_ohs.conf file, which is located in the following directory, from the test environment to the production environment:
ORACLE_INSTANCE/config/OHS/ohs_name
In the production environment, edit the mod_wl_ohs.conf file, updating the WebLogicHost, WebLogicPort, or WebLogicCluster directives with the host name, IP address, and port number for the production environment. For example:
WebLogicHost hostname | [IPaddress] WebCluster IPaddress_1:portnum1, IPaddress_2:portnum2, IPaddress_3:portnum3, ...
If SSL is configured for mod_wl_ohs:
Export the wallet from the test environment and import it to the production environment. For information about exporting and importing wallets, see Section 7.4.4.
Update the TrustedCAFile directive for the wallet location (if it is changed) in the mod_wl_ohs.conf file at the production environment.
At the test environment, inspect the httpd.conf file to determine if some or all of the mod_wl_ohs configuration was defined in that file. If so, update the configuration in the production environment httpd.conf file with the host name, IP address, and port number for the production environment.
If you are using mod_osso:
Make a backup copy of the mod_osso.conf file in the production environment. Then, copy the mod_osso file, which is located in the following directory, from the test environment to the production environment:
ORACLE_INSTANCE/config/OHS/component_name/moduleconf
Edit mod_osso.conf to add the following information, using values for your deployment. For example:
LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
<IfModule mod_osso.c>
OssoIdleTimeout off
OssoIpCheck on
OssoConfigFile ORACLE_INSTANCE/config/OHS/ohs_name/osso/osso.conf
#Location is the URI you want to protect
<Location />
require valid-user
#OHS 11g AuthType Osso
#OHS 10g AuthType Basic
AuthType Osso
</Location>
</IfModule>
If you are using mod_PLSQL:
Make a backup copy of the following configuration files in the production environment. Then, copy the files from the test system to the production system.
ORACLE_INSTANCE/config/OHS/ohs_name/conf/moduleconf/plsql.conf ORACLE_INSTANCE/config/OHS/ohs_name/conf/mod_plsql/dads.conf ORACLE_INSTANCE/config/OHS/ohs_name/conf/mod_plsql/cache.conf
Edit the files, replacing the values of any properties that contain information about the test environment with the values for the production environment. Usually, you only need to modify the following properties in the dads.conf file:
PlsqlDatabaseUserName PlsqlDatabasePassword PlsqlDatabaseConnectString PlsqlNLSLanguage
If you are using mod_oradav:
Make a backup copy of the following configuration file in the production environment. Then, copy the following file from the test system to the production system:
ORACLE_INSTANCE/config/OHS/ohs_name/conf/moduleconf/mod_oradav.conf.
Edit the file, replacing the values of any properties that contain information about the test environment with the values for the production environment. Usually, you only need to modify the following parameters in the mod_oradav.conf file:
DAVParam ORACONNECTSN DAVParam ORAUSER DAVParam ORACRYPTPASSWORD
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 it from the test environment to the corresponding production environment:
ORACLE_INSTANCE/config/OHS/ohs_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/component_name
If you are using Oracle Access Manager, this scenario assumes that the same Oracle Access Manager server is used for both test and production system. In addition, when you clone the Middleware home, the binary files for WebGate are installed in the Oracle home.
Run the configureWebGate program located at:
WebGate_install_dir/access/oblix/tools/configureWebGate
Provide details for the production environment, using the same configuration settings as the test environment, except for the following:
Host name
Port
Primary HTTP cookie domain (optional)
Preferred HTTP Host (depends on environment)
Edit the httpd.conf file to update the WebGate information with the values for the production system, modifying the LoadFile, LoadModule, and WebGateInstallDir directives. The following example shows an excerpt of the httpd.conf file, with the items that must be modified in bold.
#*** BEGIN WebGate Specific **** LoadFile "/webgate_path/access/oblix/lib/libgcc_s.so.1" LoadFile "/webgate_path/access/oblix/lib/libstdc++.so.5" LoadModule obWebgateModule "/webgate_path/access/oblix/apps/webgate/bin/webgate.so" WebGateInstalldir "/webgate_path/access"
Restart the processes in the Oracle instance:
opmnctl stopall 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 production environment, perform the following tasks:
In the production environment, install the binary files by using cloning and create the Oracle instances and Oracle Web Cache instances:
Clone the Middleware home containing Oracle Web Cache. See Section 19.5.1. The Oracle homes in the Middleware home are also cloned.
Create the Oracle instances and components. Create the Oracle instances on different hosts, each containing an Oracle Web Cache instance.
To create the instances and components 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 Oracle Fusion Middleware Installation Guide for 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 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 corresponding PASSWORDHASH attribute in this temporary webcache.xml.
Copy the value of 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 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 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 it from the test environment to the corresponding production environment.
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 it 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 7.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, follow the steps in Section 20.7.1.1.
For Oracle Web Cache, follow the steps in Section 20.7.1.2.
In this scenario, you have installed Oracle Fusion Middleware Classic components, including 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.
Created 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 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:
Install and configure Oracle WebLogic Server, creating a Middleware home, as described in Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer.
Alternatively, you can clone the Middleware home, as described in Section 19.5.1.
Install and 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 migrated. 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.
Migrate 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 the production environment:
Stop the processes running in the Oracle instance and the Managed Servers in the production environment, using the following commands:
ORACLE_INSTANCE/bin/opmnctl stopall MW_HOME/user_projects/domains/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.
Migrate the application-related data from the test environment to a database in the production environment using database migration tools.
Create entries in the SQLnet 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. Migrate 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 2, "Move Oracle Internet Directory to a New Production Environment".
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:
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 MW_HOME/user_projects/domains/domain_name/bin/startManagedWebLogic.sh managed_server_name admin_url
If you made customizations to the Forms J2EE application ear file, such as overriding the default Forms servlet access URL, custom deploy the Forms J2EE application ear file and create servlet aliases similar to test environment in the Forms J2EE 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/servers/server_namestage/reports/reports/configuration/cgicmd.dat DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/rwservlet.properties DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/rwserver.conf DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/jdbcpds.conf DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/xmlpds.conf DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/textpds.conf DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/rwnetwork.conf DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/logging.xml DOMAIN_HOME/servers/server_namestage/reports/reports/configuration/logmetadata.xml DOMAIN_HOME/servers/server_namestage/reports/reports/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 |
|---|---|
| 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/* |
| EM Agent configuration |
ORACLE_INSTANCE/EMAGENT/emagent_namesysman/emd/target.xml |
| OPMN configuration |
ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml
|
| 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 |
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.
Migrate the Common UNIX Printing System (CUPS) printing configuration to the production environment, if applicable. Refer to the following for more information:
http://www.cups.org/
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
Migrate 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 migrate the data:
Use the following script:
ORACLE_HOME/reports/admin/sql/rw_job_repos.sql
Migrate 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.
Migrate 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, migrate 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 2, "Move Oracle Internet Directory to a New Production Environment".
If you used JAZN-XML-based identity and policy store in the test environment, migrate 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 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 Security Guide.
Migrate 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 changed the 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/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/configuration.xml DOMAIN_HOME/servers/WLS_DISCO/stage/discoverer/11.1.1.1.0/discoverer/configuration/configuration-preview.xml
In configuration.xml, 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.
If you want 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
Migrate the DISCOVERER schema from the test environment to the production environment. You can use the Oracle Database export and import utilities to migrate the schema.
Note that if you choose to use the same database for test and production, you do not need to migrate the data.
Migrate 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.
Migrate 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.
Migrate 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
Authorized 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.
Migrate 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.
Migrate PStore data:
Delete the default encryption key from the table WWSSO_PS_CONFIGURATION_INFO_T.
Migrate 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 20.8.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:
opmnctl stopall 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 20.8.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:
Migrate the configuration files that are listed in Steps 1 and 5 in Task 6, "Move Oracle Business Intelligence Discoverer to the New Production Environment".
Migrate the DISCOVERER schema from the test environment to the production environment. You can use the Oracle Database export and import utilities to migrate the schema.
Note that if you choose to use the same database for test and production, you do not need to migrate the data.
Migrate 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.