9 Extending the Domain to Include Oracle SOA Suite Components

This chapter describes how to use the Oracle Fusion Middleware Configuration Wizard to extend the domain created in Chapter 8, "Creating a Domain for an Enterprise Deployment," to include Oracle SOA Suite components and Oracle WSM Policy Manager. You can extend the resulting domain to add other Fusion Middleware components, as described in the next chapters. It is assumed that a SOA Oracle home (binaries) has already been installed and is available from SOAHOST1 and SOAHOST2 and that a domain with an Administration Server has been created. This is the domain that will be extended in this chapter to support Oracle SOA Suite components.

Note:

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

This chapter contains the following sections:

Section 9.1, "Overview of Extending the Domain to Include Oracle SOA Suite Components"
Section 9.2, "Enabling SOAHOST1VHN1 on SOAHOST1 and SOAHOST2VHN1 on SOAHOST2"
Section 9.3, "Extending the Domain for Oracle SOA Suite Components"
Section 9.4, "Configuring Oracle Coherence for Deploying Composites"
Section 9.5, "Completing Post-Configuration and Verification Tasks"
Section 9.6, "Configuring the Java Object Cache for Oracle Web Services Manager"
Section 9.7, "Configuring Oracle HTTP Server with the Extended Domain"
Section 9.8, "Configuring a Default Persistence Store for Transaction Recovery"
Section 9.9, "Configuring Oracle Adapters"
Section 9.10, "Configuring Node Manager for the WLS_SOA Managed Servers"
Section 9.11, "Configuring Server Migration for the WLS_SOA Managed Servers"
Section 9.12, "Backing Up the Installation"

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

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

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

Step	Description	More Information
Prepare for extending the domain for Oracle SOA Suite components	Enable a VIP mapping for each of the host names, and synchronize the system clocks for the Oracle SOA Suite WebLogic Server cluster	Section 9.2, "Enabling SOAHOST1VHN1 on SOAHOST1 and SOAHOST2VHN1 on SOAHOST2"
Extend the domain for Oracle SOA Suite components	Extend the WebLogic Server domain you created in Chapter 8, "Creating a Domain for an Enterprise Deployment."	Section 9.3, "Extending the Domain for Oracle SOA Suite Components"
Configure Oracle Coherence for deploying composites	Configure Oracle Coherence to use unicast communication for deploying composites.	Section 9.4, "Configuring Oracle Coherence for Deploying Composites"
Complete post-configuration and verification tasks	Follow these instructions for disabling host name verification, restarting Node Manager, propagating the domain configuration, starting and validating the Managed Servers, and validating GridLink data sources.	Section 9.5, "Completing Post-Configuration and Verification Tasks"
Configure the Java Object Cache (JOC) among all the servers running Oracle Web Services Manager (Oracle WSM)	Configure a local cache to increase the performance of Oracle WSM.	Section 9.6, "Configuring the Java Object Cache for Oracle Web Services Manager"
Configure Oracle HTTP Server with the extended domain	Configure the Oracle HTTP Server with the Managed Servers, validate access, set the front-end HTTP host and port, and set the WebLogic Server cluster address for SOA_Cluster.	Section 9.7, "Configuring Oracle HTTP Server 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 Adapters	Enable high availability for Oracle File and FTP Adapters and configure the Oracle Database Adapter.	Section 9.9, "Configuring Oracle Adapters"
Configure host name verification for the communication between Node Manager and the Managed Servers in the domain	Use certificates for the different addresses communicating with the Administration Server and other servers.	Section 9.10, "Configuring Node Manager for the WLS_SOA Managed Servers"
Configure server migration for the Oracle SOA Suite Managed Servers.	Specify the Oracle SOA Suite Managed Server names, host names, and cluster name for migration.	Section 9.11, "Configuring Server Migration for the WLS_SOA Managed Servers"
Back up the Oracle SOA Suite configuration	Back up the newly extended domain configuration.	Section 9.12, "Backing Up the Installation"

9.2 Enabling SOAHOST1VHN1 on SOAHOST1 and SOAHOST2VHN1 on SOAHOST2

