13 Extending the Domain to Include Oracle SOA Suite Components

This chapter describes how to extend the domain created in Chapter 9, "Creating a Domain for an Enterprise Deployment," to include Oracle SOA Suite components and the Oracle WSM Policy Manager Server, using the Oracle Fusion Middleware Configuration Wizard.

This chapter contains the following sections:

Notes:

  • Oracle SOA Suite is required only if your enterprise deployment topology includes Oracle WebCenter Content: Imaging.

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

13.1 Overview of Extending the Domain to Include Oracle SOA Suite Components

The instructions in this chapter are based on an assumption that a SOA Oracle home (binaries) has already been installed and is available from WCCHOST1 and WCCHOST2 and that a domain with an Administration Server has been created. This is the domain that will be extended to support Oracle SOA Suite components.

Extend the Oracle WebLogic Server domain to include Oracle SOA Suite components. Table 13-1 lists the steps for configuring Oracle SOA Suite and other tasks required for extending the domain for Oracle SOA Suite components.

Table 13-1 Steps for Extending the Domain for Oracle SOA Suite Components

Step Description More Information

Prepare for extending the domain for Oracle SOA Suite components

Enable a virtual IP address mapping for each of the host names for the Oracle SOA Suite WebLogic Server cluster.

Section 13.2, "Enabling VIP2 on WCCHOST1 and VIP3 on WCCHOST2"

Extend the domain for Oracle SOA Suite components

Extend the WebLogic Server domain you created in Chapter 9, "Creating a Domain for an Enterprise Deployment."

Section 13.3, "Extending the Domain for Oracle SOA Suite Components"

Configure Oracle Coherence for deploying composites

Configure Oracle Coherence to use unicast communication for deploying composites.

Section 13.5, "Configuring Oracle Coherence for Deploying Composites"

Complete postconfiguration and verification tasks

Follow these instructions for disabling host name verification, restarting Node Manager, propagating the domain configuration, starting and validating the Managed Servers, and validating GridLink data sources.

Section 13.6, "Completing Postconfiguration and Verification Tasks for Oracle SOA Suite"

Configure the Java Object Cache (JOC) among all the servers running Oracle Web Services Manager (Oracle WSM)

Configure a local cache to increase the performance of Oracle WSM.

Section 13.7, "Configuring the Java Object Cache for Oracle Web Services Manager"

Configure Oracle HTTP Server with the extended domain

Configure the Oracle HTTP Server with the Managed Servers, validate access, set the front-end HTTP host and port, and set the WebLogic Server cluster address for SOA_Cluster.

Section 13.8, "Configuring Oracle HTTP Server with the Extended Domain"

Configure a default persistence store

Configure a default persistence store for transaction recovery.

Section 13.9, "Configuring a Default Persistence Store for Transaction Recovery"

Configure host name verification for communication between Node Manager and the Managed Servers in the domain

Use certificates for the different addresses communicating with the Administration Server and other servers.

Section 13.10, "Configuring Node Manager for the WLS_SOA Managed Servers"

Configure server migration for the Oracle SOA Suite Managed Servers.

Specify the Oracle SOA Suite Managed Server names, host names, and cluster name for migration.

vSection 13.11, "Configuring Server Migration for the WLS_SOA Managed Servers"

Back up the Oracle SOA Suite configuration

Back up the newly extended domain configuration.

Section 13.12, "Backing Up the Installation"

13.2 Enabling VIP2 on WCCHOST1 and VIP3 on WCCHOST2

The Oracle WebCenter Content domain uses virtual host names as the listen addresses for the Oracle SOA Suite Managed Servers. If you have not previously done so, you must enable a virtual IP address mapping from VIP2 to WCCHOST1VHN1 on WCCHOST1 and from VIP3 to WCCHOST2VHN1 on WCCHOST2, and you must correctly resolve the virtual host names in the network system used by the topology, with either DNS Server or /etc/hosts resolution.

To enable the virtual IP addresses, follow the procedure described in Section 6.6, "Enabling Virtual IP Addresses" if you have not yet completed it. These virtual IP addresses and virtual host names are required to enable server migration for the Oracle SOA Suite servers. You can configure server migration for the Oracle SOA Suite servers later for high availability purposes. For more information about configuring server migration, see Chapter 17, "Configuring Server Migration for an Enterprise Deployment."

13.3 Extending the Domain for Oracle SOA Suite Components

Use the Configuration Wizard to extend the domain created in Chapter 9, "Creating a Domain for an Enterprise Deployment" to support Oracle Web Services Manager and Oracle SOA Suite components.

Notes:

  • Oracle SOA Suite is only required if the enterprise deployment topology requires Oracle WebCenter Content: Imaging.

  • If you have not backed up the domain created in Chapter 9, "Creating a Domain for an Enterprise Deployment," back up the current domain before extending it for Oracle SOA Suite components. You may use the backup to recover in case any errors are made in the domain extension. See "Backing Up Your Environment" in the Oracle Fusion Middleware Administrator's Guide.

To extend the domain for Oracle SOA Suite components:

  1. Make sure that the database where you installed the repository is running.

    For Oracle RAC databases, it is recommended that all instances are running, so that the validation check later on becomes more reliable.

  2. Shut down all Managed Servers in the domain.

  3. On WCCHOST1, change the directory to the location of the Oracle Fusion Middleware Configuration Wizard. This is within the Oracle Common home directory (domain extensions are run from the node where the Administration Server resides).

    cd ORACLE_COMMON_HOME/common/bin

  4. Start the Configuration Wizard:

    ./config.sh

  5. In the Welcome screen, select Extend an Existing WebLogic Domain, and click Next.

  6. In the Select a WebLogic Domain Directory screen, select the WebLogic Server domain directory (ORACLE_BASE/admin/domain_name/aserver/domain_name), and click Next.

  7. In the Select Extension Source screen, which Figure 13-1 shows, do the following steps:

    1. Select Extend my domain automatically to support the following added products.

    2. Select these products:

      • Oracle SOA Suite

      • Oracle WSM Policy Manager

      The following products are grayed out if they were selected when you created the domain (Section 9.3) or extended it for WebCenter Content (Section 11.2) or Inbound Refinery (Section 12.2).

      • Basic WebLogic Server Domain

      • Oracle Universal Content Management - Inbound Refinery

      • Oracle Universal Content Management - Content Server

      • Oracle Enterprise Manager Plugin for IBR

      • Oracle Enterprise Manager

      • Oracle JRF

      Figure 13-1 Select Extension Source Screen for Oracle SOA Suite

      Description of Figure 13-1 follows
      Description of "Figure 13-1 Select Extension Source Screen for Oracle SOA Suite"

    3. Click Next.

  8. If you get a Conflict Detected message that Oracle JRF is already defined in the domain, select the Keep Existing Component option and click OK.

  9. In the Configure JDBC Component Schema screen, which Figure 13-2 shows, do the following steps:

    1. Select the rows SOA Infrastructure, User Messaging Service, OWSM MDS Schema, and SOA 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.

      After you select a RAC configuration, all selected schemas are grayed.

      Figure 13-2 Configure JDBC Component Schema Screen for Oracle SOA Suite

      Description of Figure 13-2 follows
      Description of "Figure 13-2 Configure JDBC Component Schema Screen for Oracle SOA Suite"

    3. Click Next.

  10. In the Configure GridLink RAC Component Schema screen, which Figure 13-3 shows, do the following steps:

    1. Select only the SOA Infrastructure row.

      Figure 13-3 Configure GridLink RAC Component Schema Screen for Oracle SOA Suite

      Description of Figure 13-3 follows
      Description of "Figure 13-3 Configure GridLink RAC Component Schema Screen for Oracle SOA Suite"

    2. Enter values for the following fields, specifying the connection information for the GridLink RAC database that was seeded through RCU:

      • Driver: Select Oracle 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, wccedg.mycompany.com.

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

        This book uses WCC as the prefix of user names for the database schemas.

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

      • Select Enable FAN.

      • Enable SSL: Leave this option deselected.

        If you select SSL to enable Oracle Notification Service (ONS) notification encryption, provide the appropriate Wallet File and Wallet Password details.

      • 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 a SCAN address to specify the Service Listener (and OSN Host) so you do not need to update a GridLink data source containing a SCAN address if you add or remove Oracle RAC nodes. To determine the SCAN address, query the remote_listener parameter in the database:

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

        Note:

        For Oracle Database 11g, use the virtual IP address and port of each database instance listener, as in these examples:

        custdbhost1-vip.mycompany.com (port 1521) 

custdbhost2-vip.mycompany.com (1521)

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

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

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

        Note:

        For Oracle Database 11g, use the host name and port of each database's ONS service, as in these examples:

        custdbhost1.mycompany.com (port 6200)

custdbhost2.mycompany.com (6200)

    3. Select each data source, one at a time, and enter appropriate values for the user names and passwords.

    4. Ensure that all values are correct for all schemas (SOA Infrastructure, User Messaging Service, OWSM MDS Schema, and SOA MDS Schema), and then click Next.

      Note:

      Oracle recommends using the database used for Oracle Identity Management (see Chapter 18, "Integrating with Oracle Identity Management") to store the Oracle WSM policies. It is therefore expected that you will use the Oracle Identity Management database information that has been seeded through RCU (as recommended in Chapter 3, "Preparing the Network for an Enterprise Deployment") to store the WSM metadata and that this Oracle Identity Management database information will be used in this screen for the OWSM MDS schemas. (This database connection information will be different from the one used for the rest of the Oracle SOA Suite schemas.)

  11. In the Test JDBC Component Schema screen, (Figure 13-4), select each schema, and then click Test Connections.

    The Connection Results Log displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen, correct your entries, and then retry the test.

    Figure 13-4 Test JDBC Component Schema Screen for Oracle SOA Suite

    Description of Figure 13-4 follows
    Description of "Figure 13-4 Test JDBC Component Schema Screen for Oracle SOA Suite"

    Click Next when all the connections are successful.

  12. In the Select Optional Configuration screen, select the following options:

    • JMS Distributed Destination

    • Managed Servers, Clusters and Machines

    • Deployments and Services

    • JMS File Store

    Click Next.

  13. In the Select JMS Distributed Destination Type screen, do the following:

    • Select UDD from the drop-down list for UMSJMSystemResource.

    • Select UDD from the drop-down list for SOAJMSModule.

    • Select UDD from the drop-down list for BPMJMSModule.

    If an override warning appears, click OK to acknowledge it.

  14. In the Configure Managed Servers screen, add the required Managed Servers.

    A server called soa_server1 is created automatically. Rename this to WLS_SOA1 and add a new server called WLS_SOA2. Give these servers the attributes listed in Table 13-2. Do not modify any other servers that are shown in this screen.

    Table 13-2 Managed Servers for Oracle SOA Suite

    Name Listen Address Listen Port SSL Listen Port SSL Enabled

    WLS_SOA1

    WCCHOST1VHN1

    8001

    n/a

    No

    WLS_SOA2

    WCCHOST2VHN1

    8001

    n/a

    No

    Click Next.

  15. In the Configure Clusters screen, add SOA_Cluster, which Table 13-3 describes.

    Table 13-3 Cluster Configuration for Oracle SOA Suite

    Name Cluster Messaging Mode Multicast Address Multicast Port Cluster Address

    SOA_Cluster

    unicast

    n/a

    n/a

    WCCHOST1VHN1:8001,WCCHOST2VHN1:8001

    Click Next.

    Note:

    For asynch request/response interactions over direct binding, the SOA composites must provide their JNDI provider URL for the invoked service to look up the beans for callbacks.

    If soa-infra config properties are not specified, but the WebLogic Server cluster address is specified, the cluster address from the JNDI provider URL is used. This cluster address can be either a single DNS name that maps to the IP addresses of the clustered servers or a comma-separated list of server ip:port. Alternatively, the soa-infra config property JndiProviderURL/SecureJndiProviderURL can be used for the same purpose if explicitly set by users.

  16. In the Assign Servers to Clusters screen, assign the following servers to SOA_Cluster:

      • WLS_SOA1

      • WLS_SOA2

      Do not modify any other assignments that appear in this screen.

    Click Next.

  17. In the Configure Machines screen, delete LocalMachine, which appears by default, open the Unix Machine tab, and click Next.

    You do not need to add any machines here. The machines configured earlier, as described in Section 11.2, "Extending the Domain for WebCenter Content," will be used for all Managed Servers configured on WCCHOST1 and WCCHOST2.

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

    • ADMINVHN:

      • AdminServer

    • WCCHOST1:

      • WLS_SOA1

    • WCCHOST2:

      • WLS_SOA2

    Click Next.

  19. In the Target Deployments to Clusters or Servers screen, make sure that targeting is done as follows:

    • The usermessagingserver and usermessagingdriver-email deployments are targeted only to SOA_Cluster. (The usermessaging-xmpp, usermessaging-smpp, and usermessaging-voicexml applications are optional.)

    • WSM-PM is targeted only to SOA_Cluster.

    • The oracle.rules#*, oracle.sdp.*, and oracle.soa.* deployments are targeted only to SOA_Cluster.

    • NonJ2EEManagement Application is targeted only to AdminServer.

    Click Next.

  20. In the Target Services to Clusters or Servers screen, click Next.

  21. In the Configure JMS File Stores screen, enter the shared directory location specified for your JMS stores, as recommended in Section 4.3, "About Recommended Locations for the Different Directories." For example:

    ORACLE_BASE/admin/domain_name/soa_cluster_name/jms

    Click Next.

  22. In the Configuration Summary screen, click Extend.

    The domain is extended to include the Oracle SOA Suite components.

  23. In the Extending Domain screen, click Done.

13.4 Restarting the Administration Server

You need to restart the Administration Server to make the domain extension changes take effect, using the Node Manager nmKill and nmStart commands through the Oracle WebLogic Scripting Tool (WLST), as described in Section 11.3, "Restarting the Administration Server." You can use the Administration Console instead of nmKill to stop the Administration Server. Log in to the Administration Console using the credentials for the weblogic_ecm user.

13.5 Configuring Oracle Coherence for Deploying Composites

Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication instead in Oracle SOA Suite enterprise deployments. Use unicast if you disable multicast communication for security reasons.

Unicast communication does not enable nodes to discover other cluster members in this way. Consequently, you must specify the nodes that belong to the cluster. You do not need to specify all of the nodes of a cluster, however. You need only specify enough nodes so that a new node added to the cluster can discover one of the existing nodes. As a result, when a new node has joined the cluster, it is able to discover all of the other nodes in the cluster. Additionally, in configurations such as Oracle SOA Suite enterprise deployments where multiple IP addresses are available in the same system, you must configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.

Note:

An incorrect configuration of the Oracle Coherence framework used for deployment may prevent the Oracle SOA Suite system from starting. The deployment framework must be properly customized for the network environment on which the Oracle SOA Suite system runs. Oracle recommends the configuration described in this section.

13.5.1 Enabling Communication for Deployment Using Unicast Communication

Specify the nodes using the tangosol.coherence.wkan system property, where n is a number in the range 1 to 9. You can specify up to 9 nodes as Well Known Addresses, but the cluster can have more than 9 nodes. Start the numbering at 1. This numbering must be sequential and must not contain gaps.

Tip:

To guarantee high availability during deployments of Oracle SOA Suite composites, specify enough nodes so that at least one of them is running at any given time.

In addition, specify the host name used by Oracle Coherence to create a cluster through the tangosol.coherence.localhost system property. This local host name should be the virtual host name used by the Oracle SOA Suite server as the listener addresses (WCCHOST1VHN1 and WCCHOST2VHN1). Set this property by adding the -Dtangosol.coherence.localhost parameter to the Arguments field on the Server Start tab of the Oracle WebLogic Server Administration Console, shown in Figure 13-5.

Note:

WCCHOST1VHN1 is the virtual host name that maps to the virtual IP address where WLS_SOA1 is listening (in WCCHOST1). WCCHOST2VHN1 is the virtual host name that maps to the virtual IP address where WLS_SOA2 is listening (in WCCHOST2).

13.5.2 Specifying the Host Name Used by Oracle Coherence

Use the Administration Console to add a host name for Oracle Coherence to use.

To specify the host name used by Oracle Coherence:

  1. Log in to the WebLogic Server Administration Console.

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

  3. Click Servers.

  4. On the Summary of Servers page, click the name of the server (WLS_SOA1 or WLS_SOA2, which are represented as hyperlinks) in the Name column of the table.

  5. On the settings page for the selected server, click Lock & Edit.

  6. On the Configuration tab, click the Server Start tab (illustrated in Figure 13-5).

  7. Enter the following parameters for WLS_SOA1 and WLS_SOA2 in the Arguments field.

    Note:

    There should be no breaks in lines between the different -D parameters. Do not copy or paste the text to the Arguments text field in your Administration Console because this could result in HTML tags being inserted into the Java arguments. The text should not contain other text characters than those included the example that follows.

    For WLS_SOA1, enter the following text (on a single line, without a carriage return):

    -Dtangosol.coherence.wka1=WCCHOST1VHN1
-Dtangosol.coherence.wka2=WCCHOST2VHN1 
-Dtangosol.coherence.localhost=WCCHOST1VHN1

    For WLS_SOA2, enter the following text (on a single line, without a carriage return):

    -Dtangosol.coherence.wka1=WCCHOST1VHN1
-Dtangosol.coherence.wka2=WCCHOST2VHN1
-Dtangosol.coherence.localhost=WCCHOST2VHN1

    Note:

    The Coherence cluster used for deployment uses port 8088 by default. This port can be changed by specifying a different port (for example, 8089) using the -Dtangosol.coherence.wkan.port and -Dtangosol.coherence.localport startup parameters; for example:

    • WLS_SOA1 (enter the following text into the Arguments field on a single line, without a carriage return):

      -Dtangosol.coherence.wka1=WCCHOST1VHN1
-Dtangosol.coherence.wka2=WCCHOST2VHN1
-Dtangosol.coherence.localhost=WCCHOST1VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

    • WLS_SOA2 (enter the following text into the Arguments field on a single line, without a carriage return):

      -Dtangosol.coherence.wka1=WCCHOST1VHN1
-Dtangosol.coherence.wka2=WCCHOST2VHN1
-Dtangosol.coherence.localhost=WCCHOST2VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

    For more information about Coherence clusters, see the Oracle Coherence Developer's Guide.

  8. Click Save and Activate Changes.

Notes:

  • You must ensure that these variables are passed to the Managed Server correctly. (They should be reflected in the server's output log.) Failure of the Oracle Coherence framework can prevent the soa-infra application from starting.

  • The multicast and unicast addresses are different from the ones used by the WebLogic Server cluster for cluster communication. Oracle SOA Suite guarantees that composites are deployed to members of a single WebLogic Server cluster even though the communication protocol for the two entities (the WebLogic Server cluster and the groups to which composites are deployed) are different.

Figure 13-5 Setting the Host Name on the Start Server Tab of the Administration Console

Description of Figure 13-5 follows
Description of "Figure 13-5 Setting the Host Name on the Start Server Tab of the Administration Console"

13.6 Completing Postconfiguration and Verification Tasks for Oracle SOA Suite

After extending the domain with the Configuration Wizard and configuring Oracle Coherence, follow these instructions for postconfiguration and validation. The following sections describe how to do postconfiguration and verification tasks for Oracle SOA Suite:

13.6.1 Disabling Host Name Verification for the WLS_SOAn Managed Servers

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 9.4.5, "Disabling Host Name Verification."

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

13.6.2 Propagating the Domain Configuration to WLS_SOA1 and WLS_SOA2

Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the Managed Server domain directory.

To propagate the domain configuration to the Oracle SOA Suite Managed Servers:

  1. Create a copy of the Managed Server domain directory and the Managed Server applications directory.

  2. Run the following pack command on WCCHOST1 to create a template pack:

    cd ORACLE_COMMON_HOME/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateSOA.jar -template_name=edgdomain_templateSOA

  3. Run the following unpack command on WCCHOST1 to propagate the template created in the preceding step to the WLS_SOA1 domain directory:

    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications -overwrite_domain=true

    Notes:

    • Make sure to run unpack from the ORACLE_COMMON_HOME/common/bin/ directory, not from WL_HOME/common/bin/.

    • The ORACLE_BASE/admin/domain_name/mserver/ directory must exist before you run unpack. In addition, the ORACLE_BASE/admin/domain_name/mserver/applications/ directory must be empty.

  4. Run the following command on WCCHOST1 to copy the template pack created in step 2 to WCCHOST2:

    scp edgdomaintemplateSOA.jar oracle@WCCHOST2:ORACLE_BASE/product/fmw/oracle_common/common/bin

  5. Run the following unpack command on WCCHOST2 to unpack the propagated template to the WLS_SOA2 Managed Server domain directory:

    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications –overwrite_domain=true

    Notes:

    • Make sure to run unpack from the ORACLE_COMMON_HOME/common/bin/ directory, not from WL_HOME/common/bin/.

    • The ORACLE_BASE/admin/domain_name/mserver/ directory must exist before you run unpack. In addition, the ORACLE_BASE/admin/domain_name/mserver/applications/ directory must be empty.

    • The -overwrite_domain option in the unpack command allows unpacking a Managed Server template into an existing domain and existing applications directories. For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and EAR files in the Managed Server domain directory, they must be restored after this unpack operation.

  6. Restart the Administration Server to make these changes take effect, stopping it with the nmKill command, or with the Administration Console, and then starting it with the nmStart command, as described in Section 11.3, "Restarting the Administration Server." Log in to the Administration Console using the credentials for the weblogic_ecm user.

13.6.3 Starting and Validating the WLS_SOA1 Managed Server

You can start and validate the WLS_SOA1 Managed Server through the Administration Console.

To start the WLS_SOA1 Managed Server on WCCHOST1:

  1. Log in to the Oracle WebLogic Server Administration Console at http://admin.mycompany.com:7001/console.

  2. Start the WLS_SOA1 Managed Server through the WebLogic Server Administration Console, as follows:

    1. Expand the Environment node in the Domain Structure tree on the left.

    2. Click Servers.

    3. On the Summary of Servers page, click the Control tab.

    4. Select WLS_SOA1 from the Servers column of the table.

    5. Click Start.

  3. Verify that the server status is reported as Running in the Administration Console.

  4. Access the following URLs:

    • Access http://WCCHOST1VHN1:8001/soa-infra to verify the status of WLS_SOA1.

    • Access http://WCCHOST1VHN1:8001/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data store opens.The configuration is incorrect if no policies or assertion templates appear.

    • Access http://WCCHOST1VHN1:8001/integration/worklistapp to verify the status of the worklist application.

13.6.4 Starting and Validating the WLS_SOA2 Managed Server

After you start the WLS_SOA2 Managed Server, you can validate it by verifying its status through the WebLogic Server Administration Console and some URLs.

Note:

Before starting the WLS_SOA2 Managed Server using the WebLogic Server Administration Console, make sure Node Manager is running. Section 19.8.1, "Assumptions and Procedure," says to start it, in Step 3, "Start Node Manager in WCCHOST2."

If Node Manager is not running, restart it on WCCHOST2, as described in Section 9.4.2, "Starting Node Manager on WCCHOST1."

To start and validate the WLS_SOA2 Managed Server:

  1. Start the WLS_SOA2 Managed Server using the WebLogic Server Administration Console, as follows:

    1. Expand the Environment node in the Domain Structure tree on the left.

    2. Click Servers.

    3. On the Summary of Servers page, open the Control tab.

    4. Select WLS_SOA2 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 19.13, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology" for possible causes.

  3. Access the following URLs:

    • Access http://WCCHOST2VHN1:8001/soa-infra to verify the status of WLS_SOA2.

    • Access http://WCCHOST2VHN1:8001/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data store opens.

      Note:

      The configuration is incorrect if no policies or assertion templates appear.

    • Access http://WCCHOST2VHN1:8001/integration/worklistapp to verify the status of the worklist application.

13.6.5 Validating GridLink Data Sources for Oracle SOA Suite

After 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 verify the configuration of a GridLink data source for Oracle SOA Suite:

  1. Log in to the WebLogic Server Administration Console.

  2. In the Domain Structure tree, expand Services, then click Data Sources.

  3. Click the name of a GridLink data source that was created.

  4. Click the Monitoring tab.

  5. Click the Testing tab (Figure 13-6), select one of the servers, and click Test Data Source.

    Figure 13-6 Testing a GridLink Data Source for Oracle SOA Suite

    Description of Figure 13-6 follows
    Description of "Figure 13-6 Testing a GridLink Data Source for Oracle SOA Suite"

    The test should be successful if the configuration is correct.

  6. Repeat the test for every WebLogic Server instance that uses the GridLink data source.

To verify the configuration of ONS for a GridLink data source for Oracle SOA Suite:

  1. Log in to the WebLogic Server Administration Console.

  2. In the Domain Structure tree, expand Services, then click Data Sources.

  3. Click the name of a GridLink data source that was created.

  4. Click the Monitoring tab.

  5. Click the ONS tab and then the Testing tab (Figure 13-7).

  6. Select a server, and click Test ONS.

    Figure 13-7 Testing the ONS Configuration for Oracle SOA Suite

    Description of Figure 13-7 follows
    Description of "Figure 13-7 Testing the ONS Configuration for Oracle SOA Suite"

    The test should be successful if the configuration is correct. If the ONS test fails, verify that the ONS service is running in the Oracle 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

  7. Repeat the ONS test for every WebLogic Server instance that uses the GridLink data source.

13.7 Configuring the Java Object Cache for Oracle Web Services Manager

The Java Object Cache (JOC) should be configured among all the servers running Oracle Web Services Manager (Oracle WSM). This local cache is provided to increase the performance of Oracle WSM. The Java Object Cache can be configured using the MW_HOME/oracle_common/bin/configure-joc.py script. This is a Python script, which can be used to configure JOC in the Managed Servers. The script 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.

Note:

After you configure the Java Object Cache using the WLST commands or configure-joc.py script, all affected Managed Servers should be restarted, using the WebLogic Server Administration Console, for the configurations to take effect.

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/oracle_common/common/bin/wlst.sh
$ connect()

    Enter the WebLogic Server Administrator user name, password, and server URL (t3://ADMINVHN:7001) when prompted.

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

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

Specifically, for enterprise deployment environments, the first cluster option in step 2 should be used. Here is a walkthrough for using configure-joc.py for enterprise deployment environments (see the following text for the script input parameters):

Execfile("MW_HOME/oracle_common/bin/configure-joc.py").
Enter Hostnames (eg host1,host2) : WCCHOST1VHN1,WCCHOST2VHN1
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : SOA_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

After configuring the Java Object Cache using WLST commands or the configure-joc.py script, restart all affected Managed Servers, using the WebLogic Server Administration Console, for the configurations to take effect.

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

Script Input Parameters

The input parameters are prompted by the script. The script can be used to perform the following optional JOC configurations:

  • Configure JOC for all specified 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 configures 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 : SOA_Cluster
Enter Discover Port : 9991

  • 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_SOA1:9991, WLS_SOA21:9991) : WLS_SOA1:9999,WLS_SOA2:9999

    This example configures JOC only for the specified Managed Servers (that is, WLS_SOA1 and WLS_SOA2). The discover port is specified with the Managed Server (for example, WLS_SOA1:2222).

  • 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_SOA1,WLS_SOA2

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

13.8 Configuring Oracle HTTP Server with the Extended Domain

After propagating the domain configuration to WCCHOST2, configure the Oracle HTTP Server with the extended domain.

This section includes the following topics:

13.8.1 Configuring Oracle HTTP Server for the WLS_SOA Managed Servers

To enable Oracle HTTP Server to route to SOA_Cluster, which contains the WLS_SOAn Managed Servers, you must set the WebLogicCluster parameter to the list of nodes in the cluster.

To configure Oracle HTTP Server for the WLS_SOA Managed Servers:

  1. For each of the web servers on WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/wccinternal_vh.conf and ORACLE_INSTANCE/config/OHS/ohs2/moduleconf/wccinternal_vh.conf files:

    # WSM-PM
<Location /wsm-pm>
    WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
    SetHandler weblogic-handler
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# SOA soa-infra app
<Location /soa-infra>
    WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
    SetHandler weblogic-handler
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
    WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
    SetHandler weblogic-handler
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Worklist
<Location /integration/>
    WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
    SetHandler weblogic-handler
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
    WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
    SetHandler weblogic-handler
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow/>
    WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
    SetHandler weblogic-handler
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Workflow
<Location /workflow>
    WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
    SetHandler weblogic-handler
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

#SOA Composer
<Location /soa/composer>
    WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001
    SetHandler weblogic-handler
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

  2. Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2:

    ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohsX

    For WEBHOST1, use ohs1 for ias-component and for WEBHOST2 use 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. Please 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.

Sample 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 run time.

  • 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 Guide.

13.8.2 Setting the Front-End HTTP Host and Port

You must set the front-end HTTP host and port for the Oracle WebLogic Server cluster hosting the Oracle SOA Suite servers.

To set the front-end HTTP host and port for the Oracle SOA Suite cluster:

  1. Log in to the WebLogic Server Administration Console.

  2. Go to the Change Center section and click Lock & Edit.

  3. Expand the Environment node in the Domain Structure tree on the left.

  4. Click Clusters.

  5. On the Summary of Servers page, select SOA_Cluster.

  6. Open the HTTP tab.

  7. Set the following values:

    • Frontend Host: wccinternal.mycompany.com

    • Frontend HTTP Port: 80

  8. Click Save.

  9. Click Activate Changes in the Change Center section of the Administration Console.

  10. Restart the WLS_SOA1 and WLS_SOA2 Managed Servers, using the WebLogic Server Administration Console, to make the front-end host directive in the cluster take effect.

13.8.3 Validating Access Through the Load Balancer

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. For possible causes, see Section 19.13, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology."

Validate access to SOA_cluster using the following URLs:

  • http://wccinternal.mycompany.com/soa-infra

  • http://wccinternal.mycompany.com/integration/worklistapp

  • http://wccinternal.mycompany.com/sdpmessaging/userprefs-ui

  • http://wccinternal.mycompany.com/soa/composer

  • http://wccinternal.mycompany.com/wsm-pm

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

13.9 Configuring a Default Persistence Store for Transaction Recovery

Each server has a transaction log that stores information about the committed transactions coordinated by the server that may not have been completed. Oracle WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the Managed Servers within a cluster, store the transaction logs in a location accessible to each server and its backup servers.

Note:

The recommended location is on a dual-ported SCSI disk or on a Storage Area Network (SAN).

To set the locations of the default persistence stores for the Oracle SOA Suite Managed Servers:

  1. Log in to the WebLogic Server Administration Console.

  2. In the Change Center section of the page, click Lock & Edit.

  3. In the Domain Structure tree on the left, expand the Environment node, and then click the Servers node.

  4. On the Summary of Servers page, click the name of the server WLS_SOA1 (represented as a hyperlink) in the Name column of the table. The settings page for the selected server opens and defaults to the Configuration tab.

  5. On the Configuration tab, click the Services tab (not the top-level Services tab).

  6. In the Default Store section of the page, enter the path to the folder where the default persistence store will store its data files. The directory structure of the path follows:

    ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs/

  7. Repeat steps 4, 5, and 6 for the WLS_SOA2 server.

  8. Click Save and Activate Changes.

  9. Restart the WLS_SOA1 and WLS_SOA2 Managed Servers, using the WebLogic Server Administration Console.

  10. After WLS_SOA1 and WLS_SOA2 are restarted, verify that the following DAT files are created in this directory:

    ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs/

    • _WLS_WLS_SOA1000000.DAT

    • _WLS_WLS_SOA2000000.DAT

Note:

To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both WLS_SOA1 and WLS_SOA2 must be able to access this directory. Also, the directory must exist before you restart the servers.

13.10 Configuring Node Manager for the WLS_SOA Managed Servers

Oracle recommends using host name verification for communication between Node Manager and the servers in the domain. This requires the use of certificates for the different addresses communicating with the Administration Server and other servers.

If you have not already done so, configure the host names used by the WLS_SOA Managed Servers as listen addresses for host name verification as explained in Section 11.6, "Configuring Node Manager for Managed Servers."

At this point, after you have added the Oracle Soa Suite Managed Servers to the domain, perform the procedure in Section 16.3.5, "Configuring Managed Servers to Use the Custom Keystores," for Oracle SOA Suite.

13.11 Configuring Server Migration for the WLS_SOA Managed Servers

Server migration is required for proper failover of the Oracle SOA Suite components in the event of failure in any of the WCCHOST1 and WCCHOST2 nodes. See Chapter 17, "Configuring Server Migration for an Enterprise Deployment" for further details. For Oracle SOA Suite, use the following values for the variables in that chapter:

  • Server names:

    • WLS_SERVER1: WLS_SOA1

    • WLS_SERVER2: WLS_SOA2

  • Host names:

    • HOST1: WCCHOST1

    • HOST2: WCCHOST2

  • Cluster name:

    • CLUSTER: SOA_Cluster

13.12 Backing Up the Installation

After you have verified that the extended domain is working, back up the installation. This is a quick backup for the express purpose of immediate restore in case of problems in the further steps. The backup destination is the local disk. This backup can be discarded once the enterprise deployment setup is complete. At that point, the regular deployment-specific backup and recovery process can be initiated. The Oracle Fusion Middleware Administrator's Guide provides further details. For information on describing the Oracle HTTP Server data that must be backed up and restored, refer to the "Backup and Recovery Recommendations for Oracle HTTP Server" section in that guide. For information on how to recover components, see the "Recovery of Components" and "Recovery After Loss of Component" sections in the guide. For recommendations specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" section in the guide. For information about database backup, see the Oracle Database Backup and Recovery Guide.

To back up the installation at this point:

  1. Back up Oracle Web Tier on WEBHOST1:

    1. Shut down the instance using opmnctl:

      ORACLE_BASE/admin/instance_name/bin/opmnctl stopall

    2. Back up the Middleware home on Oracle Web Tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web.tar MW_HOME

    3. Back up the Oracle instance on Oracle Web Tier using the following command:

      tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE

    4. Start the instance using opmnctl:

      cd ORACLE_BASE/admin/instance_name/bin

opmnctl startall

  2. Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or operating system tools such as tar for cold backups if possible.

  3. Back up the Administration Server and Managed Server domain directories to save your domain configuration. The configuration files all exist in the ORACLE_BASE/admin/domain_name directory. Run the following command on WCCHOST1 to create the backup:

    tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name