| Oracle® Application Server Administrator's Guide 10g Release 2 (10.1.2) B13995-08 |
|
 Previous |
 Next |
| Oracle® Application Server Administrator's Guide 10g Release 2 (10.1.2) B13995-08 |
|
Previous |
Next |
This chapter provides use cases for changing from a test 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.
It contains the following topics:
Understanding the Options for Creating a Production Middle Tier
Case 1: Moving J2EE Applications to a Production Environment
Case 2: Moving Non-J2EE Applications to a Production Environment
Table 12-1 provides guidance on how to find the use case scenario that applies to your application and configuration environment.
Table 12-1 Test-to-Production Use Cases
| Type of Application | Configuration Assumptions | Refer To This Use Case Scenario: |
|---|---|---|
|
J2EE |
||
|
Scenario 1 |
Test Environment: Middle-tier instance already exists. Production Environment: Middle-tier instance already exists. |
|
|
Scenario 2 |
Test Environment: Middle-tier instance already exists. Production Environment: The production environment does not exist. You want to create a middle-tier instance. |
|
|
Scenario 3 |
Test Environment Includes: Middle-tier instance and Identity Management already exists. Production Environment: The production environment does not exist. You want to create a middle-tier instance and Identity Management. |
|
|
Non-J2EE |
||
|
Scenario 1 |
Test Environment: The test environment does not exist. You want to create a middle-tier instance and Identity Management. Production Environment: Identity Management already exists. You want to create a middle-tier instance. |
|
|
Scenario 2 |
Test Environment: The test environment does not exist. You want to create a middle-tier instance, Identity Management, and a Metadata Repository for product metadata. Production Environment: Identity Management already exists. You want to create a middle-tier instance, and a Metadata Repository for product metadata. |
|
|
Scenario 3 |
Test Environment: The test environment does not exist. You want to create multiple middle-tier instances, each with Identity Management and Metadata Repository for product metadata. Production Environment: Identity Management already exists. You want to create multiple middle-tier instances, each with a Metadata Repository for product metadata. |
In addition to J2EE and non-J2EE use case, this chapter also provides guidance on moving incremental product-specific data from a test environment to a production environment.
Many of the scenarios presented in this chapter describe creating a production middle-tier instance in a configuration that already includes a test middle-tier instance for application development. For these scenarios, you have the choice of three options. You can:
Clone the test middle-tier instance.
Use this option to preserve configuration settings.
Point the test middle-tier instance to the production Identity Management.
Use this option if you want to repurpose the test middle-tier instance as the production middle-tier instance.
Install a middle-tier instance into the production environment, and then redeploy applications.
Use this option when you are creating the production middle-tier instance in a different operating system than the test middle-tier instance.
This section demonstrates how to move J2EE applications from a test environment to a production environment. The following topics present typical scenarios:
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.
Figure 12-1 Redeploying a J2EE Application to an Existing Production Middle Tier
This use case assumes the following configuration:
Separate test and production environments already exist.
You have a J2EE application in the test middle-tier instance.
Redeploy J2EE application EAR files to the new middle tier. You can use one of the following mechanisms:
Use the DCM redeployApplication command
Navigate to the OC4J Home page -> Applications tab in Oracle Enterprise Manager 10g Application Server Control Console and click Deploy EAR file.
|
See Also:
|
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.
Figure 12-2 Moving a J2EE Application to a New Production Middle Tier Without Identity Management
This use case assumes the following configuration:
You have an existing test environment that includes a middle-tier instance with a J2EE application.
The production environment does not exist.
For this scenario, you must create the production middle-tier instance. You have a choice of two configuration options. You can either:
Clone the test middle-tier instance to make a production middle-tier instance. See Section 10.4, "Cloning Oracle Application Server Instances".
Install a middle tier into the production environment, and then redeploy the J2EE application, as described in Section 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 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.
Figure 12-3 Moving a J2EE Application from a Test Middle Tier with Identity Management
This scenario assumes the following configuration:
The test environment includes a middle-tier instance with a J2EE application and an Identity Management installation with a Metadata Repository.
The production middle-tier instance does not the exist, and the production Identity Management may exist.
For this scenario, you create the production environment by following these tasks:
If the production Identity Management and Metadata Repository does not exist, install and configure it:
Install Oracle Application Server using Oracle Universal Installer.
From the Select a Product to Install screen, choose OracleAS Infrastructure.
From the Select Installation Type, choose Identity Management and OracleAS Metadata Repository.
From the Select Configuration Options screen, choose Oracle Internet Directory.
Install the production middle-tier instance.
Install Oracle Application Server using Oracle Universal Installer.
From the Select a Product to Install screen, choose the appropriate middle tier type for your environment.
Redeploy the J2EE application, as described in Section 12.2.1, "Scenario 1: Redeploying J2EE Applications to an Existing Production Environment with a Middle-Tier Instance".
In this use case, a test environment is created from a preexisting production environment. Once data is tested, it is moved back to the production environment. This use case is useful for environments in which you want to create a test environment that simulates a production environment, such as testing and rolling out patches. The following topics present typical scenarios:
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.
Figure 12-4 Moving an Application from a Test Middle Tier with Identity Management to a New Production Environment
This scenario assumes the following configuration:
The test environment does not exist.
The production environment includes only Identity Management with a Metadata Repository.
This procedure contains the following tasks:
Task 1: Configure the Test Identity Management and Metadata Repository
To configure the test Identity Management and Metadata Repository, set up Identity Management in the test environment. Use these subtasks to perform this configuration:
Perform procedure "Install and Set Up the Test Identity Management and Metadata Repository".
Perform procedure "Identify the Test Oracle Internet Directory as a Pilot".
Task 2: Set Up the Test Middle-Tier Instance
To configure the test middle-tier instance, install the middle-tier instance and develop and test applications. Use these subtasks to perform this configuration:
Perform procedure "Install Test Middle-Tier Instance".
Perform procedure "Develop and Test Your Applications".
Task 3: Set Up the Production Middle-Tier Instance
To create a production middle-tier instance, you can either clone the test middle-tier instance or perform a middle-tier installation. If you do not want to create a separate production middle-tier instance, you can choose to point the test middle-tier instance to the production Identity Management.
When you clone a test middle-tier instance, you must also migrate data from the test Identity Management to the production Identity Management, and associate the production middle-tier instance with the production Identity Management. Perform the following procedures to clone the test middle-tier instance:
Perform procedure "Clean Up Test Oracle Internet Directory".
Perform procedure "Quiesce the Distributed Directory Environment".
Perform procedure "End Pilot Mode on the Test Oracle Internet Directory".
Perform procedure "Migrate Oracle Internet Directory Data to Production".
Perform tasks in procedure Section 10.4, "Cloning Oracle Application Server Instances".
Perform procedure "Change Middle-Tier Instance to the Production Identity Management".
To point the test middle-tier instance to the production Identity Management, perform the same tasks for cloning, except for Task 5.
To install the production middle-tier instance:
Install the production middle-tier instance.
Install Oracle Application Server using Oracle Universal Installer.
From the Select a Product to Install screen, choose the appropriate middle tier type for your environment.
Redeploy the application, as described in Section 12.2.1, "Scenario 1: Redeploying J2EE Applications to an Existing Production Environment with a Middle-Tier Instance".
When you install, data in the test Identity Management is not migrated from to the production environment.
If you want to deploy a test application to another middle-tier instance in the production environment, perform these tasks to create a second middle-tier instance:
Perform subtask 2 in "Task 1: Configure the Test Identity Management and Metadata Repository".
Perform procedure "Task 2: Set Up the Test Middle-Tier Instance".
Perform procedure "Task 3: Set Up the Production Middle-Tier Instance".
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.
Figure 12-5 Moving an Application from a Test Middle Tier with Identity Management and Product Metadata Repository to an Existing Production Environment with Identity Management
This scenario assumes the following configuration:
The test environment does not exist.
The production environment includes only Identity Management with a Metadata Repository.
This procedure contains the following tasks:
Task 1: Configure the Test Identity Management and Metadata Repository
Task 4: Move Test Product Metadata Repository to Production Environment
Task 1: Configure the Test Identity Management and Metadata Repository
To configure the test Identity Management and Metadata Repository, set up Identity Management in the test environment. Follow these procedures to perform this configuration:
Perform procedure "Install and Set Up the Test Identity Management and Metadata Repository".
Perform procedure "Identify the Test Oracle Internet Directory as a Pilot".
Task 2: Create the Test Product Metadata Repository
To configure the test product metadata repository, follow the procedure "Install and Populate Test Product Metadata Repository".
Task 3: Set Up the Test Middle-Tier Instance
To configure the test middle-tier instance, install the middle-tier instance and develop and test applications. Follow these procedures to perform this configuration:
Perform procedure "Install Test Middle-Tier Instance".
Perform procedure "Develop and Test Your Applications".
Task 4: Move Test Product Metadata Repository to Production Environment
To configure the production product Metadata Repository, follow the procedure "Move the Test Product Metadata Repository to Production".
Task 5: Set Up the Production Middle-Tier Instance
To create a production middle-tier instance, you can either clone the test middle-tier instance or perform a middle-tier installation. If you do not want to create a separate production middle-tier instance, you can choose to point the test middle-tier instance to the production Identity Management.
When you clone a test middle-tier instance, you must also migrate data from the test Identity Management to the production Identity Management, and associate the production middle-tier instance with the production Identity Management. Perform these procedures to clone the test middle-tier instance:
Perform procedure "Clean Up Test Oracle Internet Directory".
Perform procedure "Quiesce the Distributed Directory Environment".
Perform procedure "End Pilot Mode on the Test Oracle Internet Directory".
Perform procedure "Migrate Oracle Internet Directory Data to Production".
Perform tasks in procedure Section 10.4, "Cloning Oracle Application Server Instances".
Perform procedure "Change Middle-Tier Instance to the Production Identity Management".
To point the test middle-tier instance to the production Identity Management, perform the same tasks for cloning, except for Task 5.
To install the production middle-tier instance:
Install the production middle-tier instance.
Redeploy the application, as described in Section 12.2.1, "Scenario 1: Redeploying J2EE Applications to an Existing Production Environment with a Middle-Tier Instance".
When you install, test data in the test Identity Management is not migrated from to the production environment.
|
See Also: Section 12.3.1.3, "Creating a Second Middle-Tier Instance in the Production Environment" for further information |
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.
Figure 12-6 Moving Applications from Separate Test Middle Tiers
This scenario assumes the following configuration:
The test environment does not exist.
The production environment includes only Identity Management with a Metadata Repository.
This procedure contains the following tasks:
Task 1: Configure the Test Identity Management and Metadata Repository
Task 4: Move Test Product Metadata Repository to Production Environment
Task 1: Configure the Test Identity Management and Metadata Repository for Department 1 and 2
To configure the test Identity Management and Metadata Repository, set up Identity Management in the test environment in both departments. Follow these procedures to perform this configuration:
Perform procedure "Install and Set Up the Test Identity Management and Metadata Repository".
Perform procedure "Identify the Test Oracle Internet Directory as a Pilot".
Ensure each Identity Management and Metadata Repository has distinct user sets of data.
Task 2: Create the Test Product Metadata Repository
To configure the test product metadata repository, follow the procedure "Install and Populate Test Product Metadata Repository".
Configure each product Metadata Repository in each department with a unique host name, instance name, global database name, and Oracle System Identifier (SID).
Task 3: Set Up the Test Middle-Tier Instance
To configure the test middle-tier instances, install the middle-tier instance and develop and test applications. Follow these procedures to perform this configuration:
Task 4: Move Test Product Metadata Repository to Production Environment
To configure the production product Metadata Repositories, follow the procedure "Move the Test Product Metadata Repository to Production" first for Department 1 and then for Department 2. When you merge the data from Department 2 with information already present from Department 1, you must merge user groups and ensure there are no user data conflicts.
Task 5: Set Up the Production Middle-Tier Instance
To create a production middle-tier instance for each department, you can either clone the test middle-tier instance or perform a middle-tier installation. If you do not want to create a separate production middle-tier instance, you can choose to point the test middle-tier instance to the production Identity Management.
When you clone a test middle-tier instance, you must also migrate data from the test Identity Management to the production Identity Management, and associate the production middle-tier instance with the production Identity Management. Perform these procedures to clone the test middle-tier instance:
Perform procedure "Clean Up Test Oracle Internet Directory".
Perform procedure "Quiesce the Distributed Directory Environment".
Perform procedure "End Pilot Mode on the Test Oracle Internet Directory".
Perform procedure "Migrate Oracle Internet Directory Data to Production".
Perform tasks in procedure Section 10.4, "Cloning Oracle Application Server Instances".
Perform procedure "Change Middle-Tier Instance to the Production Identity Management".
To point the test middle-tier instance to the production Identity Management, perform the same tasks for cloning, except for Task 5.
To install the production middle-tier instance:
Install the production middle-tier instance.
Install Oracle Application Server using Oracle Universal Installer.
From the Select a Product to Install screen, choose the appropriate middle tier type for your environment.
Redeploy the application, as described in Section 12.2.1, "Scenario 1: Redeploying J2EE Applications to an Existing Production Environment with a Middle-Tier Instance".
When you install, test data in the test Identity Management is not migrated from to the production environment.
|
See Also: Section 12.3.1.3, "Creating a Second Middle-Tier Instance in the Production Environment" for further information |
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
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.
Read Section H.1, "About LDAP-Based Replicas" to learn about LDAP-based Replicas and how they are used for this procedure.
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.
|
See Also:
|
Install and Populate Test Product Metadata Repository
Create a new database and populate it with the OracleAS Metadata Repository.
Install Oracle Application Server using Oracle Universal Installer.
From the Select a Product to Install screen, select OracleAS Infrastructure.
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:
Install Oracle Application Server using Oracle Universal Installer.
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.
|
See Also: Oracle Identity Management User Reference for more information about theldapdelete command |
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:
Make sure both the test and production Oracle Internet Directories are up and running.
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).
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".
|
See Also:
|
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:
Using the Application Server Control Console, navigate to the Instance Home Page for the middle-tier instance.
Click Infrastructure.
On the Infrastructure Page, in the Metadata Repository section, click Change.
Follow the tasks in the wizard for supplying the new Metadata Repository information.
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.
|
Note: Make sure theORACLE_HOME and ORACLE_SID environment variables are set before you begin. This applies to all operating systems. |
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".
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.
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:
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
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.
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
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.
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.
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 |
Stop the Directory Integration and Provisioning Data server on the test directory server:
TEST_HOME/bin/oidctl server=odisrv instance=1 stop
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.
Stop the Directory Integration and Provisioning Data server on the production directory server:
PRODUCTION_HOME/bin/oidctl server=odisrv instance=1 stop
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.
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.
(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:
Using the Application Server Control Console, navigate to the Instance Home Page for the middle-tier instance.
Click Infrastructure.
On the Infrastructure Page, in the Identity Management section, click Change.
Follow the tasks in the wizard for supplying the production Identity Management information.
When the wizard is finished, navigate to the Instance Home Page and start your instance by clicking Start All.
In this use case, you want to only migrate the incremental data that was used for testing applications in a configuration with preexisting test and production environments. How you migrate the data depends upon the application. This section describes how the migration process works for following components:
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.
Figure 12-7 Moving Test OracleAS Portal Metadata to a Production Environment
You have existing test and production environments that each include a middle-tier instance, an Identity Management installation with a Metadata Repository, and an additional Metadata Repository for OracleAS Portal metadata. OracleAS Portal metadata already exists in the test environment.
To use export and import to move OracleAS Portal metadata:
Create transport sets and extract the content to transport tables. Transport sets contain the portal objects that you are planning to export to your target portal environment. This information is displayed in a manifest. The manifest is simply the list of objects in a transport set, used to provide a granular level of control over the export.
Move the transport sets from one system (source) to another (target) using Portal export/import command-line scripts to generate a transport set dump file.
Transfer the script and dump file to the target system using FTP or other file transfer utilities.
Invoke the command line script to import the dump file to the transport tables on your target system.
Import the objects from the transport tables to the target portal repository using the Transport Set Manager portlet.
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.
Figure 12-8 Moving Test OracleBI Discoverer Data to a Production Environment
You have existing test and production environments that each include a middle-tier instance, an Identity Management installation with a Metadata Repository, and an additional Metadata Repository for OracleBI Discoverer metadata, and a database. OracleAS Portal metadata already exists in the test environment.
To migrate OracleBI Discoverer configuration, metadata, and database data:
Task 1: Copy Test Configuration Files
If you have changed the user preferences, copy the pref.txt file to the production environment.
If you have changed the OracleBI Discoverer settings, copy the configuration.xml file to the production environment.
If you have changed the server configuration settings, copy the opmn.xml file to the production environment.
If you have want to use the same database service entries in the production area, copy the tnsnames.ora file to the production environment.
Task 2: Migrate the Test DISCOVERER5 Schema
Perform "Move the Test Product Metadata Repository to Production", ensuring that you also move the DISCOVERER5 schema, which stores the OracleBI Discoverer metadata.
Task 3: Migrate the Test EUL and Catalog Data
Use the Discoverer Administrator to export the EUL schema from the test database, and then import it into the production database.
Run the eul5_id.sql script to give the new EUL a unique reference number. Having run the eul5_id.sql script, you can grant the entire Discoverer end user community access to the EUL.
Use the Application Server Control Console to export the Discoverer Catalog from the test database and import it into the production database.
|
See Also:
|
