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 WebCenter Portal components.

Note:

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

This chapter includes the following topics:

8.1 Overview of Creating a Domain

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

Table 8-1 Steps for Creating a WebLogic Server domain

Step Description More Information

Enable VIP1 in SOAHOST1

Enable a VIP1 for the SOAHOST1 hostname.

Section 8.2, "Enabling VIP1 in SOAHOST1"

Create a WebLogic Server Domain

Run the Configuration Wizard to create WebLogic Server domain.

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

Perform 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 Server Domain

Configure the Oracle HTTP Server with the WebLogic Server domain and validate the configuration.

Section 8.7, "Configuring Oracle HTTP Server for the WebLogic Server domain"

Back Up the Domain

Back up the newly configured WebLogic Server domain.

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


Once this domain is created and configured you can extend the domain to include Oracle WebCenter Portal components, Oracle SOA Suite, Oracle WebCenter Content, and so on, described in the next chapters.

8.2 Enabling VIP1 in SOAHOST1

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 WebCenter Portal 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 an Enterprise Deployment".

Check that the virtual hosts are enabled as shown in Table 8-2.

Table 8-2 Virtual Hosts

VIP Enabled on Host

ADMINVHN.example.com

SOAHOST1

SOAHOST1VHN1.example.com

SOAHOST1

SOAHOST2VHN1.example.com

SOAHOST2


Note:

This is the DNS name associated with the floating IP address. It is not the DNS name of the virtual host configured on the load balancer.

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 WebCenter Portal, SOA, and WebCenter Content 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. On SOAHOST1, change directory to the location of the Configuration Wizard:

    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.

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

    Figure 8-1 Select Domain Source Screen

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

  5. 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] (this should be selected automatically)

    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.

    Note:

    If multiple Oracle Homes are installed (for example a WebCenter Portal Home and a SOA Home), available products will show up for both homes. In this step, select only products from the Oracle Common home (oracle_common). This is indicated by brackets at the end of the product name; for example, "Oracle JRF - 11.1.1.0 [oracle_common]."
  6. In the Specify Domain Name and Location screen, enter the domain name (for example, wcpedg_domain).

    Make sure that the domain location matches the directory and shared storage mount point recommended in Chapter 3, "Preparing the Network for an Enterprise Deployment".

    For the domain location enter:

    ORACLE_BASE/admin/domain_name/aserver
    

    For the application location, enter (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>.

      Note:

      The examples documented in this guide use JRockit. Any certified version of Java can be used unless otherwise noted.

    Click Next.

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

    1. Select the OWSM MDS schema.

    2. For the RAC configuration, you can select Convert to GridLink or Convert to RAC multi data source (described in Appendix A, "Using Multi Data Sources with Oracle RAC").

      For the instructions given here, select Convert to GridLink.

    3. Click Next.

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

    Figure 8-2 Configure GridLink RAC Component Schema

    Description of Figure 8-2 follows
    Description of "Figure 8-2 Configure GridLink RAC Component Schema"

    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 Oracle RAC database in lowercase letters, followed by the domain name. For example, wcpedg.example.com.

    • Username: Enter the complete user name (including the prefix) for the database schema owner 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 Oracle Single Client Access Name (SCAN) address and port for the Oracle RAC database being used. The protocol should be TCP.

      Oracle recommends that you use SCAN addresses to specify the Service Listener (and OSN Host) so you do not need to update a GridLink data source containing SCAN addresses if you add or remove Oracle RAC nodes. To determine the SCAN address, query the remote_listener parameter in the database using the TCP protocol:

      SQL>show parameter remote_listener;
       
      NAME              TYPE        VALUE
      -----             ------      -------
      remote_listener   string      custdbhost.example.com:1521
      

      Note:

      For database versions that do not support SCAN:
      • For Oracle Database 11g Release 1 (11.1), enter the Virtual IP and port of each database's instance listener, for example:

        custdbhost1-vip.example.com (Port 1521)

        and

        custdbhost2-vip.example.com (Port 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@CUSTDBHOST1 ~]$ srvctl config nodeapps -s
      ONS exists: Local port 6100, remote port 6200, EM port 2016
      

      Note:

      For Oracle Database 11g Release 1 (11.1), enter the host name and port for the database's ONS service. For example:

      custdbhost1.example.com (Port 6200)

      and

      custdbhost2.example.com (Port 6200)

  12. In the Test JDBC Component Schema screen, the connections should be 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 Optional 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: 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-3 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-4 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 clusters as follows:

    • WSM-PM_Cluster:

      • WLS_WSM1

      • WLS_WSM2

    Click Next.

  18. In the Configure Machines screen, do the following:

    • Click the Unix Machine tab and then click Add to add the following machines.

      Table 8-5 Machines

      NameFoot 1  Node Manager Listen AddressFoot 2 

      SOAHOST1

      SOAHOST1

      SOAHOST2

      SOAHOST2

      ADMINHOST

      localhost


      Footnote 1 Can be any unique string

      Footnote 2 Must be a resolvable host name

      Leave all other fields with their default values.

      Note:

      The Node Manager listen address for ADMINHOST must point to localhost because localhost is the relative internal address for whatever machine is active. The Node Manager instance associated with the Administration Server changes when the Administration Server fails over because the Administration Server uses the localhost attribute in conjunction with the first host and then again, after failover, in conjunction with the second host.

    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 only to WSM-PM_Cluster. Make sure that all other deployments are targeted to AdminServer. 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.

  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:

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=Admin_Username
    password=Password
    

    Note:

    When you start the Administration Server, the user name 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 the "Incomplete Policy Migration After Failed Restart of SOA Server" section in the Enterprise Deployment Guide for Oracle SOA Suite.
  2. Start Node Manager:

    nohup $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh \
            > $MW_HOME/wlserver_10.3/common/nodemanager/nodemanager.out 2>&1 &
    

    Note:

    It is important that you set -DDomainRegistrationEnabled=true whenever a Node Manager instance is started that must manage the Administration Server. This is due to the fact that the Administration Server domain home does not exist in the Node Manager domains file, and you must use dynamic registration of the domain. Oracle does not recommend using this parameter except in the case specified here.

    If there is no Administration Server on this machine and this machine is not an Administration Server failover node, you should start Node Manager as follows:

    ./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, 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 operating system.

  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 user name 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 Configuration

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@CUSTDBHOST1 ~]$ srvctl status scan_listener
    SCAN Listener LISTENER_SCAN1 is enabled
    SCAN listener LISTENER_SCAN1 is running on node CUSTDBHOST1
    SCAN Listener LISTENER_SCAN2 is enabled
    SCAN listener LISTENER_SCAN2 is running on node CUSTDBHOST2
    SCAN Listener LISTENER_SCAN3 is enabled
    SCAN listener LISTENER_SCAN3 is running on node CUSTDBHOST2
     
    [orcl@CUSTDBHOST1 ~]$ srvctl config nodeapps -s 
    ONS exists: Local port 6100, remote port 6200, EM port 2016
     
    [orcl@CUSTDBHOST1 ~]$ srvctl status nodeapps | grep ONS
    ONS is enabled
    ONS daemon is running on node: CUSTDBHOST1
    ONS daemon is running on node: CUSTDBHOST2
    

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 WSM-PM_Cluster is listed.

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

    http://ADMINVHN:7001/em
    
  6. Log in to Enterprise Manager 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 ORACLE_BASE/admin/domain_name/mserver directory exists as explained in Chapter 4, "Recommended Locations for the Different Directories."

