Skip Headers
Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter
11g Release 1 (11.1.1)

Part Number E12037-04
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

5 Extending the Domain for SOA Components

This chapter describes how to use the Configuration Wizard to extend the domain to include SOA components. You created in the domain in Chapter 4, "Creating a Domain."

Important:

Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.

Note:

Follow the steps in this chapter only if you want to run SOA components on SOAHOST1 and SOAHOST2. If you do not want to run SOA components in your WebCenter topology, you can skip this chapter.

This chapter contains the following sections:

5.1 Installing Oracle Fusion Middleware for SOA Home

You must install Oracle Fusion Middleware for SOA on both SOAHOST1 and SOAHOST2. These nodes will run managed servers configured with SOA components.

  1. Start the installer for Oracle Fusion Middleware for SOA.

    SOAHOST1> runInstaller
    

    When the installer prompts you for a JRE/JDK location enter the Oracle SDK location created in the Oracle WebLogic Server installation, for example, MW_HOME/jrockit_160_<version>.

  2. In the Welcome screen, click Next.

  3. In the Prerequisite Check screen, verify that the checks complete successfully, and click Next.

  4. Specify the installation location. Select the previously installed Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name (soa).

    Click Next.

  5. In the Installation Summary screen, click Install.

  6. In the Installation Complete screen, click Finish.

5.2 Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2

The SOA domain uses virtual hostnames as the listen addresses for the SOA managed servers. You must enable A VIP mapping each of these hostnames on the two SOA Machines, (VIP2 on SOAHOST1 and VIP3 on SOAHOST2), and must be correctly resolve the virtual hostnames in the network system used by the topology (either by DNS Server, hosts resolution).

To enable the VIP, follow the steps described in Section 4.3, "Enabling VIP1 in SOAHOST1."These VIPs and VHNs are required to enable server migration for the SOA Servers. Server migration must be configured for the SOA System for high availability purposes. Refer to Chapter 9, "Server Migration" of the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for more details on configuring server migration for the SOA servers.

5.3 Extending the Domain for SOA Components

In this step, you extend the domain created in Chapter 4, "Creating a Domain" to contain SOA components. In this section we are assuming that the SOA deployment uses the same database service (wcedg.mycompany.com) as the WebCenter deployment. However, a deployment may choose to use a different database service specifically for SOA such as soaedg.mycompany.com.

Note:

You must back up the current domain before extending the domain. You may use the backup to recover in case any errors were made in the domain extension. See Oracle Fusion Middleware Administrator's Guide.

Note:

Oracle SOA uses Quartz to maintain its jobs and schedules in the database. The system clocks for the SOA WebLogic cluster must be synchronized to enable Quartz jobs to run correctly across the cluster.
  1. Change directory to the location of the Configuration Wizard. This is within the SOA home directory. (It is recommended that all database instances should be up.)

    SOAHOST1> cd ORACLE_HOME/common/bin
    
  2. Start the Configuration Wizard.

    SOAHOST1> ./config.sh
    
  3. In the Welcome screen, select Extend an existing WebLogic domain, and click Next.

  4. In the WebLogic Domain Directory screen, select the WebLogic domain directory (ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>), and click Next.

  5. In the Select Extension Source screen, do the following:

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

    • Select the following products:

      • Oracle SOA Suite 11.1.1.0

      The following products should already be selected, and grayed out. They were selected when you created in domain in Section 4.4, "Running the Configuration Wizard on SOAHOST1 to Create a Domain."

      • Basic WebLogic Server Domain

      • Oracle Enterprise Manager

      • Oracle WSM Policy Manager

      • Oracle JRF

    Click Next.

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

  7. In the Configure JDBC Component Schema screen (Figure 5-1), do the following:

    1. Select the SOA Infrastructure, User Messaging Service, and SOA MDS Schema rows in the table.

    2. Select Configure selected component schemas as RAC multi data source schemas in the next panel.

    3. Click Next.

    Figure 5-1 Configure JDBC Component Schema Screen

    Description of Figure 5-1 follows
    Description of "Figure 5-1 Configure JDBC Component Schema Screen"

  8. In the Configure RAC Multi Data Source Component Schema screen (Figure 5-2), do the following:

    1. Select SOA Infrastructure.

    2. Enter values for the following fields, specifying the connect information for the RAC database that was seeded with RCU.

      • Driver: Select Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11.

      • Service Name: Enter the service name of the database; for example, wcedg.mycompany.com.

      • Username: Enter the complete user name (including prefix) for the schemas. The user names shown in Figure 5-2 assume that soedg was used as prefix for schema creation from RCU.

      • Password: Enter the password to use to access the schemas.

    3. Click Add and enter the details for the first RAC instance.

    4. Repeat for each RAC instance.

    5. Deselect SOA Infrastructure.

    6. Select User Messaging Service.

    7. Repeat steps b, c, and d for the User Messaging Schema.

    8. Deselect User Messaging Service.

    9. Select SOA MDS Schema.

    10. Repeat steps b, c, and d for the SOA MDS Schema.

    11. Leave the OWSM MDS Schema information as it is.

    12. Click Next

    Figure 5-2 Configure RAC Multi Data Source Component Schema Screen

    Description of Figure 5-2 follows
    Description of "Figure 5-2 Configure RAC Multi Data Source Component Schema Screen"

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

    Click Next when all the connections are successful.

  10. In the Select Optional Configuration screen, select the following:

    • JMS Distributed Destinations

    • Managed Servers, Clusters, and Machines

    • Deployments and Services

    Click Next.

  11. In the Select JMS Distributed Destination Type screen:

    • Select UDD from the drop down list for UMSJMSystemResource.

    • Select UDD from the drop down list for SOAJMSModule.

  12. 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 give it the attributes listed in Table 5-1. Then, add a new server called WLS_SOA2. The WLS_WSM1 and WLS_WSM2 managed servers should already be present because they are part of the domain that you are extending. In the end, the list of managed servers should match that in Table 5-1.

    Table 5-1 Managed Servers

    Name Listen Address Listen Port SSL Listen Port SSL Enabled

    WLS_SOA1

    SOAHOST1VHN1

    8001

    n/a

    No

    WLS_SOA2

    SOAHOST2VHN1

    8001

    n/a

    No

    WLS_WSM1

    SOAHOST1

    7010

    n/a

    No

    WLS_WSM2

    SOAHOST2

    7010

    n/a

    No


    Click Next.

  13. In the Configure Clusters screen, add the following clusters:

    Table 5-2 Clusters

    Name Cluster Messaging Mode Multicast Address Multicast Port Cluster Address

    SOA_Cluster

    unicast

    n/a

    n/a

    Leave it empty.

    WSM-PM_Cluster

    unicast

    n/a

    n/a

    Leave it empty.


    Click Next.

  14. In the Assign Servers to Clusters screen, assign servers to clusters as follows:

    • SOA_Cluster:

      • WLS_SOA1

      • WLS_SOA2

    • WSM-PM_Cluster:

      • WLS_WSM1

      • WLS_WSM2

    Click Next.

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

    • Delete the LocalMachine that appears by default.

    • Click the Unix Machine tab. The following entries appear (listed in Table 5-3):

      Table 5-3 Machines

      Name Node Manager Listen Address

      SOAHOST1

      SOAHOST1

      SOAHOST2

      SOAHOST2


    Leave all other fields to their default values.

    Click Next.

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

    • ADMINHOST:

      • AdminServer

    • SOAHOST1:

      • WLS_SOA1

      • WLS_WSM1

    • SOAHOST2:

      • WLS_SOA2

      • WLS_WSM2

    Click Next.

  17. In the Target Deployments to Clusters or Servers screen, ensure the following targets:

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

    • The oracle.sdp.*, and oracle.soa.* libraries should be targeted only to SOA_Cluster.

    • The oracle.rules.* library should be targeted only to Admin Server and SOA_Cluster.

    • The wsm-pm application should be targeted only to WSM-PM_Cluster.

    • The oracle.wsm.seedpolicies library should be targeted only to WSM-PM_Cluster.

      Target this library to the SOA_Cluster also only if you are planning to deploy WebLogic WebServices to it.

    Click Next.

  18. In the Target Services to Clusters or Servers screen, ensure the following targets:

    • Target JOC Startup Class and JOC Shutdown Class only to WSM-PM_Cluster.

    • Target mds-owsm, mds-owsm-rac0, and mds-owsm-rac1 to both WSM-PM_Cluster and AdminServer.

    Click Next.

  19. In the Configuration Summary screen click Extend.

    Note:

    Click OK to dismiss the warning dialog about the domain configuration ports conflicting with the host ports. This warning appears because of the existing WSM-PM installation.
  20. In the Extending Domain screen, click Done.

    You must restart the Administration Server for this configuration to take effect.

5.4 Restarting the Administration Server

Restart the Administration Server using the procedure in Section 4.5, "Creating boot.properties for the Administration Server on SOAHOST1."

5.5 Configuring Oracle Coherence for Deploying Composites

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

Note:

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

Enabling Communication for Deployment Using Unicast Communication

Multicast communication enables Oracle Fusion Middleware SOA to discover all of the members of a cluster to which to it deploys composites dynamically. However, 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 SOA enterprise deployments where multiple IPs are available in the same box, you must configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.

Tip:

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

Specify the nodes using the tangosol.coherence.wka<n> system property, where <n> is a number between 1 and 9. You can specify up to 9 nodes. Start the numbering at 1. This numbering must be sequential and must not contain gaps. 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 SOA server as the listener addresses (SOAHOST2VHN1and SOAHOST2VHN1). Set this property by adding the -Dtangosol.coherence.localhost parameters to the Arguments field of the Oracle WebLogic Server Administration Console's Server Start tab (Figure 5-2).

Note:

SOAHOST1VHN1 is the virtual host name that maps to the virtual IP where WLS_SOA1 listening (in SOAHOST1). SOAHOST2VHN1 is the virtual host name that maps to the virtual IP where WLS_SOA2 is listening (in SOAHOST2).

Figure 5-3 Setting the Host Name Using the Start Server Tab of Oracle WebLogic Server Administration Console

Description of Figure 5-3 follows
Description of "Figure 5-3 Setting the Host Name Using the Start Server Tab of Oracle WebLogic Server Administration Console"

Specifying the host name

To add the host name used by Oracle Coherence, complete these steps:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand the Environment node.

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

  4. Click the name of the server (WLS_SOA1 or WLS_SOA2, which are represented as hyperlinks) in Name column of the table. The settings page for the selected server appears.

  5. Click Lock and Edit.

  6. Click the Server Start tab (illustrated in Figure 5-3).

  7. Enter the following for WLS_SOA1 and WLS_SOA2 into the Arguments field.

    For WLS_SOA1, enter the following:

    -Dtangosol.coherence.wka1=SOAHOST1VHN1
    -Dtangosol.coherence.wka2=SOAHOST2VHN1
    -Dtangosol.coherence.localhost=SOAHOST1VHN1
    

    For WLS_SOA2, enter the following:

    -Dtangosol.coherence.wka1=SOAHOST2VHN1
    -Dtangosol.coherence.wka2=SOAHOST1VHN1
    -Dtangosol.coherence.localhost=SOAHOST2VHN1
    

    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) with the -Dtangosol.coherence.wkan.port and -Dtangosol.coherence.localport startup parameters. For example:

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

    -Dtangosol.coherence.wka1=SOAHOST1VHN1
    -Dtangosol.coherence.wka2=SOAHOST2VHN1
    -Dtangosol.coherence.localhost=SOAHOST1VHN1
    -Dtangosol.coherence.localport=8089
    -Dtangosol.coherence.wka1.port=8089
    -Dtangosol.coherence.wka2.port=8089
    

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

    -Dtangosol.coherence.wka1=SOAHOST1VHN1
    -Dtangosol.coherence.wka2=SOAHOST2VHN1
    -Dtangosol.coherence.localhost=SOAHOST2VHN1
    -Dtangosol.coherence.localport=8089
    -Dtangosol.coherence.wka1.port=8089
    -Dtangosol.coherence.wka2.port=8089
    

    Note:

    There should be no breaks in lines between the different -D parameters. Do not copy or paste the text from above to your Administration Console's arguments text field. This may result in HTML tags being inserted in the Java arguments. The text should not contain other text characters than those included the example above.
  8. Click Save and Activate Changes.

