8 Creating a Domain for an Enterprise Deployment

This chapter describes how to create a domain using the Configuration Wizard, Oracle WebLogic Server Administration Console, Oracle Enterprise Manager, and Oracle WSM Policy Manager. You can extend the domain to add SOA components and, optionally, Oracle Business Activity Monitoring.

Note:

Before starting the setup process, read the Oracle Fusion Middleware Release Notes for additional installation and deployment information.

This chapter contains the following sections:

• Section 8.1, "Overview of Creating a Domain"

• Section 8.2, "Enabling VIP1 in SOAHOST1"

• Section 8.3, "Running the Configuration Wizard on SOAHOST1 to Create a Domain"

• Section 8.4, "Post-Configuration and Verification Tasks"

• Section 8.5, "Propagating the Domain Configuration to SOAHOST2"

• Section 8.6, "Configuring the Java Object Cache for Oracle WSM"

• Section 8.7, "Configuring Oracle HTTP Server for the WebLogic Domain"

• Section 8.8, "Backing Up the WebLogic Domain Configuration"

8.1 Overview of Creating a Domain

Table 8-1 lists the steps for creating a WebLogic domain, including post-configuration tasks.

Table 8-1 Steps for Creating a WebLogic Domain

Step	Description	More Information
Enabling VIP1 in SOAHOST1	Enable ADMINVHN for the SOAHOST1 hostname.	Section 8.2, "Enabling VIP1 in SOAHOST1"
Create a WebLogic Domain	Run the Configuration Wizard to create WebLogic domain.	Section 8.3, "Running the Configuration Wizard on SOAHOST1 to Create a Domain"
Post-Configuration and Verification Tasks	Follow the instructions for post-configuration and validation tasks.	Section 8.4, "Post-Configuration and Verification Tasks"
Propagate the Domain Configuration to SOAHOST2	Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory.	Section 8.5, "Propagating the Domain Configuration to SOAHOST2"
Configure the Oracle HTTP Server with the WebLogic domain	Configure the Oracle HTTP Server with the WebLogic domain and validate the configuration.	Section 8.7, "Configuring Oracle HTTP Server for the WebLogic Domain"
Back Up the Domain	Back up the newly configured WebLogic domain.	Section 8.8, "Backing Up the WebLogic Domain Configuration"

Once this domain is created and configured you can extend the domain to include Oracle SOA components, Oracle BAM, or Oracle BAM as described in the next chapters.

8.2 Enabling VIP1 in SOAHOST1

Please note that this step is required for failover of the Administration Server, regardless of whether or not SOA is installed.

You are associating the Administration Server with a virtual hostname (ADMINVHN). This Virtual Host Name must be mapped to the appropriate virtual IP (VIP1) either by a DNS Server or by a custom /etc/hosts entry. Check that ADMINVHN is available according to your name resolution system, (DNS server, /etc/hosts), in the required nodes in your SOA topology. The virtual IP (VIP1) that is associated to this Virtual Host Name (ADMINVHN) must be enabled in SOAHOST1.

To enable the virtual IP, see Section 3.5, "Enabling Virtual IP Addresses for Administration Servers."

8.3 Running the Configuration Wizard on SOAHOST1 to Create a Domain

Run the Configuration Wizard from the Oracle Common home directory to create a domain containing the Administration Server and Oracle Web Services Manager. Later, you will extend the domain to contain SOA components.

To create a domain:

1. Ensure that the database where you installed the repository is running. For Oracle RAC databases, all instances should be running, so that the validation check later in the procedure is more reliable.

2. Change directory to the location of the Configuration Wizard. This is within the SOA home directory. From SOAHOST1:

   cd ORACLE_COMMON_HOME/common/bin
   

3. Start the Oracle Fusion Middleware Configuration Wizard:

   ./config.sh
   

4. In the Welcome screen, select Create a New WebLogic Domain, and click Next.

5. The Select Domain Source screen appears (Figure 8-1).

   Figure 8-1 Select Domain Source Screen

   
   Description of "Figure 8-1 Select Domain Source Screen"
   
   

   In the Select Domain Source screen, do the following:

   • Select Generate a domain configured automatically to support the following products.

   • Select the following products:

     • Basic WebLogic Server Domain - 10.3.6.0 [wlserver_10.3] (this should be selected automatically)

     • Oracle Enterprise Manager - 11.1.1.0 [oracle_common]

     • Oracle WSM Policy Manager 11.1.1.0 [oracle_common]

     • Oracle JRF - 11.1.1.0 [oracle_common]

   If you accidentally deselect some of the targets, make sure that the following selections are made in this screen:

   • Oracle Enterprise Manager

   • Oracle WSM Policy Manager

   • Oracle JRF

   Click Next.

