9 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 8, "Creating a Domain for an Exalogic Enterprise Deployment."

Note:

Before starting the setup process, read the Oracle Fusion Middleware Release Notes at the following URL:

http://docs.oracle.com/cd/E28280_01/relnotes.htm

SOA components use server migration, allowing SOA managed servers to be migrated from one host to another, so that if a node hosting one of the servers fails, the service can continue on another node. For information about configuring server migration, see Chapter 13, "Configure Server Migration for an Exalogic Enterprise Deployment."

This chapter contains the following sections:

• Section 9.1, "Overview of Extending the Domain for SOA Components."

• Section 9.2, "Pre-verifications for Extending the Domain for Oracle SOA Components."

• Section 9.3, "Extending the Domain for SOA Components using the Configuration Wizard."

• Section 9.4, "Configuring Oracle Coherence for Deploying Composites."

• Section 9.5, "Post-Configuration and Verification Tasks."

• Section 9.6, "Configuring Network Channels for HTTP and T3 Clients Through EoIB."

• Section 9.7, "Configuring Oracle Traffic Director with the Extended Domain."

• Section 9.8, "Configuring a Default Persistence Store for Transaction Recovery."

• Section 9.9, "Configuring Coherence Caches for Dehydrations."

• Section 9.10, "Updating SOA JVM settings."

• Section 9.11, "Enabling Cluster-Level Session Replication Enhancements."

• Section 9.12, "Configuring Oracle Adapters."

• Section 9.13, "Updating the Workflow Front End Address for Appropriate Task Display."

• Section 9.14, "Updating the B2B Instance Identifier for Transports."

• Section 9.15, "Backing Up the Oracle SOA Configuration."

9.1 Overview of Extending the Domain for SOA Components

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

Table 9-1 Steps for Extending the Domain for SOA Components

Step	Description	More Information
Prepare for extending the Domain for SOA Components	Verify that the appropriate virtual IP mapping for each of the hostnames on the two SOA Machines is available.	Section 9.2, "Pre-verifications for Extending the Domain for Oracle SOA Components"
Extend the Domain for SOA Components	Extend the WebLogic domain you created in Chapter 8.	Section 9.3, "Extending the Domain for SOA Components using the Configuration Wizard"
Configure Oracle Coherence for Deploying Composites	Configure Oracle Coherence in order to use unicast communication for deploying composites for Oracle BPEL Dehydration.	Section 9.4, "Configuring Oracle Coherence for Deploying Composites"
Post-Configuration and Verification Tasks	Follow these instructions for post-configuration and validation tasks.	Section 9.5, "Post-Configuration and Verification Tasks"
Configure Additional Network Channels for T3 clients.	If your HTTP clients and T3 clients use the 10 Gb Ethernet network, you must create additional network channels for the SOA Servers on SOAHOST1 and SOAHOST2.	Section 9.6, "Configuring Network Channels for HTTP and T3 Clients Through EoIB"
Configure Oracle Traffic Director for the Extended Domain	Configure Oracle Traffic Director to route to the SOA servers for the appropriate URLs.	Section 9.7, "Configuring Oracle Traffic Director with the Extended Domain"
Configure a Default Persistence Store	Configure a default persistence store for transaction recovery.	Section 9.8, "Configuring a Default Persistence Store for Transaction Recovery"
Configure Oracle Coherence for Deploying Composites	Configure Oracle Coherence in order to use unicast communication for deploying composites.	Section 9.9, "Configuring Coherence Caches for Dehydrations"
Configure Oracle Adapters	Enable high availability for Oracle File and FTP Adapters, enable high availability for Oracle JMS Adapters, and scale the Oracle Database Adapter.	Section 9.12, "Configuring Oracle Adapters"
Update the B2B Instance Identifier for Transports	Set up File, FTP, or Email transports in a high availability environment.	Section 9.14, "Updating the B2B Instance Identifier for Transports"
Back Up the SOA Configuration	Back up the newly extended domain configuration.	Section 9.15, "Backing Up the Oracle SOA Configuration"

9.2 Pre-verifications for Extending the Domain for Oracle SOA Components

Before you run the Configuration Wizard to extend the domain, verify that the appropriate virtual IP mapping for each of the hostnames on the two SOA Machines is available. Also, verify that the clocks are synchronized in the nodes where you will run SOA.

This section includes the following topics:

• Section 9.2.1, "Verify Virtual IPs and Hostnames on SOAHOST1 and SOAHOST2"

• Section 9.2.2, "Synchronize System Clocks"

• Section 9.2.3, "Verifying Oracle Home Installation"

9.2.1 Verify Virtual IPs and Hostnames on SOAHOST1 and SOAHOST2

Make sure you can ping from each of the cells and from the OTD nodes the following hostnames:

• SOAHOST1-PRIV-V1

• SOAHOST2-PRIV-V1

• SOAHOST1VHN1

• SOAHOST2VHN1

9.2.2 Synchronize System Clocks

Verify that clocks are in sync by running as simultaneously as possible a "date" command in the two nodes in the cluster.

9.2.3 Verifying Oracle Home Installation

This chapter is based on the assumption that you have installed WL_HOME and MW_HOME (binaries) containing Oracle Fusion Middleware SOA on shared storage, and they are available from SOAHOST1 and SOAHOST2. This chapter is also based on the assumption that you have already configured Node Manager, Admin Server and WSM Servers as described in previous chapters. Validate the installation by verifying that the following directories and files appear in the ORACLE_HOME directory after installing both Oracle WebLogic Sever and Oracle Fusion Middleware for SOA:

• coherence_X.X

• jrockit-jdkY.Y

• modules

• oracle_common

• registry.xml

• utils

• domain-reistry.xml

• logs

• ocm.rsp

• registry.dat

• soa

• wlserver_10.3

9.3 Extending the Domain for SOA Components using the Configuration Wizard