Note:

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.

Note:

The multicast and unicast addresses are different from the ones used by the WebLogic Server cluster for cluster communication. SOA 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.

5.6 Setting Connection Destination Identifiers for B2B Queues

Oracle B2B uses specific JMS Destination Member calls, and requires setting the Create Destination Identifier (CDI) for these calls to succeed. To set up the CDI:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand the Services node, and then the Messaging node.

  3. Click JMS Modules, and then SOAJMSModule.

  4. Click Lock and Edit.

  5. Click the dist_B2BEventQueue_auto, Configuration, and the General tab, and then click Advanced.

  6. In the Create Destination Identifier field, add the following jndi name for the queue:

    jms/b2b/B2BEventQueue

  7. Repeat these steps, creating the following Create Destination Identifiers for the queues listed below:

    • dist_B2B_OUT_QUEUE_auto : jms/b2b/B2B_OUT_QUEUE

    • dist_B2B_IN_QUEUE_auto : jms/b2b/B2B_IN_QUEUE

    • dist_B2BBroadcastTopic_auto : jms/b2b/B2BBroadcastTopic

    • dist_XmlSchemaChangeNotificationTopic_auto : jms/fabric/XmlSchemaChangeNotificationTopic

  8. Click Save and Active Changes.

5.7 Disabling Host Name Verification for the WLS_SOAn Managed Server

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

To disable host name verification, complete these steps:

  1. Log in to Oracle WebLogic Server Administration Console.

  2. Click Lock and Edit.

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

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

  5. Select WLS_SOA1 (represented as a hyperlink) from the Names column of the table. The Settings page appears.

  6. Select the SSL tab.

  7. Expand the Advanced section of the page.

  8. Set Hostname Verification to None.

  9. Click Save.

  10. Repeat these steps for the WLS_SOA2 managed server.

  11. Save and activate the changes.

5.8 Restarting the Node Manager on SOAHOST1

To restart the Node Manager on SOAHOST1:

  1. Stop Node Manager by stopping the process associated with it:

    1. If it is running in the foreground in a shell, simply use CTRL+C.

    2. If it is running in the background in the shell, find the associate process and use the kill command to stop it. For example:

      SOAHOST1> ps -ef | grep NodeManager
      orcl      9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh
      
      SOAHOST1>kill -9 9139 
      
  2. Start Node Manager:

    SOAHOST1> ./startNodeManager.sh
    

5.9 Propagating the Domain Changes to the Managed Server Domain Directory

To propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory:

  1. Create a copy of the managed server domain directory and the managed server applications directory.

  2. Run the pack command on SOAHOST1 to create a template pack using the following commands:

    SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
    
    SOAHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/admin/<domain_name>/aserver/<domain_name> 
    -template=soadomaintemplateExtSOA.jar -template_name=soa_domain_templateExtSOA
    
  3. Run the unpack command on SOAHOST1 to unpack the propagated template to the domain directory of the managed server using the following command:

    SOAHOST1> ./unpack.sh -domain=ORACLE_BASE/admin/<domain_name>/mserver/<domain_name> 
    -overwrite_domain=true -template=soadomaintemplateExtSOA.jar 
    -app_dir=ORACLE_BASE/admin/<domain_name>/mserver/applications
    

    Note:

    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.

