20 Moving from a Test to a Production Environment

20.2.1 Moving Identity Management to a New Production Environment

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 1, "Copy the Database to a New Production Environment"

• 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"

Task 1   Copy the Database 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:

1. 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.

2. 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)
         )
     )
   

3. 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)
       )
     )
   

4. 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
   

5. 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
   

6. 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'
   

7. 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 documentation

Task 2   Move Oracle Internet Directory to a New Production Environment

To move Oracle Internet Directory to a new production environment:

1. Clone the Middleware home containing Oracle Internet Directory. See Section 19.5.1. The Oracle homes in the Middleware home are also cloned.

2. Clone Oracle Internet Directory. See Section 19.5.2.

3. 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.

Task 3   Move Oracle Virtual Directory to a New Production Environment

To move Oracle Virtual Directory to a new production environment:

1. Clone the Middleware home containing Oracle Virtual Directory. See Section 19.5.1. The Oracle homes in the Middleware home are also cloned.

2. Clone Oracle Virtual Directory. See Section 19.5.3.

Task 4   Move Oracle Directory Integration Platform to a New Production System

To move Oracle Directory Integration Platform to a production system:

1. Install and configure Oracle WebLogic Server, creating a Middleware home, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

2. Install and configure Oracle Internet Directory, as described in Task 2, "Move Oracle Internet Directory to a New Production Environment".

3. 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.

4. 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.

Task 5   Move Oracle Identity Federation to a New 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.

Task 6   Move Oracle Access Manager to a New Production Environment

To move Oracle Access Manager to a production system:

1. Install and configure Oracle WebLogic Server, creating a Middleware home, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

2. 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.

3. 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).

4. 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.

5. 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:

   1. Start the server.

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

6. 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.

7. 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.

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

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

   2. Select Host Identifiers. On the List all host identifiers page, select the host identifier that is used by the test system.

   3. 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.

   4. Click Save.

   5. From the Access System Configuration tab, select Access Gate Configuration. Then, select the relevant Access Gate.

   6. In the Details for AccessGate page, click Modify.

   7. Change the Hostname and Port, specifying the host name and port of the production Web server.

   8. Change the Preferred HTTP Host, specifying the host name variation that you added in Step c.

   9. 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.

   10. 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.

9. 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.

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

11. Verify entries and delete entries related to the test environment:

    1. 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.

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

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

    4. 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.

12. 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.

13. 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.

14. 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.

Task 7   Move Audit Policies to a New Production Environment

To move audit policies to a new production environment, see the following topics in the Oracle Fusion Middleware Security Guide:

• "Migrating Audit Policies"

• "Managing Audit Policies"

Task 8   Move Oracle Platform Security to a New Production Environment

To move Oracle Platform Security to a production environment, you migrate the policy store and credential store:

1. 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.

2. 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.

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

Task 9   Move Oracle Web Services Manager to a New Production Environment

To move Oracle Web Services Manager to a production environment:

1. 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.

2. Migrate audit polices, as described in "Migrating Audit Policies" in the Oracle Fusion Middleware Security Guide.

3. Migrate policies stored in the MDS Repository:

   1. 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/')
       
      

   2. Copy the /tmp/owsmexport directory from the test environment to the production environment.

   3. 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/') 
      

   4. 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.

4. 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
   

5. Migrate the keystore from the test environment to the production environment.

   1. Because private keys differ between test and production environments, they do not need to be migrated.

   2. Public keys, intermediate certificates, and root certificates can be migrated. Use the Sun Microsystems java keytool export and import commands to migrate them.

   3. After migration, review the certificates to see if they are applicable in the production environment based on the clients invoking the services.

   4. If the encryption key alias for the production keystore is different than the test environment keystore, then you must update the rcpt-key-alias for all the policies that perform message protection in the policy configuration.

      From Fusion Middleware Control, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies. Select the policy and click Edit. Update the alias.

See Also:

"Managing Horizontal Policy Migration" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services

20.2.2 Moving Identity Management to an Existing Production Environment

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"

Task 1   Move Oracle Internet Directory to an Existing Production Environment

To move Oracle Internet Directory to an existing production environment:

1. 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:

   1. 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.

   2. 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
      

   3. 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.

2. 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:

   • "Understanding Oracle Internet Directory Replication"

   • "Setting Up a One-Way, Two-Way, or Multimaster LDAP-Based Replication Agreement by Using the Replication Wizard in Fusion Middleware Control"