6. In the Specify Domain Name and Location screen, enter the domain name (soaedg_domain).

   Make sure that the domain directory matches the directory and shared storage mount point recommended in Chapter 4, "About Recommended Locations for the Different Directories." Enter the following for the domain directory:

   ORACLE_BASE/admin/domain_name/aserver/
   

   And the following for the application directory. This directory should be in shared storage:

   ORACLE_BASE/admin/domain_name/aserver/applications
   

7. Click Next.

8. In the Configure Administrator Username and Password screen, enter the username and password to be used for the domain's administrator.

   Click Next.

9. In the Configure Server Start Mode and JDK screen, do the following:

   • For WebLogic Domain Startup Mode, select Production Mode.

   • For JDK Selection, select JROCKIT SDK1.6.0_<version>.

   Click Next.

10. In the Configure JDBC Components Schema screen, do the following:

    • Select the OWSM MDS schema.

    • For the Oracle RAC configuration for component schemas, select Convert to GridLink.

    Click Next.

11. The Configure Gridlink RAC Component Schema screen appears (Figure 8-2).

    Figure 8-2 Configure GridLink RAC Component Schema Screen

    
    

    In this screen enter values for the following fields, specifying the connect information for the Oracle RAC database that was seeded with RCU:

    • Driver: Select Oracle's driver (Thin) for GridLinkConnections,Versions:10 and later.

    • Service Name: Enter the service name of the database using lowercase characters. For example:

      soaedg.mycompany.com.

    • Username: Enter the database schema owner name of the corresponding component.

    • Password: Enter the password for the database schema owner.

    • Select Enable FAN

    • Make sure Enable SSL is unchecked (alternatively if ssl is selected for ONS notifications to be encrypted, provide the appropriate wallet and wallet password).

    • Service listener: Enter the SCAN address and port for the RAC database being used. You can identify this address by querying the appropriate parameter in the database using the TCP protocol:

      SQL>show parameter remote_listener;
      
      NAME              TYPE                VALUE
      -------------------------------------------------------------
      remote_listener   string    db-scan.mycompany.com:1521
      

      Note:

      For Oracle Database 11g Release 1 (11.1), use the virtual IP and port of each database's instance listener, for example:

      custdbhost1-vip.mycompany.com (port 1521)
      

      and

      custdbhost2-vip.mycompany.com (1521)
      

      For Oracle Database 10g, use multi data sources to connect to an Oracle RAC database. For information about configuring multi data sources see Appendix A, "Using Multi Data Sources with Oracle RAC."

    • ONS Host: Enter the SCAN address for the Oracle RAC database and the ONS remote port as reported by the database:

      [orcl@db-scan1 ~]$ srvctl config nodeapps -s
       
      ONS exists: Local port 6100, remote port 6200, EM port 2016 
      

      Note:

      For Oracle Database 11g Release 1 (11.1), use the hostname and port of each database's ONS service, for example

      custdbhost1.mycompany.com (port 6200)
      

      and

      custdbhost2.mycompany.com (6200)
      

12. In the Test JDBC Data Sources screen, the connections are tested automatically. The Status column displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen and correct your entries.

    Click Next when all the connections are successful.

13. In the Select Advanced Configuration screen, select the following:

    • Administration Server

    • Managed Servers, Clusters and Machines

    • Deployment and Services

    Click Next.

14. In the Configure the Administration Server screen, enter the following values:

    • Name: AdminServer

    • Listen Address: enter ADMINVHN.

    • Listen Port: 7001

    • SSL listen port: N/A

    • SSL enabled: unchecked

    Click Next.

15. In the Configure Managed Servers screen, click Add to add the following managed servers:

    Table 8-2 Managed Servers

    Name	Listen Address	Listen Port	SSL Listen Port	SSL Enabled
    WLS_WSM1	SOAHOST1	7010	n/a	No
    WLS_WSM2	SOAHOST2	7010	n/a	No

    
    

    Click Next.

16. In the Configure Clusters screen, Click Add to add the following clusters:

    Table 8-3 Clusters

    Name	Cluster Messaging Mode	Multicast Address	Multicast Port	Cluster Address
    WSM-PM_Cluster	unicast	n/a	n/a	Leave it empty.

    
    

    Click Next.

17. In the Assign Servers to Clusters screen, assign servers to the WSM-PM_Cluster as follows:

    • WLS_WSM

    • WLS_WSM2

    Click Next.

18. In the Configure Machines screen, click the Unix Machine tab and then click Add to add the following machines:

    Note:

    "Name" can be any unique string. "Node Manager Listen Address" must be a resolvable host name.

    Table 8-4 Machines

    Name	Node Manager Listen Address
    SOAHOST1	SOAHOST1
    SOAHOST2	SOAHOST2
    ADMINHOST	localhost

    
    

    Leave all other fields to their default values.

    Note:

    The machine name does not need to be a valid host name or listen address; it is just a unique identifier of a Node Manager location

    Click Next.

