Skip Headers
Oracle® Fusion Middleware Administrator's Guide
11g Release 1 (11.1.1)

Part Number E10105-08
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

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

See:

Section 20.6 for information about recovering from errors when you use the scripts described in this chapter.

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

Note:

The target environment must have the superuser or administrative user, with the same credentials, as the user at the source environment.

After you complete the movement of the installation, you can modify the user on the target environment.

The general steps are:

  1. If your environment uses a database, create a new database or copy the database from the test environment to the production environment.

    Note that the database in the production environment must be the same type of database as in the test environment. For example, if the database in the test environment is an Oracle Database, the database in the production environment must be an Oracle Database.

  2. Move a copy of the Middleware home from the test environment to the production environment using the copyBinary and pasteBinary commands, as described in Section 20.5.1.

    Note:

    • The production environment must be on the same operating system as the test environment. Also, the operating system architecture must be the same in both environments. For example, both environment must be running 32-bit operating systems or 64-bit operating systems.

    • The target environment must have the superuser or administrative user as the user at the source environment. The user's password can be different; you specify it on the command line when you use the pasteBinary command.

      After you complete the movement of the installation, you can modify the user on the target environment.

  3. Move a copy of the configuration of components, as described in Section 20.5.2 and Section 20.5.3.

    Notes:

    • When you move the configuration of a component, the scripts replicate the topology of the source. For example, if the source domain contains Managed Servers server_1 and server_2 on Host A and Managed Servers server_3 and server_4 on Host B, you must specify a similar relationship between Managed Servers and hosts at the target. (You specify the hosts for each Managed Server in the move plan.)

    • When you move the configuration of components, the script copyConfig handles only global data sources defined in each Oracle WebLogic Server domain. For application-level data sources, you must deploy the ADF application configured with the application-level data sources to a server in the target domain, and manually configure the data sources on the target domain.

  4. If an external LDAP was used in the test environment, move security information, such as users and groups, the identity and policy stores, and credentials. (The default security information is moved when you move the configuration of components.)

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

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

21.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 password for the sys account in the database in the test environment. The following command creates the password file:

    orapwd password=password file=ORACLE_HOME/dbs/orapwproddb
    
  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 the Middleware Homes and Domain Configuration to the New Production Environment

You move all Identity Management Middleware homes to the production environment. To move a copy of the Middleware home and the domain configuration from the test environment to the production environment:

  1. Move a copy of the Middleware home containing the Identity Management components from the test environment to the production environment using the copyBinary and pasteBinary scripts. See Section 20.5.1.

    The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.

  2. Move a copy of the configuration of each domain containing the Identity Management configuration, as described in Section 20.5.2 and Section 20.5.2.1. This step moves the configuration, including the domain, Administration Server, and Managed Servers. Moving the configuration also:

    • Reassociates the security store to an LDAP or database-based store, based on the values provided in move plan.

    • Moves Oracle Platform Security.

    • Moves Oracle Web Services Manager and any policies that are stored in the MDS repository or deployment plans, and any custom policies that are stored in DOMAIN_HOME/lib.

    • Configures data sources.

    • Configures JMS resources.

    • Starts the Administration Server.

Task 3   Move Oracle Internet Directory to the New Production Environment

To move Oracle Internet Directory to a new production environment:

  1. Move the Oracle Internet Directory configuration, as described in Section 20.5.3.2.

  2. If you have configured Oracle Internet Directory replication in the test environment, you must reconfigure it again in the production environment after moving. The replication configuration is not moved from the test to the production environment. See "Setting Up Replication" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Task 4   Move Oracle Virtual Directory to a New Production Environment

To move Oracle Virtual Directory to a new production environment:

  1. Move the Oracle Virtual Directory configuration, as described in Section 20.5.3.3.

Task 5   Move Oracle Directory Integration Platform to a New Production Environment

To move Oracle Directory Integration Platform to a new production system:

  1. Move Oracle Internet Directory, as described in Task 3, "Move Oracle Internet Directory to the New Production Environment".

    Oracle Directory Integration Platform profiles reside in Oracle Internet Directory. If you have correctly moved Oracle Internet Directory to the production system, the profiles are carried over to the production system.

  2. If you configured SSL on the test environment, that configuration is not moved to the production environment. You must configure SSL on the production environment. See Section 6.5.4.3.

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

See Also:

Task 7   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 10.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 are to be stored temporarily before they are packaged into a zip file.

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

    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\server\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\server\bin\importMetadata.bat
      

      Edit the script to specify the following values:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  13. 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 11   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. Use the Oracle Adaptive Access Manager Administration console to export the configuration to a zip file. See "System Snapshot Import/Export" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager for more information.

    You can export the following types of items:

    • Policies

    • Rule conditions

    • Patterns

    • Configurable actions

    • Transaction definitions

    • Entities

    • KBA questions

    • KBA validations

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

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

  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 Administration 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. Log in to OAAM Admin console, as described in "OAAM Admin Console and Controls" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.

    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 12   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 Application Security Guide:

Task 13   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. If the policy store on the test environment is not file-based, migrate the policy store, using the WLST command migrateSecurityStore, as described in "Migrating Policies with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.

  2. If the credential store on the test environment is not file-based, migrate the credential store, using the WLST command migrateSecurityStore, as described in "Migrating Credentials with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.

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

Task 14   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 13, "Move Oracle Platform Security to a New Production Environment".

    Oracle Web Services Manager depends on Oracle Platform Security and Oracle Fusion Middleware Audit Framework. Oracle Web Services Manager uses Oracle Platform Security for the following:

    • Credential store: Oracle Web Services Manager stores client policy user name and password credentials and keystore passwords in the credential store.

    • Policy store: Oracle Web Services Manager permission-based authorization policies use Oracle Platform Security policy store to look up permissions.

    • Login modules: Oracle Web Services Manager uses Oracle Platform Security login modules for all of its authentication.

    • Keystore configuration. However, the keystores in the test and production environments are typically different.

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

  3. Move policies that are not stored in the MDS Repository:

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

See Also:

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

21.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 the test Oracle Internet Directory instance by running the following command from the test Oracle home:

      ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port 
        -D "cn=orcladmin" -w "test_orcladmin_passwd" 
        -L -b "cn=users, default_subscriber"
        -s sub "objectclass=*" * orclguid > users.ldif
      
    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. If you use Oracle Forms Services or Oracle Reports, move Resource Access Descriptors (RAD). This procedure assumes that you have moved the Default Subscriber from the test environment to the production environment, as described in Step 1. It also assumes that the orclGUIDs of the users at the test Oracle Internet Directory are identical to those in the production Oracle Internet Directory.

    Take the following steps:

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

    2. Retrieve the RADs from the test Oracle Internet Directory instance using the following command:

      ORACLE_HOME/bin/ldapsearch -h test_oid_host -w test_orcladmin_passwd
         -p test_oid_port -D "cn=orcladmin"
         -L -b "cn=Extended Properties,cn=OracleContext, default_subscriber"
         -s sub "objectclass=*" * orclguid > rads.ldif
      
    3. Move the RADs into the production Oracle Internet Directory instance using the following command:

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

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

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

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 WLST 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 11, "Move Oracle Adaptive Access Manager to a New Production Environment" in Section 21.2.1.

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

  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 21.2.1, Task 7, "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 21.2.1, Task 8, "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. If the policy store on the test environment is not file-based, migrate the policy store, using the WLST command migrateSecurityStore, as described in "Migrating Policies with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.

  2. If the credential store on the test environment is not file-based, migrate the credential store, using the WLST command migrateSecurityStore, as described in "Migrating Credentials with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.

  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 Application 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 Application 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 file name 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.

21.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 performed the following in a test environment:

Note:

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

21.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 21.3 and you want to move it to a production environment, which does not yet exist.

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

Task 1   Move the Middleware Home and Oracle SOA Suite and Perform the Initial Configuration

See Also:

Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for information about setting up an enterprise deployment for Oracle SOA Suite

To move the Middleware home and perform the initial configuration on the production system:

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

  2. Move a copy of the Middleware home to the production environment using the copyBinary and pasteBinary scripts, as described in Section 20.5.1.

    The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.

  3. Move a copy of the domain containing the Oracle SOA Suite configuration, as described in Section 20.5.2 and Section 20.5.2.1. This step moves the configuration, including the domain, Administration Server, and Managed Servers. Moving the configuration also:

    • Moves SOA composite applications.

    • Moves Oracle Human Workflow attribute labels, flex field mappings, approval groups and standard views.

    • Moves Oracle B2B.

    • Reassociates the security store to an LDAP or database-based store, based on the values provided in move plan.

    • Moves Oracle Platform Security.

    • Moves Oracle Web Services Manager, any policies that are stored in the MDS repository or deployment plans, and any custom policies that are stored in DOMAIN_HOME/lib.

    • Deploys applications in the production environment.

    • Configures adapters, such as the database adapters, AQ adapters, JMS adapters. Note, however, that you must edit the deployment plan of any adapters before you use the pasteConfig script.

    • Configures data sources.

    • Configures JMS resources.

    • Starts the Administration Server.

  4. Install and configure Identity Management components, such as Oracle Internet Directory.

    For information about installing Identity Management components, see the Oracle Fusion Middleware Installation Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

    For information about configuring users and groups in Oracle Internet Directory, see "Configuring Users and Groups in the Oracle Internet Directory and Oracle Virtual Directory Authentication Providers" in the Oracle Fusion Middleware Securing Oracle WebLogic Server.

  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 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. If necessary, move users and groups to the production environment. For example, if you are using the Oracle Business Activity Monitoring or Human Workflow demo, move those users:

    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
      
  2. Export any JKS certificates for B2B endpoints from the test environment to the production environment. Then, import them to the production environment. For information about exporting and importing JKS certificates, see Section 8.3.3.

  3. If the security policies are stored in an external LDAP or database-based store, import the security policies, for example those that are related to the Human Workflow application roles, from the test environment to the production environment, as described in Task 7, "Move Oracle Platform Security to an Existing Production Environment" in Section 21.2.2.

  4. If the credential policies are stored in an external LDAP or database-based store, import the credential store information from the test environment to the production environment, as described in Task 7, "Move Oracle Platform Security to an Existing Production Environment" in Section 21.2.2.

Task 3   Move Human Workflow to the New Production Environment

When you moved a copy of the domain from the test environment to the production environment, the scripts moved the following Human Workflow entities:

  • Attribute labels

  • Flex field mappings

  • Approval groups

  • Standard views

The scripts do not move the following:

  • User views

  • Rules

To move Human Workflow user views and roles to a new production environment:

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

    The migration.properties file contains the following input parameters:

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

    You use the following script:

    ORACLE_HOME/bin/ant-t2p-worklist.xml
    

    The command has the following format:

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

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

    Take the following steps:

    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, user views, vacation rules) from the test environment. You can create the migration.properties file in any location. Note the following:

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

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

      For example, to export all rules for a given user, the migration.properties file would contain the following:

      operationType = EXPORT
      objectType = RULE
      name = ALL
      user = username
      group =
      grantPermission = true
      migrateAttributeLabel = false
      override = true
      skip = true
      migrateToActiveVersion = false 
      

      Note that the parameter group is left blank when you export rules for a given user.

      To export all rules for a given group, the migration.properties file would contain the following:

      operationType = EXPORT
      objectType = RULE
      name = ALL
      user =
      group = LoanAgentGroup
      grantPermission = true
      migrateAttributeLabel = false
      override = true
      skip = true
      migrateToActiveVersion = false
      

      Note that the parameter user is left blank when you export rules for a given group.

    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.

      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 10.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 4   Move Oracle Business Activity Monitoring Data to the New Production Environment

To move Oracle Business Activity Monitoring to the new production environment:

  1. On the test environment, export the ORACLEBAM database schema, using the following commands (ORACLE_HOME is the Oracle home for the Oracle Database):

    ORACLE_HOME/bin/sqlplus "sys/password as sysdba"
    create or replace directory directory as 'path';
    grant read,write on DIRECTORY directory to oraclebam;
    exit;
    
    ORACLE_HOME/bin/expdp userid=oraclebam/bam@connect_id
           directory=directory dumpfile=orabam.dmp
           schemas=oraclebam logfile=oraclebam_date.log
    

    See Also:

    "Overview of Oracle Data Pump" and other chapters on Oracle Data Pump in Oracle Database Utilities, which is available at:
    http://www.oracle.com/technology/documentation/database.html
    

    The Oracle BAM objects, such as reports, alerts, and data definitions from the test environment are exported.

  2. Install and configure Oracle Internet Directory as the LDAP provider for BAM applications on the production environment, as described in Task 1, if you have not already done so.

  3. Set up the Oracle Internet Directory Authenticator, if it was not set up in the test environment. (If it was set up in the test environment, moving the configuration moves the configuration to the production environment.)

    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.

  4. Restart the Administration Server and the Managed Server.

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

      • From the navigation pane, right-click the domain that contains Oracle Business Activity Monitoring and choose Security, then Security Provider Configuration.

      • Follow the steps in "Reassociating Domain Stores with Fusion Middleware Control" in the Oracle Fusion Middleware Application Security Guide.

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

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

    5. Restart the Oracle Business Activity Monitoring Managed Server.

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

Note that the migration tool does not move any user-specific configuration because users in the test and production environments would not be same.

You use the following script:

ORACLE_HOME/bin/ant-t2p-workspace.xml

The command has the following format:

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

For Organizations, the following objects are moved to the production environment: Organizational Units, Roles, Calendars, Organization Role, and Extended User Properties.

For Dashboards, data with the BAM_WIDGET data type in the BPMUserApplicationData table is moved to the production environment.

Take the following steps:

  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: The SOA server URL

      • 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: The SOA server URL

      • adminUserLogin

      • adminUserPassword

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

      • objectDetails: Update the login and password elements.

      • userApplicationData: Update the ownerID element.

    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: The SOA server URL

      • 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: The SOA server URL

      • adminUserLogin

      • adminUserPassword

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

      • objectDetails: Update the login and password elements.

      • userApplicationData: Update the ownerID element.

    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
      
Task 6   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 command to download the User Messaging preferences from the backend database to the specified .xml file:

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

      Note:

      In this example, 8001 is the Managed Server port on which UMS is running. Replace it with the appropriate value.
    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 reconfigured it to use the same set of information.
    5. Test the UMS drivers for send and receive capabilities for supported drivers.

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

Task 7   Enable SSL and Create Custom Keystores

During the pasteConfig operation, SSL is disabled. In addition, custom keystores are not created in the production environment. Take the following steps:

  1. Enable SSL, as described in Section 6.5.

  2. Create custom keystores, as described in Section 8.3.3.1.

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

To move Oracle SOA Suite to an existing production system:

Task 1   Move Oracle SOA Suite Changes

Move any changes that you have made to Oracle SOA Suite:

  1. If you have added users and groups in the test environment or modified security policies or credentials, follow the steps in Task 2 in Section 21.3.1 to move them to the production environment.

  2. If you have modified EJBs or Plain Old Java Objects (POJOs) in the test environment that support the composite references, move them to the production environment:

    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.

    3. If you have made any changes to Human Workflow in the test environment, move them to the production environment. See "Moving Human Workflow Data from a Test to a Production Environment" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

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

Task 2   Move Oracle B2B Changes

If you have made any changes to Oracle B2B in the test environment, move those changes to the production environment.

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

  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 3   Move Oracle Business Process Management Changes

If you have made any changes to Oracle Business Process Management in the test environment, move them to the production environment.

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

You use the following script:

ORACLE_HOME/bin/ant-t2p-workspace.xml

The command has the following format:

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

Take the following steps:

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

    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: The SOA server URL

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

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

      • serverURL: The SOA server URL

      • adminUserLogin

      • adminUserPassword

      • objectDetails: Update the login and password elements.

      • userApplicationData: Update the ownerID element.

    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: The SOA server URL

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

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

      • serverURL: The SOA server URL

      • adminUserLogin

      • adminUserPassword

      • objectDetails: Update the login and password elements.

      • userApplicationData: Update the ownerID element.

    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
      
Task 4   Move BAM Data

Move any BAM data that has changed:

  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"
    
  3. Import BAM data and artifacts into 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 Step 2 and Step 3 in Task 4, "Move Oracle Business Activity Monitoring Data to the New Production Environment".

    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
      
  4. Start the BAM server.

Task 5   Move Oracle User Messaging Service Data

Move Oracle User Messaging Service data:

  1. Configure the required UMS drivers in the production environment.

    Note:

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

    • Use the WLST command deployUserMessagingDriver to deploy multiple drivers similar to the test environment.

      Note:

      To see different options for deploying additional drivers, 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
      
  3. Test the UMS drivers for send and receive capabilities for supported drivers.

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

21.4 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 performed the following in a test environment:

21.4.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 21.4 and you want to move it to a production environment, which does not yet exist. You move WebCenter Spaces applications and custom WebCenter Framework applications.

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

Task 1   Install and Configure Oracle WebCenter in the Production Environment

Install and configure Oracle WebCenter in the production environment:

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

  2. Move a copy of the Middleware home to the production environment, as described in Section 20.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.

  3. Because Oracle Universal Content Management requires a Web server, move the Oracle HTTP Server, as described in Section 21.5.1.1.

  4. Move copy of the domain containing the Oracle WebCenter configuration, as described in Section 20.5.2. This step moves the configuration, including the domain, Administration Server, and Managed Servers. In addition, it:

    • Associates WebCenter Spaces with an external identity store.

    • For WebCenter Spaces and WebCenter Framework, creates authenticators for Identity Management in Oracle WebLogic Server.

    • For WebCenter Spaces and WebCenter Framework, reassociates the policy and credential store.

    • For WebCenter Spaces, moves application producer data.

    • For WebCenter Spaces, moves portlet customization, personalizations, and metadata from the test environment to the production environment.

    • Moves the data for the policy and credential store from the test environment to the production environment.

    • Moves the custom Oracle WebCenter Framework application metadata from the test environment to the production environment.

    • Starts the Administration Server.

Task 2   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. If necessary, export the required data for WebCenter Spaces applications, including the LDAP identity store, the Content Server, and the Discussion Forum.

    Typically, the production environment LDAP identity store may already be populated with users and groups. Take the following steps only if you need to export users, groups, and passwords from the test environment.

    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
      

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

  3. Export Portlet customization, personalizations, and metadata from the test environment, using the following command:

    exportPortletClientMetadata(appName='app_name', fileName='filename', exportPersonalizations=1)
    

    For detailed syntax, see "exportPortletClientMetadata" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

  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 3   Export Custom WebCenter Framework Applications from the Test Environment

To export custom WebCenter Framework applications from the test environment:

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

    exportPortletClientMetadata(appName='app_name',fileName='filename', exportPersonalizations=1)
    

    For detailed syntax, see "exportPortletClientMetadata" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

  2. Export the WebCenter Framework application data from the test database, using the following commands (ORACLE_HOME is the Oracle home for the Oracle Database):

    ORACLE_HOME/bin/sqlplus "sys/password as sysdba"
    create or replace directory directory as 'path';
    grant read,write on DIRECTORY directory to user;
    exit;
    
    ORACLE_HOME/bin/expdp "sys/password@connect_id as sysdba"
       schemas=prefix_WEBCENTER directory=directory dumpfile=filename
    

    For information about the CREATE OR REPLACE DIRECTORY command, see "CREATE DIRECTORY" in the Oracle Database SQL Language Reference.

    For information about the expdp command, refer to the chapters on Oracle Data Pump in Oracle Database Utilities, which is available at:

    http://www.oracle.com/technology/documentation/database.html
    
  3. 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
    
  4. 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
    
  5. Migrate the external LDAP-based policy store, using the WLST command migrateSecurityStore, as described in "Migrating Policies with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.

  6. Migrate the external LDAP-based credential store, using the WLST command migrateSecurityStore, as described in "Migrating Credentials with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.

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. If necessary, import users, groups, and passwords by importing the ldif file that you exported from the test environment in Task 2 into the production environment.

    Typically, the production environment LDAP identity store may already be populated with users and groups. Use the following command only if you need to export users, groups, and passwords from the test environment and want to import them into the production environment. (ORACLE_HOME is the Oracle home for Identity Management.)

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

    Refer to "Exporting and Importing Custom WebCenter Applications for Data Migration" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter for more information.

  2. Import Content Server:

    1. Import the Oracle Content Server data to the production database, using the file you exported in Task 2. Execute the following commands (ORACLE_HOME is the Oracle home for the Oracle Database):

      ORACLE_HOME/bin/sqlplus "sys/password as sysdba"
      create or replace directory directory as 'path';
      grant read,write on DIRECTORY directory to user;
      exit;
      
      ORACLE_HOME/bin/impdp "sys/password@connect_id as sysdba"
         remap_schema=testprefix_OCSERVER:prod_prefix_OCSERVER 
         DIRECTORY=directory dumpfile=filename
         TABLE_EXISTS_ACTION=REPLACE
      
    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 2. (ORACLE_HOME is the Oracle home for the production database.)

      ORACLE_HOME/bin/imp "sys/password@connect_id as sysdba"
         FROMUSER=testprefix_DISCUSSIONS TOUSER=prod_prefix_DISCUSSIONS
         FILE=filename statistics=none
      
  4. 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.

  5. Import Portlet customization, personalizations, and metadata to the production environment, using the following command:

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

    For detailed syntax, see "importPortletClientMetadata" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

Note:

If you are using the embedded Oracle WebLogic Server LDAP identity store, see "Managing Security" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

Although secure, the embedded LDAP identity store is not a production-class store and should be replaced with an external LDAP-based identity store, such as Oracle Internet Directory, for enterprise production environments.

See Also:

"Exporting and Importing WebCenter Portal Applications for Data Migration" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter for more information
Task 5   Import Custom WebCenter Framework Applications to the Production Environment

To import custom WebCenter Framework applications to the production environment:

  1. Import Portlet customizations and metadata from file you exported in Task 3 to the production environment, using the following WLST command:

    importPortletClientMetadata(appName='app_name',fileName='filename')
    
  2. 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
    
  3. Import Content Server, if you have not already done so in Task 4, Step 2.

  4. Import the Discussion Forum, if you have not already done so in Task 4, Step 3.

  5. If you have not already done so, import the LDAP identity, policy, and credential stores. Import the ldif file that you exported from the test environment in Task 2 into the production environment, using the ldapaddmt command, as shown in the following example. (ORACLE_HOME is the Oracle home for Identity Management.)

    ORACLE_HOME/bin/ldapaddmt -h production_oid_host
       -p production_oid_port -D "cn=orcladmin"
       -w production_orcladmin_passwd -r -f ldif_filename
    
  6. Migrate the external LDAP-based policy store, using the WLST command migrateSecurityStore, as described in "Migrating Policies with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.

  7. Migrate the external LDAP-based credential store, using the WLST command migrateSecurityStore, as described in "Migrating Credentials with the Command migrateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.

Task 6   Enable SSL and Create Custom Keystores

During the pasteConfig operation, SSL is disabled. In addition, custom keystores are not created in the production environment. Take the following steps:

  1. Enable SSL, as described in Section 6.5.

  2. Create custom keystores, as described in Section 8.3.3.1.

21.4.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 Oracle WebCenter Spaces Data from the Test Environment

To export Oracle WebCenter Spaces data from the test environment:

  1. Export Oracle WebCenter Spaces data from Discussion Forum, using the Oracle Database export utility:

    ORACLE_HOME/bin/export "sys/password@connect_id as sysdba"
     $discussions_schema/$discussions_password file=discussions_forumid.dmp
     log=jive_forumid.log
      TABLES=jiveforum,jiveThread,jivemessage,jiveForumProp,jiveQuestion,jiveAnswer,
    jiveGateway 
     rows=y STATISTICS=None QUERY=\"WHERE forumid \= $forumid\"
    
  2. Export the Oracle WebCenter Spaces data from Wiki, using the owc_wiki_export.sql script. The script is located in the following directory:

    ORACLE_HOME/wikiserver/owc-wiki/WEB-INF/classes
    

    Use the following commands:

    ORACLE_HOME/bin/sqlplus "sys/password as sysdba"
    create or replace directory WC_PUMP_DIR as 'path';
    grant read,write on DIRECTORY WC_PUMP_DIR to user;
    @owc_wiki_export.sql
    
  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 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. 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.

21.5 Moving the Web Tier to a Production Environment

In this scenario, you have installed Oracle HTTP Server and Oracle Web Cache in a test environment and you want to move them to a production environment.

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

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

21.5.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   Move the Oracle HTTP Server and Oracle Instances