Use the Configuration Wizard to extend the domain created in Chapter 8, "Creating a Domain for an Exalogic Enterprise Deployment," to contain SOA components.

Note:

If you have not backed up the domain created in Chapter 8, "Creating a Domain for an Exalogic Enterprise Deployment," back up the current domain before extending it for SOA 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 using the Configuration Wizard:

1. Change directory to the location of the Configuration Wizard. This is within the SOA home directory on SOAHOST1. Oracle recommends having all database instances up.

   ORACLE_COMMON_HOME/common/bin
   

2. Start the Configuration Wizard.

   ./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 following WebLogic domain directory

   ASERVER_HOME
   

   Click Next.

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

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

   2. 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 the domain in Chapter 8, "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 see 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 Gridlink RAC Data Sources screen

   1. Select the OPSS datasource created for Policy Store re-association.

   2. Deselect Enable SSl.

   3. Click Next.

8. In the Test Datasource screen, click Next.

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

   • Select the SOA Infrastructure, User Messaging Service, and SOA MDS Schema.

   • For the Oracle RAC configuration for component schemas, select Convert to GridLink

   Click Next.

10. The Configure Gridlink RAC Component Schema screen appears (Figure 9-1).

    Figure 9-1 Configure GridLink RAC Component Schema Screen

    
    Description of "Figure 9-1 Configure GridLink RAC Component Schema Screen"
    
    

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

    • Driver: Select Oracle's driver (Thin) for GridLinkConnections,Versions:10 and later.

    • Service Name: Enter the service name of the database using lowercase characters. For example:

      soaedg.mycompany.com.

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

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

    • Select Enable FAN

    • Make sure Enable SSL is unchecked (alternatively if ssl is selected for ONS notifications to be encrypted, provide the appropriate wallet and wallet password).

    • Service listener: Enter the SCAN address and port for the RAC database being used. You can identify this address by querying the appropriate parameter in the database using the TCP protocol:

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

      Note:

      For Oracle Database 11g Release 1 (11.1), use the virtual IP and port of each database instance listener, for example:

      custdbhost1-vip.mycompany.com (port 1521)
      

      and

      custdbhost2-vip.mycompany.com (1521)
      

      For Oracle Database 10g, use multi data sources to connect to an Oracle RAC database.

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

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

      Note:

      For Oracle Database 11g Release 1 (11.1), use the hostname and port of each database's ONS service, for example

      custdbhost1.mycompany.com (port 6200)
      

      and

      custdbhost2.mycompany.com (6200)
      

11. In the Test JDBC Data Sources screen, confirm that all connections were successful.

    The connections are tested automatically. The Status column displays the results. If all connections are not successful, click Previous to return to the previous screen and correct your entries.

    Click Next when all the connections are successful.

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

    • JMS Distributed Destinations

    • Managed Servers, Clusters, and Machines

    • Deployments and Services

    • JMS File Store

    Click Next.

13. In the Select JMS Distributed Destination Type screen, ensure that ALL JMS system resources are configured to be UDD. This should be the default.

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

    1. Select the automatically created server and click Rename to change the name to WLS_SOA1.

    2. Click Add to add another new server and enter WLS_SOA2 as the server name.

    3. Give servers WLS_SOA1 and WLS_SOA2 the attributes in Table 9-2. Do not modify the other servers that are shown in this screen; leave them as they are.

    Table 9-2 Managed Servers

    Name	Listen Address	Listen Port	SSL Listen Port	SSL Enabled
    WLS_SOA1	SOAHOST1-PRIV-V1	8001	n/a	No
    WLS_SOA2	SOAHOST2-PRIV-V1	8001	n/a	No
    WLS_WSM1	SOAHOST1-PRIV	7010	n/a	No
    WLS_WSM2	SOAHOST2-PRIV	7010	n/a	No

    
    

    Click Next.

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

    Table 9-3 Clusters

    Name	Cluster Messaging Mode	Multicast Address	Multicast Port	Cluster Address
    SOA_Cluster	unicast	n/a	n/a	SOAHOST1-PRIV-V1:8001,SOAHOST2-PRIV-V1:8001 Note: The cluster address should be changed to EoIB (SOAHOST1VHN1:8001,SOAHOST2VHN1:8001) addresses if external clients will access the SOA servers.
    WSM-PM_Cluster	unicast	n/a	n/a	Leave it empty.

    
    

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

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

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

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

    The following entries appear (listed in Table 9-4):

    • Table 9-4 Machines

      Name	Node Manager Listen Address
      SOAHOST1	SOAHOST1-PRIV
      SOAHOST2	SOAHOST2-PRIV
      ADMINHOST	localhost

      
      

    Leave all other fields to their default values.

    Click Next.

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

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

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

    • Target the oracle.sdp.* and oracle.soa.* libraries only to SOA_Cluster.

    • Target the oracle.rules.* library only to Admin Server and SOA_Cluster.

    • Target the wsm-pm application only to WSM-PM_Cluster.

    Click Next.

20. In the Target Services to Clusters or Servers screen, verify the following targets:

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

    • Target the OPSS to the WSM-PM_Cluster, SOA_Cluster and AdminServer

    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.2, "Shared Storage Recommendations for Exalogic Enterprise Deployments." For example:

    ASERVER_HOME/jms
    

    Note:

    The ASERVER_HOME/jms directory must exist before you enter this location in the JMS File Stores screen.

22. Click Next.

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

24. In the Extending Domain screen, click Done.

25. Restart the Administration Server using the procedure in Section 8.5.3, "Starting the Administration Server on SOAHOST1."

9.4 Configuring Oracle Coherence for Deploying Composites

Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication in SOA Exalogic 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 SOA Exalogic enterprise deployments where multiple IPs 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 SOA system from starting. The deployment framework must be properly customized for the network environment on which the SOA system runs. Oracle recommends the configuration described in this section.

This section includes the following topics:

• Section 9.4.1, "Enabling Communication for Deployment Using Unicast Communication"