19. In the Assign Servers to Machines screen, assign servers to machines as follows:

    • SOAHOST1: WLS_WSM1

    • SOAHOST2: WLS_WSM2

    • ADMINHOST: AdminServer

    Click Next.

20. In the Target Deployments to Clusters or Servers screen, make sure that the wsm-pm application is targeted to the WSM-PM_Cluster only. Target the library oracle.wsm.seedpolicies to WSM-PM_Cluster. Make sure that all other deployments are targeted to the AdminServer and click Next.

21. In the Target Services to Clusters or Servers screen, select the following:

    • On the left, select WSM-PM_Cluster. On the right, select JDBC System Resource (this automatically selects all the wsm datasources (mds-owsm)).

    • On the left, select Admin Server. On the right, select JDBC System Resource (this automatically selects all the wsm datasources (mds-owsm)).

    All JDBC system resources should be targeted to both the Admin Server and WSM-PM_Cluster.

    • Make sure that all the remaining services are targeted to the Admin Server.

    • Click Next.

    For information on targeting applications and resources, see Appendix B, "Targeting Applications and Resources to Servers."

22. In the Configuration Summary screen, click Create.

23. In the Create Domain screen, click Done.

8.4 Post-Configuration and Verification Tasks

After configuring the domain with the configuration Wizard, follow these instructions for post-configuration and verification.

This section includes the following topics:

• Section 8.4.1, "Creating boot.properties for the Administration Server on SOAHOST1"

• Section 8.4.2, "Starting Node Manager on SOAHOST1"

• Section 8.4.3, "Starting the Administration Server on SOAHOST1"

• Section 8.4.4, "Validating GridLink Data Sources"

• Section 8.4.5, "Validating the Administration Server Configuration"

• Section 8.4.6, "Creating a Separate Domain Directory for Managed Servers in the Same Node as the Administration Server"

• Section 8.4.7, "Applying the Java Required Files (JRF) Template to the WSM-PM_Cluster"

• Section 8.4.8, "Disabling Host Name Verification"

• Section 8.4.9, "Starting and Validating the WLS_WSM1 Managed Server"

8.4.1 Creating boot.properties for the Administration Server on SOAHOST1

Create a boot.properties file for the Administration Server on SOAHOST1. This is a required step that enables you to start the Administration Server using Node Manager.

To create a boot.properties file for the Administration Server:

1. Create the following directory structure:

   mkdir -p ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security
   

2. In a text editor, create a file called boot.properties in the last directory created in the previous step, and enter the following lines in the file:

   username=<adminuser>
   password=<password>
   

   Note:

   When you start the Administration Server, the username and password entries in the file get encrypted. You start the Administration Server in Section 8.4.3, "Starting the Administration Server on SOAHOST1."

   For security reasons, you want to minimize the time the entries in the file are left unencrypted: after you edit the file, you should start the server as soon as possible so that the entries get encrypted.

3. Save the file and close the editor.

8.4.2 Starting Node Manager on SOAHOST1

To start Node Manager on SOAHOST1, set the StartScriptEnabled property to 'true,' and then start Node Manager using startNodeManager.sh.

To start Node Manager on SOAHOST1:

1. Run the setNMProps.sh script located in the following directory:

   ORACLE_COMMON_HOME/common/bin
   

   Set the StartScriptEnabled property to 'true' before starting Node Manager:

   cd ORACLE_COMMON_HOME/common/bin
   ./setNMProps.sh
   

   Note:

   You must use the StartScriptEnabled property to avoid class loading failures and other problems. For more information, see also Section 16.14.5, "Incomplete Policy Migration After Failed Restart of SOA Server."

2. Start Node Manager:

   cd WL_HOME/server/bin
   export JAVA_OPTIONS="-DDomainRegistrationEnabled=true"
   ./startNodeManager.sh
   

   Note:

   It is important that you set -DDomainRegistrationEnabled=true whenever a Node Manager that manages the AdminServer is started. If there is no AdminServer on this machine and this machine is not an AdminServer failover node, you can start the Node Manager using the following command from SOAHOAST1:

   ./startNodeManager.sh
   

8.4.3 Starting the Administration Server on SOAHOST1

The Administration Server is started and stopped using Node Manager. However, the first start of the Administration Server with Node Manager, requires changing the defaulted username and password that are set for Node Manager by the Configuration Wizard. Therefore, use the start script for the Administration Server for the first start.

Steps 1-4 are required for the first start operation, subsequent starts require only step 4.

To start the Administration Server using Node Manager:

1. Start the Administration Server using the start script in the domain directory on SOAHOST1:

   cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin
   ./startWebLogic.sh
   