The Oracle WebCenter Content domain uses virtual host names as the listen addresses for the Oracle SOA Suite Managed Servers. If you have not previously done so, you must enable a virtual IP mapping for each of these host names on the two SOAHOST machines, (VIP2 on SOAHOST1 and VIP3 on SOAHOST2), and correctly resolve the virtual host names in the network system used by the topology (either by DNS Server or /etc/hosts resolution).

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

9.3 Extending the Domain for Oracle SOA Suite Components

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

Note:

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

To extend the domain for Oracle SOA Suite components:

Ensure that the database where you installed the repository is running.

For Oracle RAC databases, Oracle recommends that all instances are running, so that the validation check later on becomes more reliable.
Shut down all Managed Servers in the domain.
On SOAHOST1, change the directory to the location of the Oracle Fusion Middleware Configuration Wizard. This is within the Oracle Common home directory (domain extensions are run from the node where the Administration Server resides).
```
cd ORACLE_COMMON_HOME/common/bin
```
Start the Configuration Wizard:
```
./config.sh
```
In the Welcome screen, select Extend an Existing WebLogic Domain, and click Next.
In the Select a WebLogic Domain Directory screen, select the WebLogic Server domain directory (ORACLE_BASE/admin/domain_name/aserver/domain_name), and click Next.
In the Select Extension Source screen, which Figure 9-1 shows, do the following:
1. Select Extend my domain automatically to support the following added products.
2. Select these products:
  
  Oracle SOA Suite - 11.1.1.0 [soa]
  
  Oracle WSM Policy Manager - 11.1.1.0 [oracle_common] (automatically selected with Oracle SOA Suite)
  
  The following products should already be selected and grayed out. They were selected when you created the domain (Section 8.3).
  
  Basic WebLogic Server Domain - 10.3.6.0 [wlserver_10.3]
  
  Oracle Enterprise Manager - 11.1.1.0 [oracle_common]
  
  Oracle JRF - 11.1.1.0 [oracle_common]
  
  Figure 9-1 Select Extension Source Screen for Oracle SOA Suite
  
  Description of "Figure 9-1 Select Extension Source Screen for Oracle SOA Suite"
3. Click Next.
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.
In the Configure JDBC Component Schema screen, which Figure 9-2 shows, do the following:
1. Select the rows SOA Infrastructure, User Messaging Service, OWSM MDS Schema, and SOA MDS Schema.
2. For the RAC configuration, you can select Convert to GridLink or Convert to RAC multi data source (described in Appendix A, "Using Multi Data Sources with Oracle RAC"). For the instructions given here, select Convert to GridLink.
  
  After you select a RAC configuration, all selected schemas are grayed.
  
  Figure 9-2 Configure JDBC Component Schema Screen for Oracle SOA Suite
  
  Description of "Figure 9-2 Configure JDBC Component Schema Screen for Oracle SOA Suite"
3. Click Next.
In the Configure GridLink RAC Component Schema screen, which Figure 9-3 shows, do the following:
1. Select only the SOA Infrastructure row.
  
  Figure 9-3 Configure GridLink RAC Component Schema Screen for Oracle SOA Suite
  
  Description of "Figure 9-3 Configure GridLink RAC Component Schema Screen for Oracle SOA Suite"
2. Enter values for the following fields, specifying the connection information for the GridLink RAC database that was seeded through RCU:
  - Driver: Select Oracle driver (Thin) for GridLinkConnections; Versions:10 and later.
  - Service Name: Enter the service name of the Oracle RAC database in lowercase letters, followed by the domain name; for example, wccedg.mycompany.com.
  - Username: Enter the complete user name for the database schema owner of the corresponding component.
    
    This book uses DEV as the prefix of user names for the database schemas.
  - Password: Enter the password for the database schema owner.
  - Select Enable FAN.
  - Enable SSL: Leave this option deselected.
    
    If you select SSL to enable Oracle Notification Service (ONS) notification encryption, provide the appropriate Wallet File and Wallet Password details.
  - Service listener: Enter the Oracle Single Client Access Name (SCAN) address and port for the Oracle RAC database being used. The protocol should be TCP.
    
    Oracle recommends that you use a SCAN address to specify the Service Listener (and OSN Host) so you do not need to update a GridLink data source containing a SCAN address if you add or remove Oracle RAC nodes. To determine the SCAN address, query the remote_listener parameter in the database:
```
SQL>show parameter remote_listener;
 
NAME              TYPE        VALUE
-----             ------      -------
remote_listener   string      db-scan.mycompany.com:1521
```
    Note:
    
    For Oracle Database 11g 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. For information about configuring multi data sources, see Appendix A, "Using Multi Data Sources with Oracle RAC."
  - ONS Host: Enter here also the SCAN address for the RAC database and the ONS remote port, as reported by the database:
```
[orcl@CUSTDBHOST2 ~]$ srvctl config nodeapps -s
ONS exists: Local port 6100, remote port 6200, EM port 2016
```
    Note:
    
    For Oracle Database 11g Release 1 (11.1), use the host name and port of each database's ONS service; for example:
```
custdbhost1.mycompany.com (port 6200)
```
    and
```
custdbhost2.mycompany.com (6200)
```
3. Select each data source, one at a time, and enter appropriate values for the user names and passwords.
4. Ensure that all values are correct for all schemas (SOA Infrastructure, User Messaging Service, OWSM MDS Schema, and SOA MDS Schema), and then click Next.
  
  Note:
  
  Oracle recommends using the database used for Oracle Identity Management (see Chapter 15, "Integrating with Oracle Identity Management") to store the Oracle WSM policies. It is therefore expected that you will use the Oracle Identity Management database information that has been seeded through RCU (as recommended in Chapter 3, "Preparing the Network for an Enterprise Deployment") to store the WSM metadata and that this Oracle Identity Management database information will be used in this screen for the OWSM MDS schemas. (This database connection information will be different from the one used for the rest of the Oracle SOA Suite schemas.)
In the Test JDBC Component Schema screen, (Figure 9-4), select each schema, and then click Test Connections.

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

Figure 9-4 Test JDBC Component Schema Screen

Description of "Figure 9-4 Test JDBC Component Schema Screen"

Click Next when all the connections are successful.
In the Select Optional Configuration screen, select the following options:
- JMS Distributed Destination
- Managed Servers, Clusters and Machines
- Deployments and Services
- JMS File Store
Click Next.
In the Select JMS Distributed Destination Type screen, do the following:
- Select UDD from the drop-down list for UMSJMSystemResource.
- Select UDD from the drop-down list for SOAJMSModule.
- Select UDD from the drop-down list for BPMJMSModule.
If an override warning appears, click OK to acknowledge it.
In the Configure Managed Servers screen, add the required Managed Servers.

A server called soa_server1 is created automatically. Rename this to WLS_SOA1 and add a new server called WLS_SOA2. Give these servers the attributes listed in Table 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

SOAHOST1VHN1

8001

n/a

No

WLS_SOA2

SOAHOST2VHN1

8001

n/a

No

Click Next.
In the Configure Clusters screen, add the clusters as listed in Table 9-3.

Table 9-3 Clusters

Name Cluster Messaging Mode Multicast Address Multicast Port Cluster Address

SOA_Cluster

unicast

n/a

n/a

SOAHOST1VHN1:8001,SOAHOST2VHN1:8001

Click Next.

Note:

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

If soa-infra config properties are not specified, but the WebLogic Server cluster address is specified, the cluster address from the JNDI provider URL is used. This cluster address can be either a single DNS name that maps to the IP addresses of the clustered servers or a comma-separated list of server ip:port. Alternatively, the soa-infra config property JndiProviderURL/SecureJndiProviderURL can be used for the same purpose if explicitly set by users.
In the Assign Servers to Clusters screen, assign servers to clusters as follows:
- SOA_Cluster:
  - WLS_SOA1
  - WLS_SOA2
Click Next.
In the Configure Machines screen, delete the LocalMachine that appears by default and open the Unix Machine tab. You should add the SOAHOST1 and SOAHOST2 machines and eventually have the following entries:

Table 9-4 Machines

Name Node Manager Listen Address

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINVHN

localhost

Do not modify the other assignments that are shown in this screen; leave them as they are. Please note that the machine names do not need to be valid host names or listen addresses; they are just unique identifiers of Node Manager locations.

Click Next.
In the Assign Servers to Machines screen, assign servers to machines as follows:
- ADMINVHN:
  - AdminServer
- SOAHOST1:
  - WLS_SOA1
- SOAHOST2:
  - WLS_SOA2
Click Next.
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.)
- WSM-PM should be targeted only to SOA_Cluster.
- The oracle.rules#*, oracle.sdp.*, and oracle.soa.* deployments should be targeted only to SOA_Cluster.
Click Next.
In the Target Services to Clusters or Servers screen, click Next.
In the Configure JMS File Stores screen, enter the shared directory location specified for your JMS stores, as recommended in Section 4.3, "About Recommended Locations for the Different Directories." For example:
```
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
```
Click Next.
In the Configuration Summary screen, click Extend.

The domain is extended to include the Oracle SOA Suite components.
In the Extending Domain screen, click Done.
Restart the Administration Server for these changes to take effect.

To restart the Administration Server, stop it first using the Administration Console and then start it again as described in Section 8.4.3, "Starting the Administration Server on SOAHOST1."

Name	Listen Address	Listen Port	SSL Listen Port	SSL Enabled
WLS_SOA1	SOAHOST1VHN1	8001	n/a	No
WLS_SOA2	SOAHOST2VHN1	8001	n/a	No

Name	Cluster Messaging Mode	Multicast Address	Multicast Port	Cluster Address
SOA_Cluster	unicast	n/a	n/a	SOAHOST1VHN1:8001,SOAHOST2VHN1:8001

Name	Node Manager Listen Address
SOAHOST1	SOAHOST1
SOAHOST2	SOAHOST2
ADMINVHN	localhost

9.4 Configuring Oracle Coherence for Deploying Composites

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

Unicast communication does not enable nodes to discover other cluster members in this way. Consequently, you must specify the nodes that belong to the cluster. You do not need to specify all of the nodes of a cluster, however. You need only specify enough nodes so that a new node added to the cluster can discover one of the existing nodes. As a result, when a new node has joined the cluster, it is able to discover all of the other nodes in the cluster. Additionally, in configurations such as Oracle SOA Suite enterprise deployments where multiple 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 Oracle SOA Suite system from starting. The deployment framework must be properly customized for the network environment on which the Oracle SOA Suite system runs. Oracle recommends the configuration described in this section.

9.4.1 Enabling Communication for Deployment Using Unicast Communication

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

Tip:

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

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

Note:

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

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

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

9.4.2 Specifying the Host Name Used by Oracle Coherence

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

To specify the host name used by Oracle Coherence:

Log in to the WebLogic Server Administration Console.
In the Domain Structure tree on the left, expand the Environment node.
Click Servers.
On the Summary of Servers page, click the name of the server (WLS_SOA1 or WLS_SOA2, which are represented as hyperlinks) in the Name column of the table.
On the settings page for the selected server, click Lock & Edit.
On the Configuration tab, click the Server Start tab (illustrated in Figure 9-5).
Enter the following parameters for WLS_SOA1 and WLS_SOA2 in the Arguments field.

Note:

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

For WLS_SOA1, enter the following text (on a single line, without a carriage return):
```
-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1 
-Dtangosol.coherence.localhost=SOAHOST1VHN1
```
For WLS_SOA2, enter the following text (on a single line, without a carriage return):
```
-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1
```
Note:

The Coherence cluster used for deployment uses port 8088 by default. This port can be changed by specifying a different port (for example, 8089) using the -Dtangosol.coherence.wkan.port and -Dtangosol.coherence.localport startup parameters; for example:
- WLS_SOA1 (enter the following text into the Arguments field on a single line, without a carriage return):
```
-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
```
- WLS_SOA2 (enter the following text into the Arguments field on a single line, without a carriage return):
```
-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
```
For more information about Coherence clusters, see the Oracle Coherence Developer's Guide.
Click Save and Activate Changes.

Notes:

You must ensure that these variables are passed to the Managed Server correctly. (They should be reflected in the server's output log.) Failure of the Oracle Coherence framework can prevent the soa-infra application from starting.
The multicast and unicast addresses are different from the ones used by the WebLogic Server cluster for cluster communication. Oracle SOA Suite guarantees that composites are deployed to members of a single WebLogic Server cluster even though the communication protocol for the two entities (the WebLogic Server cluster and the groups to which composites are deployed) are different.

9.5 Completing 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, "Propagating the Domain Changes to the Managed Server Domain Directory"
Section 9.5.3, "Starting and Validating the WLS_SOA1 Managed Server"
Section 9.5.4, "Propagating the Domain Configuration to SOAHOST2"
Section 9.5.5, "Starting and Validating the WLS_SOA2 Managed Server"
Section 9.5.6, "Validating GridLink Data Sources for Oracle SOA Suite"

9.5.1 Disabling Host Name Verification for the WLS_SOAn Managed Servers

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

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

9.5.2 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 the start scripts and classpath configuration:

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

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=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateSOA.jar -template_name=soa_domain_templateExtSOA

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=ORACLE_BASE/admin/domain_name/mserver/domain_name -overwrite_domain=true -template=edgdomaintemplateSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
```
Note:

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

9.5.3 Starting and Validating the WLS_SOA1 Managed Server

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

To start the WLS_SOA1 Managed Server on SOAHOST1:

Start the WLS_SOA1 Managed Server using the WebLogic Server Administration Console, as follows:
1. Access the Administration Console at 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 tree on the left.
3. Click Servers.
4. On the Summary of Servers page, open the Control tab.
5. Select WLS_SOA1 and then click Start.
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 16.12, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology" for possible causes.
Access the following URLs:
- Access http://SOAHOST1VHN1:8001/soa-infra to verify the status of WLS_SOA1.
- Access http://SOAHOST1VHN1:8001/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data store opens.The configuration is incorrect if no policies or assertion templates appear.
- Access http://SOAHOST1VHN1:8001/integration/worklistapp to verify the status of the worklist application.

9.5.4 Propagating the Domain Configuration to SOAHOST2

After completing the configuration of SOAHOST1, propagate the configuration to SOAHOST2 using the unpack utility, and then validate the propagated configuration.

To propagate the domain configuration:

Run the following commands on SOAHOST1 to copy the template file created in the previous step to SOAHOST2:

cd ORACLE_BASE/product/fmw/oracle_common/common/bin

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

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

Note:

Run unpack from the ORACLE_COMMON_HOME/common/bin/ directory, not from WL_HOME/common/bin/.

cd ORACLE_COMMON_HOME/common/bin

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

Note:

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

9.5.5 Starting and Validating the WLS_SOA2 Managed Server

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

Note:

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

If Node Manager is not running, restart it on SOAHOST2, as described in Section 8.4.2, "Starting Node Manager on SOAHOST1."

To start and validate the WLS_SOA2 Managed Server:

Start the WLS_SOA2 Managed Server using the WebLogic Server Administration Console, as follows:
1. Expand the Environment node in the Domain Structure tree on the left.
2. Click Servers.
3. On the Summary of Servers page, open the Control tab.
4. Select WLS_SOA2 and then click Start.
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 16.12, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology" for possible causes.
Access the following URLs:
- Access http://SOAHOST2VHN1:8001/soa-infra to verify the status of WLS_SOA2.
- Access http://SOAHOST2VHN1:8001/wsm-pm to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data store opens.
  
  Note:
  
  The configuration is incorrect if no policies or assertion templates appear.
- Access http://SOAHOST2VHN1:8001/integration/worklistapp to verify the status of the worklist application.

9.5.6 Validating GridLink Data Sources for Oracle SOA Suite

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

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

Log in to the WebLogic Server Administration Console.
In the Domain Structure tree, expand Services, then click Data Sources.
Click the name of a GridLink data source that was created.
Click the Monitoring tab.
Click the Testing tab (Figure 9-6), select one of the servers, and click Test Data Source.

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

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

The test should be successful if the configuration is correct.
Repeat the test for every WebLogic Server instance that uses the GridLink data source.

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

Log in to the WebLogic Server Administration Console.
In the Domain Structure tree, expand Services, then click Data Sources.
Click the name of a GridLink data source that was created.
Click the Monitoring tab.
Click the ONS tab and then the Testing tab (Figure 9-7).

Select a server, and click Test ONS.

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

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

The test should be successful if the configuration is correct. If the ONS test fails, verify that the ONS service is running in the Oracle RAC database nodes:

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

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

9.6 Configuring the Java Object Cache for Oracle Web Services Manager

The Java Object Cache (JOC) should be configured among all the servers running Oracle Web Services Manager (Oracle WSM). This local cache is provided to increase the performance of Oracle WSM. The Java Object Cache can be configured using the MW_HOME/oracle_common/bin/configure-joc.py script. This is a Python script, which can be used to configure JOC in the Managed Servers. The script runs in WLST online mode and expects the Administration Server to be up and running.

For the configuration of JOC ports for Oracle products, Oracle recommends using ports in the 9988 to 9998 range.

Note:

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

To configure the Java Object Cache for Oracle WSM:

Connect to the Administration Server using the command-line Oracle WebLogic Scripting Tool (WLST); for example:
```
MW_HOME/oracle_common/common/bin/wlst.sh
$ connect()
```
Enter the WebLogic Server Administrator user name, password, and server URL (t3://ADMINVHN:7001) when prompted.
After connecting to the Administration Server using WLST, start the script using the execfile command, for example:
```
wls:/domain_name/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")
```

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

Execfile("MW_HOME/oracle_common/bin/configure-joc.py").
Enter Hostnames (eg host1,host2) : SOAHOST1VHN1,SOAHOST2VHN1
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : SOA_Cluster
.
Enter Discover Port : 9991
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n

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

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

Script Input Parameters

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

Configure JOC for all specified Managed Servers for a given cluster. Enter y when the script prompts whether you want to specify a cluster name, and also specify the cluster name and discover port, when prompted. This discovers all the Managed Servers for the given cluster and configures the JOC. The discover port is common for the entire JOC configuration across the cluster. For example:
```
Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : SOA_Cluster
Enter Discover Port : 9991
```
Configure JOC for all specified Managed Servers. Enter n when the script prompts whether you want to specify a cluster name, and also specify the Managed Server and discover port, when prompted. For example:
```
Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (eg WLS_SOA1:9991, WLS_SOA21:9991) : WLS_SOA1:9999,WLS_SOA2:9999
```
This example configures JOC only for the specified Managed Servers (that is, WLS_SOA1 and WLS_SOA2). The discover port is specified with the Managed Server (for example, WLS_SOA1:2222).
Exclude JOC configuration for some Managed Servers. The script allows you to specify the list of Managed Servers for which the JOC configuration DistributeMode will be set to false. Enter y when the script prompts whether you want to exclude any servers from JOC configuration, and enter the Managed Server names to be excluded, when prompted. For example:
```
Do you want to exclude any server(s) from JOC configuration (y/n) <n>y
Exclude Managed Server List (eg Server1,Server2) : WLS_SOA1,WLS_SOA2
```
Disable the distribution mode for all Managed Servers. The script allows you to disable the distribution to all the Managed Servers for a specified cluster. Specify false when the script prompts for the distribution mode. By default, the distribution mode is set to true.

9.7 Configuring Oracle HTTP Server with the Extended Domain

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

This section includes the following topics:

Section 9.7.1, "Configuring Oracle HTTP Server for the WLS_SOA Managed Servers"
Section 9.7.2, "Setting the Front-End HTTP Host and Port"
Section 9.7.3, "Validating Access Through the Load Balancer"

9.7.1 Configuring Oracle HTTP Server for the WLS_SOA Managed Servers

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

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

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

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

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

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

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

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

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

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

Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2:
```
ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohsX
```
For WEBHOST1, use ohs1 for ias-component and for WEBHOST2 use ohs2.

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

Sample scenarios:

Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member will be discovered on the fly at run time.
Example 2: You have a three-node cluster but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.

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

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

9.7.2 Setting the Front-End HTTP Host and Port

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

Log in to the WebLogic Server Administration Console.
Go to the Change Center section and click Lock & Edit.
Expand the Environment node in the Domain Structure tree on the left.
Click Clusters.
On the Summary of Servers page, select SOA_Cluster.
Open the HTTP tab.
Set the following values:
- Frontend Host: soainternal.mycompany.com
- Frontend HTTP Port: 80
Click Save.
Click Activate Changes in the Change Center section of the Administration Console.
Restart the WLS_SOA1 and WLS_SOA2 Managed Servers to make the front-end host directive in the cluster take effect.

9.7.3 Validating Access Through the Load Balancer

Verify that the server status is reported as Running in the Administration Console. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported (such as Admin or Failed), check the server output log files for errors. For possible causes, see Section 16.12, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology."

Validate access to SOA_cluster using the following URLs:

http://soainternal.mycompany.com/soa-infra
http://soainternal.mycompany.com/integration/worklistapp
http://soainternal.mycompany.com/sdpmessaging/userprefs-ui
http://soainternal.mycompany.com/soa/composer
http://soainternal.mycompany.com/wsm-pm

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

Note:

After the registering Oracle HTTP Server as described in Section 8.5.3, "Registering Oracle HTTP Server with WebLogic Server," Oracle HTTP Server should appear as a manageable target in the Oracle Enterprise Manager console. To verify this, log in to the Oracle Enterprise Manager console. The WebTier item in the navigation tree should show that Oracle HTTP Server has been registered.

9.8 Configuring a Default Persistence Store for Transaction Recovery

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

Note:

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

To set the location for the default persistence stores:

Log in to the WebLogic Server Administration Console.
In the Change Center section of the page, click Lock & Edit.
In the Domain Structure tree on the left, expand the Environment node, and then click the Servers node.
On the Summary of Servers page, click the name of the server WLS_SOA1 (represented as a hyperlink) in the Name column of the table. The settings page for the selected server opens and defaults to the Configuration tab.
Click the Configuration tab and then the Services tab (not the top-level Services tab).
In the Default Store section of the page, enter the path to the folder where the default persistent store will store its data files. The directory structure of the path follows:
```
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs/
```
Repeat steps 4, 5, and 6 for the WLS_SOA2 server.
Click Save and Activate Changes.
Restart the WLS_SOA1 and WLS_SOA2 Managed Servers.
After WLS_SOA1 and WLS_SOA2 are restarted, verify that the following DAT files are created in this directory:
```
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs/
```
- _WLS_WLS_SOA1000000.DAT
- _WLS_WLS_SOA2000000.DAT

Note:

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

9.9 Configuring Oracle Adapters

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

This section includes the following topics:

Section 9.9.1, "Enabling High Availability for Oracle File and FTP Adapters"
Section 9.9.2, "Configuring the Oracle Database Adapter"

9.9.1 Enabling High Availability for Oracle File and FTP Adapters

Note:

This step is optional and applies only to those deployments that require adapter support for the BPEL processes that are invoked.

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

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 nontransactional, files can be processed twice. As a result, it is possible to get duplicate files when there is failover in the Oracle RAC back end or in the Oracle SOA Suite Managed Servers.

Using the Database Mutex Locking Operation

To make an outbound Oracle File or FTP Adapter service highly available using database table as a coordinator, you must modify the Oracle File Adapter deployment descriptor for the connection-instance corresponding to eis/HAFileAdapter in the WebLogic Server Administration Console.

Note:

You must increase global transaction timeouts if you use database as a coordinator.

To use the Database Mutex locking operation:

Log in to the WebLogic Server Administration Console. To access the console, navigate to http://server_name:port_number/console.
Click Deployments in the Domain Structure tree on the left.
Click FileAdapter under Summary of Deployments on the right pane.
Open the Configuration tab.
Open the Outbound Connection Pools tab, and expand javax.resource.cci.ConnectionFactory to see the configured connection factories.
Click eis/HAFileAdapter. The Outbound Connection Properties screen for the connection factory corresponding to high availability opens. The connection factory properties are displayed as shown in Figure 9-8.

Figure 9-8 WebLogic Server Administration Console - Settings for javax.resource.cci.ConnectionFactory Page

Description of "Figure 9-8 WebLogic Server Administration Console - Settings for javax.resource.cci.ConnectionFactory Page"
Click Lock & Edit. After this, the property value column becomes editable (you can select any of the rows under Property Value and modify its value).

To reflect the updated values, click on the corresponding row for the PropertyValue column, and then press the Enter key on your keyboard. If you do not press the Enter key, the values will not be saved.

The new parameters in the connection factory for Oracle File and FTP Adapters follow:
- 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.
Note:

The parameters available for FTP Adapters are slightly different than for the connection factory, but from a high-availability standpoint, just setting the control directory to a shared storage location is what matters.
Click Save after you update the properties.
On the Save Deployment Plan page, 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
```
Click Save and Activate.
Once the new deployment plan has been saved and activated, activate the FileAdapter deployment (the deployment remains in the Prepared state if not started). To activate the FileAdapter deployment plan:

In the Administration Console, click Deployments in the Domain Structure tree on the left.

Select the FileAdapter under Summary of Deployments on the right pane and Select Start, and then Servicing All Requests.
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>
```
Notes:
- The location attribute is set to eis/HAFileAdapter for the connection factory.
- The preceding steps are for configuring the File Adapter for high availability. To configure the FTP Adapter for high availability, perform the same steps for updating the control directory. Use the eis/Ftp/HAFtpAdapter connection factory instance for these modifications.

9.9.2 Configuring the Oracle Database Adapter

Note:

This step is optional and applies only to those deployments that require adapter support for the BPEL processes.

If you are using Logical Delete polling and you set MarkReservedValue, skip locking is not used. Formerly, the best practice for multiple Oracle Database Adapter process instances deployed to multiple Oracle BPEL Process Manager or Oracle Mediator nodes was essentially using LogicalDeletePollingStrategy or DeletePollingStrategy with a unique MarkReservedValue on each polling node, and setting MaxTransactionSize. However, with the introduction of skip locking in Oracle Fusion Middleware 11g Release 1 (11.1.2.0), that approach has now been superseded. If you were using this approach previously, you can simply remove (in db.jca) or clear (on the Logical Delete wizard page) the MarkReservedValue attribute, and you will 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 (as opposed to update/reserve, then commit, then select in a new transaction), so the risk of facing non-recoverable situations in high-availability environments is minimized.
No unique MarkReservedValue needs to be specified. Previously, for this to work, you had to configure a complex variable, such as R${weblogic.Name-2}-${IP-2}-${instance}.

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

9.10 Configuring Node Manager for the WLS_SOA Managed Servers

Oracle recommends using host name verification for the communication between Node Manager and the servers in the domain. This requires the use of certificates for the different addresses communicating with the Administration Server and other servers. See Chapter 13, "Setting Up Node Manager" for further details. The procedures in that chapter must be performed twice using the following information:

Run	Host Name (HOST)	Virtual IP (VIP)	Server Name (WLS_SERVER)
Run 1:	SOAHOST1	SOAHOST1VHN1	WLS_SOA1
Run 2:	SOAHOST2	SOAHOST2VHN1	WLS_SOA2

9.11 Configuring Server Migration for the WLS_SOA Managed Servers

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

Server names:
- WLS_SERVER1: WLS_SOA1
- WLS_SERVER2: WLS_SOA2
Host names:
- HOST1: SOAHOST1
- HOST2: SOAHOST2
Cluster name:
- CLUSTER: SOA_Cluster

9.12 Backing Up the Installation

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

To back up the installation at this point:

Back up the web tier on WEBHOST1:
1. Shut down the instance using opmnctl:
```
ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
```
2. Back up the Middleware home on the web tier using the following command (as root):
```
tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
```
3. Back up the Oracle instance on the web tier using the following command:
```
tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE
```
4. Start the instance using opmnctl:
```
cd ORACLE_BASE/admin/instance_name/bin

opmnctl startall
```
Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or operating system tools such as tar for cold backups if possible.
Back up the Administration Server and Managed Server domain directories to save your domain configuration. The configuration files all exist in the ORACLE_BASE/admin/domain_name directory. Run the following command on SOAHOST1 to create the backup:
```
tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
```