3. 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:

   1. Identify the Default Subscriber as described in Step 1a.

   2. 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
      

   3. 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.

Task 2   Move Oracle Platform Security to an Existing Production Environment

You must move all of the Oracle Platform Security policy and credential store information from the test environment to an existing production environment:

1. 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.

2. 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.

3. 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.

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

Task 3   Move Oracle Web Services Manager to an Existing Production Environment

To move Oracle Web Services Manager to an existing production environment:

1. Migrate policies for SOA Composite applications, WebCenter, or ADF applications, which are stored in the MDS Repository.

   To do so using Fusion Middleware Control:

   1. On the test environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.

   2. Select a policy, then click Export to File.

      The policy is copied to a file on the test environment.

   3. Click Save File, then OK.

   4. Navigate to the location on your local directory to which you want to save the file and update the filename as desired. Click Save.

   5. Copy the file to the production environment.

   6. On the production environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.

   7. Click Import from File. Browse to the file and click OK.

   8. On test environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.

   9. Click Web Services Assertion Templates in the upper right corner of the page.

   10. Click Export to File.

   11. Click Save File, then OK.

   12. Navigate to the location on your local directory to which you want to save the file and update the filename as desired. Click Save.

   13. On the production environment, select the domain. Then, from the WebLogic Domain menu, choose Web Services, then Policies.

   14. Click Import from File. Browse to the file and click OK.

   15. Click Web Services Assertion Templates in the upper right corner of the page.

   16. Click Import from File. Browse to the file and click OK.

   To do so using WLST:

   1. 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/')
       
      

   2. Copy the /tmp/owsmexport directory from the test environment to the production environment.

   3. 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/') 
      

   4. 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
      

      See Also:

      "Managing Horizontal Policy Migration" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services

2. 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.

3. 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.

4. Migrate any policy attachments for a JAX-WS application if they have changed since the application was first deployed.

Task 4   Move Oracle Access Manager to an Existing Production Environment

In this scenario, you have created a policy domain for the application in the test environment. To migrate that to the production environment:

1. 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.

2. 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.

20.3.1 Moving Oracle SOA Suite to a New Production Environment

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"

• Task 7, "Move Oracle B2B to the New Production Environment"

Task 1   Install the Software and Perform the Initial Configuration

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 Suite

To install the software and perform the initial configuration on the production system:

1. Install Oracle WebLogic Server. See "Install Oracle WebLogic Server and Create the Middleware Home" in Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.

2. Create the required schemas in the production database using RCU. See Oracle Fusion Middleware Repository Creation Utility User's Guide.

3. Install Oracle SOA Suite. See "Installation Instructions" in Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.

4. 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.

5. 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.

6. 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.

7. 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.

Task 2   Configure Resource Adapters, Data Sources, and JMS Resources

To configure resource adapters, data sources, and JMS:

1. To configure database adapters, see "Deployment" in the Oracle Fusion Middleware User's Guide for Technology Adapters.

2. 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.

3. 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

Task 3   Configure Security in the New Production Environment

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:

1. Set up the jpsroot node in Oracle Internet Directory:

   1. 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
      

   2. 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
      

2. If necessary, migrate users and groups to the production environment. For example, if you are using the Human Workflow demo, migrate those users:

   1. 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
      

   2. 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
      

3. 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.

4. Migrate Oracle Web Services Manager policies, which are stored in the MDS Repository:

   1. 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/')
       
      

   2. Copy the /tmp/owsmexport directory from the test environment to the production environment.

   3. 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/') 
      

   4. 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.

5. 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.

6. 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.

Task 4   Deploy Applications That Support Composite References in the New Production Environment

If your composite application refers to EJBs or Plain Old Java Objects (POJOs), deploy those applications:

1. To deploy EJB Modules, see "Deploy EJB Modules" in the Oracle WebLogic Server Administration Console Online Help.

2. To deploy Enterprise Applications, see "Working with Enterprise Applications" in the Oracle WebLogic Server Administration Console Online Help.

Task 5   Migrate Composite Deployments to the New Production Environment

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.

Task 6   Move Human Workflow to the New Production Environment

To move Human Workflow:

1. 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:

   1. 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.

   2. 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.

   3. 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
      

   4. Ensure that the application is deployed to the production system.

   5. 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.

   6. 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.

