12 Changing from a Test to a Production Environment

12.2.1 Scenario 1: Redeploying J2EE Applications to an Existing Production Environment with a Middle-Tier Instance

In this scenario, you have a J2EE application on a test middle-tier instance, and you want to redeploy it to an existing production middle tier. Figure 12-1 shows this scenario.

12.2.2 Scenario 2: Moving J2EE Applications from a Test Middle Tier Without Identity Management to a New Production Environment

In this scenario, you have a J2EE application on a test middle-tier instance without Identity Management. You want to create a new production environment that includes a middle-tier instance, and move the J2EE application. Figure 12-2 shows this scenario.

12.2.3 Scenario 3: Moving J2EE Applications from a Test Middle Tier with Identity Management to a New Production Environment

In this scenario, you have a J2EE application on a test middle-tier instance with Identity Management. You want to create a new production environment that includes a middle-tier instance with the J2EE application and Identity Management with a Metadata Repository. Figure 12-3 shows this scenario.

12.3.1 Scenario 1: Moving Applications from a Test Middle Tier with Identity Management to a Production Environment with a Preexisting Identity Management

In this scenario, you have an existing production environment that includes an Identity Management installation with a Metadata Repository. You would like to create a test environment for developing and testing applications. You would then like to roll out these applications to the production environment.

For this scenario, you create a test environment by installing and setting up a replica of the production Identity Management. The Identity Management has its own Metadata Repository. The Oracle Internet Directory in the test Identity Management is an LDAP-based replica of the production Oracle Internet Directory. Replication takes place constantly from the production Oracle Internet Directory to the test Oracle Internet Directory. This replica has its own Metadata Repository. You then install a test middle-tier instance to use the test Identity Management.

After developing and testing your applications, you then create a production middle-tier instance by either cloning the test middle-tier instance, or installing a middle tier into the production environment, and then redeploying the applications.

Figure 12-4 shows an example of this scenario.

12.3.2 Scenario 2: Moving Applications from a Test Middle Tier with Identity Management and a Product Metadata Repository to an Existing Production Environment with Identity Management

This scenario is similar to Section 12.3.1, "Scenario 1: Moving Applications from a Test Middle Tier with Identity Management to a Production Environment with a Preexisting Identity Management", except the test middle-tier instance has an additional Metadata Repository for product metadata. With this scenario, you develop and test one application or a set of related applications against the same Identity Management. You then roll out these applications at the same time to the production environment. After deploying the first set of applications, you can then develop, test, and deploy a second set of applications. In this manner, this scenario works like an assembly line.

If you prefer to instead deploy applications at different times, then consider Section 12.3.3, "Scenario 3: Moving Applications from Multiple Test Middle Tiers with Dedicated Identity Management Metadata Repositories".

Like Scenario 1, you start by creating a test environment with a replica of the production Identity Management. You then install a test middle-tier instance to use the test Identity Management and a separate Metadata Repository for the product metadata.

You then configure the production environment. You move the test product Metadata Repository to the production environment. You then create a production middle-tier instance by either cloning the test middle-tier instance, or installing a middle tier into the production environment, and then redeploying the applications.

Figure 12-5 shows an example of this scenario.

12.3.3 Scenario 3: Moving Applications from Multiple Test Middle Tiers with Dedicated Identity Management Metadata Repositories

This scenario demonstrates how to move application data from multiple test middle-tier instances to a production environment. With this scenario, you develop and test set applications or two sets of related applications in separate test environments, each with a dedicated Identity Management. You then roll out these applications at different deployment times to the production environment.

If you prefer to instead develop, test, and deploy one set of applications at a time, then consider Section 12.3.2, "Scenario 2: Moving Applications from a Test Middle Tier with Identity Management and a Product Metadata Repository to an Existing Production Environment with Identity Management".

In this scenario, you have an existing production environment that includes an Identity Management installation with a Metadata Repository. You would like to create a test environment for developing and testing your application. You want this test environment to includes two middle-tier instances, Department 1 and 2, each with a dedicated Identity Management and product Metadata Repositories. Once the applications are tested, you would like to roll them out to a production environment that also includes middle tiers for Department 1 and 2, each with dedicated product Metadata Repositories.

To accomplish this move without data conflicts of Identity Management, you move data from the departments in a serial manner.

Figure 12-6 shows an example of this scenario.

12.3.4 Common Procedures for Scenarios in Use Case 2

Common procedures for Section 12.3, "Case 2: Moving Non-J2EE Applications to a Production Environment" include:

• Install and Set Up the Test Identity Management and Metadata Repository

• Identify the Test Oracle Internet Directory as a Pilot

• Install and Populate Test Product Metadata Repository

• Install Test Middle-Tier Instance

• Develop and Test Your Applications

• Clean Up Test Oracle Internet Directory

• Quiesce the Distributed Directory Environment

• End Pilot Mode on the Test Oracle Internet Directory

• Move the Test Product Metadata Repository to Production

• Migrate Oracle Internet Directory Data to Production

• Change Middle-Tier Instance to the Production Identity Management

Install and Set Up the Test Identity Management and Metadata Repository

In this procedure, you install and set up the test Identity Management and its associated Metadata Repository. The test Identity Management is an LDAP-based replica of the original Identity Management.

1. Read Section H.1, "About LDAP-Based Replicas" to learn about LDAP-based Replicas and how they are used for this procedure.

2. Follow the procedure in Section H.2, "Installing and Setting Up an LDAP-Based Replica" to install and set up the test Identity Management and Metadata Repository.

Identify the Test Oracle Internet Directory as a Pilot

Run the following command from the Oracle home of the test Oracle Internet Directory:

remtool -pilotreplica begin -bind test_oid_host:test_oid_port/test_replication_dn_passwd

In the syntax:

test_oid_host is the host name of the test directory server.

test_oid_port is the LDAP port of the test directory server.

test_replication_dn_passwd is the password of the replication DN of the test directory server. By default, it is the same as the superuser DN (cn=orcladmin) password.

Install and Populate Test Product Metadata Repository

Create a new database and populate it with the OracleAS Metadata Repository.

1. Install Oracle Application Server using Oracle Universal Installer.

2. From the Select a Product to Install screen, select OracleAS Infrastructure.

3. From the Select Installation Type, select Metadata Repository.

Install Test Middle-Tier Instance

Install your test middle-tier instances and configure them to use the test Identity Management according to what you want to test:

1. Install Oracle Application Server using Oracle Universal Installer.

2. From the Select a Product to Install screen, choose the appropriate middle tier type for your environment.

Develop and Test Your Applications

Develop and test applications in your test environment.

Clean Up Test Oracle Internet Directory

You can clean up (delete) the data that is modified or added on the test Oracle Internet Directory so that it is not migrated to the production Oracle Internet Directory. This might be a requirement of a middle-tier component or might be desired by the administrator who maintains Oracle Internet Directory consistency in the production Oracle Internet Directory.

To clean up the data, use the ldapdelete command-line utility and delete entries that should not be migrated.

Quiesce the Distributed Directory Environment

It is very important to quiesce the distributed directory environment while the data migration from the test to the production takes place. This ensures that there are no conflicting updates, and therefore no data loss or corruption.

To quiesce the distributed directory environment:

1. Make sure both the test and production Oracle Internet Directories are up and running.

2. Change the directory server on the test node to read-only mode.

   On the test host, create an LDIF file named readonly.ldif that contains the following lines:

   dn:
   changetype:modify
   replace:orclservermode
   orclservermode:r
   
   

   Run the following command:

   TEST_HOME/bin/ldapmodify -p test_oid_port -D cn=orcladmin
    -w test_orcladmin_passwd -v -f readonly.ldif
   
   

   In the syntax:

   test_oid_port is the LDAP port of the test directory server.

   test_orcladmin_password is the password of the superuser DN (cn=orcladmin).

3. Wait until all the pending changes are applied to both nodes and the nodes are completely in sync. There is no tool to automatically detect this, but you can monitor the replication log files and make sure there are no new changes being processed by any node in the directory replication group, which ensures that the directory replication group is in a quiesced state.

End Pilot Mode on the Test Oracle Internet Directory

Run the following command from the Oracle home of the test Oracle Internet Directory:

remtool -pilotreplica end -bind test_oid_host:test_oid_port/test_replication_dn_passwd [-bkup fname]

In the syntax:

test_oid_host is the host name of the test directory server.

test_oid_port is the LDAP port of the test directory server.

test_replication_dn_passwd is the password of the replication DN of the test directory server. By default, it is the same as the superuser DN (cn=orcladmin) password.

fname specifies the backup file in which to store entries that were modified after pilot mode was started. The entries are in LDIF format. You will use this file in procedure "Migrate Oracle Internet Directory Data to Production".

Move the Test Product Metadata Repository to Production

You have several options for moving your test product Metadata Repository to your production environment:

• You can continue to use the test Metadata Repository in your production environment, thereby deeming it to be a production Metadata Repository.

  In this case, no further action is required.

• You can copy the Metadata Repository to a production host and change your middle-tier instances to use it.

  Follow the procedure in Section 9.5, "Changing the Metadata Repository Used by a Middle-Tier Instance".

• If you do not want to retain the test data in the Metadata Repository, you can install a new Metadata Repository in the production environment, and change the middle-tier instances to use that.

  Install an Infrastructure using Oracle Universal Installer. Select the Metadata Repository only option. Register the Metadata Repository with the production Identity Management.

  Change each of the former test middle-tier instances to use the new Metadata Repository. On each middle-tier instance:

  1. Using the Application Server Control Console, navigate to the Instance Home Page for the middle-tier instance.

  2. Click Infrastructure.

  3. On the Infrastructure Page, in the Metadata Repository section, click Change.

  4. Follow the tasks in the wizard for supplying the new Metadata Repository information.

  5. When the wizard is finished, navigate to the Instance Home Page and start your instance by clicking Start All.

Migrate Oracle Internet Directory Data to Production

This procedure describes how to migrate Oracle Internet Directory data from a test Identity Management to the production Identity Management.

1. Migrate test Oracle Internet Directory data to the production environment by running the following command.

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

   Make sure you specify the -r argument to migrate data and resolve conflicts. Also, ensure you specify the LDIF file you obtained in procedure "End Pilot Mode on the Test Oracle Internet Directory" for the -f argument.

   In the syntax:

   production_oid_host is the host of the production directory server.

   production_oid_port is the LDAP port of the production directory server.

   production_orcladmin_password is the password of the superuser DN (cn=orcladmin).

   fname specifies the LDIF file you specified in procedure "End Pilot Mode on the Test Oracle Internet Directory".

2. Validation step. Verify that the migration of Oracle Internet Directory data succeeded.

   Verify that ldapaddmt reported success. You can check the add.log file for errors, which is created in the directory from which you ran the ldapaddmt command.

   • If add.log is empty, the command succeeded.

   • If add.log contains errors such as Additional Info: Parent entry not found in the directory, then the entries in the LDIF file are not in the correct order—the child entry is before the parent entry. Run ldapaddmt again and this will take care of adding the child entries.

     
     

     See Also: Oracle Internet Directory Administrator's Guide for information on interpreting messages in log files

     
     

   If necessary, repeat step 1.

3. Migrate OracleAS Single Sign-On and Directory Integration and Provisioning data from the test Metadata Repository to the production Metadata Repository.

   To migrate the OracleAS Single Sign-On data:

   1. Obtain the ORASSO schema password on the test Metadata Repository:

      TEST_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port 
      -D "cn=orcladmin" -w test_orcladmin_passwd 
      -b "orclresourcename=orasso, orclreferencename=test_oid_global_db_name,
       cn=ias infrastructure databases, cn=ias, cn=products, cn=oraclecontext" -s
       base "objectclass=*" orclpasswordattribute
      
      

      In the syntax:

      test_oid_host is the host of the test directory server.

      test_oid_port is the LDAP port of the test directory server.

      test_orcladmin_password is the password of the superuser DN (cn=orcladmin).

      test_oid_global_dbname is the global database name of the test Metadata Repository.

      This command prints the ORASSO password in a line like the following:

      orclpasswordattribute=LAetjdQ5
      
      

   2. Export the OracleAS Single Sign-On data from the test environment, ensuring that the ORACLE_HOME environment variable is set before you run this command:

      TEST_HOME/sso/bin/ssomig -export -s orasso -p test_orasso_passwd 
      -c test_net_service_name -log_d $TEST_HOME/sso/log
      
      

      In the syntax:

      test_orasso_passwd is the ORASSO password obtained in the previous step.

      test_net_service_name is the database name of the test Metadata Repository.

   3. Copy the ssomig.dmp and ssoconf.log files from the test to the production directory server, preserving the exact full path for each file:

      cp TEST_HOME/sso/log/ssomig.dmp PRODUCTION_HOME/sso/log/ssomig.dmp
      cp TEST_HOME/sso/log/ssoconf.log PRODUCTION_HOME/sso/log/ssoconf.log
      
      

   4. Obtain the ORASSO schema password on the production Metadata Repository:

      PRODUCTION_HOME/bin/ldapsearch -h production_oid_host -D "cn=orcladmin"  -p production_oid_port
      -w production_orcladmin_password -b "orclresourcename=orasso,
       orclreferencename=production_global_db_name, cn=ias infrastructure
       databases, cn=ias, cn=products, cn=oraclecontext" 
      -s base "objectclass=*" orclpasswordattribute
      
      

      In the syntax:

      production_oid_host is the host of the production directory server.

      production_oid_port is the LDAP port of the production directory server.

      production_orcladmin_password is the password of the superuser DN (cn=orcladmin).

      production_oid_global_dbname is the global database name of the production Metadata Repository.

   5. Import the OracleAS Single Sign-On data to the production Metadata Repository:

      PRODUCTION_HOME/sso/bin/ssomig -import -overwrite -s orasso 
      -p production_orasso_passwd -c production_net_service_name 
      -log_d $PRODUCTION_HOME/sso/log -discoforce
      
      

      In the syntax:

      production_orasso_passwd is the ORASSO password obtained in the previous step.

      production_net_service_name is the database name of the production Metadata Repository.

   6. Validation step: Verify that the export and import of OracleAS Single Sign-On succeeded.

      Verify that the OracleAS Single Sign-On migration tool reported success. You can also check the following log files for errors:

      TEST_HOME/sso/log/ssomig.log
      PRODUCTION_HOME/sso/log/ssomig.log
      

      
      

      See Also: Oracle Application Server Single Sign-On Administrator's Guide for information on interpreting messages in the log files

      
      

   To migrate the Directory Integration and Provisioning Data data:

   
   

   See Also: Directory Integration and Provisioning Data documentation in the Oracle Internet Directory Administrator's Guide for running the following commands using the HTTPS port in environments in which the Oracle Internet Directory HTTP port is disabled

   
   

   1. Stop the Directory Integration and Provisioning Data server on the test directory server:

      TEST_HOME/bin/oidctl server=odisrv instance=1 stop
      
      

   2. Migrate the Directory Integration and Provisioning Data to the production Metadata Repository:

      TEST_HOME/bin/dipassistant reassociate -src_ldap_host
       test_oid_host -src_ldap_port test_oid_port 
      -dst_ldap_host production_oid_host -dst_ldap_port
       production_oid_port -src_ldap_passwd
       test_orcladmin_passwd -dst_ldap_passwd production_orcladmin_passwd
      
      

      This command prints log messages to:

      TEST_HOME/ldap/odi/log/reassociate.log
      
      

      In the syntax:

      test_oid_host is the host of the test directory server.

      test_oid_port is the LDAP port of the test directory server.

      production_oid_host is the host of the production directory server.

      production_oid_port is the LDAP port of the production directory server.

      test_orcladmin_password is the password of the superuser DN (cn=orcladmin) for the test directory server.

      production_orcladmin_password is the password of the superuser DN (cn=orcladmin) for the production directory server.

   3. Stop the Directory Integration and Provisioning Data server on the production directory server:

      PRODUCTION_HOME/bin/oidctl server=odisrv instance=1 stop
      
      

   4. Register the Directory Integration and Provisioning Data server on the production directory server:

      PRODUCTION_HOME/bin/odisrvreg -D "cn=orcladmin"
       -w production_orcladmin_passwd -p production_oid_port  -h production_oid_host 
      
      

      In the syntax:

      production_orcladmin_password is the password of the superuser DN (cn=orcladmin).

      production_oid_port is the LDAP port of the production directory server.

      production_oid_host is the host of the production directory server.

   5. Start the Directory Integration and Provisioning Data server on the production directory server:

      PRODUCTION_HOME/bin/oidctl server=odisrv instance=1 
      flags="port=production_oid_port" start
      
      

      In the syntax, production_oid_port is the LDAP port of the production directory server.

4. (Optional) Perform post-migration cleanup tasks.

   Some middle-tier components might have special cleanup requirements after you have changed to the production environment. You can perform these cleanup tasks to the test environment after the middle-tier instances have been changed to the production node.

Change Middle-Tier Instance to the Production Identity Management

In each production middle-tier instance, run the Change Identity Management wizard and restart the instance:

1. Using the Application Server Control Console, navigate to the Instance Home Page for the middle-tier instance.

2. Click Infrastructure.

3. On the Infrastructure Page, in the Identity Management section, click Change.

4. Follow the tasks in the wizard for supplying the production Identity Management information.

5. When the wizard is finished, navigate to the Instance Home Page and start your instance by clicking Start All.

12.4.1 OracleAS Portal

In this scenario, you have existing test and production environments with OracleAS Portal Metadata Repositories. You want to move metadata from the test Metadata Repository to the production environment. To move OracleAS Portal metadata, you use the export/import utilities to move content. Figure 12-7 shows this scenario.

12.4.2 OracleBI Discoverer

In this scenario, you have existing test and production environments. Test OracleBI Discoverer data already resides on the middle tier, Metadata Repository, and a database. You primarily use the test environment to create End User Layers (EULs) for developing a business area without compromising the performance of production systems.

The migration process involves three main tasks. You first move configuration files from the middle tier, and then move the OracleBI Discoverer metadata from the test Metadata Repository to the production environment. Finally, you migrate the OracleBI Discoverer information from the test database to the production database, including the EULs.

Figure 12-8 shows this scenario.