20 Moving from a Test to a Production Environment

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

This chapter includes the following topics:

20.1 Overview of Procedures for Moving from a Test to a Production Environment

This chapter describes how to move installations from a test environment to a production environment:

The general steps are:

  1. Install and configure the production environment with the components that you need.

  2. Move security information, such as users and groups, the identity and policy stores, and credentials.

  3. Move other data, such as UMS user messaging preferences, data for Oracle WebCenter applications, or Oracle Web Cache configuration files. Modify any information that is specific to the new environment such as host name or ports.

  4. Deploy applications.

20.2 Moving Identity Management Components to a Production Environment

The following topics describe how to move Identity Management from a test environment to a production environment:

In both scenarios, you have performed the following in the test environment:

  • Installed a database to be used for Identity Management components such as Oracle Internet Directory, Oracle Directory Integration Platform (which depends on Oracle Internet Directory,) and Oracle Identity Federation

  • Created needed schemas using RCU

  • Installed and configured Identity Management, including the following components:

    • Oracle Internet Directory

    • Oracle Virtual Directory

    • Oracle Directory Integration Platform

    • Oracle Identity Federation

    • Oracle Directory Services Manager

    • Oracle Platform Security

    • Oracle Web Services Manager

    • SSL

    • Oracle Identity Manager

    • Oracle Identity Management Navigation

    • Oracle Adaptive Access Manager

    • Oracle Access Manager 11g or Oracle Access Manager 10g

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

  • For Oracle Virtual Directory, created adapters to various data sources, such as LDAP and databases, and you may have configured a Local Store Adapter (LSA) to create local LDAP data, which resides in the local file system. In addition, you may have made other configuration changes such as adding ACLs, changing schemas, the Listener configuration, server configuration, plug-ins, mappings, auditing, logging, and keystores.

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

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

  • For Oracle Access Manager 11g, set up authentication with corresponding WebGates configured in the Web tier of the protected applications. The Oracle Access Manager configuration data resides in a file and the policy and configuration data resides in a database, as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

  • For Oracle Platform Security, creates security policies and stored credentials in the Credential Store Framework (CSF). Oracle Platform Security is useful for applications such as ADF, WebCenter, and SOA Composite applications.

  • For Oracle Web Services Manager, created Oracle Web Services Manager policies. These policies are also attached to Web services and clients.

  • For SSL, configured self-signed certificates. (In a production environment, you use trusted CA-signed certificates.)

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

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. To move the database from the test system to the production system, use RMAN.

    The following shows an example of using RMAN to duplicate the database.

    RMAN
    DUPLICATE TARGET DATABASE
      TO prodDB
      FROM ACTIVE DATABASE
      SPFILE
      NOFILENAMECHECK;
    

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

    For detailed steps, see the Oracle Database Backup and Recovery User's Guide, which is available at:

    http://www.oracle.com/technology/documentation/database.html
    

See Also:

The Oracle10g Database documentation to move a Release 10g Oracle Database,
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. The replication configuration is not moved from the test to the production environment. See "Setting Up Replication" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

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 new 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 and Audit, that are configured, and that you would need to move. Because of that, Oracle recommends that you install a new Oracle Identity Federation server, then configure the new instance, as opposed to be moving settings from the test environment to the production environment.

For information, see Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

Task 6   Move Oracle Identity Manager to a New Production Environment

You can use the Oracle Identity Manager Deployment Manager to move most metadata from a test environment to a production environment. The following table lists the entities that you can move using Deployment Manager:

Entities Deployment Manager Category
Roles Role
Organizations Organization
Access Policies Access Policy
Attestation Processes Attestation Process
Authorization Policies Authorization Policy
User Metadata User Metadata
Roles and Org Metadata Roles and Org Metadata
Scheduled Tasks Scheduled Task
Scheduled Jobs Job
IT Resources IT Resource
Resource Objects Resource
Lookup Definitions Lookup
Process Forms Process Form
Provisioning Workflows and Adapters Process
Resource Forms Resource Form
Data Object Definitions Data Object Definition
Rules Rule
Notification Templates Notification Template
GTC Providers GTC Provider
Error Codes Error Code
System Properties System Property
EmailDef Email Definition
EventHandler Event Handlers
PasswordPolicy Password Policy
GenericConnector Generic Connector
ITResourceDef IT Resource Definition
Request Templates Request Template
Request Datasets Request Dataset
Approval Policies Approval Policy

To move Oracle Identity Manager to a new production environment:

  1. On the test environment, use the Deployment Manager to export the metadata for the entities listed in the preceding table. In the wizard, select the entities' children and dependencies. See "Exporting Deployments" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager for information about how to export metadata.

    The data is exported as .xml files.

  2. On the production environment, use the Deployment Manager to import the metadata for the entities listed in the preceding table. See "Importing Deployments" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager for information about how to import metadata.

    The Deployment Manager does not manage resource bundles, jars and plug-ins, and Custom Reconciliation Profiles.

  3. Move the Approval Workflows, which are SOA composite applications, using JDeveloper:

    1. Copy all of the files in the JDeveloper project from the test environment to the production environment, using any standard file transfer method.

    2. In the application, change any calls to external systems to point to the systems in the production environment. For example, if the workflow uses an LDAP server in the test environment, change references to point to an LDAP server in the production environment.

    3. Use JDeveloper to build the sca jar file from the SOA composite.

    4. Deploy the SOA composite application on the production environment, using the SOA Deployment wizard in Fusion Middleware Control (see Section 9.5.1) or JDeveloper.

  4. In the test environment, export localization resource bundles, as well as the following sets of plug-in code from the test environment:

    • Scheduled Task jars

    • Adapter Java tasks

    • Third-party jars

    • Other plug-in code jars

    Take the following steps:

    1. Edit the following script, which exports the entities into a zip file:

      (UNIX) OIM_ORACLE_HOME/server/bin/exportMetadata.sh
      (Windows) OIM_ORACLE_HOME\server\bin\exportMetadata.bat
      

      Edit the script to specify the following values:

      • CONTEXT: The URL of the application. For example, weblogic.jndi.WLInitialContextFactory.

      • EXPORT_LOCATION: The full path to the directory where the zip file is to be created.

      • TEMP_LOCATION_TO_EXTRACT: The full path to a directory where the files will be stored temporarily before they are packaged into a zip file.

      • CONTROL_FILE: An XML file that controls what needs to be exported. You create the file, as described in Step b.

    2. Create a control file to specify the types of entities to be exported. The following example shows a sample control file that specifies that all custom resource bundles, jar files, and plug-ins be exported:

      <?xml version='1.0' encoding='UTF-8'?>
      <MigrationDetails Operation ="Export">
        <entityDetails>
          <EntityType>CustomResourceBundles</EntityType>
          <FilteringCriteria>
            <Attribute>
        <Name>Resource_Type</Name>
           <Filter>*</Filter>
            </Attribute>
          </FilteringCriteria>
        </entityDetails>
        <entityDetails>
          <EntityType>Jars</EntityType>
          <FilteringCriteria>
            <Attribute>
              <Name>Jar_Type</Name><Filter>*</Filter>
            </Attribute>
          </FilteringCriteria>
        </entityDetails>
      <entityDetails>
          <EntityType>Plugins</EntityType>
          <FilteringCriteria>
            <Attribute>
              <Name>Type</Name><Filter>*</Filter>
            </Attribute>
          </FilteringCriteria>
        </entityDetails>
       
      </MigrationDetails>
      
    3. Execute the script, specifying the user name, password, and JNDI URL when prompted. (The JNDI URL is the URL to connect to the application. For example, t3://hostname:port).

      The script creates a zip file named exportPackage_timestamp.zip, which is created in the directory exportPackage_timestamp.

  5. In the production environment, import localization resource bundles, as well as the sets of plug-in code from the test environment.

    To import these entities, you use the following script, which exports the entities into a zip file:

    (UNIX) OIM_ORACLE_HOME/server/bin/importMetadata.sh
    (Windows) OIM_ORACLE_HOME/\erver\bin\importMetadata.bat
    

    Take the following steps:

    1. Edit the following script, which imports the entities from the zip file created by the export operation:

      (UNIX) OIM_ORACLE_HOME/server/bin/importMetadata.sh
      (Windows) OIM_ORACLE_HOME/\erver\bin\importMetadata.bat
      

      Edit the script to specify the following values:

      • CONTEXT: The URL of the application. For example, weblogic.jndi.WLInitialContextFactory.

      • IMPORT_LOCATION: The full path to the directory where the zip file created by the export operation is located.

      • TEMP_LOCATION_TO_EXTRACT: The full path to a directory where the files in the zip file will be extracted before they are imported.

    2. Execute the script, specifying the user name, password, and JNDI URL when prompted. (The JNDI URL is the URL to connect to the application. For example, t3://hostname:port).

      The script imports the data into the production environment.

  6. Move any custom reconciliation profiles, as described in "Updating Reconciliation Profiles Manually" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager.

    1. Use the WLST command exportMetadata to export the custom reconciliation profiles from the test environment:

      connect('username','password',JNDI-URL')
      exportMetadata(application='OIM', server='server_name',
        toLocation='directory', docs='path_to_reconciliation_profiles'
      
    2. Copy the exported files to the production environment.

    3. Use the WLST command importMetadata to import the custom reconciliation profiles to the production environment:

      connect('username','password',JNDI-URL')
      importMetadata(application='OIM', server='server_name',
        fromLocation='directory', docs='/**'
      
  7. For connectors, if there are any changes to the forms that need the older versions of these forms to be upgraded with the new definition on the production environment, move the connectors, then run the Form Version Control (FVC) utility. For more information, see the section "Upgrading the Connector" of the Connector Patch Readme file. The Readme file is located in the top-level directory of the connector distribution media.

Task 7   Move Oracle Identity Navigator to a New Production Environment

To move Oracle Identity Navigator to a new production environment:

  1. In the test environment, use the WLST command exportMetadata to export the Oracle Identity Navigator metadata from the test environment:

    connect('username','password',JNDI-URL')
    exportMetadata(application='oinav', server='server_name',
      toLocation='directory'
    

    The format of the JNDI URL is: t3://admin_server_host:admin_server_port.

  2. In the production environment, use the WLST command importMetadata to import the Oracle Identity Navigator metadata to the production environment:

    connect('username','password',JNDI-URL')
    importMetadata(application='oinav', server='server_name',
      fromLocation='directory'
    
  3. Restart Administration Server and the Managed Servers.

Task 8   Move Oracle Access Manager 11g to a New Production Environment

Note:

The Administration Servers in both the test environment and the production environment must be started.

To replicate the policy configuration information from the test system into the production system:

  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 Access Manager, specifying the information for the production environment, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

  3. Set the environment variable JAVA_HOME and add JAVA_HOME to the PATH.

  4. Export the policies from the test system, using the following WLST command:

    exportPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
    
  5. Copy the policy file to the production environment.

  6. Import the policies into the production environment, using the following command:

    importPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
    

To replicate the configuration and the partner information from the test system to the production system, take the following steps:

  1. Follow steps 1 through 6 in the preceding procedure.

  2. Export the partner information from the test environment, using the following WLST command:

    exportPartners(pathTempOAMPartnerFile='path_of_Temp_PartnerFile')
    
  3. Copy the partner file to the production environment.

  4. Import the partner information to the production environment, using the following WLST command:

    importPartners(pathTempOAMPartnerFile='path_of_Temp_PartnerFile')
    
Task 9   Move Oracle Access Manager 10g to a New Production Environment

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

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

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

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

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

  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 moved the Directory Server. Do not configure the authentication scheme because it already exists in the Directory Server.

    Note:

    After setting up the production Policy Manager, when you log in as the Oracle Access Manager Administrator, you may get the following error:
    There was a problem obtaining the user ID. One possible reason for this is a time difference between the Identity System and Access Systems (Policy Manager and Access System Console).
    

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

  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 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 10   Move Oracle Adaptive Access Manager to a New Production Environment

To move Oracle Adaptive Access Manager to a new production environment:

  1. Install Oracle Adaptive Access Manager on the production environment, using the same installation and post-installation configuration steps that you used in the test environment.

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

    You can export the following types of items:

    • Policies

    • Rule conditions

    • Patterns

    • Configurable actions

    • Transaction definitions

    • Entities

    • KBA questions

    • KBA validations

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

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

  4. Manually update the production system for the following items, when necessary:

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

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

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

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

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

    4. Manually re-create the KBA logic, OTP logic, and policy set overrides using the Oracle Adaptive Access Manager Admin Console. See the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

    5. Copy the following from the test environment to the production environment: properties files, resource bundles, and end user JSP screens. These items are located in the oaam_extensions shared library.

    6. Copy the VAD images, which are in a custom jar, from the test environment to the production environment.

  5. Validate that the move was successful:

    1. Login to OAAM Admin console, as described in "OAAM Admin Console and Controls" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

    2. Navigate to Policies and check that the rules and groups from the test environment exist in the production environment.

    3. Navigate to the KBA module and check that the challenge questions in the test environment exist in the production environment.

    4. Test the Web applications that have been configured for Oracle Adaptive Access Manager. The user should be redirected to registration and challenge flow.

Task 11   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:

Task 12   Move Oracle Platform Security to a New Production Environment

To move Oracle Platform Security to a new 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 policies, as described in "Migrating Audit Policies" in the Oracle Fusion Middleware Security Guide.

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

To move Oracle Web Services Manager to a new production environment:

  1. Move Oracle Platform Security to the production system, as described in Task 12, "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 policies, as described in "Migrating Audit Policies" in the Oracle Fusion Middleware Security Guide.

  3. Move 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, move those by copying the jar files from the test to the production environment. The jar files are located in the following directory:

      DOMAIN_HOME/lib
      
    5. For ADF BC and Oracle WebCenter policy attachments, migrate them, as described in "Managing Application Migration Between Environments" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

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

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

    ORACLE_HOME/modules/oracle.wsm.policies_11.1.1/wsm-seed-policies.jar
    
  5. Move the keystore from the test environment to the production environment.

    1. Because private keys differ between test and production environments, you do not need to move them.

    2. Public keys, intermediate certificates, and root certificates can be moved. Use the Sun Microsystems java keytool export and import commands to move 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.

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

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. To move 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. Move the users into the production Oracle Internet Directory instance by running the following command from the production Oracle home:

      ORACLE_HOME/bin/ldapaddmt -h production_oid_host
        -p production_oid_port -D "cn=orcladmin"
        -w "production_orcladmin_passwd" -r -f ldif_filename
      

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

  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:

  3. Move Resource Access Descriptors (RAD), if you use Oracle Forms Services or Oracle Reports. This procedure assumes that you have moved the Default Subscriber from the test environment to the production environment, as described in Step 1. It also assumes that the orclGUIDs of the users at the test Oracle Internet Directory are identical to 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. Move 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 move data and resolve conflicts. The ldif_filename is the file you obtained in the previous step.

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

Task 2   Move Oracle Access Manager 11g to an Existing Production Environment

In this scenario, you move incremental changes that you have made in the test environment to the production environment.

Note:

The Administration Servers in both the test environment and the production environment must be started.

To replicate the policy configuration information from the test system into the production system:

  1. Set the environment variable JAVA_HOME and add JAVA_HOME to the PATH.

  2. Export the policies from the test system, using the following WLST command:

    exportPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
    
  3. Copy the policy file to the production environment.

  4. Import the policies into the production environment, using the following command:

    importPolicy(pathTempOAMPolicyFile='path_of_Temp_PolicyFile')
    
Task 3   Move Oracle Access Manager 10g to an Existing Production Environment

To move Oracle Access Manager 10g to an existing 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 values for the production environment:

    web_domain (The Host identifier is derived from this entry)
    protected_uris="uri1,uri2,uri3"
    app_agent_password=password to be provisioned for the WebGate
    ldap_host=hostname of LDAP server
    ldap_port=port of LDAP server
    ldap_userdn=DN of LDAP Admin User
    ldap_userpassword=password of LDAP Admin User
    oam_aaa_host=host of OAM server
    oam_aaa_port=port of OAM server
    

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

  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.

Task 4   Move Oracle Adaptive Access Manager to an Existing Production Environment

To move Oracle Adaptive Access Manager to an existing production environment:

  1. Export the necessary delta data from the test system to one or more zip files. You can export the following types of items: Policies, rule conditions, patterns, configurable actions, transactions, entities, KBA questions, KBA validations, all group types including alert and action groups, and black list and white list groups used in rules. See Step 2 in Task 10, "Move Oracle Adaptive Access Manager to a New Production Environment" in Section 20.2.1.

  2. Import the zip files created in Step 1 in the production system. See Step 3 in Task 10, "Move Oracle Adaptive Access Manager to a New Production Environment" in Section 20.2.1.

  3. Manually update the production system for the following items, when necessary:

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

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

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

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

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

    4. Manually re-create the KBA logic, OTP logic, and policy set overrides using the Oracle Adaptive Access Manager Admin Console. See the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

    5. Copy the following from the test environment to the production environment: properties files, resource bundles, and end user JSP screens. These items are located in the oaam_extensions shared library.

    6. Copy the VAD images, which are in a custom jar, from the test environment to the production environment.

    7. Copy the following from the test environment to the production environment: properties files, resource bundles, VAD images, and end user JSP screens.

  4. Validate that the move was successful:

    1. Login to OAAM Admin console, as described in "OAAM Admin Console and Controls" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

    2. Navigate to Policies and check the existing group linking and check that newly added rules and groups from the test environment exist in the production environment.

    3. Navigate to the KBA module and check that newly added challenge questions in the test environment exist in the production environment.

    4. Test the Web applications that have been configured for Oracle Adaptive Access Manager. The user should be redirected to registration and challenge flow. The behavior should be the same as in the test environment.

Task 5   Move Oracle Identity Manager to an Existing Production Environment

To move Oracle Identity Manager to an existing production environment, follow the steps described in Section 20.2.1, Task 6, "Move Oracle Identity Manager to a New Production Environment".

Task 6   Move Oracle Identity Navigator to an Existing Production Environment

To move Oracle Identity Navigator to an existing production environment, follow the steps in Section 20.2.1, Task 7, "Move Oracle Identity Navigator to a New Production Environment".

Task 7   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 policies, as described in "Migrating Audit Policies" in the Oracle Fusion Middleware Security Guide.

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

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

  1. Move 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 move policies 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, move those by copying the jar files from the test to the production environment. The jar files are located in the following directory:

      DOMAIN_HOME/lib
      
  2. Oracle WebLogic Server JAX-WS applications use policies stored in wsm-seed-policies.jar instead of in MDS. Move these policies by copying the following file from the test environment to the production environment:

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

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

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

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

20.3 Moving Oracle SOA Suite to a Production Environment

The following topics describe how to move Oracle SOA Suite from a test environment to a production environment:

In both scenarios, you have the performed the following in a test environment:

  • Installed Oracle WebLogic Server and created the Middleware home.

  • Created the required schemas in the test database using RCU.

  • Installed Oracle SOA Suite.

  • Configured Oracle SOA Suite using the Configuration Wizard.

  • Installed and configured Identity Management components, such as Oracle Internet Directory, Oracle Platform Security, and Oracle Web Services Manager.

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

  • Changed some configuration settings. For example, you may have changed something in the config directory, in MDS, or another data source.

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 new production environment, perform the following tasks:

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. Create the required schemas in the production database using RCU. See Oracle Fusion Middleware Repository Creation Utility User's Guide.

  2. Clone the Middleware home, as described in Section 19.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also cloned.

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

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

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

  6. 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, move users and groups to the production environment. For example, if you are using the Human Workflow demo, move 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" -b "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. Move 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, move those by copying the jar files from the test to the production environment. The jar files are located in the following directory:

      DOMAIN_HOME/lib
      

    If you have policy attachments, the attachments are moved 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 7, "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 7, "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   Move 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 to a new production environment:

  1. Move Human Workflow user metadata, such as views, flex field mappings, or vacation rules, from the test environment to the production environment, using the Data Migrator. The Data Migrator is available as an ant target that can be executed in the command line. It calls a properties file, migration.properties, that you create specifying the input parameters for the migration of data.

    The migration.properties file contains the following input parameters:

    operationType = {EXPORT | IMPORT}
    objectType = {VIEW | RULE | APPROVAL_GROUP | TASK_PAYLOAD_FLEX_FIELD_MAPPING}
    name = name of VIEW or APPROVAL_GROUP or TASK_PAYLOAD_FLEX_FIELD_MAPPING
    user = username of VIEW or RULE
    group = groupname for RULE
    grantPermission = {true | false}
    migrateAttributeLabel = {true | false}
    override = {true | false} 
    skip = {true | false}
    migrateToActiveVersion = {true | false}
    

    You use the following script:

    ORACLE_HOME/bin/ant-t2p-worklist.xml
    

    The command has the following format:

    ant -f ant-t2p-worklist.xml
         -Dbea.home=BEA_HOME
         -Dsoa.home=SOA_HOME
         -Dmigration.properties.file=MIGRATION_PROPERTY_FILE_PATH
         -Dsoa.hostname=SOA_HOSTNAME
         -Dsoa.rmi.port=SOA_RMI_PORT
         -Dsoa.admin.user=SOA_ADMIN_USER
         -Dsoa.admin.password=SOA_ADMIN_PASSWORD
         -Drealm=REALM
         -Dmigration.file=MIGRATION_FILE
         -Dmap.file=MAP_FILE
    

    For additional information about the migration utility, see "Using the User Metadata Migration Utility" in the Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.

    Take the following steps:

    1. Ensure that the PATH environment variable contains the required JAVA_HOME and ANT_HOME environment variables and that they point to the locations within the Oracle SOA Suite installation.

    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 export only non-protected flex field mappings.

      • You can export only protected attribute labels.

      • You can only export one type of data at a time.

      • When you are exporting data for a particular user or group, you must migrate them in separate operations.

      • 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 importing data for a particular user or group, you must import 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 and Oracle Business Process Management Suite.

Task 7   Move Oracle B2B to the New Production Environment

To move Oracle B2B to a new production environment:

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

  2. Move other configuration properties by using the B2B command line, as described in "Setting Properties of b2b-config" in the Oracle Fusion Middleware User's Guide for Oracle B2B.

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

Task 8   Move Oracle Business Process Management to the New Production Environment

To move Oracle Business Process Management to the new production environment, you move Oracle Business Process Management user metadata, such as organizations and dashboards, from the test environment to the production environment, using the migration tool. The migration tool is available as an ant target that can be executed in the command line. It calls a configuration file that you create specifying the input parameters for the migration of data.

You use the following script:

ORACLE_HOME/bin/ant-t2p-workspace.xml

The command has the following format:

ant -f ant-t2p-workspace.xml
     -Dbea.home=BEA_HOME
     -Dbpm.home=BPM_HOME
     -Dbpm.t2p.migration.config=MIGRATION_CONFIG_FILE

Take the following steps:

  1. Ensure that the PATH environment variable contains the required JAVA_HOME and ANT_HOME environment variables and that they point to the locations within the Oracle SOA Suite installation.

  2. Export Organizations and Dashboard:

    1. Create a configuration file to export Organizations. (You pass that file to the ant command.)

      The following shows a sample configuration file that exports Organizations:

      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
       
      <testToProductionMigrationConfiguration xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config"
       xmlns:ns2="http://xmlns.oracle.com/bpm/common" override="true" skip="true">
          <sourceEndPoint>
              <serverEndPoint>
                  <serverURL>t3://hostname:port</serverURL>
                  <adminUserLogin>admin_username</adminUserLogin>
                  <adminUserPassword>admin_password</adminUserPassword>
                  <realm>jazn.com</realm>
              </serverEndPoint>
          </sourceEndPoint>
          <targetEndPoint>
              <fileEndPoint>
                  <migrationFile>/tmp/bpm_organization.xml</migrationFile>
              </fileEndPoint>
          </targetEndPoint>
          <operation>EXPORT</operation>
          <object>ORGANIZATION</object>
          <objectDetails>
              <login>username</login>
              <password>password</password>
              <identityContext>jazn.com</identityContext>
              <organization/>
          </objectDetails>
      </testToProductionMigrationConfiguration>
      

      In the configuration file, you must specify the values for the test environment in the following elements:

      • migrationFile: This element specifies the file that was generated by the export operation.

      • serverURL

      • adminUserLogin

      • adminUserPassword

      • objectDetails: Update the login and password elements.

    2. Export Organizations, using the following command:

      ant -f ant-t2p-workspace.xml
           -Dbea.home=BEA_HOME
           -Dbpm.home=BPM_HOME
           -Dbpm.t2p.migration.config=ORG_MIGRATION_CONFIG_FILE
      
    3. Create a configuration file to export Dashboards:

      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <testToProductionMigrationConfiguration xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config" xmlns:ns2="http://xmlns.oracle.com/bpm/common" override="true" skip="true">
          <sourceEndPoint>
              <serverEndPoint>
                  <serverURL>t3://hostname:port</serverURL>
                  <adminUserLogin>admin_username</adminUserLogin>
                  <adminUserPassword>admin_password</adminUserPassword>
                  <realm>jazn.com</realm>
              </serverEndPoint>
          </sourceEndPoint>
          <targetEndPoint>
              <fileEndPoint>
                  <migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
              </fileEndPoint>
          </targetEndPoint>
          <operation>EXPORT</operation>
          <object>DASHBOARD</object>
          <objectDetails>
              <login>username</login>
              <password>password</password>
              <identityContext>jazn.com</identityContext>
              <userApplicationData>
                <ownerId>username</ownerId>
              </userApplicationData>
          </objectDetails>
      </testToProductionMigrationConfiguration>
      

      In the configuration file, you must specify the values for the test environment in the following elements:

      • serverURL

      • adminUserLogin

      • adminUserPassword

      • migrationFile. Note that this element specifies the file that was generated by the export operation.

      • objectDetails: Update the login and password elements.

      • userApplicationData: Update the ownerID element.

    4. Export Dashboards, using the following command:

      ant -f ant-t2p-workspace.xml
           -Dbea.home=BEA_HOME
           -Dbpm.home=BPM_HOME
           -Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE
      
  3. Import Organization and Dashboards:

    1. Create a configuration file to import Organizations. (You pass that file to the ant command.)

      The following shows a sample configuration file that imports Organizations:

      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <testToProductionMigrationConfiguration xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config" xmlns:ns2="http://xmlns.oracle.com/bpm/common" override="true" skip="true">
          <sourceEndPoint>
              <fileEndPoint>
                  <migrationFile>/tmp/bpm_organization.xml</migrationFile>
              </fileEndPoint>
          </sourceEndPoint>
          <targetEndPoint>
              <serverEndPoint>
                  <serverURL>t3://hostname:port</serverURL>
                  <adminUserLogin>admin_username</adminUserLogin>
                  <adminUserPassword>admin_password</adminUserPassword>
                  <realm>jazn.com</realm>
              </serverEndPoint>
          </targetEndPoint>
          <operation>IMPORT</operation>
          <object>ORGANIZATION</object>
          <objectDetails>
              <login>username</login>
              <password>password</password>
              <identityContext>jazn.com</identityContext>
              <organization/>
          </objectDetails>
      </testToProductionMigrationConfiguration>
      

      In the configuration file, you must update the following elements with the values for the production environment:

      • migrationFile: This element specifies the file that was generated by the export operation.

      • serverURL

      • adminUserLogin

      • adminUserPassword

      • objectDetails: Update the login and password elements.

    2. Import Organizations, using the following command:

      ant -f ant-t2p-workspace.xml
           -Dbea.home=BEA_HOME
           -Dbpm.home=BPM_HOME
           -Dbpm.t2p.migration.config=ORG_MIGRATION_CONFIG_FILE
      
    3. Create a configuration file to import Dashboards. The format is the same as for Organizations, except that you substitute the following lines:

         <sourceEndPoint>
              <fileEndPoint>
                  <migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
              </fileEndPoint>
          </sourceEndPoint>
          <targetEndPoint>
              <serverEndPoint>
                  <serverURL>t3://hostname:port</serverURL>
                  <adminUserLogin>admin_username</adminUserLogin>
                  <adminUserPassword>admin_password</adminUserPassword>
                  <realm>jazn.com</realm>
              </serverEndPoint>
          </targetEndPoint>
          <operation>IMPORT</operation>
          <object>DASHBOARD</object>
          <objectDetails>
              <login>username</login>
              <password>password</password>
              <identityContext>jazn.com</identityContext>
              <userApplicationData>
                <ownerId>username</ownerId>
              </userApplicationData>
          </objectDetails>
      </testToProductionMigrationConfiguration>
      

      In the configuration file, you must update the following elements with the values for the production environment:

      • serverURL

      • adminUserLogin

      • adminUserPassword

      • migrationFile. Note that this element specifies the file that was generated by the export operation.

      • objectDetails: Update the login and password elements.

      • userApplicationData: Update the ownerID element.

    4. Import Dashboards, using the following command:

      ant -f ant-t2p-workspace.xml
           -Dbea.home=BEA_HOME
           -Dbpm.home=BPM_HOME
           -Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE
      

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 an existing production system:

  1. Follow the steps in Task 2 in Section 20.3.1, modifying existing resource adapters, data sources, and JMS resources, if any changes have been made in the test environment and those changes must be moved to the production environment.

  2. 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 move them to the production environment.

  3. If you have modified EJBs or POJOs in the test environment that support the composite references, follow the steps in Task 4 in Section 20.3.1 to move them to the production environment.

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

  5. If you have made any changes to Human Workflow in the test environment, follow the steps in Task 6 in Section 20.3.1 to move them to the production environment.

  6. 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 move them to the production environment.

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

  7. If you have made any changes to Oracle Business Process Management in the test environment, follow the steps in Task 8 in Section 20.3.1 to move them to the production environment.

20.4 Moving Oracle Business Activity Monitoring to a Production Environment

The following topics describe how to move Oracle Business Activity Monitoring from a test environment to a production environment:

In both scenarios, you have performed the following in the test environment:

  • Installed Oracle WebLogic Server and created the Middleware home.

  • Created the required schemas in the test database using RCU.

  • Installed Oracle SOA Suite and Oracle Business Activity Monitoring.

  • Configured Oracle SOA Suite and Oracle Business Activity Monitoring using the Configuration Wizard.

  • Optionally configured Oracle WebLogic Server dependent artifacts, such as:

    • BAM Adapter

    • Data sources for the database or JMS

  • Configured and populated the identity store for Oracle Business Activity Monitoring users.

  • Configured security policies.

Note:

The Oracle User Messaging Service (UMS) is used in SOA and BAM scenarios. The functionality and actions in both scenarios are similar, but there are small differences. In particular, for BAM, only the e-mail driver is supported, so the reconfiguration steps for UMS only apply to the e-mail driver. Also, BAM does not make use of the UMS User Preferences in this release. Hence, the userprefs migration in UMS migration does not apply to BAM. See Section 20.5 for details on moving UMS from a test to a production system.

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

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. Create the required schemas in the production database using RCU. See Oracle Fusion Middleware Repository Creation Utility User's Guide.

  2. Clone the Middleware home, as described in Section 19.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also cloned.

  3. 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   Move BAM Data and Artifacts to the New Production Environment

Move BAM data and artifacts to the production environment:

  1. Create the BAM JPS root context by importing the ldif file. The following shows a sample ldif file:

    dn: cn=jpsroot_bam_test,dc=us,dc=oracle,dc=com
    cn: jpsroot_bam_test
    objectclass: top
    objectclass: orclcontainer
    
  2. Move the BAM application policy and roles to LDAP using Fusion Middleware Control:

  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, "Move Composite Deployments to the New Production Environment" in Section 20.3.1.

  6. Modify the e-mail server configuration on the production environment, as described in "Configuring Oracle User Messaging Service" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

  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

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   Import BAM Data and Artifacts into the Production Environment

To move 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. Move the BAM application policy and roles to LDAP using Fusion Middleware Control:

  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, "Move Composite Deployments to the New Production Environment" in Section 20.3.1.

  7. Start the BAM server.

20.5 Moving Oracle User Messaging Service to a Production Environment

The following topics describe how to move Oracle User Messaging Service (UMS) from a test environment to a production environment:

In these scenarios, you have installed Oracle User Messaging Service (UMS) in a test environment and you want to move it to a production environment. The first example shows how to move the full UMS install from a test to a new production environment; the second example shows how to merge certain UMS (delta) changes from a test to an existing production environment.

Note:

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

20.5.1 Moving Oracle User Messaging Service to a New Production Environment

In this scenario, you have set up UMS and all required subcomponents, have configured UMS drivers and user preferences in a test environment, and want to establish it in a production environment that does not exist.

Perform the following tasks:

Task 1   Install the Software and Perform the Initial Configuration

To install the software and perform the initial configuration:

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

  2. Clone the Middleware home, as described in Section 19.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also cloned.

  3. 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 2   Move UMS-Related Details to the New Production Environment

To move UMS details to the new 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. Move the User Messaging preferences from the test environment to the production environment:

    1. In the test environment, 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='username', password='password')
      wls:/offline> exit()
      

      Note:

      In this example, 8001 is the Managed Server port on which UMS is running. Replace it with the appropriate value.
    2. Copy the /tmp/userprefs-dump.xml file to the production environment.

    3. In the production environment, run the following WLST command to upload the User Messaging preferences from file to the backend database:

      wls:/offline> manageUserMessagingPrefs(operation='upload',
         filename='/tmp/userprefs-dump.xml', url='t3://localhost:8001',
         username='username', password='password')
      

      Note:

      In the example, 8001 is the Managed Server port on which UMS is running. Replace it with the appropriate value.
    4. 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 you will reconfigured it to use the same set of information.
Task 3   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.

Perform the following tasks:

Task 1   Move UMS-related Details to the Existing 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. Move the User Messaging preferences from the test environment to the production environment. Filters cannot be updated or appended to an existing filter set. You must do one of the following:

    • Delete the entire filter set and upload a new set if there are changes made to the filter set in the test environment.

    • Newly created or modified user devices and filters in the test environment must be created or modified using the following URL in the production environment:

      http://host:port/sdpmessaging/userprefs-ui
      
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 Moving Oracle WebCenter to a Production Environment

The following topics describe how to move Oracle WebCenter from a test environment to a production environment:

In both scenarios, you have the performed the following in a test environment:

  • Installed Oracle WebLogic Server.

  • Installed Oracle WebCenter.

  • Created the required schemas in the test database using RCU.

  • Installed and configured Oracle SOA Suite.

  • Configured Oracle WebCenter using the Configuration Wizard. You created a domain and Managed Servers and configured Oracle WebCenter Spaces, Oracle WebCenter Portlets, Oracle Discussions, Oracle WebCenter Wiki and Blog Server.

  • Installed and configured Oracle Universal Content Management.

  • Installed Identity Management components, such as Oracle Internet Directory, Oracle Identity Federation, and Oracle Access Manager.

  • Configured the Group Spaces.

  • Configured Oracle WebCenter to use LDAP and created some users and groups in the embedded LDAP or an LDAP store.

  • Created the required Oracle Platform Security Services policies in the policy store.

  • Created the required user credentials in the credential store.

  • Created and deployed custom WebCenter applications.

  • Created instance data in the WebCenter Spaces application, including creating a group space based on a Community of Interest template, and provisioned services. In addition, created some roles and assigned new members to the roles.

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

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, groups, and passwords from LDAP identity store, using the ldapsearch command. This produces an ldif file that you later import into the LDAP identity store in the production environment. The ldapsearch command is located in the ORACLE_HOME/bin directory of the Identity Management components. For example:

      ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port 
         -D  "cn=ldap_user" -w test_ldap_passwd -b "cn=users,dc=example,dc=com"
         -s subtree "objectclass=*" "*" orclguid -L > my_users.ldif 
      
    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. Move 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:

    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:

    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 Oracle 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 users, groups, and passwords by importing 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=ldap_user"
        -w "production_ldap_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:

    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.

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:

    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. Move 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="DOMAIN_HOME/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="DOMAIN_HOME/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, perform the following tasks:

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 in the production environment.

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

  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 Moving the Web Tier to a Production Environment

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

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:

20.7.1.1 Moving Oracle HTTP Server to a New Production Environment

In this scenario, you have installed Oracle HTTP Server in a test environment and you want to move it to a production environment, which does not yet exist. In the test environment, you have:

  • Installed Oracle HTTP Server.

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

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

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

  • Configured SSL for one or more virtual hosts.

  • Configured Oracle Single Sign-On.

  • Configured mod_plsql.

  • Configured mod_oradav.

  • In addition, you may be using Oracle Access Manager. In this scenario, the Oracle Access Manager Access Servers are not in the test environment. They reside on a separate production system. However, WebGate is running in the test environment.

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

Task 1   Create the Oracle Instance and the Components

In the production environment, install the binary files using cloning and create the Oracle instance and one or more Oracle HTTP Server component instances:

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

  2. Create the Oracle instance and the Oracle HTTP Server component instance, using either the Oracle Universal Installer or the opmnctl command line:

    • To create the instances and components using the Oracle Universal Installer, take the following steps:

      1. Run the following script:

        (UNIX) ORACLE_HOME/common/bin/config.sh
        (Windows)ORACLE_HOME\common\bin\config.bat
        
      2. Follow the instructions in Oracle Fusion Middleware Installation Guide for Oracle Web Tier.

    • To create the instances and components using the opmnctl command line, take the following steps:

      1. From the command line, go the following directory:

        (UNIX) ORACLE_HOME/opmn/bin
        (Windows) ORACLE_HOME\opmn\bin
        
      2. Create one or more Oracle instances, using the opmnctl createinstance command. For example:

        opmnctl createinstance -oracleInstance /scratch/Oracle/Middleware/inst1
           -adminHost hostname -adminPort 7001
        

        This command creates the Oracle instance and, by default, registers the instance with the Oracle WebLogic Server Administration Server.

      3. Create one or more Oracle HTTP Server component instances, using the opmnctl createcomponent. For example:

        opmnctl createcomponent -componentType OHS
            -oracleInstance /scratch/instances/inst1 -componentName ohs1
        
Task 2   Update Oracle HTTP Server

Update Oracle HTTP Server:

  1. Make a backup copy of the httpd.conf file in the production environment. Then, copy httpd.conf, which is located in the following directory, as well as any non-default include file, from the test environment to a production environment:

    (UNIX) INSTANCE_HOME/config/OHS/ohs_component_name
    (Windows) INSTANCE_HOME\config\OHS\ohs_component_name
     
    
  2. In the production environment, edit the httpd.conf file, making the following changes:

    • Update the Listen directive with the new host name or IP address and port (if the production environment Oracle HTTP Server is using a different port).

    • Update the VirtualHost directive, if the host name, IP address, or port number is defined, with the new values for the production environment.

    • Update any other non-default directives that were configured at the test environment and have topological (host name, IP address, port number) or other machine-specific information.

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

  4. Optionally, configure SSL:

    1. Make a backup copy of the ssl.conf file in the production environment. Then, copy ssl.conf, which is located in the following directory, from the test environment to the production environment:

      ORACLE_INSTANCE/config/OHS/ohs_component_name
       
      
    2. At the production environment, edit the ssl.conf file, updating the virtual host listen address, if the host name, IP address, or port number is defined, with the new values for the production environment.

    3. If the non-default wallet was used at the test environment:

      1. Export the wallet from the test environment and import it at the production environment. For information about exporting and importing wallets, see Section 7.4.4.

      2. Update the wallet location (if changed) in the ssl.conf file at the production environment.

  5. If you are using mod_wl_ohs:

    1. Make a backup copy of the mod_wl_ohs.conf file in the production environment. Then, copy the mod_wl_ohs.conf file, which is located in the following directory, from the test environment to the production environment:

      ORACLE_INSTANCE/config/OHS/ohs_component_name
      
    2. In the production environment, edit the mod_wl_ohs.conf file, updating the WebLogicHost, WebLogicPort, or WebLogicCluster directives with the host name, IP address, and port number for the production environment. For example:

      WebLogicHost hostname | [IPaddress]
      WebCluster IPaddress_1:portnum1, IPaddress_2:portnum2, IPaddress_3:portnum3, ...
      
    3. If SSL is configured for mod_wl_ohs:

      • Export the wallet from the test environment and import it to the production environment. For information about exporting and importing wallets, see Section 7.4.4.

      • Update the TrustedCAFile directive for the wallet location (if it is changed) in the mod_wl_ohs.conf file at the production environment.

    4. At the test environment, inspect the httpd.conf file to determine if some or all of the mod_wl_ohs configuration was defined in that file. If so, update the configuration in the production environment httpd.conf file with the host name, IP address, and port number for the production environment.

  6. If you are using mod_osso:

    1. Make a backup copy of the mod_osso.conf file in the production environment. Then, copy the mod_osso file, which is located in the following directory, from the test environment to the production environment:

      ORACLE_INSTANCE/config/OHS/ohs_component_name/moduleconf
      
    2. Edit mod_osso.conf to add the following information, using values for your deployment. For example:

      LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
      
      <IfModule mod_osso.c>
       
      OssoIdleTimeout off
      OssoIpCheck on
      OssoConfigFile  ORACLE_INSTANCE/config/OHS/ohs_component_name/osso/osso.conf   
       
      #Location is the URI you want to protect
      <Location />
      require valid-user
      #OHS 11g AuthType Osso    
      #OHS 10g AuthType Basic    
      AuthType Osso
       
      </Location>
       
      </IfModule>
      
  7. If you are using mod_PLSQL:

    1. Make a backup copy of the following configuration files in the production environment. Then, copy the files from the test system to the production system.

      ORACLE_INSTANCE/config/OHS/ohs_component_name/conf/moduleconf/plsql.conf 
      ORACLE_INSTANCE/config/OHS/ohs_component_name/conf/mod_plsql/dads.conf 
      ORACLE_INSTANCE/config/OHS/ohs_component_name/conf/mod_plsql/cache.conf
      
    2. Edit the files, replacing the values of any properties that contain information about the test environment with the values for the production environment. Usually, you only need to modify the following properties in the dads.conf file:

      PlsqlDatabaseUserName
      PlsqlDatabasePassword
      PlsqlDatabaseConnectString
      PlsqlNLSLanguage
      
  8. If you are using mod_oradav:

    1. Make a backup copy of the following configuration file in the production environment. Then, copy the following file from the test system to the production system:

      ORACLE_INSTANCE/config/OHS/ohs_component_name/conf/moduleconf/mod_oradav.conf.
      
    2. Edit the file, replacing the values of any properties that contain information about the test environment with the values for the production environment. Usually, you only need to modify the following parameters in the mod_oradav.conf file:

      DAVParam ORACONNECTSN
      DAVParam ORAUSER
      DAVParam ORACRYPTPASSWORD
      
  9. If any changes have been made to auditconfig.xml, which is located in the following directory, make a backup copy of the file in the production environment. Then, copy auditconfig.xml from the test environment to the corresponding production environment:

    ORACLE_INSTANCE/config/OHS/ohs_component_name/auditconfig.xml
    
  10. If any changes have been made to component-log.xml, make a backup copy of the file in the production environment. Then, copy the file, which is located in the following directory, from the test environment to the production environment:

    ORACLE_INSTANCE/diagnostics/logs/OHS/ohs_component_name
    
Task 3   Configure WebGate (Optional)

If you are using Oracle Access Manager, this scenario assumes that the same Oracle Access Manager server is used for both test and production systems. In addition, when you clone the Middleware home, the binary files for WebGate are installed in the Oracle home.

  1. Run the configureWebGate program located at:

    WebGate_install_dir/access/oblix/tools/configureWebGate
    
  2. Provide details for the production environment, using the same configuration settings as the test environment, except for the following:

    • Host name

    • Port

    • Primary HTTP cookie domain (optional)

    • Preferred HTTP Host (depends on environment)

  3. Edit the httpd.conf file to update the WebGate information with the values for the production system, modifying the LoadFile, LoadModule, and WebGateInstallDir directives. The following example shows an excerpt of the httpd.conf file, with the items that must be modified in bold.

    #*** BEGIN WebGate Specific ****
     
    LoadFile "/webgate_path/access/oblix/lib/libgcc_s.so.1"
    LoadFile "/webgate_path/access/oblix/lib/libstdc++.so.5"
     
    LoadModule obWebgateModule "/webgate_path/access/oblix/apps/webgate/bin/webgate.so"
     
    WebGateInstalldir "/webgate_path/access"
    
Task 4   Restart the Processes

Restart the processes in the Oracle instance:

ORACLE_INSTANCE/bin/opmnctl stopall
ORACLE_INSTANCE/bin/opmnctl startall

20.7.1.2 Moving Oracle Web Cache to a New Production Environment

In this scenario, you have installed Oracle Web Cache in a test environment and you want to move it to a production environment, which does not yet exist. In the test environment, you have:

  • Installed Oracle Web Cache.

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

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

  • Configured the Oracle Web Cache instances as a Oracle Web Cache cluster.

  • Created a site and configured site-to-server mapping.

  • Configured Oracle Web Cache to have an SSL-enabled listening address.

  • Configured caching rules, and defined filters for request filtering.

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

Task 1   Create the Oracle Instances and the Oracle Web Cache Instances

In the production environment, install the binary files by using cloning and create the Oracle instances and Oracle Web Cache instances:

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

  2. Create the Oracle instances and components. Create the Oracle instances on different hosts, each containing an Oracle Web Cache instance.

    To create the instances and components using the Oracle Universal Installer, take the following steps:

    1. Run the following script:

      (UNIX) ORACLE_HOME/common/bin/config.sh
      (Windows)ORACLE_HOME\common\bin\config.bat
      
    2. Follow the instructions in Oracle Fusion Middleware Installation Guide for Oracle Web Tier.

    To create the instances and components using the command line, take the following steps:

    1. From the command line, go the following directory:

      (UNIX) ORACLE_HOME/opmn/bin
      (Windows) ORACLE_HOME\opmn\bin
      
    2. Create the Oracle instances, using the opmnctl createinstance command. For example:

      opmnctl createinstance -oracleInstance /scratch/Oracle/Middleware/inst1
         -adminHost hostname -adminPort 7001
      

      This command creates the Oracle instance and, by default, registers the instance with the Oracle WebLogic Server Administration Server.

    3. Create the Oracle Web Cache instances, using the opmnctl createcomponent command. For example:

      opmnctl createcomponent -componentType WebCache 
          -oracleInstance /scratch/Oracle/Middleware/inst1 
          -componentName webcache1
      
  3. Register the Oracle instances, along with all of its components, with the Administration Server, using the opmnctl registerinstance command. For example:

    opmnctl registerinstance -adminHost admin_server_host 
         -adminPort admin_server_port -adminUsername username 
         -adminPassword password
         -oracleInstance ORACLE_INSTANCE_dir -oracleHome ORACLE_HOME_dir
         -instanceName Instance_name -wlserverHome Middleware_Home
    
Task 2   Update Oracle Web Cache

For each Oracle Web Cache instance, take the following steps:

  1. Copy the webcache.xml file, which is located in the following directory, from the test environment to a temporary location:

    (UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name
    (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
    
  2. Make the following changes to webcache.xml in the temporary location:

    • If the Web Cache Administration password at the production environment is different from the password at the test environment:

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

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

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

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

      • Update the NAME, ORACLE_HOME and HOSTNAME attributes.

      • Search for and replace the Oracle instance path.

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

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

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

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

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

  3. Copy the edited webcache.xml to the following location on the production system:

    (UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name
    (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name
    
  4. If any changes have been made to auditconfig.xml, copy auditconfig.xml from the test environment to the corresponding production environment.

    ORACLE_INSTANCE/config/WebCache/webcache_name/auditconfig.xml
    
  5. If any changes have been made to component-log.xml, first, edit the file to update the log path, and then copy the .xml file from the test environment to the corresponding production environment.

  6. If any changes have been made to the Oracle Web Cache error pages, which are located in the following directory, copy the error pages from the test environment to the production environment location:

    (UNIX) ORACLE_INSTANCE/config/WebCache/webcache_name/files
    (Windows) ORACLE_INSTANCE\config\WebCache\webcache_name\files
    
  7. If a non-default wallet was used at the test environment for either an SSL-enabled listen address or an OSwallet, or both, export the wallets from the test environment and import them at the production environment. For information about exporting and importing wallets, see Section 7.4.4.

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.

20.8 Moving Classic Components to a Production Environment

In this scenario, you have installed Oracle Fusion Middleware Classic components, including Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle Business Intelligence Discoverer, in a test environment and you want to move it to a production environment.

The following topics describe how to move these components from a test environment to a production environment:

In both scenarios, you have performed the following in a test environment:

  • Installed a database to be used for these components.

  • Created schemas needed by the components, using RCU.

  • For Oracle BI Discoverer, installed an additional database to be used for the End User Layer (EUL), Discoverer catalog, and OLAP catalog.

  • Installed Oracle WebLogic Server and created a Middleware home.

  • Installed and configured Identity Management, including Oracle Internet Directory and Oracle Single Sign-On, and a database for Identity Management data.

  • Installed and configured Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle BI Discoverer.

  • For Oracle Portal:

    • Created users and groups and assigned page access permissions to the groups.

    • Created new page groups and new templates.

    • Created new pages and added contents, such as items and portlets, to the pages.

    • Customized pages, layouts, items, and portlets.

    • Registered producers (database, Web, and WSRP) and customized the portlet from the producers.

    • Registered external applications.

  • Set up Forms applications.

  • Configured Oracle Reports instances and created connections to the database.

  • For Oracle BI Discoverer:

    • For Discoverer Plus, created a new workbook with parameters, calculations, conditions, and totals. Saved the workbook.

    • For Discoverer Viewer, opened the workbook created in Discoverer Plus and performed some formatting, sorting, exporting, and drilling.

    • For Discoverer Plus OLAP, created a new workbook in Discoverer Plus OLAP with custom members, custom expressions, and saved selections. Saved the workbook.

    • For Viewer OLAP, opened the workbook created in Discoverer Plus OLAP and performed some operations such as exporting, linking and unlinking layouts.

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 new production environment, perform the following tasks:

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. Clone the Middleware home, as described in Section 19.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also cloned.

  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 moved. 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. Move users and groups from the LDAP directory in the test environment to the LDAP directory in the production environment, as described in "Migrating Users and Groups" in the Oracle Fusion Middleware Administrator's Guide for Oracle Portal.

  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 a new 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
    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. Move the application-related data from the test environment to a database in the production environment using database migration tools.

  4. Create entries in the SQL*Net 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. Move the Forms RAD data from Oracle Internet Directory in the test environment to Oracle Internet Directory in the production environment. See Step 3 in Task 2, "Move Oracle Internet Directory to a New Production Environment" in Section 20.2.1.

  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:

    ORACLE_INSTANCE/bin/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
    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/config/fmwconfig/servers/server_name/applications/reports_version/configuration/cgicmd.dat
    DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/rwservlet.properties
    DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/rwserver.conf
    DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/jdbcpds.conf
    DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/xmlpds.conf
    DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/textpds.conf
    DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/rwnetwork.conf
    DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/logging.xml
    DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/logmetadata.xml
    DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration/jazn-data.xml
    
    Reports Tools configuration
    ORACLE_INSTANCE/config/ReportsTools/rwbuilder.conf
    ORACLE_INSTANCE/config/ReportsTools/rwnetwork.conf
    ORACLE_INSTANCE/config/ReportsTools/jdbcpds.conf
    ORACLE_INSTANCE/config/ReportsTools/xmlpds.conf
    ORACLE_INSTANCE/config/ReportsTools/textpds.conf
    ORACLE_INSTANCE/config/ReportsTools/component-logs.xml
    ORACLE_INSTANCE/config/ReportsTools/logging.xml
    
    Reports Bridge configuration
    ORACLE_INSTANCE/config/ReportsBridge/bridge_name/rwbridge.conf
    ORACLE_INSTANCE/config/ReportsBridge/bridge_name/rwnetwork.conf
    ORACLE_INSTANCE/config/ReportsBridge/bridge_name/component-logs.xml
    ORACLE_INSTANCE/config/ReportsBridge/bridge_name/loggin.xml
    
    Reports shell scripts
    (UNIX) ORACLE_INSTANCE/config/reports/bin/rw*.sh
    (Windows) ORACLE_INSTANCE\config\reports\bin\rw*.bat
    (UNIX) ORACLE_INSTANCE/config/reports/bin/reports.sh
    (Windows) ORACLE_INSTANCE\config\reports\bin\reports.bat
    (UNIX) ORACLE_INSTANCE/config/reports/bin/namingservice.sh
    (Windows) ORACLE_INSTANCE\config\reports\bin\namingservice.bat
    

  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
    JPS configuration
    DOMAIN_HOME/config/fmwconfig/jps-config.xml
    DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml 
    DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml
    
    Forms and Reports common files
    Font setup, aliasing, subsetting, embedding:
    ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/Uifont.ali
    Printer configuration (UNIX only):
    ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/uiprint.txt 
    Toolkit configuration, encoding (UNIX only):
    ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/uTk2Motif.rgb 
    PPD files (UNIX only): 
    ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon//tk/admin/PPD/*
    AFM files (UNIX only):
    ORACLE_INSTANCE/config/FRComponent/frcommon/guicommon/tk/admin/AFM/*
    

  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:

  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 
      
    • Move Reports-specific data tables that are referred to in the RDF files to the database in the production environment using database migration tools, such as the Oracle Database export and import utilities.

  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 move the data:

    1. Use the following script:

      ORACLE_HOME/reports/admin/sql/rw_job_repos.sql 
      
    2. Move any data from the test database for the schemas RW_JOBS, RW_SERVER_JOB_QUEUE, and RW_SERVER_QUEUE to production database using database migration tools, such as the Oracle Database export and import utilities.

  8. Move any user and reports server security policy information. See "Securing Oracle Reports" in the Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services.

  9. If you use Oracle Internet Directory as the identity and policy store, move the Forms RAD data from Oracle Internet Directory in the test environment to Oracle Internet Directory in the production environment. See Step 3 in Task 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, move them to the LDAP in the production environment. You can use the WLST command migrateSecurityStore, as described in "Migrating Policies with the Command migrateSecurityStore" in the Oracle Fusion Middleware 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. Move 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/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_11.1.1.3.0/configuration/configuration.xml
    DOMAIN_HOMEconfig/fmwconfig/servers/WLS_DISCO/applications/discoverer_11.1.1.3.0/configuration/configuration-preview.xml
    

    In the configuration.xml file, change the values of the following elements to reflect the production environment:

    • applicationURL

    • oracleInstance

    • discovererComponentName

  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. 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. Move the DISCOVERER schema from the test environment to the production environment. You can use the Oracle Database export and import utilities to move the schema.

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

  9. Move 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. Move the EUL schema from the test database by using the Discoverer Administrator to export the schema from the test database and import it into the database in the production environment. For more information, see "About Using the Discoverer Export Wizard and Import Wizard" in the Oracle Fusion Middleware Administrator's Guide for Oracle Business Intelligence Discoverer.

    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. Move 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. Authorize users in the production OLAP database, using the following command:

      java -classpath d4o.jar oracle.dss.d4o.administration.D4OCommand
       authorize -h hostname -po port -sid sid -p d4osys-password -u user
      
    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. Move 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. Move PStore data:

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

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

      Note that the user names and schema names must be the same in the production environment as in the test environment.

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

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:

    ORACLE_INSTANCE/bin/opmnctl stopall
    ORACLE_INSTANCE/bin/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. Move the configuration files that are listed in Steps 1 and 5 in Task 6, "Move Oracle Business Intelligence Discoverer to the New Production Environment".

  2. Move the DISCOVERER schema from the test environment to the production environment. You can use the Oracle Database export and import utilities to move the schema.

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

  3. Move the EUL schema from the test environment to the production environment by using the Oracle database export and import utilities to export the schema from the test database and import it into the database in the production environment.

    Note that the user names and schema names must be the same in the production environment as in the test environment.

20.9 Moving Oracle Business Intelligence Components to a Production System

This section describes the steps for moving Oracle Business Intelligence from a test environment to a production environment.

See Also:

"Managing the Repository Lifecycle in a Multiuser Development Environment" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for detailed information about the Oracle BI repository lifecycle, including test to production considerations for the repository."

The following scenarios assume that you have already installed and configured Oracle Business Intelligence components in a test environment, and you want to move them to either a new or an existing production environment.

20.9.1 Moving Oracle Business Intelligence Components to a New Production Environment

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

This scenario assumes that you have already installed and configured Oracle Business Intelligence components in a test environment, and you want to move them to a new production environment.

Note: The steps for moving to a new production environment are identical to the migration process.

To move Oracle Business Intelligence components to a new production environment:

Task 1   (Optional) Patch and Clone the Test Environment
  1. Patch the test environment, and test the environment until it is ready.

    For more information, see Oracle Fusion Middleware Patching Guide.

  2. If trying new configuration settings, note down the changes made so they can be replicated.

  3. Clone the test environment using the copyBinary script, as described in Section 19.3.1.

Task 2   Clone Out into the New Production Environment
  1. Copy the cloned Jar (created in Task 1, "(Optional) Patch and Clone the Test Environment"), from the test environment to the production environment.

  2. Copy the following files to the production environment:

    • UNIX:

      ORACLE_COMMON_HOME/bin/pasteBinary.sh
      ORACLE_HOME/jlib/cloningclient.jar
      
    • Windows:

      ORACLE_COMMON_HOME\bin\pasteBinary.cmd
      ORACLE_HOME\jlib\cloningclient.jar
      
  3. Ensure JDK 1.6.4 or later is installed in the production environment, or JRockit (comes with the BI installer).

  4. Use the pasteBinary command to clone to the new production environment, as described in Section 19.3.1.

Task 3   Create a BI Domain in the New Production Environment

For more information, see Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence Enterprise Edition.

Task 4   Configure Security in the New Production Environment

Complete this task if you are using something other than the default Oracle WebLogic Server LDAP. For more information, see Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.

Task 5   Move the Oracle BI Presentation Catalog from the Test Environment to the New Production Environment
  1. Zip the entire catalog in the test environment (using 7Zip).

  2. Unzip catalog in the new production environment.

    For more information, see Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

  3. Use Fusion Middleware Control to set the catalog location in the production environment.

    For more information, see "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

Task 6   Deploy the Test RPD and BI Presentation Catalog in the New Production Environment
  1. Use Fusion Middleware Control in the new production environment to upload the RPD.

    For more information, see "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

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

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

  3. (Optional) Make the production repository read-only by selecting Disallow Online RPD Updates in the Performance tab of the Capacity Management page in Fusion Middleware Control.

Task 7   Clone and Scale Out to New Cluster Hosts in the Production Environment
  1. Copy the cloned Jar (created in Task 1, "(Optional) Patch and Clone the Test Environment") to the new cluster host.

  2. Copy the following files to the new cluster host:

    • UNIX:

      ORACLE_COMMON_HOME/bin/pasteBinary.sh
      ORACLE_HOME/jlib/cloningclient.jar
      
    • Windows:

      ORACLE_COMMON_HOME\bin\pasteBinary.cmd
      ORACLE_HOME\jlib\cloningclient.jar
      
  3. Use the pasteBinary command to clone out to the new cluster host, as described in Section 19.3.1.

    Note: You must use exactly the same middleware home name on the new cluster host that is used on the master host.

  4. Use Fusion Middleware Control to scale out to the new cluster host.

    For more information, see "Using Fusion Middleware Control to Scale System Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

  5. Repeat the previous steps for each new cluster host.

Task 8   (Optional) Refresh Global Unique Identifiers (GUIDs)

You do not normally refresh GUIDs in the LDAP directory (identity store users), between test and production environments, because the LDAP directories containing the GUIDs should be fan out replicas in both the test and the production environments. Possible scenarios could be:

  • BI test servers and production servers are both configured against the corporate LDAP Directory

    There is no need to refresh LDAP GUIDs.

  • BI test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is a fan-out replica of the corporate LDAP

    There is no need to refresh LDAP GUIDs.

  • BI test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is not a fan-out copy of the corporate LDAP

    LDAP GUID refresh is needed. For more information, see Section 20.9.4, "Refresh the User GUIDs".

Task 9   Enable New Agents and Oracle BI Publisher Scheduled Jobs

If new agents were created in the test environment, click each agent in the Presentation Services Catalog Manager to enable it.

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

In a production environment, Oracle WebLogic Server administrators should create JNDI connections (to be used by Oracle BI Publisher reports), using the same names as in the test environment, but should point to the production database(s) instead of the test database(s). This way all reports automatically point to the production environment databases, instead of test environment databases, without any modification.

Task 10   Update Links to External Systems

Please remember to move static content to the production environment (for example, JPGs in dashboards), OWSM policy files, Action framework, other policy files specifying how to communicate with external systems.

Task 11   Move BI-Related Applications

(Optional) Move BI-related applications (Calculation Manager, Oracle Real-Time Decisions, Workspace, Financial Reporting, and BI Office) to the new production environment. For more information, see the appropriate sections for these applications (where available).

Task 12   Validate the Production System

Validate that the production system accurately represents the test system.

20.9.2 Moving Oracle Business Intelligence Components to an Existing Production Environment When There are Few Patches to Apply

This section describes the steps for moving Oracle Business Intelligence from a test environment to an existing production environment when there are few patches to apply.

The following steps assumes that you have already installed and configured Oracle Business Intelligence components in a test environment, and you want to move them to an existing production environment.

To move Oracle Business Intelligence components to an existing production environment when there are few patches to apply:

Task 1   Patch the Test and Existing Production Environments

A patch applies a collection of bug fixes to an existing production environment, and includes new binary files and metadata updates.

  1. Patch the test environment as required, and test until ready.

  2. Patch the existing production environment to the same level as the test environment on the master host, and on all cluster hosts.

    Note: Patching also includes non-BI patches and one-off patches.

    For more information, see "Patching Oracle Business Intelligence Systems" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

Task 2   Deploy the Test RPD to the Existing Production Environment
  1. (Optional) In the test environment use the Administration Tool and the Oracle BI Server XML API to perform a patch merge of the test RPD with the production RPD.

    You only need to complete this task if you are moving to an existing production environment, and have made changes to the RPD in the test environment.

    See "Performing Patch Merges" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition for more information.

  2. Use Fusion Middleware Control in the production environment, to upload the RPD to be used.

    For more information, see "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

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

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

  4. (Optional) Make the production repository read-only by selecting Disallow Online RPD Updates in the Performance tab of the Capacity Management page in Fusion Middleware Control.

Task 3   Deploy the Test Oracle BI Presentation Catalog to the Existing Production Environment
  1. Drag and drop new or updated folders from the test catalog into the production catalog as follows:

    1. Open two Catalog Manager windows, one with the test Catalog, and another with the production catalog.

    2. Selectively copy and paste the folders you want from the test Catalog into the production catalog.

      Note: If you copy and paste folders where the same content has been changed in the test or production environments, the test content will overwrite the production content.

      For more information, see Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

  2. Use Fusion Middleware Control in the existing production environment to specify the location of the new catalog.

    For more information, see "Using Fusion Middleware Control to Upload a Repository and Set the Oracle BI Presentation Catalog Location" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

Task 4   (Optional) Refresh Global Unique Identifiers (GUIDs)

You do not normally refresh GUIDs in the LDAP directory (identity store users), between test and production environments, because the LDAP directories containing the GUIDs should be fan out replicas in both the test and the production environments. Possible scenarios could be:

  • BI test servers and production servers are both configured against the corporate LDAP Directory

    There is no need to refresh LDAP GUIDs.

  • BI test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is a fan-out replica of the corporate LDAP

    There is no need to refresh LDAP GUIDs.

  • BI test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is not a fan-out copy of the corporate LDAP

    LDAP GUID refresh is needed. For more information, see Section 20.9.4.

Task 5   Enable New Agents and Oracle BI Publisher Scheduled Jobs

If new agents were created in the test environment, click each agent in the Presentation Services Catalog Manager (in the production environment) to enable it.

Oracle BI Publisher reports are stored in the Web Catalog and so existing reports, and new reports created in the test environment should be available.

In a production environment, Oracle WebLogic Server administrators should create JNDI connections (to be used by Oracle BI Publisher reports), using the same names as in the test environment, but should point to the production database(s) instead of the test database(s). This way all reports automatically point to the production environment databases, instead of test environment databases, without any modification.

Task 6   Update Links to External Systems

Please remember to move static content to the production environment (for example, JPGs in dashboards), OWSM policy files, Action framework, and other policy files specifying how to communicate with external systems.

Task 7   Move BI-Related Applications

(Optional) Move BI-related applications (Calculation Manager, Oracle Real-Time Decisions, Workspace, Financial Reporting, and BI Office). For more information, see the appropriate user guides for these applications.

Task 8   Validate the Production System

Validate that the production system accurately represents the test system.

20.9.3 Moving Oracle Business Intelligence Components to an Existing Production Environment When There are Many Patches to Apply

This section describes the steps for moving Oracle Business Intelligence from a test environment to an existing production environment, when there are many patches to apply.

This scenario assumes that you have already installed and configured Oracle Business Intelligence components in a test environment, and you want to move them to an existing production environment.

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

20.9.3.1 What to Do If New Hardware Is Available?

Use this task if you want to move Oracle Business Intelligence components to an existing production environment, when there are many patches to apply, and new hardware is available.

To move Oracle Business Intelligence components to an existing production environment when there are many patches to apply, and if new hardware is available:

Task 1   Follow the Steps for Moving to a New Production Environment

Note: This includes merging the new test RPD/catalog with those in the existing production environment. Ideally you do this once and resolve the issues while users continue using the existing environment. Once the files are correct, you lock the production environment and repeat the merge to pick up the latest changes.

For more information, see Section 20.9.1.

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

You can use a load balancer like Oracle WebCache to redirect users from a standard URL to the new production environment.

Task 3   Remove the Old Production Environment and Prepare It for the Next Patch

The old environment can now be shutdown and all software de-installed. When needed, the next patchset can be applied to this host and the sequence can start all over again.

20.9.3.2 What to Do If New Hardware Is Unavailable?

Use this task if you want to move Oracle Business Intelligence components to an existing production environment, when there are many patches to apply, and if new hardware is unavailable.

To move Oracle Business Intelligence components to an existing production environment when there are many patches to apply, and if new hardware is unavailable:

Task 1   Scale the Production Environment Back to One Host

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

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

Task 2   Patch the Host in the Production Environment

This imposes less downtime on users than having to patch multiple cluster hosts.

For more information, see Oracle Fusion Middleware Patching Guide.

Task 3   Remove the Old Software on the Cluster Hosts

De-install all the Oracle Business Intelligence software on the cluster hosts. For more information, see Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence Enterprise Edition.

Task 4   Clone the Production Environment and Then Clone to the Cluster Hosts

Complete the tasks beginning with Task 7, "Clone and Scale Out to New Cluster Hosts in the Production Environment" in Section 20.9.1.

20.9.4 Refresh the User GUIDs

Best practice is to update the user GUIDs after changing the directory server used as the data source for the authentication provider. If the same user name exists in both directory servers (original and new), the original user GUID may conflict with the user GUID contained in new directory server. A refresh forces the system to reference the user GUID contained in the new directory server. Authentication errors may result if the GUIDs are not refreshed and the system detects a mis-match for the user GUID.

The GUIDs stored in the BI Presentation Catalog or RPD can be resynchronized as follows:

Before you begin this procedure, ensure that you are familiar with the information in the section "Manually Updating Oracle Business Intelligence Configuration Settings Not Normally Managed by Fusion Middleware Control" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

To refresh the user GUIDs:

This task requires that you manually edit the configuration files to instruct Oracle BI Server and Oracle BI Presentation Server to refresh the GUIDs on restart. Once completed, you will edit these files to remove the modification. For information about where to locate Oracle Business Intelligence configuration files, see the section that describes where configuration files are located, in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

Note:

Refreshing the GUIDs requires that you stop and restart the System components from the command line and not Fusion Middleware Control. This includes the Administration Server and Managed Servers. After the Administration Server is stopped, you cannot start it from Fusion Middleware Control as it is not available during this time.
  1. Open the NQSConfig.INI file for editing. For more information, see "Where are Configuration Files Located?" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

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

  3. Modify the instanceconfig.xml file to instruct Oracle BI Presentation Server to refresh GUIDs on restart. Edit the file to add the last line in the following instruction.

    <ps:Catalog xmlns:ps="oracle.bi.presentation.services/config/v1.1">
    <ps:UpgradeAndExit>false</ps:UpgradeAndExit>
    <ps:UpdateAccountGUIDs>UpdateAndExit<ps:UpdateAccountGUIDs>
    
  4. From a terminal window, stop and restart the managed processes using the opmnctl parameters stopall and startall. You can use the parameter status to verify process status throughout.

    The following components are involved: Oracle BI Presentation Server, Oracle BI Server, Oracle BI Scheduler, Oracle BI Cluster Controller, and Oracle BI JavaHost.

    For information about using opmnctl commands, see "Using the OPMN command line to Start and Stop Oracle Business Intelligence System Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

  5. Edit the NQSConfig.INI file to reset the FMW_UPDATE_ROLE_AND_USER_REF_GUIDS = YES to NO and restart the Oracle BI Servers.

  6. Remove, set to none, or comment out the line (see UpgradeAndExit in the following example) added to the instanceconfig.xml file (that instructs Oracle BI Presentation Server to refresh GUIDs on restart).

    <ps:Catalog xmlns:ps="oracle.bi.presentation.services/config/v1.1">
    <ps:UpgradeAndExit>false</ps:UpgradeAndExit>
    <ps:UpdateAccountGUIDs>none<ps:UpdateAccountGUIDs>
    
  7. Restart the Presentation Server for the instanceconfig.xml file that was updated.

  8. Make sure Oracle WebLogic Server and the system components are also running, if they are not running, restart them.

    For more information, see "Starting and Stopping the Oracle Business Intelligence Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

20.10 Moving Oracle Real-Time Decisions to a Production System

The following topics describe how to move Oracle Real-Time Decisions (Oracle RTD) from a test environment to a new production environment:

20.10.1 Moving Oracle Real-Time Decisions to a New Production Environment

To move the environment to a production environment, perform the following tasks:

Task 1   Install the Oracle RTD Software and Perform the Initial Configuration

To install the Oracle RTD software and perform the initial configuration:

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

  2. Clone the Middleware home, as described in Section 19.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also cloned.

  3. Configure Oracle RTD and create a domain using the Configuration Wizard. See "Configuring Oracle RTD After Installation" in Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions. For the purposes of this configuration, follow the steps for configuring Oracle RTD after a Software Only install.

The following are important factors to consider in the setup and configuration of the production system:

  1. When using the Repository Configuration Utility (RCU), connection pools must reflect database connections specific to the production environment.

  2. During the configuration of custom roles and security settings, the setup parameters must be modified to reflect settings for the production environment.

    For more details, see the Security chapter in Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

  3. Any performance tuning parameters defined in the test environment should also be re-created in the production environment. This includes performance parameters both at the application server and database levels.

Task 2   Install Oracle RTD Clients (if used) on to the Production Environment

If used for the integration of Oracle RTD to a customer's front end applications, Oracle RTD clients must be installed in the production environment, according to the setup steps outlined in Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

Configuration of client parameters should reflect values specific to the production architecture.

Task 3   Move Inline Services

After the administrator has completed Task 1, Oracle RTD Inline Services that exist on the test environment can then be moved to the production environment.

  1. Moving Inline Services to the production environment can be performed in two ways:

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

    • Calls to third party APIs and third party JAR files

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

    • Calls to third party web services

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

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

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

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

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

    • For dynamic choices:

      If dynamic choices are part of the Inline Service configuration, administrators need to re-create both the data and the tables that store the dynamic choices, if the test and production environment do not share the same source.

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

    • For external rules:

      If external rules are part of the Inline Service configuration, administrators will need to re-create both the data and the tables that store the rule data if the test and production environment do not share the same source.

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

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

Task 4   Edit Additional Oracle RTD Components for Production

Additional tasks that an administrator may encounter with Oracle RTD include the following:

  1. Creating and configuring the model snapshot tables.

    1. The Oracle RTD model snapshot tables can be created in the production environment in two ways, RCU or the tool sdexec/SDDBTool, which is provided with the installation.

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

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

  2. Modifying the loadgen files.

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

    1. ClientHttpEndpoints.properties files

    2. Inline Service name (if changed)

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

    4. Path to the loadgen log file

  3. Modifying batch processing files.

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

20.10.2 Moving Oracle Real-Time Decisions to an Existing Production Environment

After a production environment has been created, typical Oracle RTD incremental changes include the following:

Task 1   Oracle RTD Patch Updates

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

Task 2   Update Inline Services

For incremental Inline Service changes, moving the Inline Service to production follows the same steps as outlined for a full product test to production move.

Task 3    Update Data Sources

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

20.11 Moving Oracle Enterprise Content Management to a Production System

The following topics describe how to move Oracle Enterprise Content Management Suite to a production environment:

In both scenarios, you have performed the following in the test environment:

  • Installed a database to be used for required schemas.

  • Created needed schemas using RCU. See Oracle Fusion Middleware Repository Creation Utility User's Guide.

  • Installed Oracle WebLogic Server and created the Middleware home.

  • Installed and configured Oracle Enterprise Content Management Suite.

  • If Oracle Imaging and Process Management is using Workflow or Oracle Application Extension Framework (AXF), installed and configured Oracle SOA Suite.

  • Configured Oracle Universal Content Management.

  • Configured Oracle Imaging and Process Management.

    If Oracle I/PM uses Oracle Universal Content Management 10g repository, ensure that the repository was manually configured for Oracle I/PM.

  • Configured Oracle Universal Records Management.

  • Defined several definitions, such as Connections, Applications, Searches, and Inputs for Oracle I/PM.

  • Installed and configured Identity Management components, such as Oracle Internet Directory.

20.11.1 Moving Oracle Enterprise Content Management Suite to a New Production Environment

To move Oracle Enterprise Content Management Suite to a new production environment, perform the following tasks:

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

  • Oracle Internet Directory

  • Oracle Virtual Directory

  • A third-party LDAP Server

Task 1   Create a New Database and Populate It with Schemas

To create the database and populate it with the necessary schemas:

  1. Create a new database on the production system.

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

Task 2   Install the Software and Perform the Initial Configuration

Take the following steps to install the software and perform the initial configuration:

  1. Clone the Middleware home, as described in Section 19.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also cloned.

  2. Configure Oracle WebLogic Server, Oracle Imaging and Process Management, Oracle Universal Content Management, and Oracle Universal Records Management. See "Configuring Oracle Enterprise Content Management Suite" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.

    See Task 3, "Move Oracle Information Rights Management to a New Production Environment" for information about configuring Oracle IRM. That task describes how to configure Oracle IRM using pack and unpack, rather than using the Configuration Wizard.

    When you configure, note the following actions that you perform for Oracle UCM:

    • Ensure that Oracle UCM is installed in the same path as it is in the test environment.

    • In the JDBC Component Schema screen, make sure that you specify the production database and the newly imported schema.

    • After installation, complete the Content Server Configuration page. Ensure that the intraDoc directory on the production environment is in the same path as on the test environment.

  3. If you are using an Oracle UCM 10g repository, ensure that Full-Text is configured correctly on the production Oracle UCM system, if configured on the test Oracle UCM 10g system.

    Note that if you are using an Oracle UCM 10g server, you install it using the procedures described in the Oracle Universal Content Management page at:

    http://www.oracle.com/technology/products/content-management/ucm/index.html
    
Task 3   Move Oracle Information Rights Management to a New Production Environment

Organizations that host Oracle Information Rights Management as a service for customers, where each deployment needs to be completely separated from other deployments, can use templates of an Oracle IRM development domain to configure production domains for the customers. For example, Oracle On Demand might use this approach to rapidly deploy Oracle IRM applications for new customers.

You pack the Oracle WebLogic Server domain that includes the Oracle IRM Managed Server in the source environment, making it ready for deployment to the target environment. After the migration, the target environment would have a fully configured Oracle IRM Server, only requiring the server, host name, privacy policy URL, database, keystore, and SSL certificate to be changed.

To roll out an Oracle IRM template to a new production environment:

  1. Unpack a template Oracle IRM domain installation. See Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands for information about packing and unpacking a template.

  2. Start the Administration Server and the Managed Servers.

  3. Modify the information about the database:

    1. Log into the Oracle WebLogic Server Administration Console.

    2. From the Domain Structure menu, expand Services, then JDBC. Select Data Sources.

    3. Click OracleIRM.

    4. Select the Connection Pool tab.

    5. Change the following entries to reflect the information for the database on the production environment:

      • URL, database host, and port details. For example:

        jdbc:oracle:thin:@newhostname.domainname:port/sid
        jdbc:sqlserver://newhostname.domainname:port;database=database
        
      • Driver class, which is database-specific. For example:

        oracle.jdbc.OracleDrivercom.microsoft.sqlserver.jdbc.SQLServerDriver
        
      • Properties: Database user name

      • Password: Database password

    6. Click Save.

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

  5. Change the following settings for the Oracle IRM Managed Server. You can use Fusion Middleware Control, WLST, or you can edit the configuration file, irm-config.xml. To use Fusion Middleware Control, expand the navigation tree and click IRM. From the IRM menu, choose Administration, then General Settings. On the General Setting pages set the following:

    • Server URL. The URL value that is sealed into sealed content and used by Oracle IRM Desktop to request rights, keys, and settings. The value is typically the public-facing URL of the server pointing at the load balancer or Oracle HTTP Server. The default value is https://irm.example.com/irm_desktop.

      This is a mandatory setting and must be specified.

      Alternatively, use the setIRMServerURL WLST command:

      wls:/offline> connect('weblogic','welcome1','t3://adminServerHost:adminServerPort')
      wls:/base_domain/serverConfig> 
      setIRMServerURL('https://acme.example.com/irm_desktop')
      

      As another alternative, you can edit the configuration file and update the classificationUrl element of the configuration file:

      <classificationUrl>https://irm.example.com/irm_desktop</classificationUrl>
      
    • Privacy URL. A URL to a page hosting the Oracle IRM usage privacy policy for the installation. There is no default value, so typically you would not need to alter this setting after unpacking a domain. The default behavior is to show the built-in privacy page.

      Alternatively, use the setIRMPrivacyURL WLST command:

      wls:/offline> connect('weblogic','welcome1','t3://adminServerHost:adminServerPort')
      wls:/base_domain/serverConfig> 
      setIRMPrivacyURL('http://example.com/privacy')
      

      As another alternative, you can edit the configuration file and update the privacyUrl element:

      <privacyUrl>http://example.com/privacy</privacyUrl>
      

      This is an optional setting. Absence of the privacyUrl element means that there is no privacy page configured.

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

      Alternatively, use the setIRMStatusPageRedirectTarget WLST command:

      wls:/offline> connect('weblogic','welcome1','t3://adminServerHost:adminServerPort')
      wls:/base_domain/serverConfig> setIRMStatusPageRedirectTarget('http://example.com/status_pages', 'POST')
      

      As another alternative, you can edit the configuration file and update the statusPageRedirectTarget element:

      <statusPageRedirectTarget>
          <uri>http://example.com/status_pages</uri>
          <method>POST</method>
      </statusPageRedirectTarget>
      

      This is an optional setting. Absence of the statusPageRedirectTarget element means that there is no status page redirection configured.

  6. Each Oracle IRM installation requires access to a keystore with installation specific keys. The unpacked domain may have a keystore. If it does, delete this keystore, clear the passwords details, and create a new keystore:

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

      DOMAIN_HOME/config/fmwconfig
      

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

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

      connect('username', 'password', 'localhost:7001')
      deleteCred('IRM', 'keystore:keystore_filename')
      deleteCred('IRM', 'key:irm.jks:oracle.irm.wrap')
      

      For the key, you use the keystore file name stored in the template.

    3. Create a new keystore, as described in "Configuring the Keystore for Oracle IRM" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.

  7. If the production environment is not using the same LDAP store as the test environment, migrate the users from the test environment to the production environment. See "Reassociating the Identity Store with an External LDAP Authentication Provider" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.

Task 4   Move Oracle Universal Content Management to a New Production Environment

To move Oracle Universal Content Management to a new production environment:

  1. Export the OCS database schema from the test environment, using the following command (ORACLE_HOME is the Oracle home for the Oracle Database):

    ORACLE_HOME/bin/expdp \"sys/password as sysdba\" 
           schemas=test_env_schema_name 
           directory=directory dumpfile=ucm.dmp
    

    Make sure that the dumpfile is in a location that can be accessed by the production database.

  2. Import the OCS database schema that you exported from the test environment, using the following commands (ORACLE_HOME is the Oracle home for the Oracle Database):

    ORACLE_HOME/bin/impdp \"sys/password as sysdba\" 
          remap_schema=test_env_schema_name:prod_env_schema_name
          directory=directory dumpfile=ucm.dmp
          TABLE_EXISTS_ACTION=REPLACE
    
  3. For a system that has a full text search solution using external databases, set up a new database to hold the new search collection.

    To set up a Oracle Secure Enterprise Search instance and configure it for Oracle UCM:

    1. Install Oracle Secure Enterprise Search as described in the Oracle Secure Enterprise Search Installation and Upgrade Guide.

    2. Create a new data source to connect to Oracle Secure Enterprise Search. See Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server.

      Oracle recommends that you use the same data source name as in the test environment.

    3. On the Oracle Universal Content Management Post Configuration page, choose External Full Text Search, and enter the name of the data source. See "Configuring Oracle SES and Oracle UCM" in the Oracle Fusion Middleware System Administrator's Guide for Universal Content Management.

  4. Move Oracle UCM data from the test environment to the production environment.

    In this step, you move data from the intradoc, Weblayout, and Vault directories. The location of these directories are set by the intradocDir, WeblayoutDir, and VaultDir configuration parameters in intradoc.cfg. This file is located in:

    DOMAIN_HOME/bin
    
    1. In the test environment, archive the intradoc directory. For example:

      tar -cvzf intradoc.tgz intradoc_dir
      
    2. In the test environment, archive the Weblayout and Vault directories, if necessary. For example:

      tar -cvzf weblayout.tgz Weblayout_dir
      tar -cvzf vault.tgz vault_dir
      
    3. Copy the archive files to the production system.

    4. In the production environment, modify the following file, updating the entries for IntradocDir, WeblayoutDir, and VaultDir:

      DOMAIN_HOME/bin/intradoc.cfg 
      
    5. In the production environment, extract the intradoc directory from the archive file to the location specified by the IntradocDir parameter. For example:

      tar -xvzf intradoc.tgz
      
    6. In the production environment, extract the files from the Weblayout and Vault archive files to the location specified by the WeblayoutDir and VaultDir parameters. For example:

      tar -xvzf weblayout.tgz 
      tar -xvzf vault.tgz
      
  5. On the production system, delete the following file:

    IntradocDir/data/contenttracker/config/sct.cfg
     
    

    The file is regenerated when you restart the server.

  6. Modify the following file, updating the HttpServerAddress to reflect the correct address:

    instance_dir/config/config.cfg
    
  7. Restart the Managed Server.

To use the new production system as a template and replicate it in multiple production systems, you follow the procedures in Task 2, "Move Oracle Universal Content Management to an Existing Production Environment", except that you would also change the parameters IDC_Name, InstanceMenuLabel, InstanceDescription, HttpServerAddress, and AutoNumberPrefix in the following file:

instance_dir/config/config.cfg

You may also need to change the parameters MailServer and SysAdminAddress.

Task 5   Move Oracle Imaging and Process Management to a New Production Environment

Note that no Oracle I/PM data is migrated in this procedure. Data migrated with Oracle UCM will not be accessible from production Oracle I/PM system.

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

To move Oracle I/PM to the new production environment:

  1. Start the Administration Server and the Oracle I/PM Managed Server.

  2. Ensure that the Oracle UCM 11g Managed Server is running, or, if you are using Oracle UCM 10g, that the Oracle UCM 10g services are running.

  3. Configure the security provider.

  4. If necessary, move Oracle I/PM users and groups to the production environment.

    The user who logs in first to an Oracle I/PM Managed Server is provisioned with full security throughout the server. It is easier to reassociate the identity store for Oracle I/PM with an external LDAP authentication provider before the first user logs in, completes the configuration of the Oracle I/PM Managed Server, and connects it to the Oracle UCM repository.

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

    ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port 
      -D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Users,dc=us"
    
  5. Export the system definitions from the test environment.

    Note the following:

    • This procedure does not transfer any documents from the test environment to the production environment. This procedure only moves the structure defined by the applications, inputs, and searches.

    • The documents reside within the supporting Oracle UCM repository. Oracle I/PM does not recognize any documents that were transferred using Oracle UCM test-to-production procedures or database utilities. The documents will not be accessible from Oracle I/PM. Use Oracle I/PM to upload new documents into the Oracle UCM repository.

    1. Log into the test system as administrator to export the definitions, using the following URL:

      http://hostname:16000/imaging
      
    2. Expand Tools, then select Export Definitions.

    3. For Export Comments, enter any comments, then click Next.

    4. Select the applications to export, then click Next.

    5. Select the searches to export. All dependent applications for each search are included in the export. Click Next.

    6. Select the inputs to export. All dependent applications for each input are included in the export. Click Next.

    7. Review your selections for accuracy, then click Next.

      If you need to make any changes, select the appropriate type of definition at the top of the page, such as Applications, and correct the selections. Then, select the Summary at the top of the page.

    8. Select Create Export File.

    9. Depending on your browser, a dialog box is displayed allowing you to open or save the file. The file is saved to the location you specify.

  6. Copy input sample files from the test environment to the production environment. The location of the files is specified in the Oracle I/PM MBean SampleDirectory.

    For information about the Oracle I/PM MBeans, see "Oracle I/PM MBeans" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management. For more information about using Input sample files to create input definitions, see "Creating Input Definitions" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.

  7. Import users and groups into the LDAP identity store on the production environment by importing the ldif file that you exported from the test environment into the production environment, using the ldapaddmt command, as shown in the following example. (ORACLE_HOME is the Oracle home for Identity Management.)

    ORACLE_HOME/bin/ldapaddmt -h production_oid_host
       -p production_oid_port -D "cn=orcladmin"
       -w "production_orcladmin_passwd" -r -f ldif_filename
    
  8. If the test environment is configured for BPEL processing, you must replicate the BPEL credentials in the Credential Store on the production environment:

    1. Log into Fusion Middleware Control, using the following URL:

      http://hostname:admin_port/em
      
    2. From the navigation pane, select your domain.

    3. From the WebLogic Domain menu, choose Security, then Credentials.

      The Credentials page is displayed.

    4. Because this is a new production system, a map does not exist. Click Create Map.

      The Create Map dialog box is displayed.

    5. For Map Name, enter oracle.wsm.security. Then, click OK.

    6. In the Credentials page, click Create Key.

      The Create Key dialog box is displayed.

    7. For Select Map, select the map that you created.

    8. For key, enter a key. (This is the credential alias that will be used in the Workflow connection configuration.)

    9. For Type, choose Password.

    10. For User Name, enter the name of an Administration user.

    11. For Password, enter the password of the Administration user.

    12. Click OK.

  9. On the production environment, configure Oracle Web Services Manager policy stores.

    Oracle Web Services Manager policies are configured using Oracle WebLogic Server deployment plans. If the test environment is configured to use the deployment plans to apply policies to the Web services, you must apply these policies to the production environment. The steps you take depend on how the Oracle I/PM application was deployed:

    • If the Oracle I/PM application was deployed with only the default policies, you do not need to take further action because the default policies were set up by the installation on the production environment.

    • If the Oracle I/PM application was deployed using one of the deployment plans packaged with Oracle I/PM, you must take the following steps so that the production environment has the same deployment plan selected as the test environment:

      1. Assign the correct plan file, overwriting the existing file, using the following commands:

        cd MW_HOME/user_projects/applications/Domain_Name/server/ipm/plan/imaging-ws.war/WEB-INF
        cp policy-saml_token.xml weblogic-webservices-policy.xml
        
      2. Log in to the Oracle WebLogic Server Administration Console, using the following URL:

        http://hostname:admin_port/console
        
      3. In the Domain Structure pane, select Deployments.

        The Summary of Deployments page is displayed.

      4. Select the imaging deployment, and click Update.

      5. For Deployment plan path, click Change Path.

        The Update Application Assistant page is displayed.

      6. For Path, enter the following:

        MW_HOME/user_projects/applications/Domain_Name/server/ipm/Plan.xml
        
      7. Click Next, then Finish.

    • If the Oracle I/PM application was deployed using a custom set of policies, you must move the policies to the production environment, using the following steps:

      1. Copy the Plan. xml file that was created on the test environment, along with its associated directories, to the production environment.

      2. Update the Oracle I/PM application deployment to use this deployment plan. Use the steps b through g but specify the location of the custom Plan.xml file.

  10. Enable SSL, as described in "System Security" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.

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

  12. Configure connections on the production environment. Before you can import the applications into the production environment, you must set up the Oracle I/PM system connection objects that establish links to Oracle UCM repository and Workflow servers in the production environment. If the connections in the production environment are named the same as in the test environment, the imported definitions link correctly without further action.

    If the names are different, you can select the desired connection name using the using the Oracle I/PM import tool.

  13. Modify configuration settings. You use Fusion Middleware Control to modify the system MBean values, which control the execution of Oracle I/PM. If any MBean values need to be changed, follow the procedures in "Configuring the AgentUser and GDFontPath MBeans" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.

  14. If the Work Manager configuration for the Input Agents does not already specify values for the production environment, update the configuration, as described in "Changing Oracle WebLogic Server Work Manager Settings" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.

  15. If the Work Manager configuration for the Workflow Agents does not already specify values for the production environment, update the configuration, as described in "Changing WebLogic Server Work Manager Settings" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.

  16. Note that User preferences are not migrated. Users must reconfigure their preferences on the production Oracle I/PM system.

  17. On the production system, set the Listen address for the Managed Server that contains Oracle Application Extension Framework (AXF):

    1. Log in to the Oracle WebLogic Server Administration Console, using the following URL:

      http://hostname:admin_port/console
      
    2. From Domain Structure, expand Environment, then Servers. Select the Oracle I/PM Managed Server, which is typically IPM_server1.

      The Settings for server_name page is displayed.

    3. If you do not use a clustered configuration or a load balancer, for Listen Address, enter a name that is equivalent to the name on the test environment. That is, enter the fully qualified domain name.

    4. If you use a clustered configuration or a load balancer:

      Check the Cluster MBean. If the FrontendHost and HTTPPort have been specified, on the server_name page, for Frontend Host, enter the new host name. For Frontend HTTP Port and Frontend HTTPs Port, if applicable, enter the port number.

      If they have not been specified, check the Web server MBean. If FrontendHost and HTTPPort have been specified, on the server_name page, for Frontend Host, enter the new host name. For Frontend HTTP Port, enter the port number.

      If the Web Server MBean does not have the FrontendHost and HTTPPort specified, check the Server runtime Mbean. If ListenAddress and ListenPort have been specified, on the server_name page, for Listen Address, enter the Server ListenAddress. For Listen Port, enter the port number of the Server ListenPort.

      If the Server runtime Mbean does not have a Listen address specified, for Listen Port, enter the port number of the Server ListenPort. Then, for Listen Address, use the localhost name.

    5. Restart the Oracle I/PM Managed Server.

  18. Import the system definitions to the production environment.

    1. Log into the production environment system as administrator to import the definitions, using the following URL:

      http://hostname:16000/imaging
      
    2. Expand Tools, then select Import Definitions.

    3. For File Location, click Browse, and browse to the location of the file you exported from the test environment in step 5.

      When you select the file, the File Date, and File Comments fields are populated.

    4. Click Next.

    5. From each table, select the applications, inputs, and searches, to be imported.

      Selecting the Plus sign (+), shows the description for the definition. Selecting the pull down for the repository allows you to place each definition in any of the defined repository connections.

    6. Click Next.

    7. In the validation phase, you can see the status of each definition and you can select Document Security, Storage Policy, Workflow, and Full-Text options. See "Import Definitions: Validate Imports Page" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.

      If any of the definitions are marked by a red X, the definition cannot be imported. Some of the likely causes are:

      • For search and input definitions, a required application was not imported.

      • The security checks failed.

      • The connection specified by the application does not exist.

      • The Workflow validation failed.

    8. Correct any problems. When all the definitions are valid, select Submit.

      If the validation is successful, the changes are committed. If there are errors, the page shows new exceptions. Correct any errors and click Submit.

  19. Move the Oracle Application Extension Framework (AXF) configuration database:

    1. Export the following tables from the test database schema and insert them into the production database schema:

      • AXF_ACTIONS

      • AXF_ACTION_MENU

      • AXF_ACTION_PARAMETERS

      • AXF_COMMANDS

      • AXF_ENUM_ITEMS

      • AXF_ENUM_TYPES

      • AXF_METADATA_ATTRIBUTES

      • AXF_METADATA_BLOCKS

      • AXF_SOLUTIONS

      • AXF_SOLUTION_ATTRIBUTES

      • AXF_SOLUTION_PARAMETERS

      • AXF_XPATH_NAMESPACES

      • AXF_XPATH_ATTRIBUTES

    2. Modify the Workflow Connection information to point the connection to the production Workflow system.

      If you are using a different Workflow Connection name in the production environment,update the PARAMETER_VALUE column. Using the Workflow connection created in step 12, update the PARAMETER_VALUE column for the BPEL_CONNECTION row in the AXF_SOLUTION_ATTRIBUTES table using your preferred SQL utility:

      UPDATE AXF_SOLUTION_ATTRIBUTES SET PARAMETER_VALUE = '<ConnectionName>'
               WHERE PARAMETER_KEY = 'BPEL_CONNECTION'
      
    3. If you have created any SOA Composites for an AXF solution in the test environment, deploy those versions of composites in the production environment, as described in the AXF11g Solution Template Guide.

Task 6   Move Oracle Universal Records Management to a New Production Environment

To move Oracle Universal Records Management to a new production environment:

  1. On the test environment, export the configuration settings, such as retention schedule, security classifications, and triggers, as described in "Exporting an Archive" in Oracle Fusion Middleware Administrator's Guide for Universal Records Management.

  2. Copy the archive to the production environment.

  3. Import the archive to the production environment, as described in "Importing an Archive" in Oracle Fusion Middleware Administrator's Guide for Universal Records Management.

20.11.2 Moving Oracle Enterprise Content Management Suite to an Existing Production Environment

In this scenario, you have installed Oracle Enterprise Content Management Suite components, such as Oracle Information Rights Management, in a test environment and you want to move them to a production environment that already exists.

On the existing production system, you have installed and configured the components. You want to move an application from the test environment to the production Oracle Enterprise Content Management Suite environment.

To move Oracle Enterprise Content Management Suite to an existing production environment, perform the following tasks:

Task 1   Move Oracle Information Rights Management to an Existing Production Environment

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

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

  • Configure SSL in the test deployment because switching from http in the test system to https in the production system would prevent test-sealed content from working in a production system.

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

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

To move a test deployment into a production environment:

  1. If the production database is different from the test database, you should back up the Oracle IRM schema. Restore the backup into the production database.

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

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

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

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

    connect("username", "password", "t3://adminServerHost:adminServerPort")
    createCred("IRM", "keystore:irm.jks", "dummy", "secureproductionpassword")
    createCred("IRM", "key:irm.jks:oracle.irm.wrap", "dummy", "secureproductionpassword")
    

    For more information, see "Setting Passwords for the Keystore" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.

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

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

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

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

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

      DOMAIN_HOME/config/fmwconfig
      
  7. If the production environment is not using the same user store as the test environment, migrate the users from the test environment to the production environment. See "Reassociating the Identity Store with an External LDAP Authentication Provider" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.

Task 2   Move Oracle Universal Content Management to an Existing Production Environment

To move Oracle Universal Content Management to an existing production environment:

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

  2. From Actions, select Create New Template.

  3. For Server Config, select SearchIndexEngineName.

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

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

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

  7. From Action, select Save.

  8. From Action, select Export.

  9. Click Configuration Bundles.

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

  11. If you are using Records Manager for UCM and you want to perform incremental migrations from the test environment to the production environment, export archives from the test environment and then import them into the production environment, as described in "Managing Imports and Exports" in the Oracle Fusion Middleware Administrator's Guide for Universal Records Management.

Task 3   Move Oracle Imaging and Process Management to an Existing Production Environment

To move Oracle Imaging and Process Management from a test environment to an existing production environment, you use the same steps as described in Task 5, "Move Oracle Imaging and Process Management to a New Production Environment". However, note the following about updating definitions on the production environment:

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

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

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

  • You cannot delete definitions through the export and import process. If you delete a search in the test environment, you much manually delete it in the production environment using the Manage Search functions.

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

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

    2. Select Toggle On-Line.

Task 4   Move Oracle Universal Records Management to an Existing Production Environment.

To move Oracle URM to an existing production environment:

  1. On the test environment, export any configuration settings that have changed, as described in "Exporting an Archive" in Oracle Fusion Middleware Administrator's Guide for Universal Records Management.

  2. Copy the archive to the production environment.

  3. Import the archive to the production environment, as described in "Importing an Archive" in Oracle Fusion Middleware Administrator's Guide for Universal Records Management.

20.12 Moving Oracle Data Integrator to a Production Environment

The following describes three scenarios for moving Oracle Data Integrator from a test environment to a production environment: