8 Creating a Domain for an Exalogic 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 such as Oracle BPM and Oracle Service Bus. To create the domain, you must first create the appropriate Middleware Home and Oracle Homes with the required binaries and libraries to run Oracle SOA.

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:

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

Install Oracle Fusion Middleware Software

Install the required Oracle Fusion Middleware software for the Exalogic enterprise deployment reference topology for Oracle SOA

Section 8.2, "Installing Oracle Fusion Middleware"

Verify ADMINVHN on SOAHOST1

Associate the administration server with a virtual hostname, ADMINVHN for the SOAHOST1 hostname.

Section 8.3, "Verifying ADMINVHN in SOAHOST1"

Create a WebLogic Domain

Run the Configuration Wizard to create WebLogic domain.

Section 8.4, "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.5, "Post-Configuration and Verification Tasks"

Associate the Domain with a Database Policy Store

Create a data source for OPSS database access.

Section 8.6, "Associate the Domain with a Database OPSS Policy Store"

Enable Domain-Level Exalogic Enhancements

Enable domain-level Exalogic enhancements.

Section 8.9, "Enabling Domain-Level Exalogic Enhancements"

Validate GridLink Data Sources

Verify that the GridLink data sources are correctly configured and that the ONS setup is correct

Section 8.10, "Validating GridLink Data Sources"

Validate the Administration Server Configuration

Validate the configuration by logging into the Oracle WebLogic Server Administration Console and verifying the managed servers and the cluster are listed

Section 8.11, "Validating the Administration Server Configuration"

Create a Separate Domain Directory for Managed Servers

Use the pack and unpack commands to separate the domain directory used by the Administration Server.

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

Apply the JRF Template to the WSM-PM_CLUSTER

Target a number of resources not included in the WebLogic server installation to the WSM-PM_Cluster.

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

Disable Hostname Verification

Disable host name verification while setting up and validating the topology, and enable it again once the Exalogic enterprise deployment topology configuration is complete.

Section 8.14, "Disabling Host Name Verification"

Start and Validate the WLS_WSM1 Managed Server

Start the managed server and check to confirm that it is running properly.

Section 8.15, "Starting and Validating the WLS_WSM1 Managed Server"

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.16, "Propagating the Domain Configuration to SOAHOST2"

Configure the Oracle Traffic Director with the WebLogic domain

Configure the Oracle Traffic Director with the WebLogic domain and validate the configuration.

Section 8.18, "Configuring Oracle Traffic Director for the WebLogic Domain"

Back Up the Domain

Back up the newly configured WebLogic domain.

Section 8.19, "Backing Up the WebLogic Domain Configuration"


After you create and configure this domain, you can extend it to include Oracle SOA components or Oracle BAM, as other chapters describe.

8.2 Installing Oracle Fusion Middleware

This section describes how to install the required Oracle Fusion Middleware software for the Exalogic enterprise deployment reference topology for Oracle SOA. The main software components to be installed consist of the Oracle WebLogic Server Home (WL_HOME) and Oracle Home (ORACLE_HOME). You install Oracle Fusion Middleware in at least two storage locations for redundancy.

Note:

Before starting the setup process, read the release notes for additional installation and deployment information. They are available on the Oracle Fusion Middleware Documentation Library.

This section covers the following topics:

8.2.1 Installing JRockit

Install JRockit on SOAHOST1. SOAHOST2 will use the same mount points.

To install JRockit:

  1. Download the version of JRockit for your platform from:

    http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html
    
  2. Add execute permissions to JRockit. For example:

    chmod +x jrockit-1.6.0_29-R28.2.0-4.0.1-linux-x64.bin
    
  3. Start the JRockit installer by issuing the command:

    ./jrockit-version.bin
    

    For example:

    ./jrockit-1.6.0_29-R28.2.0-4.0.1-linux-x64.bin
    
  4. On the Welcome Screen, click Next.

  5. On the Choose Product Installation Directories screen, enter the Product Installation Directory, which is in the Middleware Home.

  6. On the Optional Components Screen, click Next.

  7. On the Installation Complete screen, click Done.

8.2.2 Installing WebLogic Server Using the Generic Installer

Install WebLogic Server on SOAHOST1. SOAHOST2 uses the same mount points.

To install WebLogic Server:

  1. Download the Oracle WebLogic Server Generic Installer from the following site:

    http://edelivery.oracle.com
    
  2. Add JRockit to your path. For example, on Linux, enter:

    export PATH=IAM_MW_HOME/jrockit-jdk1.6.0_29-R28.2.0-4.0.1/bin;$PATH
    
  3. Check the version of Java with the following command:

    java -version
    

    Verify that the 64-bit version appears if you have a 64-bit operating system.

  4. Start the WebLogic installer by entering one of the following command:

    java -d64 -jar wls1036_generic.jar
    
  5. On the Welcome screen, click Next.

  6. In the Choose Middleware Home Directory screen, select Create a new Middleware Home then enter the following for Middleware Home Directory:

    ORACLE_BASE/product/fmw
    
  7. Click Next.

  8. In the Register for Security Updates screen, enter your contact information so that you can be notified of security updates, and click Next.

  9. In the Choose Install Type screen, select Custom and click Next.

  10. In the Choose Products and Components screen, deselect Evaluation database and click Next.

  11. In the JDK Selection screen, select only Oracle JRockit 1.6.0_<version> SDK then click Next.

  12. In the Choose Product Installation Directories screen, accept the directories ORACLE_BASE/fmw/wlserver_10.3 and ORACLE_BASE/fmw/coherence_3.7 then click Next.

  13. In the Installation Summary screen, click Next.

  14. In the Installation Complete screen, clear the Run Quickstart check box and click Done.

  15. Validate the installation by verifying that the following directories and files are in the MW_HOME directory:

    • coherence_version

    • jrockit-jdkversion

    • modules

    • registry.xml

    • utils

    • domain-registry.xml

    • logs

    • ocm.rsp

    • registry.dat

    • wlserver_10.3

8.2.3 Installing Oracle Fusion Middleware SOA Suite

Install Oracle Fusion Middleware SOA Suite on SOAHOST1. SOAHOST2 uses the same mount points.

To install Oracle Fusion Middleware SOA Suite on SOAHOST1 and SOAHOST2:

  1. On Linux platforms, if the /etc/oraInst.loc file exists, check that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory. If the /etc/oraInst.loc file does not exist, you can skip this step.

  2. Start the installer for Oracle Fusion Middleware SOA Suite from Disk 1 of the installation media:

    ./runInstaller
    
  3. When the installer prompts you for a JRE/JDK location, enter the Oracle SDK location created in the Oracle WebLogic Server installation, for example, ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version.

  4. In the Specify Inventory Directory screen, enter HOME/oraInventory, where HOME is the home directory of the user performing the installation. This is the recommended location.

  5. Enter the OS group for the user performing the installation then select OK.

  6. Follow the instructions to run /createCentralInventory.sh as root, then click OK.

    Note:

    The Specify Inventory Directory screen appears only on a UNIX operating system for the first installation by Oracle Universal Installer. The installer uses the inventory directory to keep track of all Oracle products installed on the machine.

  7. In the Welcome screen, click Next.

  8. In the Install Software Updates screen, choose Skip Software Updates and click Next.

  9. In the Prerequisite Checks screen, verify that all checks complete successfully, and click OK.

  10. In the Specify Installation Location screen, enter the installation location for Oracle Fusion Middleware SOA Suite. Select the previously-installed Oracle Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name (soa).

8.3 Verifying ADMINVHN 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. External to the Exalogic rack, this VHN must be reachable because this is an EoIB address that typically needs to be accessible to external JMX, JMS, and RMI clients.

8.4 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

    The graphic is described in the text that follows it.
    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 (soaexa_domain).

    Make sure that the domain directory matches the directory and shared storage mount point recommended in Section 4.2, "Shared Storage Recommendations for Exalogic Enterprise Deployments." Enter the following for the domain directory:

    /u01/oracle/config/domains
    

    And the following for the application directory, which should be in shared storage:

    /u01/oracle/config/domains/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. The Configure Gridlink RAC Component Schema screen appears (Figure 8-2).

    Figure 8-2 RAC Component Schema Screen

    RAC Component Schema Screen
    Description of "Figure 8-2 RAC Component Schema Screen"

  11. 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)
      
    • 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-PRIV

    7010

    n/a

    No

    WLS_WSM2

    SOAHOST2-PRIV

    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-PRIV

    SOAHOST2

    SOAHOST2-PRIV

    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" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite.

  22. In the Configuration Summary screen, click Create.

  23. In the Create Domain screen, click Done.

8.5 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.5.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 /u01/oracle/config/domains/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.5.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.5.2 Configuring and Starting Node Manager on SOAHOST1 and SOAHOST2

Oracle recommends placing the Node Manager configuration and log files in a separate directory from the default directory that uses the Middleware Home.

This section includes the following topics:

8.5.2.1 Generating a properties file for Node Manager and Configuring it to use start scripts

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 "Incomplete Policy Migration After Failed Restart of SOA Server" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite.

  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 starts. 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
    
  3. Stop the Node Manager process by running the following commands:

    ps -eaf |grep NodeManager
    

    Example output:

    user 10597 472 7 10:40 pts/3 00:00:00 java 
    weblogic.NodeManager
    

Run the kill command to stop the Node Manager process, as in the following example:

kill 10597

8.5.2.2 Changing the Location of Node Manager Configuration Files

You must create a new directory for Node Manager configuration and log files outside the MW_HOME directory, and perform all Node Manager configuration tasks from this directory. Ensure that you do not make any configuration changes to Node Manager files located in the Oracle WebLogic home directory.

To change the location of Node Manager configuration files, see Section 12.2.1, "Changing the Location of Node Manager Configuration Files.":

8.5.2.3 Editing the nodemanager.properties File

Node Manager properties define configuration settings for a Java-based Node Manager process. You must specify Node Manager properties on the command line or define them in the nodemanager.properties file, located at /u02/private/oracle/config/nodemanager on SOAHOST1 and SOAHOST2. Values you enter on the command line override the values in nodemanager.properties.

Table 8-5 lists the Node Manager properties that you must change for SOAHOST1 and SOAHOST2.

Table 8-5 Node Manager Properties for SOAHOST1 and SOAHOST2

Properties Value

StartScriptEnabled

Set the value to "true" to start a server. For more information, see the section "Configuring Node Manager to Use Start and Stop Scripts" in the Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.

DomainsFile

/u02/private/oracle/config/nodemanager/nodemanager.domains

ListenAddress

For SOAHOST1: SOAHOST1-PRIV

For SOAHOST2: SOAHOST2-PRIV

NodeManagerHome

/u02/private/oracle/config/nodemanager/

LogFile

/u02/private/oracle/config/nodemanager.log

DomainRegistrationEnabled

Set the value to "true".


Note:

For more information about nodemanager.properties, see "Reviewing nodemanager.properties" in the Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.

You must restart Node Manager for changes to take effect.

For SOAHOST1:

cd /u02/private/oracle/config/nodemanager
./startNodeManager.sh

For SOAHOST2:

cd /u02/private/oracle/config/nodemanager
./startNodeManager.sh

8.5.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 /u01/oracle/config/domains/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-PRIV','5556','domain_name','ASERVER_HOME/')
     
    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:

    u01/oracle/config/domain_name/config/nodemanager
    
  5. Restart Node Manager after changing the user and password.

8.6 Associate the Domain with a Database OPSS Policy Store

Associate the domain with a Database OPSS Policy Store.

Before re-association, back up the following configuration files:

  • ASERVER_HOME/config/config.xml

  • ASERVER_HOME/config/fmwconfig/jps-config.xml

  • ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

Back up the boot.properties file for the Administration Server in the following directory:

ASERVER_HOME/servers/AdminServer/security

To re-associate the policy stores with a database:

  1. Create a data source for OPSS database access. Use jdbc/OPSS as the name and point the connection pool to the OPSS schema that you created using RCU.

    Use Appendix D, "Creating a GridLink Data Source." to create a GridLink data source for OPSS database access using the Oracle WebLogic Administration Console.

    For an a GridLink OPSS database access, use the following names:

    • Datasource Name: OPSS

    • JNDI Name: jdbc/OPSS

    • Database User Name: PROD_OPSS

  2. From SOAHOST1, start the wlst shell:

    cd ORACLE_COMMON_HOME/common/bin
    ./wlst.sh
    
  3. Use the wlst command to connect to the WebLogic Administration Server:

    connect('AdminUser','AdminUserPassword','t3://hostname:port')
    
  4. Run the reassociateSecurityStore command:

    reassociateSecurityStore(domain="domainName",
    servertype="DB_ORACLE", datasourcename="datasourceName", 
    jpsroot="jpsRoot",admin="adminAccnt"
    ,password="passWord")
    

    For example:

    reassociateSecurityStore(domain='soaexa_domain'
    ,servertype='DB_ORACLE',datasourcename='jdbc/OPSS',jpsroot='cn=jpsRoot')
    

    For more information on this command, see "reassociateSecurityStore" in the Oracle Fusion Middleware Application Security Guide.

  5. The reassociateSecurityStore command returns output indicating that data is migrated, has been tested, and that audit store re-association is done.

  6. Restart the Administration Server using Node Manager. To restart the Administration Server:

    1. Access ./wlst.sh in the following directory:

      cd ORACLE_COMMON_HOME/common/bin
      
    2. Run the following command:

      wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
      'SOAHOST1-PRIV','5556','domain_name','ASERVER_HOME')
       
      wls:/nm/domain_name nmKill('AdminServer')
      
    3. Once you stop the administration server, following command to start it:

      wls:/nm/domain_name nmStart('AdminServer')
      

8.7 Using an LDAP Authenticator (OID, OVD, OUD)

This section describes how to create the LDAP authenticator using the WebLogic Server Administration Console.

Prerequisites

Before you create the LDAP authenticator, back up the relevant configuration files:

ASERVER_HOME/config/config.xml
ASERVER_HOME/config/fmwconfig/jps-config.xml
ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

Back up the boot.properties file for the Administration Server in the following directory:

ASERVER_HOME/servers/AdminServer/security

To configure the credential store to use LDAP:

  1. Log in to the WebLogic Server Console.

  2. Click the Security Realms link on the left navigational bar.

  3. Click the myrealm default realm entry to configure it.

  4. Open the Providers tab within the realm.

  5. Observe that there is a DefaultAuthenticator provider configured for the realm.

  6. Click Lock & Edit.

  7. Click the New button to add a new provider.

  8. Enter a name for the provider such as OIDAuthenticator or OVDAuthenticator depending on whether Oracle Internet Directory or Oracle Virtual Directory will be used.

  9. Select the OracleInternetDirectoryAuthenticator, OracleVirtualDirectoryAuthenticator or LDAPAuthenbticator type from the list of authenticators depending on whether Oracle Internet Directory, Oracle Virtual Directory or Oracle Unified Directory will be used and click OK.

    Note:

    The table below applies to OID and is an example, for OUD the default ports and other properties vary.

  10. In the Providers screen, click the newly created Authenticator.

  11. Set the control flag to SUFFICIENT. This indicates that if a user can be authenticated successfully by this authenticator, then it should accept that authentication and should not continue to invoke any additional authenticators. If the authentication fails, it will fall through to the next authenticator in the chain. Make sure all subsequent authenticators also have their control flag set to SUFFICIENT; in particular, check the DefaultAuthenticator and set that to SUFFICIENT.

  12. Click Save to save this setting.

  13. Open the Provider Specific tab to enter the details for the LDAP server.

  14. Enter the details specific to your LDAP server, as shown in the following table:

    Parameter Value Value Description

    Host

    For example: oid.mycompany.com

    The LDAP server's server ID.

    Port

    For example: 636

    The LDAP server's port number.

    Principal

    For example: cn=orcladmin

    The LDAP user DN used to connect to the LDAP server.

    Credential

    NA

    The password used to connect to the LDAP server

    SSL Enabled

    Checked

    Specifies whether SSL protocol is used when connecting to LDAP server.

    User Base DN

    For example: cn=users,dc=us,dc=mycompany,dc=com

    Specify the DN under which your Users start.

    Group Base DN

    For example: cn=groups,dc=us,dc=mycompany,dc=com

    Specify the DN that points to your Groups node.

    Use Retrieved User Name as Principal

    Checked

    Must be turned on.


    Click Save when done.

  15. Click Activate Changes to propagate the changes.

Reorder Authenticator

Reorder the OID/OVD/OUD Authenticator and Default Authenticator and ensure that the control flag for each authenticator is set in the following order:

To set the order of the Authenticators:

  1. Log in to WebLogic Console, if not already logged in.

  2. Click Lock & Edit.

  3. Navigate to SecurityRealms, then the default realm name, and then Providers.

  4. Reorder the OID/OVD Authenticator, and Default Authenticator by ensuring that the control flag for each authenticator is set as follows:

    • OID LDAP Authenticator /OVD LDAP Authenticator/LDAP Authenticator: SUFFICIENT

    • Default Authenticator: SUFFICIENT

  5. Click OK.

  6. Click Activate Changes to propagate the changes.

  7. Restart the Administration Server and all managed servers.

8.8 Moving the WebLogic Administrator to LDAP

This section provides details for provisioning a new administrator user and group for managing the Oracle Fusion Middleware SOA Suite Enterprise Deployment WebLogic Domain. This section describes the following tasks:

8.8.1 Provisioning Admin Users and Groups in an LDAP Directory

As mentioned in the introduction to this section, users and groups from multiple WebLogic domains may be provisioned in a central LDAP user store. In such a case, there is a possibility that one WebLogic admin user may have access to all the domains within an enterprise. Oracle does not recommend this. To avoid one WebLogic admin user having access to all the domains, the users and groups provisioned must have a unique distinguished name within the directory tree. For the SOA enterprise deployment WebLogic domain described in this guide, the admin user and group are provisioned with the DNs below:

  • Admin User DN:

    cn=weblogic_soa,cn=Users,dc=us,dc=mycompany,dc=com
    
  • Admin Group DN:

    cn=SOA Administrators,cn=Groups,dc=us,dc=mycompany,dc=com
    

To provision the admin user and admin group in Oracle Internet Directory:

  1. Create an ldif file named admin_user.ldif with the contents shown below and then save the file:

    dn: cn=weblogic_soa, cn=Users, dc=us, dc=mycompany, dc=com
    orclsamaccountname: weblogic_soa
    givenname: weblogic_soa
    sn: weblogic_soa
    userpassword: password
    mail: weblogic_soa
    objectclass: top
    objectclass: person
    objectclass: organizationalPerson
    objectclass: inetorgperson
    objectclass: orcluser
    objectclass: orcluserV2
    uid: weblogic_soa
    cn: weblogic_soa
    description: Admin User for the SOA Domain
    
  2. Run the ldapadd command located under the ORACLE_HOME/bin directory to provision the user in Oracle Internet Directory.

    Note:

    The ORACLE_HOME used here is the ORACLE_HOME for the Identity Management installation where Oracle Internet Directory resides. The ORACLE_HOME environment variable must be set for the ldapadd command to succeed.

    Note:

    For OUD, refer to t e import-ldiff command reference in the OUD documentation.

    For example (the command is shown as two lines in the example below for readability purposes, but you should enter the command on a single line):

    OIDHOST1> ORACLE_HOME/bin/ldapadd -h oid.mycompany.com -p 389 -D
    cn="orcladmin" -w <password> -c -v -f admin_user.ldif
    
  3. Create an ldif file named admin_group.ldif with the contents shown below and then save the file:

    dn: cn=SOA Administrators, cn=Groups, dc=us, dc=mycompany, dc=com
    displayname: SOA Administrators
    objectclass: top
    objectclass: groupOfUniqueNames
    objectclass: orclGroup
    uniquemember: cn=weblogic_soa,cn=users,dc=us,dc=mycompany,dc=com
    cn: SOA Administrators
    description: Administrators Group for the SOA Domain
    
  4. Run the ldapadd command located under the ORACLE_HOME/bin/ directory to provision the group in Oracle Internet Directory (the command is shown as two lines in the example below for readability purposes, but you should enter the command on a single line):

    OIDHOST1> ORACLE_HOME/bin/ldapadd -h oid.mycompany.com -p 389 -D
    cn="orcladmin" -w <password> -c -v -f admin_group.ldif
    

8.8.2 Assigning the Admin Role to the Admin Group

After adding the users and groups to Oracle Internet Directory, the group must be assigned the Admin role within the WebLogic domain security realm. This enables all users that belong to the group to be administrators for that domain.

To assign the Admin role to the Admin group:

  1. Log into the WebLogic Administration Server Console.

  2. In the left pane of the console, click Security Realms.

  3. On the Summary of Security Realms page, click myrealm under the Realms table.

  4. On the Settings page for myrealm, click the Roles & Policies tab.

  5. On the Realm Roles page, expand the Global Roles entry under the Roles table. This brings up the entry for Roles. Click on the Roles link to bring up the Global Roles page.

  6. On the Global Roles page, click the Admin role to bring up the Edit Global Role page:

    1. On the Edit Global Roles page, under the Role Conditions table, click the Add Conditions button.

    2. On the Choose a Predicate page, select Group from the drop down list for predicates and click Next.

    3. On the Edit Arguments Page, specify SOA Administrators in the Group Argument field and click Add.

  7. Click Finish to return to the Edit Global Rule page.

  8. The Role Conditions table now shows the SOA Administrators Group as an entry.

  9. Click Save to finish adding the Admin Role to the SOA Administrators Group.

  10. Validate that the changes were successful by bringing up the WebLogic Administration Server Console using a web browser. Log in using the credentials for the weblogic_soa user.

    Note:

    Each SOA application has its own predefined roles and groups defined for administration and monitoring. By default, the "Administrator" group allows these operations. However, the "Administrator" group may be too broad. For example, you may not want B2B Administrators to be WebLogic Server Domain Administrators where SOA is running. Therefore, you may wish to create a more specific group, such as "SOA Administrators." In order for the different applications to allow the SOA Administrator group to administer the different systems, you must add the required roles to the SOA Administrator group. For example, for B2B's Administration, add the B2BAdmin role to the SOA Administrators group, for Worklistapp's administration, add the SOAAdmin role. Refer to each component's specific roles for the required roles in each case.

8.8.3 Updating the boot.properties File and Restarting the System

The boot.properties file for the Administration Server should be updated with the WebLogic admin user created in Oracle Internet Directory. Follow the steps below to update the boot.properties file:

  1. On SOAHOST1, go the following directory:

    cd ASERVER_HOME/servers/AdminServer/security
    
  2. Rename the existing boot.properties file:

    mv boot.properties boot.properties.backup
    
  3. Use a text editor to create a file called boot.properties under the security directory. Enter the following lines in the file:

    username=weblogic_soa
    password=password
    
  4. Save the file.

  5. Stop the Administration Server using the following command:

    wls:/nm/domain_name>nmKill("AdminServer")
    
  6. Start the Administrator Server using the procedure in Section 8.5.3, "Starting the Administration Server on SOAHOST1."

8.9 Enabling Domain-Level Exalogic Enhancements

To enable domain-level Exalogic enhancements, complete the following steps:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. Click Lock & Edit.

  3. Select the domain name in the left navigation pane. The Settings for Domainname screen appear. Click the General tab.

  4. In your domain home page, select Enable Exalogic Optimizations then click Save.

  5. Activate the changes.

  6. Stop and start your domain.

8.10 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.11 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.5.1, "Creating boot.properties for the Administration Server on SOAHOST1."

8.12 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 Section 4.4, "Recommended Directory Locations for an Oracle Exalogic Enterprise Deployment" recommends.

Before running the unpack script, be sure the following directory exists:

/u02/private/oracle/config/domains

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=ASERVER_HOME
     -template=soadomaintemplate.jar -template_name=soa_domain_template
    
  2. If the ASERVER_HOME directory does not exist, create the directory:

    mkdir -p /u02/private/oracle/config/domains/soaedg_domain
    
  3. 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=MSERVER_HOME 
    -template=soadomaintemplate.jar -app_dir=APP_DIR
    

Note:

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

/u02/private/oracle/config

8.13 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 using the following URL:

    http://ADMINVHN:7001/em
    

    Use the username and password you specified in Section 8.5.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.

8.14 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 12, "Setting Up Node Manager for an Exalogic 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 Exalogic enterprise deployment topology configuration is complete as Chapter 12, "Setting Up Node Manager for an Exalogic Enterprise Deployment" describes.

To disable host name verification:

  1. Log in to Oracle WebLogic Server Administration Console using the following URL:

    http://ADMINVHN:7001/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 9 for 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.5.3, "Starting the Administration Server on SOAHOST1."

8.15 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 14.14, "Troubleshooting the Topology in an Enterprise Deployment." for possible causes.

  3. Access the following URL:

    http://SOAHOST1-priv:7010/wsm-pm
    

    Note:

    Because SOAHOST1-PRIV-V1 is a private/infiniband address, you must use browser from within the Exalogic cells to open the http://SOAHOST1-priv:7010/wsm-pm URL.

  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.16 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.16.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 Section 4.4, "Recommended Directory Locations for an Oracle Exalogic Enterprise Deployment" recommends:

/u02/private/oracle/config/

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=MSERVER_HOME
    -template=soadomaintemplate.jar -app_dir=APP_DIR
    

Note:

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

8.16.2 Modify the Upload and Stage Directories to an Absolute Path

After creating the domain and unpacking to the private directory, update the upload and stage directories for WLS_WSM1, WLS_WSM2 and the Administration Server. 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:

ASERVER_HOME/servers/AdminServer/upload

And update the stage directory to:

MSERVER_HOME/servers/manage_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.16.3 Disabling Host Name Verification for the WLS_WSM2 Managed Server

For the Exalogic 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.14, "Disabling Host Name Verification."

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

8.16.4 Starting Node Manager on SOAHOST2

After you propagate the domain configuration and disable host name verification, start Node Manager using the startNodeManager.sh script.

Note:

A prerequisite for starting Node Manager is updating the Node Manager location, which Section 8.5.2.2, "Changing the Location of Node Manager Configuration Files" describes.

To start Node Manager on SOAHOST2, run the following:

cd /u02/private/oracle/config/nodemanager
./startNodeManager.sh

8.16.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 14.14, "Troubleshooting the Topology in an Enterprise Deployment."for possible causes.

  3. Access the following URL:

    http://SOAHOST2-priv:7010/wsm-pm
    

    Note:

    Because SOAHOST2-PRIV-V1 is a private/infiniband address, you must use browser from within the Exalogic cells to open the http://SOAHOST2-priv:7010/wsm-pm URL.

  4. Click validate policy manager.

8.17 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/oracle_common/common/bin/wlst.sh
    connect('weblogic_userr','weblogic_password','t3://ADMINVHN:7001')
    

    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-PRIV,SOAHOST2-PRIV
    .
    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.18 Configuring Oracle Traffic Director for the WebLogic Domain

This section describes tasks for configuring Oracle Traffic Director for the WebLogic Domain, and for verifying the configuration.

This section includes the following topics:

8.18.1 Configuring Oracle Traffic Director to Create Virtual Server Routes

The required virtual servers for the SOA EDG topology were created in Chapter 7, "Installing and Configuring Oracle Traffic Director for an Exalogic Enterprise Deployment." For this procedure, add the routes so that those virtual servers route to the appropriate servers only when specific URLs are used.

To create the required virtual server routes for Oracle Traffic Director:

  1. Log into the Administration Console using the following URL:

    https://OTDADMINVHN:8989
    
  2. Click Configurations to open a list of available configurations.

  3. Select the configuration you want to configure routes for.

  4. In the Navigation pane, expand Virtual Servers, expand the admin.mycompany.com virtual server, and select Routes to open the Routes page, which lists the routes that are currently defined for the virtual server.

    Continue to the following procedure.

To create a new route:

  1. Click New Route.

  2. In the Step 1: Route Properties screen, enter admin-route in the Name field.

  3. In the Origin Server Pool drop-down menu, select admin-pool and click Next.

  4. In the Step2: Condition Information screen, select the $uri variable from the Variable/Function drop-down list. Select the Operator ('= ~). And enter /console in the Value field.

    Note:

    You cannot use a joiner (and/or) for the first expression in the sequence.

  5. Click OK and click Plus to add the next expression.

    Note:

    You can now select the joiner 'or'.

  6. Select $uri as the Variable/Function, = ~ as the Operator, and /em in the Value field. Click OK.

    Figure 8-3 New Route Condition Information

    Description of Figure 8-3 follows
    Description of "Figure 8-3 New Route Condition Information"

  7. Click Next and then click Create Route.

The new route appears on the Routes page and a Deployment Pending message appears in the main pane. You can deploy the updated configuration immediately by selecting Deploy Changes or wait until you make changes. See the topic Section 7.8, "Deploying the Configuration and Testing the Virtual Server Addresses" for more information.

To create a new route in the soainternal virtual server, repeat the preceding steps and conditions. You can copy the rules from the first route you created and use origin-server-pool1.

8.18.2 Validating Access through Oracle Traffic Director

In the Administration Console, verify that the server status is Running. If the server status is Starting or Resuming, wait for the server status to change to Started. If you see another status, such as Admin or Failed, check the server output log files for errors. See Section 14.14, "Troubleshooting the Topology in an Enterprise Deployment."

Test the WebLogic Server Administration Console and Enterprise Manager Fusion Middleware Control using the admin.mycompany.com URL (through the pertaining load balancer). To do this, verify using the following URLs:

http://admin.mycompany.com/console

http://admin.mycompany.com/em

8.18.3 Turning on the WebLogic Plug-in Enabled Flag

For security purposes, and since the load balancer terminates SSL requests, turn on the WebLogic plug-in enabled flag for the domain after you configure SSL for the load balancer.

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.18.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.

8.19 Backing Up the WebLogic Domain Configuration

Back up the WebLogic domain configuration. For more information, see Section 14.8, "Backing Up the Oracle SOA Enterprise Deployment."