• Section 9.4.2, "Specifying the Host Name Used by Oracle Coherence"

9.4.1 Enabling Communication for Deployment Using Unicast Communication

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 nine nodes as Well Known Addresses, but you can have more than nine nodes in the cluster. 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 (SOAHOST1-PRIV-V1 and SOAHOST2-PRIV-V1). 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 9–4).

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.

Note:

SOAHOST1-PRIV-V1 is the virtual host name that maps to the virtual IP where WLS_SOA1 is listening (in SOAHOST1). SOAHOST2-PRIV-V1 is the virtual host name that maps to the virtual IP where WLS_SOA2 is listening (in SOAHOST2).

Figure 9-2 Setting the Host Name Using the Start Server Tab of Oracle WebLogic Server Administration Console

Description of "Figure 9-2 Setting the Host Name Using the Start Server Tab of Oracle WebLogic Server Administration Console"

9.4.2 Specifying the Host Name Used by Oracle Coherence

Use the Administration Console to specify a host name used by Oracle Coherence.

To add the host name used by Oracle Coherence:

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

   http://ADMINVHN:7001/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 the Name column of the table. The settings page for the selected server appears.

5. Click Lock & Edit.

6. Click the Server Start tab (shown in Figure 9-2).

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

   Note:

   There should be no breaks in lines between the different -D parameters. Do not copy or paste the text to your Administration Console's arguments text field. It may result in HTML tags being inserted in the Java arguments. The text should not contain other text characters than those included the example below.

   Note:

   The Coherence cluster used for deployment uses port 8088 by default. You can change this port 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=SOAHOST1-PRIV-V1
   -Dtangosol.coherence.wka2=SOAHOST2-PRIV-V1
   -Dtangosol.coherence.localhost=SOAHOST1-PRIV-V1
   -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=SOAHOST1-PRIV-V1
   -Dtangosol.coherence.wka2=SOAHOST2-PRIV-V1
   -Dtangosol.coherence.localhost=SOAHOST2-PRIV-V1
   -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.

   For WLS_SOA1, enter the following:

   -Dtangosol.coherence.wka1=SOAHOST1-PRIV-V1
   -Dtangosol.coherence.wka2=SOAHOST2-PRIV-V1
   -Dtangosol.coherence.localhost=SOAHOST1-PRIV-V1
   

   For WLS_SOA2, enter the following:

   -Dtangosol.coherence.wka1=SOAHOST1-PRIV-V1
   -Dtangosol.coherence.wka2=SOAHOST2-PRIV-V1
   -Dtangosol.coherence.localhost=SOAHOST2-PRIV-V1
   

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.

9.5 Post-Configuration and Verification Tasks

After extending the domain with the configuration Wizard and configuring Oracle Coherence, follow these instructions for post-configuration and validation.

This section includes the following topics:

• Section 9.5.1, "Disabling Host Name Verification for the WLS_SOAn Managed Servers"

• Section 9.5.2, "Restarting the Node Manager on SOAHOST1"

• Section 9.5.3, "Propagating the Domain Changes to the Managed Server Domain Directory"

• Section 9.5.4, "Starting and Validating the WLS_SOA1 Managed Server"

• Section 9.5.5, "Propagating the Domain Configuration to SOAHOST2 Using the unpack Utility"

• Section 9.5.6, "Starting and Validating the WLS_SOA2 Managed Server"

• Section 9.5.7, "Validating GridLink Data Sources"

9.5.1 Disabling Host Name Verification for the WLS_SOAn Managed Servers

For the Exalogic enterprise deployment described in this guide, you set up the appropriate certificates to authenticate the different nodes with the Administration Server after you have completed the procedures to extend the domain for Oracle SOA Suite. You must disable the host name verification for the WLS_SOA1 and WLS_SOA2 managed servers to avoid errors when managing the different WebLogic Server instances. For more information, see Chapter 8, "Disabling Host Name Verification for the WLS_WSM2 Managed Server."

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

9.5.2 Restarting the Node Manager on SOAHOST1

Use the startNodeManager.sh script to restart Node Manager from the private directory for Node Manager in each compute node.

To restart the Node Manager on SOAHOST1:

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

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

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

     ps -ef | grep NodeManager
     orcl      9139  9120  0 Mar03 pts/6    00:00:00 /bin/sh ./startNodeManager.sh
     
     kill -9 9139 
     

2. Start Node Manager:

   ./startNodeManager.sh
   

9.5.3 Propagating the Domain Changes to the Managed Server Domain Directory

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

To propagate start scripts and classpath configuration:

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:

   cd ORACLE_COMMON_HOME/common/bin
   
   ./pack.sh -managed=true -domain=ASERVER_HOME 
   -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:

   ./unpack.sh -domain=MSERVER_HOME
   -overwrite_domain=true -template=soadomaintemplateExtSOA.jar 
   -app_dir=APP_DIR
   

   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.

   Note:

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

9.5.4 Starting and Validating the WLS_SOA1 Managed Server

Before starting the WLS_SOA1 managed server please make sure the WLS__WSM1 managed server is up and running. Otherwise WLS_SOA1 will not start.

Start and validate the WLS_SOA1 managed server using the Administration Console.

To start the WLS_SOA1 managed server on SOAHOST1:

1. Start the WLS_SOA1 managed server using the Oracle WebLogic Server Administration Console as follows:

   1. Access the Administration Console at the following URL:

      http://ADMINVHN:7001/console
      

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

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

   3. Click Servers.

      The Summary of Servers screen appears.

   4. Click the Control tab.

   5. Select WLS_SOA1 and then click Start.

2. Verify that the server status is reported as Running. 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.

3. Access the following URL to verify status of WLS_SOA1:

   http://SOAHOST1-PRIV-V1:8001/soa-infra/
   

   Note:

   Because SOAHOST1-PRIV-V1 is a private/infiniband address, you must use browser from within the Exalogic cells to open the http://SOAHOST1-PRIV-V1:8001/soa-infra/ URL.

   Access the following URL to verify the status of B2B:

   http://SOAHOST1-PRIV-V1:8001/b2bconsole/
   

   Access the following URL to verify status of the worklist application:

   http://SOAHOST1-PRIV-V1:8001/integration/worklistapp/
   

   Access the following URL to verify status of the composer application:

   http://SOAHOST1-PRIV-V1:8001/soa/composer/
   

   Before verifying access is granted, ensure that the WLS_WSM1 managed server is up and running.

9.5.5 Propagating the Domain Configuration to SOAHOST2 Using the unpack Utility

Propagate the domain you just configured to SOAHOST2 using the unpack utility.

To propagate the domain configuration:

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

   cd ORACLE_COMMON_HOME/common/bin
   
   scp soadomaintemplateExtSOA.jar oracle@SOAHOST2:ORACLE_COMMON_HOME/common/bin
   

2. Run the unpack command on SOAHOST2 to unpack the propagated template.

   cd ORACLE_COMMON_HOME/common/bin
   
   /unpack.sh-domain=MSERVER_HOME
   -template=soadomaintemplateExtSOA.jar -overwrite_domain=true
   -app_dir=APP_DIR
   

   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.

   Note:

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

9.5.6 Starting and Validating the WLS_SOA2 Managed Server

Use the Administration Console to start the WLS_SOA2 managed server. Validate it by accessing soa-infra, b2bconsole, and worklistapp URLs.

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

3. Access the following URL for soa-infra:

   http://SOAHOST2-PRIV-V1:8001/soa-infra
   

4. Access the following URL to verify status of B2B:

   http://SOAHOST2-PRIV-V1:8001/b2bconsole
   

5. Access the following URL to verify status of the worklist application.

   http://SOAHOST2-PRIV-V1:8001/integration/worklistapp/
   

   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.

6. Access the following URL to verify status of the composer application.

   http://SOAHOST2-PRIV-V1:8001/soa/composer/
   

9.5.7 Validating GridLink Data Sources

When the servers are started, verify that the GridLink data sources are correctly configured and that the ONS setup is correct. Perform this procedure for every GridLink data source created.

To validate the GridLink data sources configuration:

1. Log on to the Oracle WebLogic Administration Console.

   http://ADMINVHN:7001/console
   

2. In the Domain Structure tree, expand Services, and select Data Sources.

3. Click one of the new data sources.

4. Click the Monitoring tab and select one of the servers.

5. Click the Statistics tab and select one of the servers.

6. Click the ONS tab, and then click the Testing tab.

7. Select the server and click Test ONS.

   If both tests are successful, the configuration is correct. If the ONS test fails, verify that the ONS service is running in the RAC database nodes:

   orcl@db-scan1 ~]$ srvctl status scan_listener
   SCAN Listener LISTENER_SCAN1 is enabled
   SCAN listener LISTENER_SCAN1 is running on node db-scan1
   SCAN Listener LISTENER_SCAN2 is enabled
   SCAN listener LISTENER_SCAN2 is running on node db-scan2
   SCAN Listener LISTENER_SCAN3 is enabled
   SCAN listener LISTENER_SCAN3 is running on node db-scan2
    
   [orcl@db-scan1 ~]$ srvctl config nodeapps -s 
   ONS exists: Local port 6100, remote port 6200, EM port 2016
    
   [orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS
   ONS is enabled
   ONS daemon is running on node: db-scan1
   ONS daemon is running on node: db-scan2
   

Run the ONS test from every WebLogic server that uses the data source.

9.6 Configuring Network Channels for HTTP and T3 Clients Through EoIB

If HTTP/RMI clients must access the SOA servers directly, for example, deployment of a composite from JDEV, Direct-Binding client directly invoking Direct-Binding service. For more information, see Chapter 3, "Configuring the Network for an Exalogic Enterprise Deployment."

9.6.1 Configuring Network Channels for SOA Servers on SOAHOST1 and SOAHOST2

For Managed Servers, you must create the following network channels using Ethernet over InfiniBand (EoIB):

• Section 9.6.1.1, "Creating an HTTP Client Channel"

• Section 9.6.1.2, "Creating the T3 Client Channel"

9.6.1.1 Creating an HTTP Client Channel

To create a HTTP network channel for a Managed Server such as WLS1, complete the following steps:

1. Go to the following URL:

   http://ADMINVHN1:7001/console
   

2. Log in as the administrator.

3. Click Lock & Edit in the Change Center if you have not already done so.

4. In the left pane of the Administration Console, expand Environment and then Servers to open the Summary of Servers page.

5. In the Servers table, click WLS_SOA1 to open the WLS_SOA1 page.

6. Select Protocols and then Channels. Click New.

7. Enter SOA_HTTPChannel as the name of the new network channel and select http as the protocol. Click Next.

8. Enter the following information in the Network Channel Addressing page:

   Table 9-5 Network Channel Addressing Page

   Field	Value	Notes
   Listen address	SOAHOST1VHN1	This address is the virtual hostname assigned to the WLS_SOA1 Server using the BOND1 interface.
   Listen port	8001
   External Listen Address	soa.mycompany.com	This is the DNS name to access application on the server.
   External Listen Port	443

   
   

9. Click Next and select the following in the Network Channel Properties page:

   • Enabled

   • HTTP Enabled for This Protocol

10. Click Finish.

11. Click Activate Changes in the Change Center of the Administration Console to activate these changes.

You must repeat the preceding steps to create a network channel for the WLS_SOA2 Managed Servers on SOAHOST2 and enter the required properties in Table 9-6 describes.

Table 9-6 Network Channels Properties

Managed Server	Name	Protocol	Listen Address	Listen Port	External Listen Address	External Listen PortFoot 1
WLS_SOA1	SOA_HTTPChannel	HTTP	SOAHOST1VHN1	8001	soa.mycompany.com	443
WLS_SOA2	SOA_HTTPChannel	HTTP	SOAHOST2VHN1	8001	soa.mycompany.com	443

^Footnote 1 In the Configuration tab and General subtab, this port is referred to as the External Listen Port. In the Protocols tab and Channels subtab, this port is listed in the Network Channels table as the Public Port.

Note:

After these channels are created, the server is accessible from a browser outside the Exalogic rack using the appropriate EoIB addresses (SOAHOST1VHN1:8001/soa-infra and SOAHOST2VHN1:8001/soa-infra).

9.6.1.2 Creating the T3 Client Channel

To create the T3network channel for the SOA Managed Servers, complete the following steps:

1. Go to the following URL:

   http://ADMINVHN1:7001/console
   

2. Log in as the administrator.

3. Click Lock & Edit in the Change Center if you have not already done so.

4. In the left pane of the Administration Console, expand Environment and then Servers to open the Summary of Servers page.

5. In the Servers table, click WLS_SOA1 to open the WLS_SOA1 page.

6. Select Protocols and then Channels. Click New.

7. Enter SOA_T3_Channel as the name of the new network channel and select t3 as the protocol. Click Next.

8. Enter the following information in the Network Channel Addressing page:

   Table 9-7 Network Channel Addressing Page

   Field	Value	Notes
   Listen address	SOAHOST1VHN1	This address is the virtual hostname assigned to the WLS_SOA1 Server using the BOND1 interface.
   Listen port	8003	Remove the default external listen port value.

   
   

9. Click Next and select the following in the Network Channel Properties page:

   • Enabled

   • HTTP Enabled for This Protocol

10. Click Finish.

11. Click Activate Changes in the Change Center of the Administration Console to activate these changes.

Note:

You must repeat the preceding steps to create a network channel for the WLS_SOA2 Managed Servers on SOAHOST2 and enter the required properties that Table 9-8 describes.

Table 9-8 Network Channels Properties

Managed Server	Name	Protocol	Listen Address	Listen Port	External Listen Address	External Listen PortFoot 1
WLS_SOA1	SOA_T3_Channel	T3 Channel	SOAHOST1VHN1	8003	SOAHOST1VHN1	8003
WLS_SOA2	SOA_T3_Channel	T3 Channel	SOAHOST2VHN1	8003	SOAHOST2VHN1	8003

^Footnote 1 In the Configuration tab and General subtab, this port is referred to as the External Listen Port. In the Protocols tab and Channels subtab, this port is listed in the Network Channels table as the Public Port.

9.7 Configuring Oracle Traffic Director with the Extended Domain

After you create the appropriate channels, you must configure Oracle Traffic Director to route to the SOA servers for the appropriate URLs.

Note:

You created a virtual server for soa.mycompany.com and soainternal.mycompany.com in Chapter 7, "Installing and Configuring Oracle Traffic Director for an Exalogic Enterprise Deployment.".

This section includes the following topics:

• Section 9.7.1, "Configuring Access Through Oracle Traffic Director for the WLS_SOAn Managed Servers"

• Section 9.7.2, "Validating Access Through Oracle Traffic Director"

• Section 9.7.3, "Setting Server and HTTP URLs for SOA Servers"

9.7.1 Configuring Access Through Oracle Traffic Director for the WLS_SOAn Managed Servers

To create the required virtual server routes:

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

   https://OTDADMINVHN.mycompany.com:8989
   

2. Click Configurations at the upper left corner of the page to view a list of available configurations.

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

4. In the Navigation pane, expand Virtual Servers and the SOAEXA virtual server. Select Routes to open a list of routes that are defined for the virtual server.

Continue to Section 9.7.1.1, "Creating a New Route"

9.7.1.1 Creating a New Route

To enable Oracle HTTP Server to route to the SOA_Cluster:

1. Click New Route to open the New Route dialog box.

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

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

4. In the Step2: Condition Information screen, select the variable $uri from the Variable/Function drop-down list. Select = ~ in the Operator drop-down menu, then enter /soa-infra in the Value field.

   Note:

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

5. Select OK then select Plus to add the next expression.

   Note:

   You can now select the joiner or.

6. Select uri as the Variable /Function, = ~ as the Operator, and inspection.wsil as the Value. Select OK.

7. Add the rest of the conditions using the information in the preceding step.

   Table 9-9 Routes and Conditions

   Route	Origin: Server Pool	Conditions
   soa-route	origin-server-pool-1	'/soa-infra' or $uri =~ '/inspection.wsil' or $uri =~ '/integration' or $uri =~ '/b2bconsole' or $uri =~ '/b2b/services/ws' or $uri =~ '/sdpmessaging/userprefs-ui' or $uri =~ '/DefaultToDoTaskFlow' or$uri =~ '/workflow' or$uri =~ '/ADFAttachmentHelper' or $uri =~ '/soa/composer' or $uri =~ '/frevvo' '

   
   

8. Click Next and then Create Route.

   Your route appears on the Routes and the Deployment Pending message appears in the main pane.

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

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

9.7.2 Validating Access Through Oracle Traffic Director

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

Verify that you can access these URLs, where 'webhostN' specifies the name of each Oracle Traffic Director host. Check these URLS for both WEBHOST1 and WEBHOST2):

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

• http://webhostN-priv-v1:7777/integration/worklistapp

• http://webhostN-priv-v1:7777/b2bconsole

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

• http://webhostN-priv-v1:7777/soa/composer

Validate SOA_Cluster through both Oracle Traffic Director instances.

For information on configuring system access through the load balancer, see Section 3.7, "Configuring the Load Balancer."

Note:

The webhostn-priv-v1 addresses are internal to the Exalogic rack; you must start a browser from a node within the rack itself.

In addition, verify that you can access SOA using the external/EoIB addresses exposed by the OTD servers. Use the URLs, where webhostN specifies the name of each Oracle Traffic Director hosts. Check the following URLs for both WEBHOST1 and WEBHOST2):

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

• http://WEBHOSTnVHN1:7777/integration/worklistapp

• http://WEBHOSTnVHN1:7777/b2bconsole

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

• http://WEBHOSTnVHN1:7777/soa/composer

9.7.3 Setting Server and HTTP URLs for SOA Servers

To make the system use the infiniband and web services local optimization, you must use the correct Server URL and Oracle Traffic Director URL properties in the SOA Infrastructure. To do this you must set both the SERVER and HTTP Server URLs to point to Oracle Traffic Director's virtual server (infiniband address). This section describes the procedures to set both URLs.

To set the Server URL to point to Oracle Traffic Director's virtual server (infiniband address:)

1. Log in to Oracle Enterprise Manager Fusion Middleware Control with the username and password you specified in Section 8.5.1, "Creating boot.properties for the Administration Server on SOAHOST1."

2. On the navigation tree on the left, expand Farm_domain_name, SOA. Right click soa-infra (WSL_SOA1), SOA Administration, and then Common Properties.

3. In the Server URL field, enter the virtual hostname set up in Oracle Traffic Director as a load balancer entry point on IP over InfiniBand (IPoIB):

   http://webhost1-priv-v1:7777
   

4. Select Apply.

Note:

The changes are automatically propagated to the other managed server (WLS_SOA2) at the SOA cluster level, because these MBeans are shared for all managed servers on the cluster.

To set the HTTP Server URL property point to Oracle Traffic Director's virtual server (Infiniband address:)

1. Log into Fusion Middleware Control with the username and password you specified in Section 8.5.1, "Creating boot.properties for the Administration Server on SOAHOST1."

2. On the navigation tree on the left, expand Farm_domain_name, SOA. Right click on the soa-infra (Server_name) SOA Administration, then Common Properties.

3. Select the link More SOA Infra Advanced Configuration Properties... at the bottom of the page.

4. In the HTTPServerURL field, enter the same values that you entered for the Server URL field in the Server URL procedure.

5. Select Apply.

Callbacks now route through Infiniband using the Oracle Traffic Director instance instead of the external load balancer. Also, the SOA Service Engines use Web services local optimizations.

9.7.3.1 Webservice Local Optimization

For webservice local optimization, the basic requirement is to make sure that the two SOA composites are co-located on the same server/process. For that determination, SOA compares the server (on which the target service composite is deployed) host and port configuration with those specified in the reference service endpoint URI.

• For target service host value, here is the sequence of checks in order of precedence:

  • Checks the Server URL configuration property value on SOA Infrastructure Common Properties page.

  • If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort if SSL is enabled) configuration property values from the cluster MBeans.

  • If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort if SSL is enabled) configuration property values from the Oracle WebLogic Server MBeans.

  • If not specified, uses the DNS-resolved Inet address of localhost.

• For target service port value, here is the sequence of checks in order precedence:

  • Checks the port configured in HttpServerURL on SOA Infrastructure Common Properties page.

  • If not specified, checks the port configured in Server URL on SOA Infrastructure Common Properties page.

  • If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort if SSL is enabled) configuration property values from the cluster MBeans.

  • If not specified, checks the FrontendHost and FrontendHTTPPort (or FrontendHTTPSPort if SSL is enabled) configuration property values from the Oracle WebLogic Server MBean.

  • If not specified, SOA Suite assumes 80 for HTTP and 443 for HTTPS URLs.

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

To set the location for the default persistence stores:

1. Log on to the Oracle WebLogic Administration Console.

   http://ADMINVHN:7001/console
   

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

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

4. Click the WLS_SOA1 (represented as a hyperlink) in Name column of the table. The settings page appears and defaults to the Configuration tab.

5. Click the Configuration tab, and then the Services tab.

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

   ASERVER_HOME/tlogs
   

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

8. Click Save and Activate Changes.

9. Restart both SOA servers.

10. Verify that the following files are created in the following directory after WLS_SOA1 and WLS_SOA2 are restarted:

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

9.9 Configuring Coherence Caches for Dehydrations

This release of Oracle Fusion Middleware permits using Oracle Coherence Caches for optimized performance in BPEL object access. If you configure the BPEL engine with the CacheEnabled property, the engine runs many fewer reads against database. Because many reads require locks and version checks, eliminating them improves BPEL engine performance substantially. Configuring Oracle Coherence for dehydration requires the following steps:

• Section 9.9.1, "Enabling the CacheEnabled property"

• Section 9.9.2, "Setting Server Properties for In-Process Coherence Cache for Dehydration"

9.9.1 Enabling the CacheEnabled property

To enable the cache enabled property in SOA, follow theses steps:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control with the username and password you specified inSection 8.5.1, "Creating boot.properties for the Administration Server on SOAHOST1."

2. On the navigation tree on the left, expand Farm_domain_name, SOA, and then right click soa-infra (server_name) (either one of the servers).

3. Click SOA Administration, and then BPEL Properties.

4. Select More BPEL Configuration properties.

5. Enter CacheEnabled for the property QualityOfService property.

6. Select Apply.

9.9.2 Setting Server Properties for In-Process Coherence Cache for Dehydration

Set the required server properties for using in-process coherence cache for dehydration.

To enable the cache enabled property in SOA:

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

   http://ADMINVHN:7001/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 the Name column of the table.

   The settings page for the selected server appears.

5. Click Lock & Edit.

6. Click the Server Start tab.

7. In the Arguments field, add the following for WLS_SOA1 and WLS_SOA2

   -Dbpel.cache.localStorage=true 
    -Dbpel.cache.threadCount=20
    -Dbpel.cache.cubeInstance.sizeLimit=4g
    -Dbpel.cache.invokeMessage.sizeLimit=2g
    -Dbpel.cache.deliveryMessage.sizeLimit=2g
    -Dbpel.cache.deliverySubscription.sizeLimit=2g
   

8. Click Save and Activate Changes.

