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

  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 SOAHOST1VHN2 and SOAHOST2VHN1

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 8, "Configuring External Services"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.)

    SOAHOS1> 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:

      • Business Rules

      • User Messaging Service

      • User Messaging Service Drivers for SMS, IM, Voice

      • User Messaging Service Worklist Drivers

      • 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

      • 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 Managed Servers, Cluster and Machines, and then Deployment and services. Click Next.

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

    WLS_SOA1

    8001

    n/a

    No

    WLS_SOA2

    WLS_SOA2

    8001

    n/a

    No

    WLS_WSM1

    SOAHOST1

    7010

    n/a

    No

    WLS_WSM2

    SOAHOST2

    7010

    n/a

    No


    Click Next.

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

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

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

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

    • SOAHOST1:

      • AdminServer

      • WLS_SOA1

      • WLS_WSM1

    • SOAHOST2:

      • WLS_SOA2

      • WLS_WSM2

    Click Next.

  16. 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.rules.*, oracle.sdp.*, and oracle.soa.* deployments should be targeted only to SOA_Cluster.

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

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

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

    Click Next.

  17. 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 OWSM Startup 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.

  18. 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.
  19. 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 so that the changes to the domain are picked up.

  1. Stop the Administration Server.

    SOAHOST1> cd ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/bin
    SOAHOST1> ./stopWebLogic.sh
    
  2. Start the Administration Server:

    SOAHOST1> ./startWebLogic.sh
    

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 (SOAHOST1VHN2 and 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:

SOAHOST1VHN2 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 Configuration tab, and then the Server Start tab.

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

    For WLS_SOA1, enter the following:

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

    For WLS_SOA2, enter the following:

    -Dtangosol.coherence.wka1=SOAHOST2VHN1 -Dtangosol.coherence.wka2=SOAHOST1VHN2 -Dtangosol.coherence.localhost=SOAHOST2VHN1
    
  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.

Note:

The coherence cluster used for deployment uses port 8088 by default. This port can be changed by specifying the -Dtangosol.coherence.wkaX.port startup parameter.

5.6 Running the soa-createUDD.py Script

Before you can start the WLS_SOA1 managed server on SOAHOST1, you must run the soa-createUDD.py script. You run the script using WLST offline:

  1. Run the setDomainEnv.sh script to set up the environment:

    SOAHOST1>. ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>/bin/setDomainEnv.sh
    
  2. Run the soa-createUDD.py script, which is located in the ORACLE_HOME/bin directory:

    SOAHOST1> MW_HOME/jrockit_160_14_R27.6.4-18/bin/java weblogic.WLST ORACLE_HOME/bin/soa-createUDD.py --domain_home ORACLE_BASE/admin/<domain_name>/aserver/<domain_name> --soacluster SOA_Cluster
    
  3. Restart the Administration Server. See the steps in Section 5.4, "Restarting the Administration Server."

  4. Verify that the following modules are listed in the Oracle WebLogic Server Administration Console:

    • SOAJMSModuleUDDs

      Verify this module by first expanding the Services node in the Domain Structure window and then expanding the Messaging node in the Oracle WebLogic Server Administration Console. Select JMS Modules. Select SOAJMSMOduleUDDS (represented as a hyperlink) in the Names column of the table. Open the Subdeployment tab, and then click SOAJMSSubDM.

      Verify that the module is targeted to SOAJMSServer_auto_1 and SOAJMSServer_auto_2.

    • UMSJMSSystemResource

      Verify this module by first expanding the Services node in the Domain Structure window and then expanding the Messaging node in the Oracle WebLogic Server Administration Console. Select JMS Modules. Select UMSJMSSystemResource (represented as a hyperlink) in the Names column of the table. Open the Subdeployment tab, and then click UMSJMSSubDMSOA.

      Verify that the module is targeted to UMSJMSServer_auto_1 and UMSJMSServer_auto_2.

You also create UDDs using the HA Power Tools tab in the Oracle WebLogic Administration Console as described in the Oracle Fusion Middleware High Availability Guide

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, complete these steps:

  1. Stop Node Manager.

    SOAHOST1> cd WL_HOME/server/bin
    SOAHOST1> ./stopNodeManager.sh
    
  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_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/apps
    

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://SOAHOST1VHN1:7001/console.

  2. Click Servers.

  3. Open the Control tab.

  4. Select WLS_SOA1.

  5. Click Start.

Note:

SOAHOST1VHN1 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 and WLS_WSM1 Managed Servers

To validate the WLS_SOA1 and WLS_WSM1 managed servers, 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.5, "Troubleshooting" for possible causes.

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

  3. Access http://SOAHOST1:7010/wsm-pm to verify status of WLS_WSM1.

  4. Access http://SOAHOST1VHN2:8001/b2b to verify status of B2B.

  5. Access http://SOAHOST1VHN2:8001/integration/worklistapp to verify status of the worklist application.

Note:

These URLs vary if you use VIPs for WLS_SOAn.

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
    

5.13 Extracting the XEngine Files in SOAHOST2

To enable B2B's XEngine in SOAHOST2, you need to extract the content of the XEngine tar manually:

SOAHOST2>cd ORACLE_HOME/soa/thirdparty/edifecs
SOAHOST2>tar -xzvf XEngine.tar.gz

5.14 Restarting Node Manager on SOAHOST2

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

5.15 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.5, "Troubleshooting" for possible causes.

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

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

  5. Access http://SOAHOST2VHN1:8001/integration/worklistapp to verify status of the worklist application.

5.16 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 SOAHOST1VHN2:8001,SOAHOST2VHN1:8001
    </Location>
    
    # Worklist
    <Location /integration/>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN2:8001,SOAHOST2VHN1:8001
    </Location>
    
    # B2B
    <Location /b2b>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN2:8001,SOAHOST2VHN1:8001
    </Location>
    
    # UMS prefs
    <Location /sdpmessaging/userprefs-ui >
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN2:8001,SOAHOST2VHN1:8001
    </Location>
    
    # Default to-do taskflow
    <Location /DefaultToDoTaskFlow/>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN2:8001,SOAHOST2VHN1:8001
    </Location>
    
    # Workflow
    <Location /workflow>
        SetHandler weblogic-handler
        WebLogicCluster SOAHOST1VHN2:8001,SOAHOST2VHN1:8001
    </Location>
    
    #Required if attachments are added for workflow tasks
     <Location /ADFAttachmentHelper> 
        SetHandler weblogic-handler 
        WebLogicCluster SOAHOST1VHN2:8001,SOAHOST2VHN1:8001 
     </Location>
    
    # SOA composer application 
     <Location /soa/composer> 
         SetHandler weblogic-handler 
         WebLogicCluster SOAHOST1VHN2:8001,SOAHOST2VHN1:8001 
     </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:

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

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

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

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

5.17 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.5, "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):

  • http://webhostN:7777/soa-infra

  • http://webhostN:7777/integration/worklistapp

  • http://webhostN:7777/b2b

  • http://webhostN:7777/sdpmessaging/userprefs-ui

Validate SOA_Cluster through both Oracle HTTP Server instances.

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

5.18 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 WLS_SOA cluster.

  4. Select HTTP.

  5. Set the values for the following:

    • Frontend Host: wc.mycompany.com

    • Frontend HTTPS Port: 443

  6. Click Save.

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

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:

  • If a request to SOA originates from an external or internal service, then SOA uses the callback URL specified by the client.

  • If a request to an external or internal asynchronous service originates from SOA, the callback URL is determined using the following method, in decreasing order of preference:

    1. Use callbackServerURL specified as a binding property for the specific reference. (You can set this when modeling the composite or at runtime using the MBeans). This allows different service calls to have different callback URLs. That is, a callback URL from an external service can be set to be different than one to an internal service In the context of the EDG architecture, typically this will be soa.mycompany.com (443/https) for external services and soainternal.mycompany.com (7777/http) for internal services. At runtime, this property is set using the System MBean Browser, through the corresponding binding mbean. To add a specific URL, add a callbackServerURL property to its Properties attribute, then invoke the save operation.

    2. Use the callback URL as specified in soa-infra-config.xml. In this case, only one address can be specified. When a mix of both external and internal services can be invoked, this should be set to soa.mycompany.com (443/https) in the EDG architecture. When only internal services are to be invoked, this can be set to soainternal.mycompany.com (7777/http).

    3. Use the callback URL as the frontend host specified in WLS for the SOA_Cluster. In this case, too, only one address can be specified and the recommendation is same as the one for soa-infra-config.xml.

    4. Use the local host name as provided by WLS MBean APIs. This is not recommended in HA environments such as EDG.

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 4.1, "Installing Oracle Fusion Middleware Home." 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, as shown in Figure 5-4.

    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.

      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:

      <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

The best practice for multiple Oracle Database Adapter process instances that are deployed to multiple Oracle BPEL Process Manager or Oracle Mediator nodes is to use LogicalDeletePollingStrategy or DeletePollingStrategy with a unique MarkReservedValue on each polling node and setting MaxTransactionSize. Example 5-1 illustrates how to use MarkReservedValue with DeletePollingStrategy in a .jca file.

Example 5-1 Snippet of .jca Showing the Usage of MarkReservedValue with DeletePolling Strategy

<adapter-config name="poll" adapter="Database Adapter"
xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/DB/SOADemo" UIConnectionName="SOADemo"
adapterRef=""/>
<endpoint-activation portType="poll_ptt" operation="receive">
    <activation-spec className="oracle.tip.adapter.db.DBActivationSpec">
         <property name="DescriptorName" value="poll.PerfMasterIn"/>
          <property name="QueryName" value="pollSelect"/>
          <property name="MappingsMetaDataURL" value="poll-or-mappings.xml"/>
          <property name="PollingStrategy" value="DeletePollingStrategy"/>
          <property name="MarkReadColumn" value="ATTRIBUTE2"/>
          <property name="MarkReservedValue"
 value=MyPrefix_${weblogic.Name-1}-${IP}"/>
          <property name="MarkUnreadValue" value="UNREAD"/>
          <property name="PollingInterval" value="5"/>
          <property name="MaxRaiseSize" value="5"/>
          <property name="MaxTransactionSize" value="10"/>
          <property name="SequencingColumn" value="PK"/>
          <property name="ReturnSingleResultSet" value="false"/>
     </activation-spec>
 </endpoint-activation>
 </adapter-config> 

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