5.10 Starting the WLS_SOA1 Managed Server on SOAHOST1

To start the WLS_SOA1 managed server on SOAHOST1, complete these steps:

  1. Access the Administration Console at http://ADMINVHN:7001/console.

  2. Click Servers.

  3. Open the Control tab.

  4. Select WLS_SOA1.

  5. Click Start.

Note:

ADMINVHN is the virtual host name that maps to the virtual IP where the Administration Server is listening (in SOAHOST1).

5.11 Validating the WLS_SOA1 Managed Server

To validate the WLS_SOA1 managed server, complete these steps:

  1. 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 11.6, "Troubleshooting"for possible causes.

  2. Access http://SOAHOST1VHN1:8001/soa-infra/ to verify status of WLS_SOA1.

  3. Access http://SOAHOST1VHN1:8001/b2bconsole/ to verify status of B2B.

  4. Access http://SOAHOST1VHN1:8001/integration/worklistapp/ to verify status of the worklist application. Before verifying access is granted, ensure that the WLS_WSM1 managed server is up and running.

    Note:

    Notice that, although the WLS_SOA1 server may be up, some applications may be in a failed state. Therefore, Oracle recommends verifying the URLs above and watch for errors pertaining each individual application in the server's output file.

5.12 Propagating the Domain Configuration to SOAHOST2 Using the unpack Utility

To propagate the domain configuration, complete these steps:

  1. Run the following command on SOAHOST1 to copy the template file created in the previous step to SOAHOST2.

    SOAHOST1> cd ORACLE_HOME/common/bin
    
    SOAHOST1> scp soadomaintemplateExtSOA.jar oracle@node2:ORACLE_HOME/common/bin
    
  2. Run the unpack command on SOAHOST2 to unpack the propagated template.

    SOAHOST2> cd ORACLE_HOME/common/bin
    
    SOAHOST2> ./unpack.sh -domain=ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/ -template=soadomaintemplateExtSOA.jar -overwrite_domain=true -app_dir=ORACLE_BASE/admin/<domain_dir>/mserver/apps
    

Note:

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.

5.13 Restarting Node Manager on SOAHOST2

Perform the steps in Section 5.8, "Restarting the Node Manager on SOAHOST1" on SOAHOST2.

5.14 Starting and Validating the WLS_SOA2 Managed Server

Perform these steps to start the WLS_SOA2 managed server and check that it is configured correctly:

  1. Start the WLS_SOA2 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 11.6, "Troubleshooting" for possible causes.

  3. Access http://SOAHOST2VHN1:8001/soa-infra.

  4. Access http://SOAHOST2VHN1:8001/b2bconsole to verify status of B2B.

  5. Access http://SOAHOST2VHN1:8001/integration/worklistapp/ to verify status of the worklist application. Before verifying access is granted, ensure that at least one of the managed servers (WLS_WSM1 or WLS_WSM2) is up and running.

    Note:

    Although the WLS_SOA1 server may be up, some applications may be in a failed state. Therefore, Oracle recommends verifying the URLs above and watch for errors pertaining each individual application in the server's output file.

5.15 Configuring Oracle HTTP Server for the WLS_SOAn Managed Servers

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

  1. On WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_BASE/ admin/<instance_name>/config/OHS/<component_name>/mod_wl_ohs.conf file:

    # SOA soa-infra app
    <Location /soa-infra>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # SOA inspection.wsil
    <Location /inspection.wsil>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # Worklist
    <Location /integration>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # B2B
    <Location /b2bconsole>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # UMS prefs
    <Location /sdpmessaging/userprefs-ui>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # Default to-do taskflow
    <Location /DefaultToDoTaskFlow>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # Workflow
    <Location /workflow>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # UMS parlay 
    <Location /sdpmessaging/parlayx>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # UMS WS
    <Location /ucs/messaging/webservice>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    #Required if attachments are added for workflow tasks
     <Location /ADFAttachmentHelper> 
        SetHandler weblogic-handler 
        WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    
    # SOA composer application 
     <Location /soa/composer> 
         SetHandler weblogic-handler 
         WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
        WLProxySSL ON
        WLProxySSLPassThrough ON
    </Location>
    

    Note:

    The entry for /workflow is optional. It is for workflow tasks associated with ADF task forms. The /workflow URL itself can be a different value, depending on the form.
  2. Restart Oracle HTTP Server on WEBHOST1 and WEBHOST2:

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

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

Sample scenarios:

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

5.16 Validating Access Through Oracle HTTP Server

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

Verify that you can access these URLs, where 'webhostN' specifies the name of each Oracle HTTP Server host (for example, WEBHOST1, WEBHOST2):

Validate SOA_Cluster through both Oracle HTTP Server instances.

Refer to load balancer configuration to access the system through the load balancer.

5.17 Setting the Frontend HTTP Host and Port

You must set the frontend HTTP host and port for the Oracle WebLogic Server cluster:

  1. In the WebLogic Server Administration Console, in the Change Center section, click Lock & Edit.

  2. In the left pane, choose Environment in the Domain Structure window and then choose Clusters. The Summary of Clusters page appears.

  3. Select the SOA_Cluster cluster.

  4. Select HTTP.

  5. Set the values for the following:

    • Frontend Host: wc.mycompany.com

    • Frontend HTTPS Port: 443

    • Frontend HTTP Port: 80

  6. Click Save.

  7. To activate the changes, click Activate Changes in the Change Center section of the Administration Console.

  8. Restart the servers to make the Frontend Host directive in the cluster effective.

Note:

If you do not set the frontend HTTP host and port, you get the following message when trying to retrieve a document definition XSD from Oracle B2B:
An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.

Callback URL

The SOA system calculates the callback URL as follows:

5.18 Setting the WLS Cluster address for Direct Binding/RMI invocations to composites

When using direct binding composites, you must set the WLS Cluster address for the SOA_Cluster. To set the WLS Cluster address:

  1. In the WebLogic Server Administration Console, in the Change Center section, click Lock & Edit.

  2. In the left pane, choose Environment from the Domain Structure window, and then choose Clusters. The Summary of Clusters page appears.

  3. Select the SOA_Cluster cluster.

  4. In the Configuration, General tab, enter the following in the Cluster Address field:

    SOAHOST1VHN1:8001,SOAHOST2VHN1:8001

  5. Click Save.

  6. To activate the changes, click Activate Changes in the Change Center section of the Administration Console.

  7. Restart the servers for the Frontend Host directive to take effect in the cluster.

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

    If soa-infra config properties are not specified, but the WLS Cluster address is specified, the cluster address from the JNDI provider URL is used. This cluster address can be a single DNS name which maps to the clustered servers' IP addresses 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.

5.19 Configuring a Shared JMS Persistence Store

Configure the location for all of the persistence stores as a directory that is visible from both nodes. For more information see Section 2.3, "Shared Storage and Recommended Directory Structure." You must then change all of the persistent stores to use this shared base directory as follows:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand the Services node and then click the Persistence Stores node. The Summary of Persistence Stores page appears.

  3. Select the persistence store (represented as a hyperlink) from the Name column of the table. The Settings page for the persistence store appear.

  4. In the Configuration tab, enter the location on a persistent storage solution (such as NAS or SAN) that is available to other servers in the cluster in the Directory field. Specifying this location enables pending JMS messages to be sent. The location should follow the following directory structure:

    ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/jms
    

    Note:

    Both WLS_SOA1 and WLS_SOA2 must be able to access this directory. This directory must also exist before you restart the server.
  5. Click Save and activate changes.

  6. Restart the servers to make the change in the persistent stores effective.

5.20 Configuring a Default Persistence Store for Transaction Recovery

Each server has a transaction log that stores information about committed transactions that are coordinated by the server that may not have been completed. The 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 servers within a cluster, store the transaction log in a location accessible to a server and its backup servers.

Note:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

To set the location for the default persistence store, complete these steps:

  1. Log into the Oracle WebLogic Server Administration Console.

  2. In the Domain Structure window, expand the Environment node and then click the Servers node. The Summary of Servers page appears.

  3. Click the name of the server (represented as a hyperlink) in Name column of the table. The settings page for the selected server appears and defaults to the Configuration tab.

  4. Click the Services tab.

  5. In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:

    ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/tlogs
    
  6. Click Save.

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. This directory must also exist before you restart the server.

5.21 Enabling High Availability for Oracle File and FTP Adapters

The Oracle File and FTP Adapters enable a BPEL process or an Oracle Mediator to read and write files on local file systems and on remote file systems through FTP (File Transfer Protocol).These adapters support high availability for an active-active topology with Oracle BPEL Process Manager and Oracle Mediator service engines for both inbound and outbound operations. To make Oracle File and FTP Adapters highly available for outbound operations, use the database mutex locking operation as described in "High Availability in Outbound Operations" in Oracle Fusion Middleware User's Guide for Technology Adapters. The database mutex locking operation enables these adapters to ensure that multiple references do not overwrite one another if they write to the same directory.

Note:

The File Adapter picks up a file from the inbound directory, processes it, and then outputs a file to the output directory. Because the File Adapter is non-transactional, files can be processed twice. As a result, it is possible to get duplicate files when there is failover in the RAC backend or in the SOA managed servers.

5.21.1 Using the Database Mutex Locking Operation

Use the following procedure to make an outbound Oracle File or FTP Adapter service highly available using database table as a coordinator:

Note:

You must increase global transaction timeouts if you use database as a coordinator.
  1. Create Database Tables

    You are not required to perform this step since the database schemas are pre-created as a part of soainfra.

  2. Modify Deployment Descriptor for Oracle File Adapter

    Modify Oracle File Adapter deployment descriptor for the connection-instance corresponding to eis/HAFileAdapter from the Oracle WebLogic Server console:

    1. Log into your Oracle WebLogic Server console. To access the console navigate to http://servername:portnumber/console.

    2. Click Deployments in the left pane for Domain Structure.

    3. Click FileAdapter under Summary of Deployments on the right pane.

    4. Click the Configuration tab.

    5. Click the Outbound Connection Pools tab, and expand javax.resource.cci.ConnectionFactory to see the configured connection factories.

    6. Click eis/HAFileAdapter. The Outbound Connection Properties for the connection factory corresponding to high availability is displayed.

    7. The connection factory properties appear as shown in Figure 5-4.

      Figure 5-4 Oracle WebLogic Server Console - Settings for javax.resource.cci.Connectionfactory Page

      Description of Figure 5-4 follows
      Description of "Figure 5-4 Oracle WebLogic Server Console - Settings for javax.resource.cci.Connectionfactory Page"

      Click on Lock and Edit. After this, the property value column becomes editable (you can click on any of the rows under "Property Value" and modify its value).

      The new parameters in connection factory for Oracle File and FTP Adapters are as follows:

      controlDir: Set it to the directory structure where you want the control files to be stored. You must set it to a shared location if multiple WebLogic Server instances run in a cluster. Structure the directory for shared storage as follows:

      ORACLE_BASE/admin/<domain_name>/<cluster_name>/fadapter
      

      inboundDataSource: Set the value to jdbc/SOADataSource. This is the data source, where the schemas corresponding to high availability are pre-created. The pre-created schemas can be found under ORACLE_HOME/ rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql. If you want to create the schemas elsewhere, use this script. You must set the inboundDataSource property accordingly if you choose a different schema.

      outboundDataSource: Set the value to jdbc/SOADataSource. This is the data source where the schemas corresponding to high availability are pre-created. The pre-created schemas can be found under ORACLE_HOME/ rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql. If you want to create the schemas elsewhere, use this script. You must set the outboundDataSource property if you choose to do so.

      outboundDataSourceLocal: Set the value to jdbc/SOALocalTxDataSource. This is the datasource where the schemas corresponding to high availability are pre-created.

      outboundLockTypeForWrite: Set the value to oracle if you are using Oracle Database. By default the Oracle File and FTP Adapters use an in-memory mutex to lock outbound write operations. You must choose from the following values for synchronizing write operations:

      memory: The Oracle File and FTP Adapters use an in-memory mutex to synchronize access to the file system.

      oracle: The adapter uses Oracle Database sequence.

      db: The adapter uses a pre-created database table (FILEADAPTER_MUTEX) as the locking mechanism. You must use this option only if you are using a schema other than the Oracle Database schema.

      user-defined: The adapter uses a user-defined mutex. To configure the user-defined mutex, you must implement the mutex interface: "oracle.tip.adapter.file.Mutex" and then configure a new binding-property with the name "oracle.tip.adapter.file.mutex" and value as the fully qualified class name for the mutex for the outbound reference.

    8. Click Save after you update the properties. The Save Deployment Plan page appears.

    9. Enter a shared storage location for the deployment plan. The directory structure is as follows:

      ORACLE_BASE/admin/<domain_name>/<cluster_name>/dp/Plan.xml
      
    10. Click Save and Activate.

    11. Configure BPEL Process or Mediator Scenario to use the connection factory as shown in the following example (in the jca file included in the composite for the binding component):

      <adapter-config name="FlatStructureOut" adapter="File Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
        <connection-factory location="eis/HAFileAdapter" adapterRef=""/>
        <endpoint-interaction portType="Write_ptt" operation="Write">
      <interaction-spec className="oracle.tip.adapter.file.outbound.FileInteractionSpec">
            <property../>
            <property../>
          </interaction-spec>
        </endpoint-interaction>
      </adapter-config>
      

      Note:

      The location attribute is set to eis/HAFileAdapter for the connection factory.

5.22 Scaling the Oracle Database Adapter

If you are using Logical Delete polling, and you set MarkReservedValue, skip locking is not used.

Formerly, the best practice for multiple Oracle Database Adapter process instances deployed to multiple Oracle BPEL Process Manager, or Oracle Mediator nodes was essentially using LogicalDeletePollingStrategy or DeletePollingStrategy with a unique MarkReservedValue on each polling node, and setting MaxTransactionSize.

However, with the introduction of skip locking in this release that approach has now been superseded. If you were using this approach previously, you can simply remove (in db.jca) or clear (Logical Delete Page of wizard) the MarkReservedValue, and you automatically get skip locking.

The benefits of using skip locking over a reserved value include:

For more information, see "Scalability" and "Polling Strategies" in Oracle Fusion Middleware User's Guide for Technology Adapters.

5.23 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 this 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 this guide. For information on how to recover components, see "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" in the guide. Also refer to the Oracle Database Backup and Recovery Guide for information on database backup.

To back up the installation a this point, complete these steps:

  1. Back up the web tier:

    1. Shut down the instance using opmnctl.

      ORACLE_BASE/admin/<instance_name>/bin/opmnctl stopall
      
    2. Back up the Middleware Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME
      
    3. Back up the Instance Home on the web tier using the following command (as root):

      tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE
      
    4. Start the instance using opmnctl:

      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 OS tools such as tar for cold backups if possible.

  3. Back up the Administration Server domain directory to save your domain configuration. The configuration files all exist under the ORACLE_BASE/ admin/<domain_name> directory.

    SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/<domain_name>
    

Note:

ORACLE_HOME should be backed up if any changes are made to the XEngine configuration that are part of your B2B setup. These files are located under ORACLE_HOME/soa/thirdparty/edifecs/XEngine. To back up ORACLE_HOME, execute the following command:
SOAHOST1> tar -cvpf fmwhomeback.tar MW_HOME