To create a separate domain directory:

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

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

    Note:

    If the specified template pack jar file exists from previous pack/unpack operations, choose another name (such as wcdomaintemplate2.jar).
  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=wcdomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications -overwrite_domain=true
    

    Note:

    You must have write permissions on the /ORACLE_BASE/admin/domain_name directory before running the unpack command. For example, the directory:
    /ORACLE_BASE/admin/wcpedg_domain/
    

8.4.7 Applying the Java Required Files (JRF) Template to 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 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.

8.4.8 Disabling Host Name Verification

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

You can disable host name verification for a server as soon as it is up and running, starting with the Administration Server.

To disable host name verification:

  1. Log in to Oracle WebLogic Server Administration Console.

  2. Click Lock & Edit.

  3. In the Domain Structure tree on the left, expand the Environment node.

  4. Click Servers.

  5. On the Summary of Servers page, select the name of a server in the Names column of the Servers table. Select AdminServer(admin).

  6. On the settings page for the server, click the SSL tab.

  7. Click Advanced.

  8. Set Hostname Verification to None.

  9. Click Save.

  10. Repeat steps 5 to 9 for the WLS_WSM1 and WLS_WSM2 servers.

  11. Save and activate the changes.

  12. These changes require you 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 correctly. You can start the Managed Server and check its status by using the Oracle WebLogic Server Administration Console.

To start and validate the WLS_WSM1 Managed Server:

  1. Start the WLS_WSM1 Managed Server through the Administration Console, as follows:

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

    2. Select 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 Administration 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.9, "Troubleshooting Oracle WebCenter Portal Enterprise Deployments" for possible causes.

  3. Access the Oracle WSM Policy Manager using the following URL:

    http://SOAHOST1:7010/wsm-pm
    

    Enter the user name and password that you specified earlier in Section 8.4.1, "Creating boot.properties for the Administration Server on SOAHOST1".

  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:

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, "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 wcdomaintemplate.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=wcdomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications -overwrite_domain=true
    

8.5.2 Modifying 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/server_name/upload

and

/u01/app/oracle/admin/wcpedg_domain/aserver/wcpedg_domain/servers/server_name/stage

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

To avoid these issues, update the upload directory to:

ORACLE_BASE/admin/wcpedg_domain/mserver/wcpedg_domain/servers/server_name/upload

And update the stage directory to:

ORACLE_BASE/admin/wcpedg_domain/mserver/wcpedg_domain/servers/server_name/stage

Update these directory paths for all Managed 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 Deployment tab, change the Upload and Stage directories.

  5. Restart the WLS_WSM1 Managed Server, by stopping and then starting it again, for these changes to take effect.

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 Chapter 11, "Enabling Host Name Verification Certificates for Node Manager."

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.

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
    

    Note:

    You must use the StartScriptEnabled property to avoid class loading failures and other problems.
  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.9, "Troubleshooting Oracle WebCenter Portal Enterprise Deployments" 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 Policy Manager. This procedure is optional, but increases the performance of Oracle WSM by keeping a local cache instead of having to search for a cache.

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

For the configuration of JOC ports for Oracle products, Oracle recommends using ports in the 9988 to 9998 range.

To configure the Java Object Cache for Oracle WSM:

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

    MW_HOME/wc/common/bin/wlst.sh
    $ connect()
    

    Enter the server URL, and the WebLogic Server administrator user name and password when prompted.

  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 in 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 also the "Configuring the Distributed Java Object Cache" section in the Oracle Fusion Middleware High Availability Guide.

8.7 Configuring Oracle HTTP Server for the WebLogic Server domain

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

This section includes the following topics:

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 WSM-PM_Cluster (which contains the WLS_WSMn Managed Servers), you must set the WebLogicCluster parameter to the list of nodes in the cluster.

To configure Oracle HTTP Server for the Administration Server and the WLS_WSMn Managed Servers:

  1. On WEBHOST1 and WEBHOST2, add directives to the admin_vh.conf and wcpinternal_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 wcpinternal_vh.conf files using the instructions in Section 7.6, "Defining Virtual Hosts."

    1. Add the directives highlighted in bold (in Example 8-1) to the admin_vh.conf file.

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

      Example 8-1 admin_vh.conf File

      # Admin URLs are only accessible through the admin virtual host
      
      <VirtualHost *:7777>
          ServerName admin.example.com:80
          ServerAdmin you@your.address
          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>
      

      Note:

      Values such as 7777, admin.example.com:80, and you@your.address that are noted in this document serve as examples only. Enter values based on the actual environment.
    2. Add the directive highlighted in bold (in Example 8-1) to the wcpinternal_vh.conf file. Set the WebLogicCluster parameter to the list of nodes in the cluster:

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

      Example 8-2 wcpinternal_vh.conf File

      <VirtualHost *:7777>
          ServerName wcpinternal.example.com:80
          ServerAdmin you@your.address
          RewriteEngine On
          RewriteOptions inherit
      
      # WSM-PM
      <Location /wsm-pm>
          SetHandler weblogic-handler
          WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
      </Location>
      
      </VirtualHost>
      
  2. 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
    

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 Oracle Fusion Middleware Using Web Server Plug-Ins With Oracle WebLogic Server.

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 the domain name in the navigation tree on the left.

  3. Click 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 Server 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 Oracle Enterprise Manager Fusion Middleware Control.

To associate the Oracle web tier with the WebLogic Server domain, run the following command on WEBHOST1:

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 you register Oracle HTTP Server, it should appear as a manageable target in the Fusion Middleware Control. To verify this, log in to Fusion Middleware Control. 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 Frontend Host to admin.example.com and 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.9.2, "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.9, "Troubleshooting Oracle WebCenter Portal Enterprise Deployments" for possible causes.

Verify these load balancer URLs to ensure that appropriate routing and failover is working from Oracle HTTP Server to WSM-PM_Cluster:

  • http://wcpinternal.example.com/wsm-pm

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

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

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 Server 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 -cpzf BACKUP_LOCATION/edg8.8_fmwhome.tgz MW_HOME

Back up the instance home on the web tier using the following command:

tar -cpzf BACKUP_LOCATION/edg8.8_OHS_web_instances.tgz ORACLE_INSTANCE