2. Deploy J2EE Human Task Forms, as you would deploy any .ear file. See Section 9.3.1 for more information.

3. 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.

Task 7   Move Oracle B2B to the New Production Environment

To move Oracle B2B to a new production environment:

1. 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.

2. 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.

3. Move the B2B agreements and trading partners to the production environment:

   1. 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"
      

   2. 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.

4. 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.

5. 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.

6. Deploy the B2B agreements, as described in "Deploying an Agreement" in the Oracle Fusion Middleware User's Guide for Oracle B2B.

20.3.2 Moving Oracle SOA Suite to an Existing Production Environment

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

20.4.1 Moving Oracle Business Activity Monitoring to a New Production Environment

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 3, "Set Up the LDAP Provider"

• Task 4, "Migrate BAM Data and Artifacts to the New Production Environment"

Task 1   Export BAM Data and Artifacts from the Test Environment

On the test environment, take the following steps:

1. 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
   

2. 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
   

Task 2   Install the Software and Perform the Initial Configuration

To install the software and perform the initial configuration:

1. Install Oracle WebLogic Server. See "Install Oracle WebLogic Server and Create the Middleware Home" in Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.

2. Create the required schemas in the production database using RCU. See Oracle Fusion Middleware Repository Creation Utility User's Guide.

3. Install Oracle SOA Suite and Oracle Business Activity Monitoring. See "Installation Instructions" in Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.

4. 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.

Task 3   Set Up the LDAP Provider

Set up the LDAP provider for BAM applications on the production environment:

1. 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.

2. Set up the Oracle Internet Directory Authenticator:

   1. From the Oracle WebLogic Server Administration Console, select Security Realms, then myrealm, then Providers.

      A default Authenticator is configured for the realm.

   2. Click New to add a new authenticator.

   3. Enter a name for the provider, such as OIDAuthenticator for a provider that authenticates the user to the Oracle Internet Directory.

   4. For Type, select OracleInternetDirectoryAuthenticator.

   5. Click OK.

   6. On the Providers tab, click the newly created OIDAuthenticator.

   7. 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.

   8. Select the Provider Specific tab.

   9. Enter the details of the LDAP provider.

   10. Click Save.

   11. In the Providers tab, reorder the authenticators so that the newly created authenticator is first.

3. Restart the Administration Server and the Managed Server.

Task 4   Migrate BAM Data and Artifacts to the New Production Environment

Migrate BAM data and artifacts to the production environment:

1. 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
   

2. 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.

3. 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
   

4. 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.

5. 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.

6. 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.

7. Restart the Oracle Business Activity Monitoring Managed Server.

20.4.2 Moving Oracle Business Activity Monitoring to an Existing Production Environment

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 "

Task 1   Export BAM Data and Artifacts from the Test Environment

Export data and artifacts from the test environment:

1. 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.

2. 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
   

Task 2   Migrate BAM Data and Artifacts to the Production Environment

To migrate data and artifacts to the production environment:

1. 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.

2. 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.

3. 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
   

4. 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.

5. 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
   

6. 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.

7. Start the BAM server.

20.5.1 Moving Oracle User Messaging Service to a New 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.

Task 1   Migrate UMS-Related Details to the Production Environment

To migrate UMS details to the production environment:

1. 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, execute help('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.

2. Migrate the User Messaging preferences from the test environment to the production environment:

   1. Go to the test machine.

   2. 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.

   3. Copy the /tmp/userprefs-dump.xml file to the production machine.

   4. Go to production machine.

   5. 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.

   6. Observe the message displayed for successful upload. Exit the WLST command line tool.

      Note:

      To see different options for performing download and upload operations, execute help('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.

Task 2   Validate the Production Environment

Follow these steps to validate the production environment:

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

2. 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.

20.5.2 Moving Oracle User Messaging Service to an Existing Production Environment

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.

Task 1   Migrate UMS-related Details to the Production Environment

Any configuration change must be applied to both test and production environments.

1. 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, execute help('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.

2. 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.

Task 2   Validate the Production Environment

Follow these steps to validate the production environment:

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

2. 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.

20.6.1 Moving Oracle WebCenter to a New Production Environment

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"

Task 1   Export WebCenter Spaces Applications and Required Data from the Test Environment

Export WebCenter Spaces applications and data required for the applications from the test environment:

1. Export the required data for WebCenter Spaces applications, including the LDAP identity store, the Content Server, Discussion Forum, Wiki.

   1. 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
      

   2. 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
      

   3. 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
      

   4. 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.

2. Migrate Oracle SOA Suite from the test environment to the production environment, as described in Section 20.3.

3. If you want to move all application producer data:

   1. 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.

   2. 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.

4. 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.

Task 2   Export Custom WebCenter Framework Applications from the Test Environment

To export custom WebCenter Framework applications from the test environment:

1. 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='/**')
   

2. Export Portlet customizations and metadata from the test environment, using the following command:

   exportProducerMetadata(appName='app_name',fileName='filename')
   

3. 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

Task 3   Install and Configure Oracle WebCenter in the Production Environment

Install and configure Oracle WebCenter in the production environment:

1. 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.

2. Create the required schemas in the production database using RCU. See Oracle Fusion Middleware Repository Creation Utility User's Guide.

3. 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.

4. Install Oracle WebCenter, including Oracle Universal Content Management. See "Installing Oracle WebCenter" in Oracle Fusion Middleware Installation Guide for Oracle WebCenter.

5. 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.

6. Associate WebCenter Spaces with an external identity store. See "Configuring the Identity Store" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

Task 4   Import WebCenter Spaces Data and Application to the Production Environment

To import the WebCenter Spaces data and application to the production environment:

1. Import the LDAP identity store, policy, and credential store:

   1. 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.

   2. 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
      

   3. 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.

2. Import Content Server:

   1. 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
      

   2. 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
      

3. Import the Discussion Forum:

   1. 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"
      

   2. Drop the target user:

      drop user prefix_DISCUSSIONS cascade;
      

   3. Create the target user:

      create user prefix_DISCUSSIONS identified by password 
       default tablespace prefix_IAS_DISCUSSIONS 
       temporary tablespace prefix_IAS_TEMP;
      

   4. Grant connect and resource privileges to the user and exit from SQLPlus:

      grant connect,resource to prefix_DISCUSSIONS;
      exit;
      

   5. 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
      

4. 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
   

5. If you want to move all application producer data:

   1. 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.

   2. 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.

6. 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)
   

7. 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.

Task 5   Import Custom WebCenter Framework Applications to the Production Environment

To import custom WebCenter Framework applications to the production environment:

1. 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='/**')
   

2. 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')
   

3. 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
   

4. If you have not already done so, import the LDAP identity, policy, and credential stores:

   1. 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.

   2. 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
      

   3. 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")
      

5. Migrate the credential and policy store:

   1. Copy the following file and name it jps-config-cred.xml:

      DOMAIN_HOME/config/fmwconfig/jps-config.xml
      

   2. 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.

   3. 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>
      

   4. Make a copy of the element <serviceInstance provider="ldap.credentialstore.provider" name="credstore.ldap"> and change the name to credstore.ldap.s.

   5. 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>
      

   6. Make a copy of the element <jpsContext name="default"> and change the name to source.

   7. 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>
      

   8. Make a copy of the element <jpsContext name="default"> and change the name to source.

   9. 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>
      

   10. 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.

   11. 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.

   12. 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")
       

   13. 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
       

   14. 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")
       

20.6.2 Moving Oracle WebCenter to an Existing Production Environment

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:

Task 1   Export Group Spaces Data from the Test Environment

To export Group Spaces data from the test environment:

1. 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\"
   

2. 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
   

3. Export the Group Space from the test environment:

   1. Login to WebCenter Spaces with administrative privileges.

   2. Click the Administration link at the top of the application.

   3. Click the Group Spaces tab.

   4. Click the Group Spaces subtab.

   5. Select the group space required by highlighting the row in the table.

   6. From the Change State drop down, select Offline.

   7. Click Save.

   8. Click Export in the toolbar.

Task 2   Import Group Spaces Data to the Production Environment

To import Group Spaces data to the production environment:

1. 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
   

2. 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');
   

3. Create the directory WC_PUMP_DIR.

4. Copy the file that you generated when you exported the data from the database in Task 1, to the WC_PUMP_DIR production environment.

5. Run the script:

   ORACLE_HOME/bin/sqlplus "sys/password as sysdba"
   @owc_wiki_import.sql
   

6. Import the Group Space from the test environment:

   1. Login to WebCenter Spaces with administrative privileges.

   2. Click the Administration link at the top of the application.

   3. Click the Group Spaces tab.

   4. Click the Group Spaces subtab.

   5. Select the group space required by highlighting the row in the table.

   6. From the Change State drop down, select Offline.

   7. Click Save.

   8. Click Import in the toolbar and select the exported archive.

7. 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.

Task 3   Export WebCenter Group Space Template from the Test Environment

To export the Group Space template from the test environment:

1. Login to WebCenter Spaces with administrative privileges.

2. Click the Administration link at the top of the application.

3. Click the Group Spaces tab.

4. From the Group Spaces tab, select Templates.

5. Click Export in the toolbar.

Task 4   Import WebCenter Group Space Template from the Test Environment

To import the Group Space template to the production environment:

1. Login to WebCenter Spaces with administrative privileges.

2. Click the Administration link at the top of the application.

3. Click the Group Spaces tab.

4. From the Group Spaces tab, select Templates.

5. Click Import in the toolbar, and select the exported archive.

20.7.1 Moving the Web Tier to a New Production Environment

The following topics describe how to move the Web tier to a new production environment:

• Moving Oracle HTTP Server to a New Production Environment

• Moving Oracle Web Cache to a New Production Environment

20.7.2 Moving the Web Tier to an Existing Production Environment

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.

20.8.1 Moving Classic Components to a New Production 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 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 2, "Install and Configure the Components"

• Task 3, "Move Oracle Portal to the New Production Environment"

• Task 4, "Move Oracle Forms Services to the New Production Environment"

• Task 5, "Move Oracle Reports to the New Production System"

• Task 6, "Move Oracle Business Intelligence Discoverer to the New Production Environment"

Task 1   Copy the Database 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.

Task 2   Install and Configure the Components

To install and configure the components:

1. 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.

2. 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.

Task 3   Move Oracle Portal to the New Production Environment

To move Oracle Portal configuration to a new production environment:

1. 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.

2. Export the data from the test environment, as described in "Exporting Data" in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.

3. 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.

4. 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.

5. 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.

6. Import the data, as described in "Import in Oracle Portal" in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.

7. 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.

8. Import the external applications list using the SSOMig utility:

   1. 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
      

   2. 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
      

9. 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
   

10. 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.

Task 4   Move Oracle Forms Services to the New Production Environment

To move Oracle Forms Services to the production environment:

1. 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 
   

2. 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.

3. Migrate the application-related data from the test environment to a database in the production environment using database migration tools.

4. Create entries in the SQLnet configuration files to refer to the database in the production environment.

5. 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".

6. 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
   

7. 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.

8. 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 
   

9. 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.

Task 5   Move Oracle Reports to the New Production System

To move Oracle Reports to the production environment:

1. 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

   
   

2. 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

   
   

3. If you created additional Oracle Reports Server component instances in the test environment, create these in the production environment using opmnctl.

4. 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.

5. 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.

6. 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.

7. 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:

   1. Use the following script:

      ORACLE_HOME/reports/admin/sql/rw_job_repos.sql 
      

   2. 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.

8. 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.

9. 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".

10. 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.

11. 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.

12. Migrate any database proxy users to the production database using database cloning tools.

13. 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.

Task 6   Move Oracle Business Intelligence Discoverer to the New Production Environment

To move Oracle BI Discoverer to the new production environment:

1. 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
   

2. 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

3. 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
   

4. 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

5. 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 
   

6. 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.

7. 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
   

8. 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.

9. Migrate the EUL data from the test environment to the production environment:

   1. 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.

   2. 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.

   3. 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.

10. Migrate the catalog data from the test environment to the production environment:

    1. 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
       

    2. 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
       

    3. 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.

11. Migrate Portlet data from the test Discoverer metadata repository to the production Discoverer metadata repository:

    1. 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.

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

12. Migrate PStore data:

    1. Delete the default encryption key from the table WWSSO_PS_CONFIGURATION_INFO_T.

    2. 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.

20.8.2 Moving Classic Components to an Existing Production 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"

Task 1   Move Oracle Portal 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.

Task 2   Move Oracle Forms Services to an Existing Production Environment

To move Oracle Forms Services to the existing production environment:

1. 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.

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

3. Restart the components:

   opmnctl stopall
   opmnctl startall
   

Task 3   Move Oracle Reports to an Existing Production Environment

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.

Task 4   Move Oracle Business Intelligence Discoverer to an Existing Production Environment

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:

1. 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".

2. 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.

3. 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.