Oracle® Application Server Administrator's Guide 10g Release 3 (10.1.3) B25209-03 |
|
![]() Previous |
![]() Next |
This chapter provides scenarios for moving J2EE applications 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. These scenarios use a release 10g (9.0.4) or 10g Release 2 (10.1.2) OracleAS Infrastructure.
It contains the following topics:
See the Oracle Application Server Upgrade and Compatibility Guide for information about the specific versions of OracleAS Infrastructure that are supported with 10g Release 3 (10.1.3).
Table 10-1 provides guidance on how to find the scenario that applies to your application and configuration environment.
Table 10-1 Test-to-Production Scenarios
Scenario | Configuration Assumptions | Refer To This Scenario: |
---|---|---|
Scenario 1 |
Test Environment: Middle-tier instance already exists. Production Environment: The production environment may not exist. You want to create a middle-tier instance. |
|
Scenario 2 |
Test Environment: Middle-tier instance and Oracle Identity Management already exists. Production Environment: The production environment does not exist. You want to create a middle-tier instance and Oracle Identity Management. |
|
Scenario 3 |
Test Environment: The test environment does not exist. You want to create a middle-tier instance and Oracle Identity Management. Production Environment: Oracle Identity Management already exists. You want to either create a middle-tier instance or configure the test middle-tier instance to point to the production Oracle Identity Management. |
|
In this scenario, you have a J2EE application on a test middle-tier instance without Oracle Identity Management. You want to create a new production environment that includes a middle-tier instance, and move the J2EE application. Figure 10-1 shows this scenario.
Figure 10-1 Moving a J2EE Application to a New Production Middle Tier Without Oracle Identity Management
This scenario assumes the following configuration:
You have an existing test environment that includes a middle-tier instance with a J2EE application.
The production environment may not exist.
For this scenario, you must create the production middle-tier instance.
To create the production middle-tier instance:
If the production middle tier does not exist, install it into the production environment.
Deploy J2EE application EAR files to the new middle tier. You can use one of the following mechanisms:
Use the admin_client.jar
utility with the -deploy
command.
Navigate to the OC4J Home page -> Applications tab in Oracle Enterprise Manager 10g Application Server Control Console, select the application, and click Deploy.
See Also:
|
After you deploy the applications, test them in the production environment.
In this scenario, you have a J2EE application on a test middle-tier instance with Oracle Identity Management. You want to create a new production environment that includes a 10g Release 3 (10.1.3) middle-tier instance with the J2EE application and a release 10g (9.0.4) or 10g Release 2 (10.1.2) Oracle Identity Management with a Metadata Repository. Figure 10-2 shows this scenario.
Figure 10-2 Moving a J2EE Application from a Test Middle Tier with Oracle Identity Management
This scenario assumes the following configuration:
The test environment includes a middle-tier instance with a J2EE application and a release 10g (9.0.4) or 10g Release 2 (10.1.2) Oracle Identity Management installation with a Metadata Repository.
The production middle-tier instance does not the exist, and the production Oracle Identity Management may exist.
For this scenario, you create the production environment by following these tasks:
If the production Oracle Identity Management and Metadata Repository does not exist, install and configure a release 10g (9.0.4) or 10g Release 2 (10.1.2) of 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 Oracle Identity Management and OracleAS Metadata Repository.
From the Select Configuration Options screen, choose Oracle Internet Directory.
Install the 10g Release 3 (10.1.3) production middle-tier instance.
Install Oracle Application Server using Oracle Universal Installer.
From Oracle Application Server 10g 10.1.3 Installation screen, follow the prompts to install the middle tier.
Deploy J2EE application EAR files to the new middle tier. You can use one of the following mechanisms:
Use the admin_client.jar
utility with the -deploy
command.
Navigate to the OC4J Home page -> Applications tab in Oracle Enterprise Manager 10g Application Server Control Console, select the application, and click Deploy.
See Also:
|
Perform these substeps for application usage:
Point the production middle-tier instance to the production Oracle Identity Management, as described in "Task 3: Change Middle-Tier Instances to the New Identity Management".
Use Delegated Administration Services to create any users needed for the redeployed J2EE applications, and grant the necessary permission for the applications.
Test the applications in the production environment.
In this scenario, you have an existing production environment that includes an Oracle 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 production Oracle Identity Management. The release 10g (9.0.4) or 10g Release 2 (10.1.2) Oracle Identity Management has its own Metadata Repository. The Oracle Internet Directory in the test Oracle 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 10g Release 3 (10.1.3) test middle-tier instance to test Oracle Identity Management.
After developing and testing your applications, create a production middle-tier instance or use the existing test middle-tier instance. The following sections explain how to configure this scenario. The first example describes how to create a new middle-tier instance, and the second example describes how to use the test middle-tier instance.
Figure 10-3 shows an example of this scenario in which you install a new 10g Release 3 (10.1.3) production middle-tier instance.
Figure 10-3 Example 1: Moving an Application from a Test Middle Tier with Oracle Identity Management to a New Production Environment
This scenario assumes the following configuration:
The test environment does not exist.
The production environment includes only a release 10g (9.0.4) or 10g Release 2 (10.1.2) Oracle Identity Management with a Metadata Repository.
This procedure contains the following tasks:
Task 1: Configure the Test Oracle Identity Management and Metadata Repository
To configure the test Oracle Identity Management and Metadata Repository, set up a release 10g (9.0.4) or 10g Release 2 (10.1.2) Oracle Identity Management in the test environment. Use these subtasks to perform this configuration:
Perform the procedure "Install and Set Up the Test Oracle Identity Management and Metadata Repository".
Perform the 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 10g Release 3 (10.1.3) middle-tier instance and develop and test applications. Use these subtasks to perform this configuration:
Perform the procedure "Install Test Middle-Tier Instance".
Associate the test Oracle Internet Directory with the test middle-tier instance.
See Also: Oracle Containers for J2EE Security Guide |
Perform the procedure "Develop and Test Your Applications".
Task 3: Set Up the Production Middle-Tier Instance
To install the 10g Release 3 (10.1.3) production middle-tier instance:
Install the production middle-tier instance.
Install Oracle Application Server using Oracle Universal Installer.
From Oracle Application Server 10g 10.1.3 Installation screen, follow the prompts to install the middle tier.
When you install, data in the test Oracle Identity Management is not migrated from to the production environment. You can choose instead to point the test middle-tier instance to the production Oracle Identity Management. See "Example 2: Pointing the Test Middle Tier to the Production Oracle Identity Management".
Task 4: Deploy Applications
To deploy applications:
Deploy J2EE application EAR files to the new middle tier. You can use one of the following mechanisms:
Use the admin_client.jar
utility with the -deploy
command.
Navigate to the OC4J Home page -> Applications tab in Oracle Enterprise Manager 10g Application Server Control Console, select the application, and click Deploy.
See Also:
|
Point the production middle-tier instance to the production Oracle Identity Management, as described in "Task 3: Change Middle-Tier Instances to the New Identity Management".
Use Delegated Administration Services to create any users needed for the redeployed J2EE applications, and grant the necessary permission for the applications.
Test the applications in the production environment.
Figure 10-3 shows an example of this scenario in which you point the test middle-tier instance to the production Oracle Identity Management.
Figure 10-4 Example 2: Moving an Application from a Test Middle Tier with Oracle Identity Management to a New Production Environment
This scenario assumes the following configuration:
The test environment does not exist.
The production environment includes only a release 10g (9.0.4) or 10g Release 2 (10.1.2) Oracle Identity Management with a Metadata Repository.
This procedure contains the following tasks:
Task 1: Configure the Test Oracle Identity Management and Metadata Repository
Task 3: Point the Test Middle-Tier Instance to the Production Oracle Identity Management
Task 1: Configure the Test Oracle Identity Management and Metadata Repository
To configure the test Oracle Identity Management and Metadata Repository, set up a release 10g (9.0.4) or 10g Release 2 (10.1.2) Oracle Identity Management in the test environment. Use these subtasks to perform this configuration:
Perform procedure "Install and Set Up the Test Oracle 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 10g Release 3 (10.1.3) middle-tier instance and develop and test applications. Use these subtasks to perform this configuration:
Perform the procedure "Install Test Middle-Tier Instance".
Associate the test Oracle Internet Directory with the test middle-tier instance.
See Also: Oracle Containers for J2EE Security Guide |
Perform procedure "Develop and Test Your Applications".
Task 3: Point the Test Middle-Tier Instance to the Production Oracle Identity Management
When you point the test middle-tier instance to the production Oracle Identity Management, you must also migrate data from the test Oracle Identity Management to the production Oracle Identity Management, and associate the production middle-tier instance with the production Oracle Identity Management.
To point the test middle-tier instance to the production Oracle Identity Management:
Perform the procedure "Clean Up Test Oracle Internet Directory".
Perform the procedure "Quiesce the Distributed Directory Environment".
Perform the procedure "End Pilot Mode on the Test Oracle Internet Directory".
Perform the procedure "Migrate Oracle Internet Directory Data to Production".
Perform the procedure "Task 3: Change Middle-Tier Instances to the New Identity Management".
Common procedures for Section 10.3 include:
Install and Set Up the Test Oracle Identity Management and Metadata Repository
In this procedure, you install and set up a release 10g (9.0.4) or 10g Release 2 (10.1.2) of the test Oracle Identity Management and its associated Metadata Repository. The test Oracle Identity Management is an LDAP-based replica of the original Oracle Identity Management.
Read Section F.1, "About LDAP-Based Replicas" to learn about LDAP-based Replicas and how they are used for this procedure.
Follow the procedure in Section F.2, "Installing and Setting Up an LDAP-Based Replica" to install and set up the test Oracle 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 the 10g Release 3 (10.1.3) test middle-tier instances and configure them to use the test Oracle Identity Management according to what you want to test:
Install Oracle Application Server using Oracle Universal Installer.
From Oracle Application Server 10g 10.1.3 Installation screen, follow the prompts to install the middle tier.
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:
|
Migrate Oracle Internet Directory Data to Production
This procedure describes how to migrate Oracle Internet Directory data from a test Oracle Identity Management to the production Oracle 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.