9.10 Updating SOA JVM settings

To optimize behavior with local storage caches and improve performance, update the SOA servers' start parameters to include the following flags:

-Djava.net.preferIPv4Stack=true 
-Xlargepages:exitOnFailure=true 
-Doracle.xdkjava.exalogic.optimization=true 
-Xms16g -Xmx16g 

To update the SOA servers' start parameters:

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

   http://ADMINVHN:7001/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 the Name column of the table.

   The settings page for the selected server appears.

5. Click Lock & Edit.

6. Click the Server Start tab.

7. Add the following in the Arguments field for WLS_SOA1 and WLS_SOA2:

   -Djava.net.preferIPv4Stack=true 
   -Xlargepages:exitOnFailure=true
   -Doracle.xdkjava.exalogic.optimization=true
   -Xms16g -Xmx16g 
   

   Note:

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

8. Click Save and Activate Changes.

9. Apply these changes in both servers (WLS_SOA1 and WLS:_SOA2).

9.11 Enabling Cluster-Level Session Replication Enhancements

You can enable session replication enhancements for the SOA servers if stateful applications, such as SOA's Composer, or B2B console are going to be used.

To enable session replication enhancements for the SOA_Cluster:

1. Shut down the servers in the SOA_Cluster.

2. To set replication ports for a managed server, such as WLS_SOA1:

   1. Under Domain Structure, click Environment and Servers. The Summary of Servers page appears.

   2. Click WLS_SOA1 on the list of servers. The Settings for WLS_SOA1 appears.

   3. Under the Configuration tab, click the Cluster tab.

   4. In the Replication Ports field, enter a range of ports for configuring multiple replication channels. For example, replication channels for managed servers in SOA_Cluster can listen on ports starting from 8006 to 8009. To specify this range of ports, enter 8006-8009.

   5. Repeat these steps for WLS_SOA2.

3. Create a custom network channel for each managed server in the cluster (for example, WLS_SOA1) as follows:

   1. Log on to the Oracle WebLogic Administration Console.

      http://ADMINVHN:7001/console
      

   2. If you have not already done so, click Lock & Edit in the Change Center.

   3. In the left pane of the console, expand Environment and select Servers.

      The Summary of Servers page appears.

   4. In the Servers table, click WLS_SOA1 managed server instance.

   5. Select Protocols, and then Channels, and click New.

   6. Enter the following information:

      Listen Address: SOAHOST1-PRIV-V1

      Note:

      This is the floating IP assigned to WLS_SOA1.

      Listen port: 8006

      Remove the default external listen port.

   7. Click Next, and in the Network Channel Properties page, select Enabled and Outbound Enabled, then click Finish.

   8. Under the Network Channels table, select ReplicationChannel, the network channel you created for the WLS_SOA1 managed server.

   9. Expand Advanced, and select Enable SDP Protocol and click Save.

   10. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

   You must repeat these steps to create a network channel each for the remaining managed servers in the SOA_Cluster cluster. Enter the required properties, as Table 9-10 describes.

   Table 9-10 Network Channel Properties

   Managed Server in SOA_Cluster	Name	Protocol	Listen Address	Listen Port	Additional Channel Ports
   WLS_SOA1	ReplicationChannel	t3	SOAHOST1-PRIV-V1	8006	8006 to 8009
   WLS_SOA2	ReplicationChannel	t3	SOAHOST2-PRIV-V1	8006	8006 to 8009

   
   

4. After creating the network channel for each of the managed servers in your cluster, click Environment and then Clusters.

   The Summary of Clusters page appears.

5. Click SOA_Cluster.

   The Settings for SOA_Cluster page appears.

6. Click the Replication tab.

7. In the Replication Channel field, ensure that ReplicationChannel is set as the name of the channel to be used for replication traffic.

8. In the Advanced section, select the Enable One Way RMI for Replication option., and click Save.

9. Activate the changes and restart the managed servers.

10. Add the system property -Djava.net.preferIPv4Stack=true to the start parameters for the WebLogic servers

    1. Log on to the Oracle WebLogic Administration Console.

       http://ADMINVHN:7001/console
       

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

    3. Click Servers to open the Summary of Servers page.

    4. Click the name of the server (WLS_SOA1 or WLS_SOA2, which are represented as hyperlinks) in the Name column of the table.

       The settings page for the selected server appears.

    5. Click Lock & Edit.

    6. Enter ReplicationChannel as the name of the new network channel and select t3 as the protocol, then click Next.

    7. Click the Server Start tab.

    8. Add the following for WLS_SOA1 and WLS_SOA2 into the Arguments field:

       -Djava.net.preferIPv4Stack=true
       

    9. Click Save and Activate Changes.

Note:

To verify that multiple listening ports were opened, you can either run the netstat -na command on the command line or check the managed server logs.

Note:

These changes require restarting the SOA servers to be effective.

9.12 Configuring Oracle Adapters

Configure Oracle File, FTP, and database adapters for the extended SOA domain.

This section includes the following topics:

• Section 9.12.1, "Enabling High Availability for Oracle File and FTP Adapters"

• Section 9.12.2, "Enabling High Availability for Oracle JMS Adapters"

• Section 9.12.3, "Scaling the Oracle Database Adapter"

9.12.1 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 private 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 the 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. For inbound operations, the database is used also to prevent duplication scenarios where multiple instances read the same input file.

Note:

The operations described in this section are necessary only if your application requires these adapters.

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.

9.12.1.1 Using the Database Mutex Locking Operation

Make an outbound Oracle File or FTP Adapter service highly available using database table as a coordinator.

Note:

The steps and configuration options for the FTP adapter are exactly the same as the options for the file adapter. The connection factory to be used for FTP HA configuration is eis/Ftp/HAFtpAdapter which appears under the Outbound Connection Pools for the FTPAdapter deployment.

Note:

If you use database as a coordinator, increase global transaction timeouts.

To make outbound Oracle File or FTP Adapters highly available, modify Oracle File Adapter deployment descriptor for the connection-instance corresponding to eis/HAFileAdapter from the Oracle WebLogic Server console:

1. Log on to the Oracle WebLogic Administration Console.

   http://ADMINVHN:7001/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 appears.

7. Click on Lock & Edit. The property value column becomes editable; you can click on any of the rows under Property Value and modify its value.

   Table 9-11 describes new parameters in connection factory for Oracle File and FTP Adapters:

   Table 9-11 Oracle File and FTP Adapters

   Parameter	Description
   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: ASERVER_HOME/fadapter The directory ASERVER_HOME/fadpter must already exist.
   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 in the following directory: ORACLE_HOME/rcu/integration/soainfra/sql/createschema_soainfra_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 are located in the directory: ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql 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 data source 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.
   workingDirectory	Use "default" for working directory.

   
   

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/config/dp/soaedg_domain/FileAdapterPlan.xml
   

10. Click OK. Then click Save, and Activate Changes.

11. Once the new deployment plan is saved and activated, activate the FileAdapter deployment. The deployment remains in Prepared state if not started. To activate the FileAdapter deployment plan:

    In the Administration Console, click Deployments in the left pane for Domain Structure.

    Select the FileAdapter under Summary of Deployments on the right pane and Select Start, and then Servicing All Requests.

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

    Note:

    Perform the same steps for updating the control dir for the FTPAdapter. Use the eis/Ftp/HAFtpAdapter connection factory instance for these modifications.

9.12.2 Enabling High Availability for Oracle JMS Adapters

When the Oracle JMS adapter communicates with multiple servers in a cluster, the adapter's connection factory property FactoryProperties must list available servers. If it does not list servers, the connection establishes to only one random server. If that particular server goes down, no further messages are processed.

To verify that the adapter's JCA connection factory:

1. Log on to the Oracle WebLogic Administration Console.

   http://ADMINVHN:7001/console
   

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

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

4. Click the Configuration tab.

5. Click the Outbound Connection Pools tab and expand oracle.tip.adapter.jms.IJmsConnectionFactory to see the configured connection factories.

6. Click the specific instance you are using (for example, eis/wls/Queue). The Outbound Connection Properties for the connection factory opens.

7. Click Lock & Edit.

8. In the FactoryProperties field (click on the corresponding cell under Property value), enter the following:

   java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
   java.naming.provider.url=t3://SOAHOST1-PRIV-1:8001,SOAHOST2-PRIV-V1:8001
   ;security.principal=weblogic;java.naming.security.credentials=mypassword
   

9. Change the java.naming.provider.url property to EoIB, (SOAHOST1VHN1:8001,SOAHOST2VHN1:8001) addresses if external consumers and/or producers are to access the SOA servers

10. Click Save after you update the properties. Enter a shared storage location for the deployment plan. The directory structure is as follows:

    ORACLE_BASE/config/dp/soaedg_domain/JMSPlan.xml
    

11. Click OK. Then click Save, and Activate Changes.

Update the deployment in the console:

1. Click Deployments and select the JMS Adapter.

2. Click Lock & Edit then Update.

3. Select Update this application in place with new deployment plan changes (A deployment plan must be specified for this option.) and select the deployment plan saved in a shared storage location; all servers in the cluster must be able to access the plan).

4. Click Finish.

5. Activate the changes.

9.12.3 Scaling the Oracle Database Adapter

Previously, the best practice for multiple Oracle Database Adapter process instances deployed to multiple Oracle BPEL Process Manager, or Oracle Mediator nodes was using LogicalDeletePollingStrategy or DeletePollingStrategy with a unique MarkReservedValue on each polling node, and setting MaxTransactionSize. If you used this approach, you can remove (in db.jca) or clear (Logical Delete Page of the Configuration Wizard) the MarkReservedValue to automatically get skip locking.

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

• Skip locking scales better in a cluster and under load.

• All work is in one transaction, minimizing the risk of a non-recoverable situation in a high availability environment.

• You do not need to specify a unique MarkReservedValue, which requires configuring a complex variable such as R${weblogic.Name-2}-${IP-2}-${instance}.

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

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

9.13 Updating the Workflow Front End Address for Appropriate Task Display

You must configure Oracle Workflow with the appropriate URL so that Default-to-do tasks and custom tasks' details use the front end load balancer to create task-display URLs.

To configure the appropriate URLs:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control with the username and password you specified in Section 8.5.1, "Creating boot.properties for the Administration Server on SOAHOST1."

2. In the left navigation tree, expand Farm_domain_name, SOA, and then right click soa-infra server_name (either one of the servers).

3. Click SOA Administration, and then Workflow Properties.

4. Select More Workflow Notification Configuration Properties...

5. On the Mbean tree on the left, expand Workflow Config and click humanworkflow.

6. In the FusionAppsFrontendHostUrl field, enter the following:

   *=https://soa.mycompany.com:443
   

7. Click Apply.

9.14 Updating the B2B Instance Identifier for Transports

To set up File, FTP, or Email transports in a high availability environment, specify a unique name for each instance by using b2b.HAInstanceName unique_instance_name. If you use ServerName for the value, Oracle B2B retrieves the WebLogic Server name as the HAInstanceName.

To specify a unique name:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control with the username and password specified in Section 8.5.1, "Creating boot.properties for the Administration Server on SOAHOST1."

2. On the navigation tree on the left, expand Farm_<domain_name>, SOA, and then right click on the soa-infra<server_name>, and select the SOA Administration, and then B2B Server Properties.

3. Click on More B2B Configuration Properties... on the right.

4. Click the b2b MBean.

5. Click the Operations tab.

6. Click addProperty in the list on the right.

7. In the Key field enter b2b.HAInstanceName.

8. In the value field enter #ServerName#.

   Enter this value in only one of the two servers.

9. Click Invoke.

9.15 Backing Up the Oracle SOA Configuration

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