2. Use the Administration Console to update the Node Manager credentials.

   1. In a browser, go to the following URL:

      http://ADMINVHN:7001/console
      

   2. Log in as the administrator.

   3. Click Lock & Edit.

   4. Click domain_name, (Security) tab, General, and then expand the Advanced options at the bottom.

   5. Enter a new username for Node Manager, or make a note of the existing one and update the Node Manager password.

   6. Click Save and Activate Changes.

3. Stop the Administration Server process by using CTRL-C in the shell where it was started, or by process identification and kill in the OS.

4. Start WLST and connect to Node Manager with nmconnect and the credentials set in the previous steps and start the Administration Server using nmstart. Enter the Node Manager Username and password that you entered in step 2e.

   cd ORACLE_COMMON_HOME/common/bin
   ./wlst.sh
   

   Once you are in the WLST shell:

   wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
   'SOAHOST1','5556','domain_name','ORACLE_BASE/admin/domain_name/aserver/domain_name')
    
   wls:/nm/domain_name nmStart('AdminServer')
   

   Note:

   This username and password are used only to authenticate connections between Node Manager and clients. They are independent of the server admin ID and password and are stored in the nm_password.properties file located in the following directory:

   ORACLE_BASE/admin/domain_name/aserver/domain_name/config/nodemanager
   

8.4.4 Validating GridLink Data Sources

When the servers are started, verify that the GridLink data sources are correctly configured and that the ONS setup is correct. Perform this procedure for every GridLink data source created.

To validate the GridLink data sources configuration:

1. Log on to the Oracle WebLogic Administration Console.

2. In the Domain Structure tree, expand Services, and select Data Sources.

3. Click one of the new data sources.

4. Click the Monitoring tab and select one of the servers.

5. Click the Statistics tab and select one of the servers.

6. Click the ONS tab, and then click the Testing tab.

7. Select the server and click Test ONS.

   If both tests are successful, the configuration is correct. If the ONS test fails, verify that the ONS service is running in the RAC database nodes:

   orcl@db-scan1 ~]$ srvctl status scan_listener
   SCAN Listener LISTENER_SCAN1 is enabled
   SCAN listener LISTENER_SCAN1 is running on node db-scan1
   SCAN Listener LISTENER_SCAN2 is enabled
   SCAN listener LISTENER_SCAN2 is running on node db-scan2
   SCAN Listener LISTENER_SCAN3 is enabled
   SCAN listener LISTENER_SCAN3 is running on node db-scan2
    
   [orcl@db-scan1 ~]$ srvctl config nodeapps -s 
   ONS exists: Local port 6100, remote port 6200, EM port 2016
    
   [orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
   ONS is enabled
   ONS daemon is running on node: db-scan1
   ONS daemon is running on node: db-scan2
   

Run the ONS test from every WebLogic server that uses the data source.

8.4.5 Validating the Administration Server Configuration

To ensure that the Administration Server for the domain you have created is properly configured, validate the configuration by logging into the Oracle WebLogic Server Administration Console and verifying the managed servers and the cluster are listed, and log into Oracle Enterprise Manager.

To verify that the Administration Server is properly configured:

1. In a browser, go to the following URL:

   http://ADMINVHN:7001/console
   

2. Log in as the administrator.

3. Verify that the WLS_WSM1 and WLS_WSM2 managed servers are listed.

4. Verify that the WSM-PM_Cluster cluster is listed.

5. Check that you can access Oracle Enterprise Manager at the following URL:

   http://ADMINVHN:7001/em
   

6. Log in to EM Console with the username and password you specified in Section 8.4.1, "Creating boot.properties for the Administration Server on SOAHOST1."

8.4.6 Creating a Separate Domain Directory for Managed Servers in the Same Node as the Administration Server

Use the pack and unpack commands to separate the domain directory used by the Administration Server from the domain directory used by the managed server in SOAHOST1 as recommended in Chapter 4, "Preparing the File System for an Enterprise Deployment."

Before running the unpack script, be sure the following directory exists as explained in Section 4.3, "About Recommended Locations for the Different Directories."

ORACLE_BASE/admin/domain_name/mserver

To create a separate domain directory:

1. Run the pack command on SOAHOST1 to create a template pack as follows:

   cd ORACLE_COMMON_HOME/common/bin
    
   ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=soadomaintemplate.jar -template_name=soa_domain_template
   

2. Run the unpack command on SOAHOST1 to unpack the template in the managed server domain directory as follows:

   cd ORACLE_COMMON_HOME/common/bin
   
   ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name 
   -template=soadomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
   

Note:

You must have write permissions on the following directory before running the unpack command:

/ORACLE_BASE/admin/domain_name

For example:

ORACLE_BASE/admin/soaedg_domain/

Note:

The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.

8.4.7 Applying the Java Required Files (JRF) Template to the WSM-PM_Cluster

After the domain is created with the Configuration Wizard, you must target a number of resources not included in the WebLogic server installation to the WSM-PM_Cluster.

To target these resources:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control with the username and password you specified in Section 8.4.1, "Creating boot.properties for the Administration Server on SOAHOST1."

2. On the navigation tree on the left, expand Farm_<domain_name>, WebLogic Domain, and then <domain_name>, and select WSM-PM_Cluster.

3. Click Apply JRF Template on the right.

4. Wait for the confirmation message to appear on the screen.

   This message should confirm that the JRF Template has been successfully applied to the WSM-PM_Cluster cluster.

5. Repeat the steps for the Administration Server.

   Expand Farm_<domain_name>, WebLogic Domain, and then <domain_name>, and select Admin server.

For information on targeting applications and resources, see Appendix B, "Targeting Applications and Resources to Servers."

8.4.8 Disabling Host Name Verification

This step is required because you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server (see Chapter 13, "Setting Up Node Manager for an Enterprise Deployment"). Because you have not configured the server certificates, you receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the Enterprise Deployment topology configuration is complete as described in Chapter 13, "Setting Up Node Manager for an Enterprise Deployment."

To disable host name verification:

1. Log in to Oracle WebLogic Server Administration Console.

2. Click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers. The Summary of Servers page appears.

5. Select AdminServer(admin) in the Names column of the table. The Settings page for AdminServer(admin) appear.

6. Click the SSL tab.

7. Click Advanced.

8. Set Hostname Verification to None.

9. Click Save.

10. Repeat steps 5 to 9for the WLS_WSM1 server.

11. Save and activate the changes.

12. Restart the Administration Server for the changes to take effect.

    To restart the Administration Server:

    1. In the Summary of Servers screen, select the Control tab.

    2. Select AdminServer(admin) in the table and then click Shutdown.

    3. Start the Administration Server again using the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."

8.4.9 Starting and Validating the WLS_WSM1 Managed Server

After configuring the managed server, start it and check to confirm that it is running properly. You can start the managed server and check its status by using the Oracle WebLogic Server Administration Console.

To start the WLS_WSM1 managed server and check that it is configured correctly:

1. Start the WLS_WSM1 managed server using the Oracle WebLogic Server Administration Console as follows:

   1. Expand the Environment node in the Domain Structure window.

   2. Choose Servers. The Summary of Servers page appears.

   3. Click the Control tab.

   4. Select WLS_WSM1 and then click Start.

2. Verify that the server status is reported as Running in the Admin Console. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported (such as Admin or Failed), check the server output log files for errors. See Section 16.14, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.

3. Access the following URL:

   http://SOAHOST1:7010/wsm-pm
   

4. Click Validate Policy Manager.

   If the configuration is correct, a list of policies and assertion templates available in the data store appear. If the configuration is not correct, no policies or assertion templates appear.

8.5 Propagating the Domain Configuration to SOAHOST2

After completing the configuration of SOAHOST1, propagate the configuration to SOAHOST2 using the unpack utility, and then validate the propagated configuration.

This section includes the following topics:

• Section 8.5.1, "Propagating the Domain Configuration to SOAHOST2 Using the unpack Utility"

• Section 8.5.2, "Modify the Upload and Stage Directories to an Absolute Path"

• Section 8.5.3, "Disabling Host Name Verification for the WLS_WSM2 Managed Server"

• Section 8.5.4, "Starting Node Manager on SOAHOST2"

• Section 8.5.5, "Starting and Validating the WLS_WSM2 Managed Server"

8.5.1 Propagating the Domain Configuration to SOAHOST2 Using the unpack Utility

Propagate the domain configuration using the unpack utility. Before running the unpack script, be sure the following directory exists as explained in Section 4.3, "About Recommended Locations for the Different Directories."

ORACLE_BASE/admin/domain_name/mserver

To propagate the domain configuration:

1. Run the following command on SOAHOST1 to copy the template file created previously.

   cd ORACLE_COMMON_HOME/common/bin
   

   scp soadomaintemplate.jar oracle@SOAHOST2:/ORACLE_COMMON_HOME/common/bin
   

2. Run the unpack command from the ORACLE_COMMON_HOME/common/bin directory, not from the WL_HOME/common/bin directory on SOAHOST2 to unpack the propagated template.

   cd ORACLE_COMMON_HOME/common/bin
   
   ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name
   -template=soadomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
   

Note:

The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.

8.5.2 Modify the Upload and Stage Directories to an Absolute Path

After creating the domain and unpacking to the mserver directory, update the upload and stage directories. These directories are defaulted to:

./servers/AdminServer/upload

and

./servers/server_name/stage

As a result, these default directory paths create issues for remote deployments and for deployments using the stage mode.

To avoid these issues, update the upload directory to:

/u11/app/oracle/admin/domain_name/aserver/domain_name/servers/AdminServer/upload

And update the stage directory to:

/u11/app/oracle/admin/domain_name/mserver/domain_name/servers/server_name/stage

Update these directory paths for all servers.

To update these directories:

1. Access the Administration Console.

2. In the left navigation tree, expand Domain, and then Environment.

3. Click on Servers, and then the server's name.

4. Under the Configuration, and then Deployments section, change the Upload and Stage directories.

8.5.3 Disabling Host Name Verification for the WLS_WSM2 Managed Server

For the enterprise deployment described in this guide, you set up the appropriate certificates to authenticate the different nodes with the Administration Server after you have completed the procedures to extend the domain for Oracle SOA Suite. You must disable the host name verification for the WLS_SOA1 and WLS_SOA2 managed servers to avoid errors when managing the different WebLogic Server instances. For more information, see Section 8.4.8, "Disabling Host Name Verification."

You enable host name verification again once the enterprise deployment topology configuration is complete. For more information, see Section 13.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1."

8.5.4 Starting Node Manager on SOAHOST2

Once you have propagated the domain configuration and disabled host name verification, start Node Manager using the StartNodeManager.sh script.

You must use the StartScriptEnabled property to avoid class loading failures and other problems. See also Section 16.14.5, "Incomplete Policy Migration After Failed Restart of SOA Server."

To start Node Manager on SOAHOST2:

1. Run the setNMProps.sh script, which is located in the ORACLE_COMMON_HOME/common/bin directory, to set the StartScriptEnabled property to 'true' before starting Node Manager:

   cd ORACLE_COMMON_HOME/common/bin
   ./setNMProps.sh
   

2. Start Node Manager:

   cd WL_HOME/server/bin
   ./startNodeManager.sh
   

8.5.5 Starting and Validating the WLS_WSM2 Managed Server

Use the Administration Console to start and validate the WLS_WSM2 managed server.

To start the WLS_WSM2 managed server and check that it is configured correctly:

1. Start the WLS_WSM2 managed server using the Administration Console.

2. Verify that the server status is reported as Running in the Admin Console. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported (such as Admin or Failed), check the server output log files for errors. See Section 16.14, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.

3. Access the following URL:

   http://SOAHOST2:7010/wsm-pm
   

4. Click validate policy manager.

8.6 Configuring the Java Object Cache for Oracle WSM

Configure the Java Object Cache (JOC) among all the servers running Oracle WSM. This procedure is optional, but increases the performance of Oracle WSM by keeping a local cache instead of having to search for a cache.

Use JOC for MDS updates in B2B if you are planning to change the delivery channels for B2B agreements frequently.

Configure the Java Object Cache using the configure-joc.py script in the following directory:

MW_HOME/oracle_common/bin/

This is a Python script that runs in WLST online mode and expects the Administration Server to be up and running.

Use ports in the 9988 to 9998 range when configuring JOC ports for Oracle products.

To configuring the Java Object Cache for Oracle WSM:

1. Connect to the Administration Server on SOAHOST1 using the command-line Oracle WebLogic Scripting Tool (WLST), for example:

   MW_HOME/soa/common/bin/wlst.sh
   connect()
   

   When prompted, enter the server URL (t3://ADMINVHN:7001) and the Oracle WebLogic Server administrator user name and password.

2. After connecting to the Administration Server using wlst, start the script using the execfile command, for example:

   wls:/mydomain/serverConfig> execfile('MW_HOME/oracle_common/bin/configure-joc.py')
   

3. Configure JOC for all the managed servers for a given cluster.

   Enter 'y' when the script prompts whether you want to specify a cluster name, and also specify the cluster name and discover port, when prompted. This discovers all the managed servers for the given cluster and configure the JOC. The discover port is common for the entire JOC configuration across the cluster. For example:

   Do you want to specify a cluster name (y/n) <y>
   Enter Cluster Name : WSM-PM_Cluster
   Enter Discover Port : 9991
   

   Here is a walkthrough for using configure-joc.py for HA environments:

   execfile('MW_HOME/oracle_common/bin/configure-joc.py')
   .
   Enter Hostnames (eg host1,host2) : SOAHOST1,SOAHOST2
   .
   Do you want to specify a cluster name (y/n) <y>y
   .
   Enter Cluster Name : WSM-PM_Cluster
   .
   Enter Discover Port : 9991
   .
   Enter Distribute Mode (true|false) <true> : true
   .
   Do you want to exclude any server(s) from JOC configuration (y/n) <n> n
   

4. After configuring the Java Object Cache using the wlst commands or configure-joc.py script, restart all affected managed servers for the configurations to take effect.

The script can also be used to perform the following optional JOC configurations:

• Configure JOC for all specified managed servers.

  Enter 'n' when the script prompts whether you want to specify a cluster name, and also specify the managed server and discover port, when prompted. For example:

  Do you want to specify a cluster name (y/n) <y>n
  Enter Managed Server and Discover Port (eg WLS_WSM1:9998, WLS_WSM1:9998) : WLS_WSM1:9991,WLS_WSM2:9991
  

• Exclude JOC configuration for some managed servers.

  The script allows you to specify the list of managed servers for which the JOC configuration "DistributeMode" will be set to 'false'. Enter 'y' when the script prompts whether you want to exclude any servers from JOC configuration, and enter the managed server names to be excluded, when prompted. For example:

  Do you want to exclude any server(s) from JOC configuration (y/n) <n>y
  Exclude Managed Server List (eg Server1,Server2) : WLS_WSM1,WLS_WSM3
  

• Disable the distribution mode for all managed servers.

  The script allows you to disable the distribution to all the managed servers for a specified cluster. Specify 'false' when the script prompts for the distribution mode. By default, the distribution mode is set to 'true'.

Verify JOC configuration using the CacheWatcher utility. See Oracle Fusion Middleware High Availability Guide.

You can configure the Java Object Cache (JOC) using the HA Power Tools tab in the Oracle WebLogic Administration Console as described in the Oracle Fusion Middleware High Availability Guide.

8.7 Configuring Oracle HTTP Server for the WebLogic Domain

This section describes tasks for configuring Oracle HTTP Server for the WebLogic Domain, and for verifying the configuration.

This section includes the following topics:

• Section 8.7.1, "Configuring Oracle HTTP Server for the Administration Server and the WLS_WSMn Managed Servers"

• Section 8.7.2, "Turning on the WebLogic Plug-In enabled Flag"

• Section 8.7.3, "Registering Oracle HTTP Server With WebLogic Server"

• Section 8.7.4, "Setting the Frontend URL for the Administration Console and Setting Redirection Preferences"

• Section 8.7.5, "Validating Access Through Oracle HTTP Server"

• Section 8.7.6, "Verifying Manual Failover of the Administration Server"

8.7.1 Configuring Oracle HTTP Server for the Administration Server and the WLS_WSMn Managed Servers

To enable Oracle HTTP Server to route to the Administration Server and the WSM-PM_Cluster, which contain the WLS_WSMn managed servers, you must set the WebLogicCluster parameter to the list of nodes in the cluster.

To set the WebLogicCluster parameter:

1. On WEBHOST1 and WEBHOST2, add directives to the admin_vh.conf and soainternal_vh.conf files located in the following directory:

   ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf
   

   Note that this assumes you created the admin_vh.conf and soainternal_vh.conf files using the instructions in Section 7.6, "Defining Virtual Hosts."

   Add the following directives to the admin_vh.conf file within the <VirtualHost> tags.

   # Admin Server and EM
   <Location /console>
       SetHandler weblogic-handler
       WebLogicHost ADMINVHN
       WeblogicPort 7001
   </Location>
   
   <Location /consolehelp>
       SetHandler weblogic-handler
       WebLogicHost ADMINVHN
       WeblogicPort 7001
   </Location>
   
   <Location /em>
       SetHandler weblogic-handler
       WebLogicHost ADMINVHN
       WeblogicPort 7001
   </Location>
   

   The admin_vh.conf file will appear as it does in Example 8-1.

2. Add the following directives to the soainternal_vh.conf file within the <VirtualHost> tags:

   # WSM-PM
   <Location /wsm-pm>
       SetHandler weblogic-handler
       WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
       WLProxySSL ON
       WLProxySSLPassThrough ON
   </Location>
   

   The soainternal_vh.conf file will appear as it does in Example 8-2.

3. Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2.

   WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1
   
   WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2
   

Example 8-1 admin_vh.conf file

# The admin URLs should only be accessible via the admin virtual host 

<VirtualHost *:7777>
    ServerName admin.mycompany.com:80
    ServerAdmin [e-mail]
    RewriteEngine On
    RewriteOptions inherit

# Admin Server and EM
<Location /console>
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /consolehelp>
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /em>
    SetHandler weblogic-handler
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>
</VirtualHost>

Example 8-2 soainternal_vh.conf file

<VirtualHost *:7777>
    ServerName soainternal.mycompany.com:80
    ServerAdmin [e-mail]
    RewriteEngine On
    RewriteOptions inherit

# WSM-PM
<Location /wsm-pm>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
</VirtualHost>

The servers specified in the WebLogicCluster parameter are only important at startup time for the plug-in. The list needs to provide at least one running cluster member for the plug-in to discover other members of the cluster. Note that the listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.

Some example scenarios:

• Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member will be discovered on the fly at runtime.

• Example 2: You have a three-node cluster but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.

  If you list all members of the cluster, then you guarantee you can route to the cluster, assuming at least one member is running when Oracle HTTP Server is started.

For more information on configuring the WebLogic Server plug-in, see the Oracle Fusion Middleware Using Web Server Plug-Ins With Oracle WebLogic Server guide.

8.7.2 Turning on the WebLogic Plug-In enabled Flag

For security purposes, and since the load balancer terminates SSL request (Oracle HTTP Server routes the requests as non-SSL to WebLogic Server), once you configure SSL for the load balancer, turn on the WebLogic plug-in enabled flag for the domain.

To turn on the WebLogic plug-in enabled flag:

1. Log on to the Administration Console.

2. Click on the domain name in the navigation tree on the left.

3. Click on the Web Applications tab.

4. Click Lock & Edit.

5. Select the WebLogic Plugin Enabled check box.

6. Save and activate the changes.

8.7.3 Registering Oracle HTTP Server With WebLogic Server

Once an Oracle WebLogic domain is created, the Oracle Web Tier can be linked to the domain. The advantage of doing this is that the Oracle Web Tier can be managed and monitored using the Oracle Enterprise Manager Fusion Middleware Control.

To associate the Oracle Web Tier with the WebLogic domain use the following commands:

WEBHOST1> cd ORACLE_BASE/admin/instance_name/bin

WEBHOST1> ./opmnctl registerinstance -adminHost ADMINVHN -adminPort 7001 -adminUsername weblogic

You must also run this command from WEBHOST2 for OHS2.

After registering Oracle HTTP Server, it should appear as a manageable target in the Oracle Enterprise Manager Console. To verify this, log in to the Enterprise Manager Console. The WebTier item in the navigation tree should show that Oracle HTTP Server has been registered.

8.7.4 Setting the Frontend URL for the Administration Console and Setting Redirection Preferences

When you access the Oracle WebLogic Server Administration Console using a load balancer, changing the Administration Server's frontend URL is required so that the user's browser is redirected to the appropriate load balancer address.

The Oracle WebLogic Server Administration Console application tracks changes made to ports, channels and security using the console. When changes made through the console are activated, the console validates its current listen address, port and protocol. If the listen address, port and protocol are still valid, the console redirects the HTTP request replacing the host and port information with the Administration Server's listen address and port.

To change the Administration Server's frontend URL:

1. Log in to Oracle WebLogic Server Administration Console.

2. Click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers to open the Summary of Servers page.

5. Select Admin Server in the Names column of the table. The Settings page for AdminServer(admin) appears.

6. Click the Protocols tab.

7. Click the HTTP tab.

8. Set the Frontend Host to admin.mycompany.com and the Frontend HTTP Port to 80 (modify accordingly if HTTPS is used for the admin URL).

9. Save and activate the changes.

10. Disable tracking on configuration changes in the Oracle WebLogic Server Administration Console so that the console does not trigger the reload of configuration pages when activation of changes occurs.

    1. Log in to the Oracle WebLogic Server Administration Console.

    2. Click the preferences link in the banner.

    3. Click the shared preferences tab.

    4. Deselect the follow configuration changes check box.

Note:

If you have any issues activating any configuration changes after modifying the Frontend Host and Port settings, then refer to Section 16.14.14, "Redirecting of Users to Login Screen After Activating Changes in Administration Console."

8.7.5 Validating Access Through Oracle HTTP Server

To validate access through Oracle HTTP Server:

Verify that the server status is reported as Running in the Admin Console. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported (such as Admin or Failed), check the server output log files for errors. See Section 16.14, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.

Validate WSM-PM_Cluster through both Oracle HTTP Server using the following URLs:

• http://WEBHOST1:7777/wsm-pm

• http://WEBHOST2:7777/wsm-pm

• http://WEBHOST1:7777/console

• http://WEBHOST2:7777/console

• http://WEBHOST1:7777/em

• http://WEBHOST2:7777/em

• https://soa.mycompany.com/wsm-pm

• http://admin.mycompany.com/console

• http://admin.mycompany.com/em

After setting the frontend URL to the load balancer address, access to the console through the WEBHOSTn addresses will be redirected by the console to the frontend URL, thus validating the correct configuration of both Oracle HTTP Server and the load balancer.

For information on configuring system access through the load balancer, see Section 3.3, "Configuring the Load Balancers."

After the registering Oracle HTTP Server as described in Section 8.7.3, "Registering Oracle HTTP Server With WebLogic Server," the Oracle HTTP Server should appear as a manageable target in the Oracle Enterprise Manager Console. To verify this, log into the Enterprise Manager Console. The WebTier item in the navigation tree should show that Oracle HTTP Server has been registered.

8.7.6 Verifying Manual Failover of the Administration Server

After configuring the domain, test failover by following the steps in Section 16.7, "Verifying Manual Failover of the Administration Server."

8.8 Backing Up the WebLogic Domain Configuration

Perform a backup to save your domain configuration. Make sure you stop the server first. The configuration files are located in the following directory:

ORACLE_BASE/admin/domain_name

To back up the domain configuration run the following command on SOAHOST1:

tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name

Back up the Instance Home on the web tier using the following command:

tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE