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 Enterprise Deployment."

Note:

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

This chapter contains the following sections:

Section 9.1, "Overview of Extending the Domain for SOA Components"
Section 9.2, "Prerequisites 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 Oracle HTTP Server with the Extended Domain"
Section 9.7, "Configuring a Default Persistence Store for Transaction Recovery"
Section 9.8, "Configuring Oracle Adapters"
Section 9.9, "Updating the B2B Instance Identifier for Transports"
Section 9.10, "Backing Up the 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	Enable a virtual IP mapping for each of the hostnames, and synchronize the system clocks for the SOA WebLogic cluster	Section 9.2, "Prerequisites for Extending the Domain for Oracle SOA Components"
Extend the Domain for SOA Components	Extend the WebLogic domain you created in Chapter 8, "Creating a Domain for an Enterprise Deployment.".	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.	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 the Oracle HTTP Server with the extended domain	Configure the Oracle HTTP Server with the managed servers, validate access, set the frontend HTTP host and port, and set the WLS Cluster address for the SOA_Cluster.	Section 9.6, "Configuring Oracle HTTP Server with the Extended Domain"
Configure a Default Persistence Store	Configure a default persistence store for transaction recovery.	Section 9.7, "Configuring a Default Persistence Store for Transaction Recovery"
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.8, "Configuring Oracle Adapters"
Update the B2B Instance Identifier for Transports	Set up File, FTP, or Email transports in a high availability environment.	Section 9.9, "Updating the B2B Instance Identifier for Transports"
Back Up the SOA Configuration	Back up the newly extended domain configuration.	Section 9.10, "Backing Up the SOA Configuration"

9.2 Prerequisites for Extending the Domain for Oracle SOA Components

Before you run the Configuration Wizard to extend the domain, enable a virtual IP mapping for each of the hostnames on the two SOA Machines, and synchronize the system clocks for the SOA WebLogic cluster.

This section includes the following topics:

Section 9.2.1, "Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2"
Section 9.2.2, "Synchronize System Clocks"

9.2.1 Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2

The SOA domain uses virtual hostnames as the listen addresses for the SOA managed servers. If you have not previously done so, you must enable a virtual IP mapping for each of these hostnames on the two SOA Machines, (VIP2 on SOAHOST1 and VIP3 on SOAHOST2), and correctly resolve the virtual hostnames in the network system used by the topology (either by DNS Server, hosts resolution).

To enable the virtual IPs, follow the steps described in Section 3.5, "Enabling Virtual IP Addresses for Administration Servers" if you have yet completed this procedure. These virtual IPs and VHNs are required to enable server migration for the SOA Servers. You can configure server migration for the SOA system later for high availability purposes. Refer to Chapter 14, "Configuring Server Migration for an Enterprise Deployment" for more details on configuring server migration for the SOA servers.

9.2.2 Synchronize System Clocks

Oracle SOA uses Quartz to maintain its jobs and schedules in the database. Synchronize the system clocks for the SOA WebLogic cluster to enable proper functioning of jobs, adapters, and Oracle B2B.

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 Enterprise Deployment" to contain SOA 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 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:

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
```
Start the Configuration Wizard.
```
./config.sh
```
In the Welcome screen, select Extend an existing WebLogic domain, and click Next.
In the WebLogic Domain Directory screen, select the following WebLogic domain directory
```
ORACLE_BASE/admin/domain_name/aserver/domain_name
```
Click Next.
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 Section 8.3, "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.
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 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.
The Configure Gridlink RAC Component Schema screen appears (Figure 9-1).

Figure 9-1 Configure GridLink RAC Component Schema Screen

In this 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. For information about configuring multi data sources see Appendix A, "Using Multi Data Sources with Oracle RAC."
- 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)
```
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.
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.
n the Select JMS Distributed Destination Type screen, ensure that ALL JMS system resources are configured to be UDD. This should be the default.

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

Select the automatically created server and click Rename to change the name to WLS_SOA1.
Click Add to add another new server and enter WLS_SOA2 as the server name.
Give servers WLS_SOA1 and WLS_SOA2 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
WLS_WSM1	SOAHOST1	7010	n/a	No
WLS_WSM2	SOAHOST2	7010	n/a	No

Click Next.

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	SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
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.

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.
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
  
  SOAHOST2
  
  SOAHOST2
  
  ADMINHOST
  
  localhost
Leave all other fields to their default values.

Click Next.
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.
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.
For information on targeting applications and resources, see Appendix B, "Targeting Applications and Resources to Servers."

Click Next.
In the Target Services to Clusters or Servers screen, ensure the following targets:
- Target mds-owsm to both WSM-PM_Cluster and AdminServer.
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.

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.
In the Extending Domain screen, click Done.
Restart the Administration Server using the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."

Name	Node Manager Listen Address
SOAHOST1	SOAHOST1
SOAHOST2	SOAHOST2
ADMINHOST	localhost

9.4 Configuring Oracle Coherence for Deploying Composites

Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication in SOA 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 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.

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 (SOAHOST1VHN1 and SOAHOST2VHN1). Set this property by adding the -Dtangosol.coherence.localhost parameters to the Arguments field of the Oracle WebLogic Server Administration Console's Server Start tab (Figure 9-1).

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:

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

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

Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node.
Click Servers. The Summary of Servers page appears.
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.
Click Lock & Edit.
Click the Server Start tab (illustrated in Figure 9-2).
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. This port can be changed by specifying a different port (for example, 8089) with the -Dtangosol.coherence.wkan.port and -Dtangosol.coherence.localport startup parameters. For example:

WLS_SOA1 (enter the following into the Arguments field on a single line, without a carriage return):
```
-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
```
WLS_SOA2 (enter the following into the Arguments field on a single line, without a carriage return):
```
-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1
-Dtangosol.coherence.localport=8089
-Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089
```
For more information about Coherence Clusters see the Oracle Coherence Developer's Guide.
For WLS_SOA1, enter the following:
```
-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST1VHN1
```
For WLS_SOA2, enter the following:
```
-Dtangosol.coherence.wka1=SOAHOST1VHN1
-Dtangosol.coherence.wka2=SOAHOST2VHN1
-Dtangosol.coherence.localhost=SOAHOST2VHN1
```
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 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.8, "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 in SOAHOST1."

9.5.2 Restarting the Node Manager on SOAHOST1

Use the startNodeManager.sh script to restart Node Manager.

To restart the Node Manager on SOAHOST1:

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

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

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

Note:

The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (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:

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.
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. See Section 16.14, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.
Access the following URL to verify status of WLS_SOA1:
```
http://SOAHOST1VHN1:8001/soa-infra/
```
Access the following URL to verify the status of B2B:
```
http://SOAHOST1VHN1:8001/b2bconsole/
```
Access the following URL to verify status of the worklist application:
```
http://SOAHOST1VHN1:8001/integration/worklistapp/
```
Access the following URL to verify status of the composer application:
```
http://SOAHOST1VHN1: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:

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

Run the unpack command on SOAHOST2 to unpack the propagated template.
```
cd ORACLE_COMMON_HOME/common/bin

/unpack.sh-domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/
-template=soadomaintemplateExtSOA.jar -overwrite_domain=true
-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.

Note:

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

9.5.5.1 Extracting the XEngine Files in SOAHOST2

To enable B2B's XEngine in SOAHOST2, extract the content of the XEngine tar file manually.

To extract the content of the XEngine tar file:

Run the following command from SOAHOST2:

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

Restart Node manager on SOAHOST2 using the procedure Section 9.5.2, "Restarting the Node Manager on SOAHOST1."
Verify the following directory structure after the extraction:
```
ORACLE_HOME/soa/soa/thirdparty/edifecs/
```
In this directory the following directories should appear:
- Common
- XEngine
In the XEngine directory the following directories and files should appear:
- bin
- config
- Readme.htm
- EULA.pdf

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:

Start the WLS_SOA2 managed server using the Administration Console.
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.14, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.
Access the following URL for soa-infra:
```
http://SOAHOST2VHN1:8001/soa-infra
```
Access the following URL to verify status of B2B:
```
http://SOAHOST2VHN1:8001/b2bconsole
```
Access the following URL to verify status of the worklist application.
```
http://SOAHOST2VHN1: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.
Access the following URL to verify status of the composer application.
```
http://SOAHOST2VHN1: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:

Log on to the Oracle WebLogic Administration Console.
In the Domain Structure tree, expand Services, and select Data Sources.
Click one of the new data sources.
Click the Monitoring tab and select one of the servers.
Click the Statistics tab and select one of the servers.
Click the ONS tab, and then click the Testing tab.

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 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.6.1, "Configuring Oracle HTTP Server for the WLS_SOAn Managed Servers"
Section 9.6.2, "Validating Access Through Oracle HTTP Server"
Section 9.6.3, "Setting the Frontend HTTP Host and Port"

9.6.1 Configuring Oracle HTTP Server for the WLS_SOAn Managed Servers

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

The entry for /workflow is optional. It is for workflow tasks associated with Oracle ADF task forms. The /workflow URL itself can be a different value, depending on the form.

To enable Oracle HTTP Server to route to the SOA_Cluster:

On WEBHOST1 and WEBHOST2, add directives to the soa.vh.conf file located in the following directory:

ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf

Note that this assumes you created the soa_vh.conf file using the instructions in Section 7.6, "Defining Virtual Hosts."

Add the following directives inside the <VirtualHost> tags:

<Location /soa-infra>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

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

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

# B2B
<Location /b2bconsole>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /b2b/services/ws/>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

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

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

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

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    SetHandler weblogic-handler 
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

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

 <Location /frevvo> 
     SetHandler weblogic-handler 
     WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
</VirtualHost>

The soa_vh.conf file will appear as it does in Example 9-1.

Restart Oracle HTTP Server on WEBHOST1 and WEBHOST2:

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

Example 9-1 soa_vh.conf file

<VirtualHost *:7777>
    ServerName https://soa.mycompany.com:443
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

<Location /soa-infra>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

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

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

# B2B
<Location /b2bconsole>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

<Location /b2b/services/ws/>
    SetHandler weblogic-handler
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

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

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

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

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    SetHandler weblogic-handler 
    WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>

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

 <Location /frevvo> 
     SetHandler weblogic-handler 
     WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
</VirtualHost>

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. The listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.

Sample scenarios:

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

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

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

9.6.2 Validating Access Through Oracle HTTP Server

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.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 HTTP Server host. Check these URLS for both WEBHOST1 and WEBHOST2):

http://webhostN:7777/soa-infra
http://webhostN:7777/integration/worklistapp
http://webhostN:7777/b2bconsole
http://webhostN:7777/sdpmessaging/userprefs-ui
http://webhostN:7777/soa/composer

Validate SOA_Cluster through both Oracle HTTP Server instances.

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

9.6.3 Setting the Frontend HTTP Host and Port

This section contains the procedure for setting the frontend HTTP host and port using the Administration Console. It also contains information about how callback URLs are calculated.

9.6.3.1 Setting the Frontend HTTP Host and Port

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

In the WebLogic Server Administration Console, in the Change Center section, click Lock & Edit.
In the left pane, choose Environment in the Domain Structure window and then choose Clusters. The Summary of Clusters page appears.
Select the SOA_Cluster cluster.
Select HTTP.
Set the values for the following:
- Frontend Host: soa.mycompany.com
- Frontend HTTPS Port: 443
- Frontend HTTP Port: 80
If you do not set the frontend HTTP host and port, you get the following message when trying to retrieve a document definition XSD from Oracle B2B:
```
An error occured while loading the document definitions.
java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.
```
Click Save.
To activate the changes, click Activate Changes in the Change Center section of the Administration Console.
Restart the servers for the Frontend Host directive in the cluster to take affect.

Note:

When HTTPS is enabled in the load balancer and the load balancer terminates SSL (the SOA servers receive only HTTP requests, not HTTPS), as suggested in this guide, the endpoint protocol for webservices is set to http. Since the load balancer redirects HTTP to HTTPS this causes the following exception when testing webservices functionality in Oracle Enterprise Manger Fusion Middleware Control:

(javax.xml.soap.SOAPException: oracle.j2ee.ws.saaj.ContentTypeException)

To resolve this exception, update the URL endpoint:

In the Enterprise Manager Test Page, check Edit Endpoint URL.

Within the endpoint URL page:

Change http to https.
Change the default port number (say 80) to SSL port (say 443).

9.6.3.2 About the Callback URL

This section describes how the SOA system calculates the callback URL.

If a request to SOA originates from an external or internal service, SOA uses the callback URL specified by the client.
If a request to an external or internal asynchronous service originates from SOA, SOA uses the following method, in decreasing order of preference to calculate the callback URL:
- Use callbackServerURL specified as a binding property for the specific reference. (You can set this when modeling the composite or at runtime using the MBeans). This allows different service calls to have different callback URLs. That is, a callback URL from an external service can be set to be different than one to an internal service In the context of the Enterprise Deployment architecture, typically this will be soa.mycompany.com (443/https) for external services and soainternal.mycompany.com (7777/http) for internal services. At runtime, this property is set using the System MBean Browser, through the corresponding binding mbean. To add a specific URL, add a callbackServerURL property to its Properties attribute, then invoke the save operation.
- Use the callback URL as specified in soa-infra-config.xml. In this case, only one address can be specified. When a mix of both external and internal services can be invoked, this should be set to soa.mycompany.com (443/https) in the Enterprise Deployment architecture. When only internal services are to be invoked, this can be set to soainternal.mycompany.com (7777/http)
- Use the callback URL as the frontend host specified in WLS for the SOA_Cluster. In this case, too, only one address can be specified and the recommendation is same as the one for soa-infra-config.xml.
- Use the local host name as provided by WLS MBean APIs. Oracle does not recommend this in high availability environments such as enterprise deployment.

9.7 Configuring a Default Persistence Store for Transaction Recovery

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

Note:

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

To set the location for the default persistence stores:

Log into the Oracle WebLogic Server Administration Console.
In the Change Center section, click Lock & Edit.
In the Domain Structure window, expand the Environment node and then click the Servers node. The Summary of Servers page appears.
Click the name of the server (represented as a hyperlink) in Name column of the table. The settings page for the selected server appears and defaults to the Configuration tab.
Click the Configuration tab, and then the Services tab.
In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:
```
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
```
Repeat steps 3, 4, 5, and 6 for the WLS_SOA2 server.
Click Save and Activate Changes.
Restart both SOA servers.
Verify that the following files are created in the following directory after WLS_SOA1 and WLS_SOA2 are restarted:
```
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. This directory must also exist before you restart the server.

9.8 Configuring Oracle Adapters

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

This section includes the following topics:

Section 9.8.1, "Enabling High Availability for Oracle File and FTP Adapters"
Section 9.8.2, "Enabling High Availability for Oracle JMS Adapters"
Section 9.8.3, "Scaling the Oracle Database Adapter"

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

Log into your Oracle WebLogic Server console. To access the console navigate to the following URL:
```
http://servername:portnumber/console
```
Click Deployments in the left pane for Domain Structure.
Click FileAdapter under Summary of Deployments on the right pane.
Click the Configuration tab.
Click the Outbound Connection Pools tab, and expand javax.resource.cci.ConnectionFactory to see the configured connection factories.
Click eis/HAFileAdapter. The Outbound Connection Properties for the connection factory corresponding to high availability is displayed.

The connection factory properties appear as shown in Figure 9-3.

Figure 9-3 Oracle WebLogic Server Console - Settings for javax.resource.cci.Connectionfactory Page

Description of "Figure 9-3 Oracle WebLogic Server Console - Settings for javax.resource.cci.Connectionfactory Page"

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

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

Table 9-5 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: 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 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 following directory: ORACLE_HOME/rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql If you want to create the schemas elsewhere, use this script. You must set the outboundDataSource property if you choose to do so.
outboundDataSourceLocal	Set the value to `jdbc/SOALocalTxDataSource`. This is the 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.

Click Save after you update the properties. The Save Deployment Plan page appears.
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 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.

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

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

http://servername:portnumber/console
Click Deployments in the left pane for Domain Structure.
Click JMSAdapter under Summary of Deployments on the right pane.
Click the Configuration tab.
Click the Outbound Connection Pools tab and expand oracle.tip.adapter.jms.IJmsConnectionFactory to see the configured connection factories.
Click the specific instance you are using (for example, eis/wls/Queue). The Outbound Connection Properties for the connection factory opens.
Click Lock & Edit.

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://soahostvhn1:8001,soahost2vhn1:8001;java.naming.se
curity.principal=weblogic;java.naming.security.credentials=mypassword

Click Save after you update the properties. The Save Deployment Plan page appears.
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.

Update the deployment in the console:

Click Deployments and select the JMS Adapter.
Click Lock & Edit then Update.
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).
Click Finish.
Activate the changes.

9.8.3 Scaling the Oracle Database Adapter

The introduction of skip locking has superseded the previous best practice of using LogicalDeletePollingStrategy or DeletePollingStrategy with a unique MarkReservedValue on each polling node, and setting MaxTransactionSize. If you were using this approach previously, you can simply remove (in db.jca) or clear (Logical Delete Page of wizard) the MarkReservedValue, and you automatically get skip locking.

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

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 a non-recoverable situation in a high availability environment is minimized.
No unique MarkReservedValue must be specified. Previously, for this to work you would have to configure a complex variable, such as R${weblogic.Name-2}-${IP-2}-${instance}.

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 that approach has now been superseded. If you were using this approach previously, you can simply remove (in db.jca) or clear (Logical Delete Page of wizard) the MarkReservedValue, and you automatically get skip locking.

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

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

Log in to Oracle Enterprise Manager Fusion Middleware Control with the username and password specified in Section 8.4.1, "Creating boot.properties for the Administration Server on SOAHOST1."
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.
Click on More B2B Configuration Properties... on the right.
Click the b2b MBean.
Click the Operations tab.
Click addProperty in the list on the right.
In the Key field enter b2b.HAInstanceName.
In the value field enter #ServerName#.

Enter this value in only one of the two servers.
Click Invoke.

9.10 Backing Up the SOA Configuration

After you have verified that the extended domain is working, back up the domain configuration. This is a quick backup for the express purpose of immediate restore in case of failures in future procedures. Back up the configuration to the local disk. This backup can be discarded once you have completed the enterprise deployment. Once you have completed the enterprise deployment, you can initiate the regular deployment-specific backup and recovery process.

For information about backing up the environment, see "Backing Up Your Environment" in the Oracle Fusion Middleware Administrator's Guide. For information about recovering your information, see "Recovering Your Environment" in the Oracle Fusion Middleware Administrator's Guide.

To back up the domain configuration:

Back up the Web tier:
1. Shut down the instance using opmnctl.
```
ORACLE_BASE/admin/instance_name/bin/opmnctl stopall
```
2. Back up the Middleware Home on the web tier using the following command (as root):
```
tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME
```
3. Back up the Instance Home on the web tier using the following command (as root):
```
tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE
```
4. Start the instance using opmnctl:
```
ORACLE_BASE/admin/instance_name/bin/opmnctl startall
```
Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or OS tools such as tar for cold backups if possible.
Back up the Administration Server domain directory to save your domain configuration. The configuration files are located in the following directory:
```
ORACLE_BASE/ admin/domain_name
```
To back up the Administration Server run the following command on SOAHOST1:
```
tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
```

Note:

Back up ORACLE_HOME if any changes are made to the XEngine configuration that is part of your B2B setup. These files are located in the following directory:

ORACLE_HOME/soa/thirdparty/edifecs/XEngine

To back up ORACLE_HOME:

tar -cvpf fmwhomeback.tar MW_HOME