Note that if Oracle HTTP Server is used by WebGate, you must first move Oracle Access Manager to the production environment, as described in Section 21.2.1, Task 9 or Task 10, depending on your version of Oracle Access Manager.

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

  1. Move a copy of the Middleware home containing Oracle HTTP Server.to the production environment, as described in Section 20.5.1. The Oracle homes in the Middleware home are also moved.

  2. Move the Oracle HTTP Server configuration, as described in Section 20.5.3.1. This step moves the configuration, including the Oracle instances. In addition, it:

    • Updates the Listen address and the name of the virtual host.

    • Configures SSL, if it was configured in the test environment.

    • Updates the httpd.conf file with new values for the environment and topology directives, such as host name, IP address.

    • Updates the WebLogicHost, WebLogicPort, or WebLogicCluster directives in the mod_wl_ohs.conf file with the host name, IP address, and port number for the production environment.

    • Configures SSL for mod_wl_ohs, if SSL is configured for mod_wl_ohs.

    • Configures mod_osso, if it was configured in the test environment.

    • Configures PL/SQL, if it was configured in the test environment.

    • Configures mod_osso, if it was configured in the test environment.

    • Updates audit.config.xml, if any changes were made to it in the test environment.

    • Updates component-log.xml, if any changes were made to it in the test environment.

    • Configures WebGate if you are using Oracle Access Manager.

Task 2   Start the Processes

Start the processes in the Oracle instance:

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

21.5.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, move the binary files and create the Oracle instances and Oracle Web Cache instances:

  1. Move a copy of the Middleware home containing Oracle Web Cache to the production environment, as described in Section 20.5.1. The Oracle homes in the Middleware home are also moved.

  2. Create the Oracle instances and the Oracle Web Cache instances.

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

    1. Run the following script:

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

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

    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 the PASSWORDHASH attribute of the <USER TYPE="INVALIDATION"> element from the webcache.xml file for the production environment Web Cache instance and replace the current value of the corresponding PASSWORDHASH attribute in this temporary webcache.xml.

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

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

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

      • Update the NAME, ORACLE_HOME and HOSTNAME attributes.

      • Search for and replace the Oracle instance path.

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

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

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

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

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

  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 the following file from the test environment to the corresponding production environment.

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

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

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

21.5.2.1 Moving Oracle HTTP Server to an Existing Production Environment

To move Oracle HTTP Server to an existing production environment, you update the configuration:

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

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

21.6 Moving Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle BI Discoverer Components to a 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 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:

21.6.1 Moving Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle Business Intelligence Discoverer 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. Move a copy of the Middleware home, as described in Section 20.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.

  2. 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 stop the Managed Servers in the production environment, using the following commands:

    ORACLE_INSTANCE/bin/opmnctl stopall
    DOMAIN_NAME/bin/stopManagedWebLogic.sh
                managed_server_name admin_url username password 
    
  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 3, "Move Oracle Internet Directory to the New Production Environment" in Section 21.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 Java EE application .ear file, such as overriding the default Forms servlet access URL, custom deploy the Forms Java EE application .ear file and create servlet aliases similar to test environment in the Forms Java EE application web.xml file.

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:

    • Copy any fonts used in the test environment from the directory specified by environment variable REPORTS_FONT_DIRECTORY to production environment. By default, they are in ORACLE_INSTANCE/reports/fonts.

    • Move the Common UNIX Printing System (CUPS) printing configuration to the production environment, if applicable.

      For more information about using CUPS with Oracle Reports, see "Enhanced Printing on Linux Using CUPS" in the Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services.

  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 3, "Move Oracle Internet Directory to the 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 Application 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 Application 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 modified the default user preferences, copy the following files from the test environment to the production environment:

    ORACLE_INSTANCE/config/PreferenceServer/disco-comp-name/.reg_key.dc
    ORACLE_INSTANCE/config/PreferenceServer/disco-comp-name/pref.txt
    ORACLE_INSTANCE/config/PreferenceServer/disco-comp-name/defaults.txt
    
  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.

21.6.2 Moving Oracle Portal, Oracle Forms Services, Oracle Reports, and Oracle Business Intelligence Discoverer 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 21.6.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 21.6.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.

21.7 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 life cycle for the Oracle Business Intelligence repository, including test to production considerations for the repository.

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

If you are applying patches to an existing production environment, the steps you take depend on how many patches you need to apply. If there are few patches, you use the steps in Section 21.7.2, which apply the patches to the master host and all cluster hosts in the environment. If there are many patches to apply, consider using the steps in Section 21.7.3, which apply the patches to one host and use different means to propagate that to the other hosts, depending on whether or not new hardware is available.

21.7.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 that you want to move them to a new production environment. The steps for moving to a new production environment are identical to the migration process.

To move Oracle Business Intelligence components to a new production environment, perform the following tasks:

Task 1   Patch and Move the Test Environment
  1. Patch the test environment, and test the environment until it is ready.

    For information, see Oracle Fusion Middleware Patching Guide.

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

  3. Copy the Middleware home containing the Oracle BI EE components from the test environment using the copyBinary script, as described in Section 20.3.1.

Task 2   Patch-Merge the Repository File

In the test environment, use the Administration Tool and the Oracle BI Server XML API to perform a patch merge of the test repository file (.rpd) with the production file.

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

Task 3   Extract the Archive into the New Production Environment
  1. Copy the archive file (created in Task 1, "Patch and Move 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 that JDK 1.6.4 or later or JRockit (which is installed with the Oracle Business Intelligence installer) is installed in the production environment.

  4. Use the pasteBinary script to recreate the Middleware home in the new production environment, as described in Section 20.3.1.

Task 4   Create a BI Domain in the New Production Environment

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

Task 5   Configure Security in the New Production Environment

Configure security if you use something other than the default Oracle WebLogic Server LDAP. For information, see Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.

For information about migrating security data (for example, users, groups, policies, and roles), see the appropriate documentation for your authentication provider. The following list provides sources for various components:

Task 6   Move the Repository File and Oracle BI Presentation Catalog from the Test Environment to the New Production Environment
  1. Copy the repository file (.rpd) to the production environment.

  2. Zip the entire Oracle BI Presentation Catalog in the test environment (using zip).

  3. Unzip the catalog in the new production environment.

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

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

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

Task 7   Deploy the Test Repository File and Oracle BI Presentation Catalog in the New Production Environment
  1. Use Fusion Middleware Control in the new production environment to upload the repository file (.rpd).

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

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

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

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

Task 8   Copy and Scale Out to New Cluster Hosts in the Production Environment
  1. Copy the archive file (created in Task 1, "Patch and Move 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 script to copy the Middleware home to the new cluster host, as described in Section 20.3.1.

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

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

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

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

Task 9   (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 that contain the GUIDs should be fan-out replicas in both the test and the production environments. Possible scenarios for refreshing are described in the following list:

  • Oracle Business Intelligence test servers and production servers are both configured against the corporate LDAP directory.

    There is no need to refresh LDAP GUIDs.

  • Oracle Business Intelligence test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is a fan-out replica of the corporate LDAP directory.

    There is no need to refresh LDAP GUIDs.

  • Oracle Business Intelligence test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is not a fan-out copy of the corporate LDAP directory.

    A refresh of the LDAP GUIDs is needed. For information, see Section 21.7.4.

Task 10   Enable New Agents and Oracle BI Publisher Scheduled Jobs

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

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

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

Task 11   Update Links to External Systems

Ensure that you move the static content that relates to external systems to the production environment, including the following files: JPG files in dashboards, Oracle Web Services Manager policy files, Action Framework files, and other policy files that specify how to communicate with external systems.

For information on configuring for different types of actions, see "Configuring the Action Framework" in Oracle Fusion Middleware Integrator's Guide for Oracle Business Intelligence Enterprise Edition.

Task 12   (Optional) Move Oracle Business Intelligence Related Applications

Move Oracle Business Intelligence related applications (such as Oracle BI for Microsoft Office) to the new production environment. For information, see the appropriate sections for these applications (where available).

Task 13   Validate the Production System

Validate that the production system accurately represents the test system.

21.7.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. (See Section 21.7.3 if you have many patches to apply.

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

To move Oracle Business Intelligence components to an existing production environment when there are few patches to apply, perform the following tasks:

Task 1   Patch the Test and Existing Production Environments

A patch applies a collection of bug fixes to an existing 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-Oracle Business Intelligence patches and one-off patches.

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

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

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

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

  2. Use Fusion Middleware Control in the production environment to upload the RPD file to use.

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

  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 must be changed to the production environment connection settings.

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

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

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 that you want from the test catalog into the production catalog.

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

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

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

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

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 that contain the GUIDs should be fan-out replicas in both the test and the production environments. Possible scenarios for refreshing are described in the following list:

  • Oracle Business Intelligence test servers and production servers are both configured against the corporate LDAP directory.

    There is no need to refresh LDAP GUIDs.

  • Oracle Business Intelligence test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is a fan-out replica of the corporate LDAP directory.

    There is no need to refresh LDAP GUIDs.

  • Oracle Business Intelligence test servers are configured against a test LDAP and the production servers against the corporate LDAP, but the test LDAP is not a fan-out copy of the corporate LDAP directory.

    A refresh of the LDAP GUIDs is needed. For information, see Section 21.7.4.

Task 5   Enable New Agents and Oracle BI Publisher Scheduled Jobs

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

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

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

Task 6   Update Links to External Systems

Ensure that you move the static content that relates to external systems to the production environment, including the following files: JPG files in dashboards, Oracle Web Services Manager policy files, Action Framework files, and other policy files that specify how to communicate with external systems.

For information on configuring for different types of actions, see "Configuring the Action Framework" in Oracle Fusion Middleware Integrator's Guide for Oracle Business Intelligence Enterprise Edition.

Task 7   (Optional) Move Oracle Business Intelligence Related Applications

Move Oracle Business Intelligence related applications (such as Oracle BI for Microsoft Office) to the existing production environment. For information, see the appropriate sections for these applications (where available).

Task 8   Validate the Production System

Validate that the production system accurately represents the test system.

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

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

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

21.7.3.1 Moving to an Existing Production Environment When New Hardware Is Available

Perform the following tasks to move Oracle Business Intelligence components to an existing production environment when there are many patches to apply and new hardware is available:

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

Complete the steps in Section 21.7.1 for moving to a new production environment.

These steps include merging the new test RPD file and catalog with those in the existing production environment. Ideally you merge once and resolve the issues while users continue using the existing environment. When the files are correct, you lock the production environment and repeat the merge to access the latest changes.

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

Use a load balancer such as Oracle Web Cache to redirect users from a standard URL to the new production environment.

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

Shut down the existing environment and deinstall all software. When needed, you can apply the next patchset to this host, and the sequence can start all over again.

21.7.3.2 Moving to an Existing Production Environment When New Hardware Is Not Available

Perform the following tasks to move Oracle Business Intelligence components to an existing production environment when there are many patches to apply and new hardware is not available:

Task 1   Scale the Production Environment Back to One Host

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

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

Task 2   Patch the Host in the Production Environment

Patch the host in the production environment. Doing so imposes less downtime on users than having to patch multiple cluster hosts.

For information, see the Oracle Fusion Middleware Patching Guide.

Task 3   Remove the Existing Software on the Cluster Hosts

Deinstall all the Oracle Business Intelligence software on the cluster hosts. For information, see the Oracle Fusion Middleware Installation Guide for Oracle Business Intelligence.

Task 4   Move the Production Environment and Then Copy to the Cluster Hosts

Complete the tasks beginning with Task 8, "Copy and Scale Out to New Cluster Hosts in the Production Environment" in Section 21.7.1.

21.7.4 Refreshing the User GUIDs

After changing the directory server that is used as the data source for the authentication provider, it is best practice to update the user GUIDs. If the same user name exists in both directory servers (original and new), then the original user GUID might conflict with the user GUID that is contained in new directory server. A refresh forces the system to reference the user GUID that is contained in the new directory server. Authentication errors might result if the GUIDs are not refreshed and the system detects a mismatch for the user GUID.

The GUIDs that are stored in the Oracle BI Presentation Catalog or in the RPD file can be resynchronized and refreshed as described in the following procedure. Before you begin this procedure, ensure that you are familiar with the information in "Manually Updating Oracle Business Intelligence Configuration Settings Not Normally Managed by Fusion Middleware Control" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

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

Note:

Refreshing the GUIDs requires that you stop and restart the system components from the command line and not Fusion Middleware Control. This includes the Administration Server and Managed Servers. After the Administration Server is stopped, you cannot start it from Fusion Middleware Control because it is not available during this time.

To refresh the user GUIDs:

  1. Open the NQSConfig.INI file for editing. For information, see "Where are Configuration Files Located?" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

  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 Presentation Services to refresh GUIDs on restart. Edit the file to add the last line in the following instruction.

    <ps:Catalog xmlns:ps="oracle.bi.presentation.services/config/v1.1">
    <ps:UpgradeAndExit>false</ps:UpgradeAndExit>
    <ps:UpdateAccountGUIDs>UpdateAndExit</ps:UpdateAccountGUIDs>
    
  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: Presentation Services, Oracle BI Server, Oracle BI Scheduler, Oracle BI Cluster Controller, and Oracle BI JavaHost.

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

  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 last line added to the instanceconfig.xml file (that instructs Presentation Services to refresh GUIDs on restart, as specified in Step 3).

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

  8. Ensure that Oracle WebLogic Server and the system components are also running. If they are not running, then restart them.

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

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

21.8.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   Move the Middleware Home and Perform the Initial Configuration

To move the Middleware home and Oracle RTD software and perform the initial configuration:

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

  2. Move a copy of the Middleware home, as described in Section 20.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.

    If your environment includes Oracle BI EE and you have already moved Oracle BI EE to a new production environment, as described in Section 21.7.1, you do not need to take this step because the binary files for Oracle RTD were moved as well those for Oracle BI EE.

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

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

  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 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 the 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 Oracle RTD Inline Services

Move Oracle RTD Inline Services that exist on the test environment to the production environment:

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

    • Command Line Deployment: For more information, see the chapter "Command Line Deployment of Inline Services" in Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

    • Decision Studio Deployment: For information about Oracle RTD deployment in Decision Studio, see the chapter "Deploying, Testing, and Debugging Inline Services" in Oracle Fusion Middleware Platform Developer's Guide for Oracle Real-Time Decisions.

      Note:

      Prior to moving an Inline Service, if changes have been made to the Inline Service used by the Oracle RTD server, for example, via the Decision Center, you should first download the latest Inline Service version to Decision Studio before redeploying to the production environment.
  2. When moving Inline Services from one environment to another, note the following areas that may also need editing within the Inline Service:

    • Calls to third party APIs and third party JAR files

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

    • Calls to third party web services

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

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

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

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

  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, you must re-create both the data and the tables that store the dynamic choices, if the test and production environment do not share the same source.

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

    • For external rules:

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

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

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

Task 4   Edit Additional Oracle RTD Components for Production

Additional tasks that you may need to perform 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 you 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 the Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

  2. Modifying the loadgen files.

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

    • ClientHttpEndpoints.properties files

    • Inline Service name (if changed)

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

    • Path to the loadgen log file

  3. Modifying batch processing files.

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

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

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

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, refer to the "Configuring Data Access" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle Real-Time Decisions.

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

21.9.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 the Oracle Fusion Middleware Repository Creation Utility User's Guide.

Task 2   Move the Middleware Home and the Oracle Enterprise Content Management Suite Configuration

Take the following steps to move the Middleware home and perform the initial configuration:

  1. Move a copy of the Middleware home using the copyBinary and pasteBinary scripts, as described in Section 20.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.

  2. Move the configuration of Oracle Enterprise Content Management Suite by using the copyConfig, extractMovePlan, and pasteConfig scripts as described in Section 20.5.2.

    This step copies the configuration of Oracle Enterprise Content Management Suite components. It copies the domain directory, the Administration Server, and Managed Servers. It also:

    • Modifies information about the database that contains Oracle IRM metadata.

    • Copies the Oracle I/PM sample input files, if they are in the domain directory.

    • Copies the BPEL credentials.

    • Moves Oracle Web Services Manager policies.

    • Sets the Listen address for the Managed Server that contains Oracle Application Extension Framework (AXF).

    • Starts the Administration Server and Managed Servers.

  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, it is not configured when you move the Oracle Enterprise Content Management Suite. you must install it, similar to the way you installed it in the test environment, using the procedures described in the Oracle Universal Content Management page at:

    http://www.oracle.com/technology/products/content-management/ucm/index.html
    
Task 3   Modify Oracle Information Rights Management Settings

You need to modify some Oracle IRM settings in the new production environment:

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

  2. Each Oracle IRM installation requires access to a keystore with installation specific keys. The unpacked domain may have a keystore. If it does and if the Content Tracker component is enabled and being used in their test environment., delete this keystore, clear the passwords details, and create a new keystore:

    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.

  3. 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 an Oracle Secure Enterprise Search instance and configure it for Oracle UCM on the production system:

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

  4. If you configured the IntradocDir, WeblayoutDir, and VaultDir directories to be outside of the domain structure, copy the directories to the production environment.

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

    DOMAIN_HOME/bin/intradoc.cfg 
    

    This step is not necessary if the directory structures of the production environment is the same as the test environment.

  6. On the production system, delete the following file:

    IntradocDir/data/contenttracker/config/sct.cfg
    

    The file is regenerated when you restart the server.

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

    instance_dir/config/config.cfg
    
  8. Restart the Administration Server and 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 must also change the parameters IDC_Name, InstanceMenuLabel, InstanceDescription, HttpServerAddress, and AutoNumberPrefix in the following file:

instance_dir/config/config.cfg

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

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:

  • Installed and configured Oracle SOA Suite and moved its test environment to the production environment, as described in Section 21.3.1.

  • Configured Oracle I/PM, extending the SOA domain, as described in "Extending an Existing Domain" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.

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

  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. If you have moved Oracle Internet Directory to the production environment, export Oracle I/PM users and groups from the test environment.

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

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

    ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port 
      -D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Users,dc=us"
    
  4. 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.

  5. If the sample files are outside the domain directory, copy the files from the test environment to the production environment. The location of the files is specified in the Oracle I/PM MBean SampleDirectory.

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

  6. If you have moved Oracle Internet Directory to the production environment, import users and groups into the LDAP identity store on the production environment by importing the ldif file that you exported from the test environment into the production environment, using the ldapaddmt command, as shown in the following example. (ORACLE_HOME is the Oracle home for Identity Management.)

    ORACLE_HOME/bin/ldapaddmt -h production_oid_host
       -p production_oid_port -D "cn=orcladmin"
       -w "production_orcladmin_passwd" -r -f ldif_filename
    
  7. Enable SSL, as described in "System Security" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.

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

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

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

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

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

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

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

      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.

  15. 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 9, update the PARAMETER_VALUE column for the BPEL_CONNECTION row in the AXF_SOLUTION_ATTRIBUTES table using your preferred SQL utility:

      UPDATE AXF_SOLUTION_ATTRIBUTES SET PARAMETER_VALUE = '<ConnectionName>'
               WHERE PARAMETER_KEY = 'BPEL_CONNECTION'
      
    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.

  16. If you cannot retrieve documents from the IPM Viewer, you must change the permissions for the following file:

    DOMAIN_HOME/oracle/imaging/imaging-server/ixTransformer
    
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 the 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 the Oracle Fusion Middleware Administrator's Guide for Universal Records Management.

21.9.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 the HTTP protocol in the test system to the HTTPS protocol in the production system would prevent test-sealed content from working in a production system.

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

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

To move a test deployment into a production environment:

  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.

21.10 Moving Oracle Data Integrator to a Production Environment

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

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

21.10.1 Moving Oracle Data Integrator to a New Production Environment

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

To move Oracle Data Integrator to a new production environment, perform the following tasks:

Task 1   Install the Software and Perform the Initial Configuration

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

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

    Make sure that both the work and master repositories in the production environment are created with unique IDs across your entire organization, including your development and test repositories. Also make sure that the production work repository is created with the same type as the test repository (For example, if the test work repository is created as a development repository, the production work repository must also be created as a development repository).

  2. Install Oracle Data Integrator:

    • If you are using Java components, move a copy of the Middleware home from the test environment to the production environment, as described in Section 20.5.1. The Oracle WebLogic Server home and the Oracle homes in the Middleware home are also moved.

    • If you have performed a standalone installation of Oracle Data Integrator (that is, you did not install any Java components), install Oracle Data Integrator with the same components in the production environment.

  3. Create a domain containing Oracle Data Integrator:

    • If you are using Java components, move a copy of the domain containing Oracle Data Integrator from the test environment to the production environment, as described in Section 20.5.2.

    • If you have performed a standalone installation of Oracle Data Integrator, configure Oracle Data Integrator and create a domain using the Configuration Wizard, as described in "Configure a WebLogic Domain" in the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator.

  4. Configure the Oracle Data Integrator standalone agents required in the production environment. See "Configuring the Standalone Agent" in the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator.

Task 2   Move the Topology to the Production Environment

To move the topology to the new production environment:

  1. Export the topology from the test master repository using Oracle Data Integrator Studio. See "Export/Import the Topology and Security Settings" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.

  2. Import the topology into the production master repository using Oracle Data Integrator Studio. See "Export/Import the Topology and Security Settings" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator. Use the Synonym Mode INSERT_UPDATE for this import.

Task 3   Move the Work Repository Content to the Production Environment

To move the work repository content to the new production environment:

  1. Export the work repository content from the test work repository using Oracle Data Integrator Studio. See "Exporting and Importing a Work Repository" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.

  2. Import the work repository content into the production work repository using Oracle Data Integrator Studio. See "Exporting and Importing a Work Repository" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.

Task 4   Change the Settings for the Production Environment

Change the following settings in the production environment:

  • Topology settings: It is usually recommended to use different contexts for test and production environments, and switch the context to schedule or run scenarios in a given environment. Using a single context forces you to modify the physical architecture configuration (for example, the host name of the data servers) when moving to production.

    If you are using different Oracle Data Integrator contexts for your test and production environments, and the physical architecture is already defined for the production environment, review this physical architecture before proceeding. See "Setting-up the Topology" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.

    If you are using a single context for both the environments, then you must review and change the following items in the physical architecture in the production master repository:

    • Physical Agents: Change the host, port, and Web application context (for Java EE Agent) to match the configuration of the production environment.

    • Data Servers: Change the data server connection information (JDBC, JNDI, data source name) to match the configuration of the production environment.

    • Physical Schemas: The schemas (including file folder location) defined for the data servers must match the configuration of the production environment.

  • Scheduling: If you are using different Oracle Data Integrator contexts for your test and production environments, and schedules are only defined to run in the test context, you must change these schedules in the production work repository to execute them in the production context. See "Scheduling Scenarios" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.

    If you are using a single context for both the environments, then existing schedules do not need to be modified.

  • If scenario schedules are not defined in the test environment, you can create them in the production environment.

Task 5   Restart the Run-Time Agents

Restart the standalone and Java EE agents in the production environment. These agents start processing the scheduled scenarios.

21.10.2 Moving Oracle Data Integrator Scenarios to an Existing Production Environment

In this scenario, you have a number of new or regenerated scenarios in a test environment and you want to move them to a production environment that already exists.

Note:

Scenarios already deployed in the production environment should be regenerated before being moved in the production environment. They should not be deleted then generated.

On the existing production system, you have installed and configured the components as described in Section 21.10.1. You want to move the data integration scenarios from the test environment to the production Oracle Data Integrator environment.

To move Oracle Data Integrator scenarios to an existing production environment, perform the following tasks:

Task 1   Move Topology Updates

Perform this task if the topology in the test environment was modified or added for the new scenarios.

To move topology updates to an existing production system:

  1. Export updated and new physical and logical topology items (data servers, schemas, agents) from the test master repository using Oracle Data Integration Studio. See "Exporting and Importing Objects" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.

  2. Import updated and new physical and logical topology items (data servers, schemas, agents) into the production master repository using Oracle Data Integration Studio. See "Exporting and Importing Objects" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.

  3. Update the Open Tools definitions and declare the new ones.

Task 2   Move New and Updated Scenarios

To move Oracle Data Integrator scenarios to an existing production system:

  1. Export the new and regenerated scenarios from the test work repository using Oracle Data Integrator Studio. You can export them using single scenario export or multiple scenario export, or you can export all scenarios in a given project or folder. See "Exporting Scenarios" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.

  2. Import the new or regenerated scenarios in the production work repository using Oracle Data Integrator Studio. Use the Synonym Mode INSERT_UPDATE for this import. See "Importing Scenarios in Production" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.

  3. Change the schedules in the production work repository to execute the new scenarios in the production context. See "Scheduling Scenarios" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.

21.11 Considerations in Moving to and from an Oracle RAC Environment

If you are moving your environment to or from an Oracle Real Application Cluster (Oracle RAC) environment, note the following: