Extending the Domain with Oracle SOA Suite

Variables Used When Configuring Oracle SOA Suite

While extending the domain with Oracle SOA Suite, you are referencing the directory variables listed in this section.

The values for several directory variables are defined in File System and Directory Variables Used in This Guide.

ORACLE_HOME
ASERVER_HOME
MSERVER_HOME
APPLICATION_HOME
DEPLOY_PLAN_HOME
WEB_DOMAIN_HOME
JAVA_HOME
ORACLE_RUNTIME

In addition, you reference the following virtual IP (VIP) address that are defined in Reserving the Required IP Addresses for an Enterprise Deployment:

ADMINVHN

Actions in this chapter are performed on the following host computers:

WCPHOST1
WCPHOST2
WEBHOST1
WEBHOST2
WCCHOST1
WCCHOST2

Synchronizing the System Clocks

Verify that the system clocks on each host computer are synchronized.

Oracle recommends the use of the Network Time Protocol (NTP). See Configuring a Host to Use an NTP (time) Server.

To verify the time synchronization, query the NTP service by running the chronyc -n tracking command on each host.

Sample output:


$chronyc -n tracking
Reference ID : A9FEA9FE (169.254.169.254)
Stratum : 3
Ref time (UTC) : Tue Jan 14 15:28:01 2025
System time : 0.000043127 seconds fast of NTP time
Last offset : +0.000034640 seconds
 
...

Installing the Software for an Enterprise Deployment

The procedure to install the software for an enterprise deployment is explained in this section.

Starting the Oracle SOA Suite Installer on WCCHOST1

To start the installation program:

Log in to WCCHOST1.
Go to the directory where you downloaded the installation program.
Launch the installation program by invoking the java executable from the JDK directory on your system, as shown in the following example:
```
JAVA_HOME/bin/java -d64 -jar Installer File Name
```
Be sure to replace the JDK location in these examples with the actual JDK location on your system.

Replace Installer File Name with the name of the actual installer file for your product listed in Identifying and Obtaining Software Distributions for an Enterprise Deployment.

When the installation program appears, you are ready to begin the installation.

Navigating the Installation Screens

The installation program displays a series of screens, in the order listed in the following table.

If you need additional help with any of the installation screens, click the screen name.

Screen	Description
Welcome	This screen introduces you to the product installer.
Auto Updates	Use this screen to automatically search My Oracle Support for available patches or automatically search a local directory for patches that you have already downloaded for your organization.
Installation Location	Use this screen to specify the location of your Oracle home directory. For more information about Oracle Fusion Middleware directory structure, see Selecting Directories for Installation and Configuration in Planning an Installation of Oracle Fusion Middleware.
Installation Type	Use this screen to select the type of installation and consequently, the products and feature sets you want to install. Select SOA Suite
Prerequisite Checks	This screen verifies that your system meets the minimum necessary requirements. If there are any warning or error messages, you can refer to one of the documents in the Roadmap for Verifying Your System Environment section in Installing and Configuring the Oracle Fusion Middleware Infrastructure.
Installation Summary	Use this screen to verify the installation options that you selected. Click Install to begin the installation.
Installation Progress	This screen allows you to see the progress of the installation. Click Next when the progress bar reaches 100% complete.
Installation Complete	Review the information on this screen, then click Finish to dismiss the installer.

Installing Oracle SOA Suite on the Other Host Computers

If you have configured a separate shared storage volume or partition for the products mount point and ORACLE_HOME on WCCHOST2, then you must also perform the product installation on WCCHOST2.

See Shared Storage Recommendations When Installing and Configuring an Enterprise Deployment.

To install the software on the other host computers in the topology, log in to each host, and use the instructions in Starting the Infrastructure Installer on WCCHOST1 and Navigating the Infrastructure Installation Screens to create the Oracle home on the appropriate storage device.

Verifying the Installation

After you complete the installation, you can verify it by successfully completing the following tasks.

Reviewing the Installation Log Files

Review the contents of the installation log files to make sure that no problems were encountered. For a description of the log files and where to find them, see Understanding Installation Log Files in Installing Software with the Oracle Universal Installer.

Checking the Directory Structure

The contents of your installation vary based on the options that you select during the installation.

The addition of Oracle SOA Suite adds the following directory and sub-directories. Use the ls --format=single-column command to verify the directory structure.

ls --format=single-column /u01/oracle/products/fmw/soa

bam
bin
bpm
common
integration
jlib
modules
plugins
readme.txt
reports
soa

For more information about the directory structure you should see after installation, see What are the Key Oracle Fusion Middleware Directories? in Understanding Oracle Fusion Middleware.

Viewing the Contents of Your Oracle Home

You can also view the contents of your Oracle home by using the viewInventory script. See Viewing the contents of an Oracle home in Installing Software with the Oracle Universal Installer.

Creating the Oracle SOA Suite Database Schemas

Before you can configure an Oracle SOA Suite domain, you must install the required schemas in a certified database for use with this release of Oracle Fusion Middleware.

Starting the Repository Creation Utility (RCU)

To start the Repository Creation Utility (RCU):

Navigate to the $ORACLE_HOME/oracle_common/bin directory on your system.
Make sure that the JAVA_HOME environment variable is set to the location of a certified JDK on your system. The location should be up to but not including the bin directory. For example, if your JDK is located in /u01/oracle/products/jdk:
On UNIX operating systems:
```
export JAVA_HOME=/u01/oracle/products/jdk
```
Start RCU:
On UNIX operating systems:
```
./rcu
```
Note:

If your database has Transparent Data Encryption (TDE) enabled, and you want to encrypt your tablespaces that are created by the RCU, provide the -encryptTablespace true option when you start RCU.

This defaults the appropriate RCU GUI Encrypt Tablespace checkbox selection on the Map Tablespaces screen without further effort during the RCU execution. See Encrypting Tablespaces in Creating Schemas with the Repository Creation Utility.

Navigating the RCU Screens to Create the Schemas

Schema creation involves the following tasks:

Task 1 Introducing RCU

Click Next.

Task 2 Selecting a Method of Schema Creation

If you have the necessary permission and privileges to perform DBA activities on your database, select System Load and Product Load. This procedure assumes that you have the necessary privileges.

If you do not have the necessary permission or privileges to perform DBA activities in the database, you must select Prepare Scripts for System Load on this screen. This option generates a SQL script, which can be provided to your database administrator to create the required schema. See Understanding System Load and Product Load in Creating Schemas with the Repository Creation Utility.

Click Next.

Task 3 Providing Database Connection Details

Provide the database connection details for RCU to connect to your database.

In the Database Type, select Oracle Database enabled for edition-based redefinition.

Note:
Oracle Database enabled for edition-based redefinition (EBR) is recommended to support Zero Down Time upgrades. For more information, see https://www.oracle.com/database/technologies/high-availability/ebr.html.
In the Host Name field, enter the SCAN address of the Oracle RAC Database.
Enter the Port number of the RAC database scan listener, for example 1521.
Enter the RAC Service Name of the database.
Enter the User Name of a user that has permissions to create schemas and schema objects, for example SYS.
Enter the Password of the user name that you provided in step 5.
If you have selected the SYS user, ensure that you set the role to SYSDBA.
Click Next to proceed, then click OK on the dialog window confirming that connection to the database was successful.

Task 4 Specifying a Custom Prefix and Selecting Schemas

Choose Select existing prefix, and then select the prefix you used when you created the initial domain.

From the list of schemas, select the SOA Suite schema. This automatically selects SOA Infrastructure. In addition, the following dependent schemas have already been installed with the Infrastructure and are grayed out:

Common infrastructure Services
Oracle Platform Security Services
User Messaging Service
Audit Services
Audit Services Append
Audit Services Viewer
Metadata Services
Weblogic Services

The custom prefix is used to logically group these schemas together for use in this domain only; you must create a unique set of schemas for each domain as schema sharing across domains is not supported.

Tip:

For more information about custom prefixes, see Understanding Custom Prefixes in Creating Schemas with the Repository Creation Utility.

For more information about how to organize your schemas in a multi-domain environment, see Planning Your Schema Creation in Creating Schemas with the Repository Creation Utility.

Click Next to proceed, then click OK on the dialog window to confirm that prerequisite checking for schema creation was successful.

Task 5 Specifying Schema Passwords

Specify how you want to set the schema passwords on your database, then specify and confirm your passwords. Ensure that the complexity of the passwords meet the database security requirements before you continue. RCU proceeds at this point even if you do not meet the password polices. Hence, perform this check outside RCU itself.

Tip:

You must make a note of the passwords that you set on this screen; you need them later on during the domain creation process.

Click Next.

Task 6 Specifying Custom Variables

Specify the custom variables for the SOA Infrastructure schema.

For the enterprise deployment topology, enter LARGE for the Database Profile custom variable; if you plan to use Oracle Healthcare, then enter YES for the Healthcare Integration variable. See About the Custom Variables Required for the SOA Suite Schemas in Installing and Configuring Oracle SOA Suite and Business Process Management.

Click Next.

Task 7 Verifying the Tablespaces for the Required Schemas

On the Map Tablespaces screen, review the information, and then click Next to accept the default values.

Click OK in the confirmation dialog box.

Click Next.

Task 8 Creating Schemas

Review the summary of the schemas to be loaded, and click Create to complete schema creation.

Note:

If failures occurred, review the listed log files to identify the root cause, resolve the defects, and then use RCU to drop and recreate the schemas before you continue.

Task 9 Reviewing Completion Summary and Completing RCU Execution

When you reach the Completion Summary screen, verify that all schema creations have been completed successfully, and then click Close to dismiss RCU.

Verifying Schema Access

Verify schema access by connecting to the database as the new schema users created by the RCU. Use SQL*Plus or another utility to connect, and provide the appropriate schema names and passwords entered in the RCU.

For example:

./sqlplus FMW1412_SOAINFRA/<soainfra_password>

SQL*Plus: Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on Wed Sep 11 14:20:00 2024 Version 23.5.0.24.07
Copyright (c) 1982, 2024, Oracle. All rights reserved.


Connected to:
Oracle Database 23ai EE Extreme Perf Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems
Version 23.5.0.24.07

SQL>

Note:

If the database is a pluggable database (PDB), the apropriate TNS alias that points to the PDB must be used in the sqlplus command.

Configuring SOA Schemas for Transactional Recovery

After you have installed the Oracle SOA Suite schemas successfully, use the procedure in this section to configure the schemas for transactional recovery.

This procedure sets the appropriate database privileges so that the Oracle WebLogic Server transaction manager can query the schemas for transaction state information and issue the appropriate commands, such as commit and rollback, during recovery of in-flight transactions after a WebLogic Server is unexpectedly unavailable.

These privileges should be granted to the owner of the SOAINFRA schema, which you defined when you created the schemas with the RCU.

To configure the SOA schemas for transactional recovery privileges:

Log on to SQL*Plus as a user with sysdba privileges. For example:
```
sqlplus "/ as sysdba"
```

Enter the following commands:

SQL> Grant select on sys.dba_pending_transactions to soa_schema_prefix_soainfra;

Grant succeeded.
 
SQL> Grant force any transaction to soa_schema_prefix_soainfra;
 
Grant succeeded.
 
SQL>

Extending the Enterprise Deployment Domain with Oracle SOA Suite

Perform the following tasks to extend the existing enterprise deployment domain with the Oracle SOA Suite software.

Note:

For an improved footprint and to optimize startup, only core adapters are targeted to the SOA cluster (MFT Cluster if you are configuring MFT) after the Configuration Wizard session. You must target the second-tier adapters manually, if required. See Targeting Adapters Manually.

Extending the domain involves the following tasks:

Starting the Configuration Wizard

Start the Configuration Wizard as the first step to extend the existing enterprise deployment domain.

Note:

SSL store customizations were added to the setUserOverridesLate.sh in the domain creation chapter. Any customizations added to this file are preserved when a domain is extended and are carried over to remote servers when using the pack and unpack commands.However, if you added any additional customizations to the setDomainEnv.sh script in the domain (such as custom libraries, JAVA command line options for starting the servers or environment variables), those will be overwritten by the configuration wizard when you extend the domain. Add all the startup parameters that apply to all servers in a domain to the setUserOverridesLate.sh file. This will preserve them across extensions.

To start the Configuration Wizard:

Stop any managed servers that are modified by this domain extension. Managed Servers that are not effected can remain on-line.
For any managed servers to be modified, verify that the managed server shutdown has completed.
Stop the Administration Server once all managed servers are in a steady state.
Navigate to the following directory and start the WebLogic Server Configuration Wizard.
```
cd $ORACLE_HOME/oracle_common/common/bin
./config.sh
```

Navigating the Configuration Wizard Screens to Extend the Domain with Oracle SOA Suite

Follow the instructions in these sections to extend the domain for Oracle SOA Suite with static clusters.

Extending the Domain with Static Clusters

Follow the instructions in this section to extend the domain for Oracle SOA Suite, with static clusters.

Note:

This procedure assumes that you are extending an existing domain. If your needs do not match the instructions given in the procedure, ensure that you make your selections accordingly, or refer to the supporting documentation for additional details.

Domain creation and configuration includes the following tasks:

Task 1 Selecting the Domain Type and Domain Home Location

On the Configuration Type screen, select Update an existing domain.

In the Domain Location field, select the value of the ASERVER_HOME variable, which represents the complete path to the Administration Server domain home that you created in Creating the Initial Infrastructure Domain for an Enterprise Deployment.

For more information about the directory location variables, see File System and Directory Variables Used in This Guide.

For more information about the other options on this screen, see Configuration Type in Creating WebLogic Domains Using the Configuration Wizard.

Task 2 Selecting the Configuration Template

On the Templates screen, make sure Update Domain Using Product Templates is selected, then select the following templates:

Oracle SOA Suite - 14.1.2.0.0 [soa]

For more information about the options on this screen, see Templates in Creating WebLogic Domains Using the Configuration Wizard.

Task 3 Configuring High Availability Options

This screen appears for the first time when you create a cluster that uses Automatic Service Migration or JDBC stores or both. After you select HA Options for a cluster, all subsequent clusters that are added to the domain by using the Configuration Wizard, automatically apply HA options (that is, the Configuration Wizard creates the JDBC stores and configures ASM for them).

On the High Availability Options screen:

Select Enable Automatic Service Migration with Database Basis.
Set JTA Transaction Log Persistence to JDBC TLog Store.
Set JMS Server Persistence to JMS JDBC Store.

Note:

Oracle recommends that you use JDBC stores, which leverage the consistency, data protection, and high availability features of an oracle database and makes resources available for all the servers in the cluster. So, the Configuration Wizard steps assume that the JDBC persistent stores are used along with Automatic Service Migration.

When you choose JDBC persistent stores, additional unused File Stores are automatically created but are not targeted to your clusters. Ignore these File Stores.

If, for any reason, you want to use Files Stores, you can retain the default values for TLOGs and JMS persistent store options in this screen and configure them in a shared location later. See Task 9, "Selecting Advanced Configuration". Shared location is required to resume JMS and JTA in a failover scenario.

You can also configure TLOGs and JMS persistent stores manually in a post step. For information about the differences between JDBC and Files Stores, and for specific instructions to configure them manually, see Using Persistent Stores for TLOGs and JMS in an Enterprise Deployment.

Click Next.

Task 4 Specifying the Database Configuration Type

On the Database Configuration Type screen, select RCU Data.

All fields are prepopulated, because you already configured the domain to reference the Fusion Middleware schemas that are required for the Infrastructure domain. In the RCU Data screen:

Verify that Vendor is Oracle and Driver is *Oracle's Driver (Thin) for Service Connections; Versions: Any.
Verify that Connection Parameters is selected.
Verify and ensure that credentials in all the fields are the same as those provided during the configuration of Oracle Fusion Middleware Infrastructure.

Click Get RCU Configuration after you finish verifying the database connection information. The following output in the Connection Result Log indicates that the operation is successful.

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

Tip:

For more information about the RCU Data option, see Understanding the Service Table Schema in Creating Schemas with the Repository Creation Utility.

For more information about the other options on this screen, see Datasource Defaults in Creating WebLogic Domains Using the Configuration Wizard.

Task 5 Specifying JDBC Component Schema Information

On the JDBC Component Schema screen, select all the SOA schemas in the table.

When you select the schemas, the fields on the page are activated and the database connection fields are populated automatically.

Click Convert to GridLink , and then click Next.

Task 6 Providing the GridLink Oracle RAC Database Connection Details

On the GridLink Oracle RAC Component Schema screen, provide the information that is required to connect to the RAC database and component schemas, as shown in the following table.

Element	Description and Recommended Value
Service Name	Verify that the service name for the Oracle RAC database is appropriate. For example, `soaedg.example.com`.
SCAN, Host Name, and Port	Select the SCAN check box. In the Host Name field, enter the Single Client Access Name (SCAN) Address for the Oracle RAC database. In the Port field, enter the SCAN listening port for the database (for example, `1521`).
ONS Host and Port	These values are not required when you are using an Oracle 12c database or higher versions because the ONS list is automatically provided from the database to the driver.
Enable Fan	Verify that the Enable Fan check box is selected, so that the database can receive and process FAN events.

Task 7 Testing the JDBC Connections

Use the JDBC Component Schema Test screen to test the data source connections that you have just configured.

A green check mark in the Status column indicates a successful test. If you encounter any issues, see the error message in the Connection Result Log section of the screen, fix the problem, then try to test the connection again.

For more information about the other options on this screen, see Test Component Schema in Creating WebLogic Domains Using the Configuration Wizard.

Task 8 Keystore

Use this screen to specify details about the keystore to be used in the domain.

For a typical enterprise deployment, you can leave the default values.

See Keystore in Creating WebLogic Domains Using the Configuration Wizard.

Task 9 Selecting Advanced Configuration

To complete domain configuration for the topology, select Topology on the Advanced Configuration screen.

Note:

JDBC stores are recommended and selected in Task 3, "Configuring High Availability Options" so there is no need to configure File Stores.

If you choose File Stores in Task 3, "Configuring High Availability Options", you have to select the File Stores option here to configure them in a shared location in ORACLE_RUNTIME/domain_name/SOA_Cluster/jms. Shared location is required to resume JMS and JTA in a failover scenario.

Task 10 Configuring Managed Servers

On the Managed Servers screen, a new Managed Server for Oracle SOA Suite appears in the list of servers. This server was created automatically by the Oracle SOA Suite configuration template that you selected in Task 2, "Selecting the Configuration Template".

Perform the following tasks to modify the default Oracle SOA Suite Managed Server and create a second Oracle SOA Suite Managed Server:

Rename the default Oracle SOA Suite Managed Server to WLS_SOA1.
Click Add to create a new Oracle SOA Suite Managed Server, and name it WLS_SOA2.

Tip:

The server names recommended here are used throughout this document; if you choose different names, be sure to replace them as needed.
Use the information in the following table to fill in the rest of the columns for each Oracle SOA Suite Managed Server.

For more information about the options on the Managed Server screen, see Managed Servers in Creating WebLogic Domains Using the Configuration Wizard.

Table 14-1 Lists the Information to Provide for Each SOA Managed Server on the Configuration Wizard Managed Servers Screen

Server Name	Listen Address	Listen Port	SSL Listen Port	Administration Port	Server Groups
WLS_SOA1	WCCHOST1	Disabled	8001	9006	SOA-MGD-SVRS-ONLY
WLS_SOA2	WCCHOST2	Disabled	8001	9006	SOA-MGD-SVRS-ONLY

Task 11 Configuring a Cluster

In this task, you create a cluster of Managed Servers to which you can target the Oracle SOA Suite software.

Use the Clusters screen to create a new cluster:

Click the Add button.
Specify SOA_Cluster in the Cluster Name field.
From the Dynamic Server Groups drop-down list, select Unspecified.

Note:

By default, server instances in a cluster communicate with one another by using unicast. If you want to change your cluster communications to use multicast, refer to Considerations for Choosing Unicast or Multicast in Administering Clusters for Oracle WebLogic Server.

For more information about the options on this screen, see Clusters in Creating WebLogic Domains Using the Configuration Wizard.

Task 12 Assigning Server Templates

Click Next to continue.

Task 13 Configuring Dynamic Servers

Verify that all dynamic server options are disabled for clusters that are to remain as static clusters. To configure dynamic servers:

Confirm that the Dynamic Cluster, Calculated Listen Port, and Calculated Machine Names checkboxes on this screen are unchecked.
Confirm the Server Template selection is Unspecified.
Click Next.

Task 14 Assigning Managed Servers to the Cluster

Use the Assign Servers to Clusters screen to assign WLS_SOA1 and WLS_SOA2 to the new cluster SOA_Cluster:

In the Clusters pane, select the cluster to which you want to assign the servers; in this case, SOA_Cluster.
In the Servers pane, assign WLS_SOA1 to SOA_Cluster by doing one of the following:
- Click WLS_SOA1 Managed Server once to select it, and then click on the right arrow to move it beneath the selected cluster in the Clusters pane.
- Double-click WLS_SOA1 to move it beneath the selected cluster in the clusters pane.
Repeat to assign WLS_SOA2 to SOA_Cluster.

For more information about the options on this screen, see Assign Servers to Clusters in Creating WebLogic Domains Using the Configuration Wizard.

Task 15 Configuring Coherence Clusters

Use the Coherence Clusters screen to configure the Coherence cluster that is automatically added to the domain. Leave the port number value at 9991, as it was defined during the initial Infrastructure domain creation.

For Coherence licensing information, see Oracle Coherence Products in Oracle Fusion Middleware Licensing Information User Manual.

Task 16 Verifying the Existing Machines

Click Next to proceed.

Task 17 Assigning Servers to Machines

Use the Assign Servers to Machines screen to assign the Oracle SOA Suite Managed Servers you just created to the corresponding machines in the domain.

Assign WLS_SOA1 to WCCHOST1, and assign WLS_SOA2 to WCCHOST2.

For more information about the options on this screen, see Assign Servers to Machines in Creating WebLogic Domains Using the Configuration Wizard.

Task 18 Reviewing Your Configuration Specifications and Configuring the Domain

The Configuration Summary screen contains detailed configuration information for the domain that you are about to extend. Review the details of each item on the screen and verify that the information is correct.

If you need to make any changes, you can go back to any previous screen if you need to make any changes, either by using the Back button or by selecting the screen in the navigation pane.

Click Update to execute the domain extension.

In the Configuration Progress screen, click Next when it finishes.

For more information about the options on this screen, see Configuration Summary in Creating WebLogic Domains Using the Configuration Wizard.

Task 19 Writing Down Your Domain Home and Administration Server URL

The Configuration Success screen shows the following items about the domain that you just configured, including:

Domain Location
Administration Server URL

Make a note of both these items, because you need them later; you need the domain location to access the scripts used to start the Administration Server, and you need the Administration Server URL to access the WebLogic Remote Console and Oracle Enterprise Manager Fusion Middleware Control.

Click Finish to dismiss the Configuration Wizard.

If the Admin Server was running during the domain extension process, restart the server before you continue.

Task 20 Start the Administration Server

Start the Administration Server to ensure that the changes that you have made to the domain have been applied.

After you complete extending the domain with static clusters, go to Targeting Adapters Manually.

Targeting Adapters Manually

Only core adapters are targeted to the SOA cluster after you run the Configuration Wizard. You must target second-tier adapters manually, on a need basis.

The following second-tier adapters have to be targeted manually:

Note:

Some of these adapters may not be available with the default installation. See Oracle Technology Network for Adapter availability.

MSMQAdapter
SocketAdapter
OracleBamAdapter
CoherenceAdapter
SAPAdapter
SiebelAdapter
ERPAdapter
Oracle SalesCloudAdapter
RightNowAdapter
EloquaAdapter
NetSuiteAdapter
LdapAdapter
JDEWorldAdapter

To target a second-tier adapter manually:

Navigate to Edit Tree > Deployments > App Deployments.
Locate and click the name of the adapter in the Summary of the Deployments table.
In the Targets tab, select SOA_Cluster and move it to the Chosen pane.

Note:

If you are deploying MFT, select MFT_Cluster as the target.
Add The cart on the top right part of the screen will show full with a yellow bag inside.
Click the Cart icon on the top right and select Commit Changes.
In the Navigation Tree pane of the console, navigate to Monitoring Tree > Deployments > Ap Development Runtimes and verify that the adapter is in the Active state.

Propagating the Extended Domain to the Domain Directories and Machines

After you have extended the domain with the Oracle WebCenter Portal instances, and you have restarted the Administration Server on WCCHOST1, you must then propagate the domain changes to the domain directories and machines.

Table 14-2 summarizes the steps required to propagate the changes to all the domain directories and machines.

Note that there is no need to propagate the updated domain to the WEBHOST1 and WEBHOST2 machines because there are no changes to the Oracle HTTP Server instances on those host computers.

Table 14-2 Summary of Tasks Required to Propagate the Domain Changes to Domain Directories and Machines

Task Description More Information

Task	Description	More Information
Pack up the Extended Domain on WCCHOST1	Use the `pack` command to create a new template JAR file that contains the new Oracle SOA Suite Managed Servers configuration. When you pack up the domain, create a template JAR file called `wcpdomaintemplateExtSOA.jar`.	Packing Up the Extended Domain on WCPHOST1
Unpack the Domain in the Managed Servers directory on WCPHOST1	Unpack the template JAR file in the Managed Servers directory on WCPHOST1 local storage.	Unpacking the Domain in the Managed Servers Domain Directory on WCPHOST1
Unpack the Domain on WCPHOST2 Unpack the Domain on WCCHOST1 and WCCHOST2	Unpack the template JAR file in the Managed Servers directory on the WCPHOST2local storage. Unpack the JAR file, later, in the Managed Services directory on WCCHOST1 and WCCHOST2 local storage.	Unpacking the Domain on WCPHOST2

Pack up the Extended Domain on WCCHOST1

Use the pack command to create a new template JAR file that contains the new Oracle SOA Suite Managed Servers configuration.

When you pack up the domain, create a template JAR file called wcpdomaintemplateExtSOA.jar.

Packing Up the Extended Domain on WCPHOST1

Unpack the Domain in the Managed Servers directory on WCPHOST1

Unpack the template JAR file in the Managed Servers directory on WCPHOST1 local storage.

Unpacking the Domain in the Managed Servers Domain Directory on WCPHOST1

Unpack the Domain on WCPHOST2

Unpack the Domain on WCCHOST1 and WCCHOST2

Unpack the template JAR file in the Managed Servers directory on the WCPHOST2local storage.

Unpack the JAR file, later, in the Managed Services directory on WCCHOST1 and WCCHOST2 local storage.

Unpacking the Domain on WCPHOST2

Packing Up the Extended Domain on WCCHOST1

Use the following steps to create a template JAR file that contains the domain configuration information:

Log in to WCCHOST1 and run the pack command to create a template JAR file as follows:
```
cd ORACLE_COMMON_HOME/common/bin
 
./pack.sh -managed=true \ 
          -domain=ASERVER_HOME \ 
          -template=full_path/wcpdomaintemplateExtSOA.jar \
          -template_name=wcp_domain_template_extension_soa \
	  -log=/tmp/pack_soa.log \
	  -log_priority=debug
```
In this example:
- Replace ASERVER_HOME with the actual path to the domain directory that you created on the shared storage device.
- Replace full_path with the complete path to the directory where you want the template jar file saved.
- wcpdomaintemplateExtSOA.jar is a sample name for the JAR file that you are creating, which contains the domain configuration files, including the configuration files for the Oracle HTTP Server instances.
- wcp_domain_template_extension_soa is the name assigned to the domain template file.
Make a note of the location of the template JAR file that you just created with the pack command.

Tip:

For more information about the pack and unpack commands, see Overview of the Pack and Unpack Commands in Creating Templates and Domains Using the Pack and Unpack Commands.

Unpacking the Domain in the Managed Servers Domain Directory on WCCHOST1

To copy the updated domain configuration information from the Administration Server domain directory to the Managed Servers domain directory:

Log in to WCCHOST1 if you haven't already.
If you haven't already, create the recommended directory structure for the Managed Server domain on the WCCHOST1 local storage device.

Use the examples in File System and Directory Variables Used in This Guide as a guide.
Run the unpack command to unpack the template in the domain directory onto the local storage, as follows:
```
cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
    -overwrite_domain=true \
    -template=/full_path/wcpdomaintemplateExtSOA.jar \
    -log_priority=DEBUG \
    -log=/tmp/unpack.log \
    -app_dir=APPLICATION_HOME
```
Note:

The -overwrite_domain option in the unpack command allows you to unpack 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.

Additionally, to customize server startup parameters that apply to all servers in a domain, you can create a file called setUserOverridesLate.sh and configure it to, for example, add custom libraries to the WebLogic Server classpath, specify additional JAVA command-line options for running the servers, or specify additional environment variables. Any customizations that you add to this file are preserved during domain upgrade operations, and are carried over to remote servers when you use the pack and unpack commands.

In this example:
- Replace MSERVER_HOME with the complete path to the domain home to be created on the local storage disk. This is the location where the copy of the domain is unpacked.
- Replace /full_path/wcpdomaintemplateExtSOA.jar with the complete path and file name of the domain template jar file that you created when you ran the pack command to pack up the domain on the shared storage device.
- Replace APPLICATION_HOME with the complete path to the applications directory for the domain on shared storage. See File System and Directory Variables Used in This Guide
Tip:

For more information about the pack and unpack commands, see Overview of the Pack and Unpack Commands in Creating Templates and Domains Using the Pack and Unpack Commands.
Change directory to the newly created MSERVER_HOME directory and verify that the domain configuration files were copied to the correct location on the WCCHOST1 local storage device.

Unpacking the Domain on WCCHOST2

This procedure assumes that you have copied the file which you created earlier into a location that is accessible from each application-tier host, whether that is local to each host, or on shared storage.

Log in to WCCHOST2.
If you have not already, create the recommended directory structure for the Managed Server domain on the WCCHOST2 storage device.

Use the examples in File System and Directory Variables Used in This Guide as a guide.
Make sure that the create_domain.jar accessible to WCCHOST2.

For example, if you are using a separate shared storage volume or partition for WCCHOST2, then copy the template to the volume or partition mounted to WCCHOST2.
Run the unpack command to unpack the template in the domain directory onto the local storage, as follows:
```
cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
            -overwrite_domain=true \
            -template=/full_path/create_domain.jar \ 
            -log_priority=DEBUG \
            -log=/tmp/unpack.log \
            -app_dir=APPLICATION_HOME 
```
Note:

The -overwrite_domain option in the unpack command allows you to unpack 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.

Additionally, to customize server startup parameters that apply to all servers in a domain, you can create a file called setUserOverridesLate.sh and configure it to, for example, add custom libraries to the WebLogic Server classpath, specify additional JAVA command-line options for running the servers, or specify additional environment variables. Any customizations that you add to this file are preserved during domain upgrade operations, and are carried over to remote servers when you use the pack and unpack commands.
In this example:
- Replace MSERVER_HOME with the complete path to the domain home to be created on the local storage disk. This is the location where the copy of the domain is unpacked.
- Replace /full_path/create_domain.jar with the complete path and file name of the domain template jar file that you created when you ran the pack command to pack the domain on the shared storage device.
- Replace APPLICATION_HOME with the complete path to the Application directory for the domain on shared storage. See File System and Directory Variables Used in This Guide.
Tip:

For more information about the pack and unpack commands, see Overview of the Pack and Unpack Commands in Creating Templates and Domains Using the Pack and Unpack Commands.
Change directory to the newly created MSERVER_HOME directory and verify that the domain configuration files were copied to the correct location on the WCCHOST2 local storage device.
Repeat this procedure for WCPHOST1 and WCPHOST2.

Modifying the Upload and Stage Directories to an Absolute Path in an Enterprise Deployment

After you configure the domain and unpack it to the Managed Server domain directories on all the hosts, verify and update the upload and stage directories for Managed Servers in the new clusters. Also, update the upload directory for the AdminServer to have the same absolute path instead of relative, otherwise deployment issues can occur.

This step is necessary to avoid potential issues when you perform remote deployments and for deployments that require the stage mode.

To update the directory paths for the Deployment Stage and Upload locations, complete the following steps:

Log in to the WebLogic Remote Console to access the provider of this domain.
In the left navigation tree, expand Domain, and then Environment.
Click Lock & Edit.
Navigate to and edit the appropriate objects for your cluster type.
1. For Static Clusters, navigate to Servers and click the name of the Managed Server you want to edit.
2. For Dynamic Clusters, navigate to Clusters > Server Templates, and click on the name of the server template to be edited.
For each new Managed Server or Server Template to be edited:
1. Click the Configuration tab, and then click the Deployment tab.
2. Verify that the Staging Directory Name is set to the following:
```
MSERVER_HOME/servers/server_or_template_name/stage
```
  Replace MSERVER_HOME with the full path for the MSERVER_HOME directory.
  
  If you use static clusters, update with the correct name of the Managed Server that you are editing.
  
  If you use dynamic clusters, leave the template name intact. For example: /u02/oracle/config/domains/wcpedg_domain/servers/XYZ-server-template/stage
3. Update the Upload Directory Name to the following value:
```
ASERVER_HOME/servers/AdminServer/upload
```
  Replace ASERVER_HOME with the directory path for the ASERVER_HOME directory.
4. Click Save.
5. Return to the Summary of Servers or Summary of Server Templates screen as applicable.
Repeat the previous steps for each of the new managed servers.
Navigate to and update the Upload Directory Name value for the AdminServer:
1. Navigate to Servers, and select the AdminServer.
2. Click the Configuration tab, and then click the Deployment Tab.
3. Verify that the Staging Directory Name is set to the following absolute path:
  
  ASERVER_HOME/servers/AdminServer/stage
4. Update the Upload Directory Name to the following absolute path:
  
  ASERVER_HOME/servers/AdminServer/upload
  
  Replace ASERVER_HOME with the directory path for the ASERVER_HOME directory.
5. Click Save.
When you have modified all the appropriate objects, click Activate Changes.

Note:

If you continue directly with further domain configurations, a restart to enable the stage and upload directory changes is not strictly necessary at this time.

Starting and Validating the WLS_SOA1 Managed Server

Now that you have extended the domain, started the Administration Server, and propagated the domain to the other hosts, you can start the newly configured Oracle SOA Suite Managed Servers.

This process involves three tasks as described in the following sections.

Starting the WLS_SOA1 Managed Server

To start the WLS_SOA1 Managed Server:

Enter the following URL into a browser to display the Fusion Middleware Control login screen:
```
https://admin.example.com:445/em
```
Note:

If you have already configured web tier, use http://admin.example.com/console.
Sign in to the Fusion Middleware Control by using the administrator's account. For example: weblogic_wcp.
In the Target Navigation pane, expand the domain to view the Managed Servers in the domain.

Description of the illustration fmwc_soacluster.gif
Select only the WLS_SOA1 Managed Server and click Start Up on the Oracle WebLogic Server toolbar.

Note:

SOA Servers depend on the policy access service to be functional. This implies that the WSM-PM Managed Servers in the domain need to be up and running and reachable before the SOA servers are started.
When the startup operation is complete, navigate to the Domain home page and verify that the WLS_SOA1 Managed Server is up and running.

Adding the SOAAdmin Role to the Administrators Group

Before you validate the Oracle SOA Suite configuration on the WLS_SOA1 Managed Server, add the SOAAdmin administration role to the enterprise deployment administration group (WCPAdministrators).

To perform this task, refer to Configuring Roles for Administration of an Enterprise Deployment.

Validating the Managed Server by Logging in to the SOA Infrastructure

After you add the SOAAdmin role to the SOA Administrators group, you can then validate the configuration of the Oracle SOA Suite software on the WLS_SOA1 Managed Server as follows:

Use your web browser to navigate to the following URL:
```
https://WCCHOST1:8001/soa-infra
```
Log in by using the enterprise deployment administrator user credentials (weblogic_wcp).
You should see a web page with the following title:
```
Welcome to the Oracle SOA Platform on WebLogic
```

Starting and Validating the WLS_SOA2 Managed Server

After you validate the successful configuration and startup of the WLS_SOA1 Managed Server, you can start and validate the WLS_SOA2 Managed Server.

To start and validate the WLS_SOA2 Managed Server, use the procedure in Starting and Validating the WLS_SOA1 Managed Serverfor WLS_SOA2 Managed Server.

For validation of the URL, enter the following URL in your web browser and log in by using the enterprise deployment administrator user (weblogic_wcp):

https://WCCHOSt2:8001/soa-infra

Configuring the Web Tier for the Extended Domain

The following sections describe how to configure the Oracle HTTP Server instances so they route requests for both public and internal URLs to the proper clusters in the enterprise topology.

Configuring Oracle HTTP Server for SOA in an Oracle WebCenter Portal Enterprise Deployment

When integrating SOA with WebCenter Portal for workflow functionality both internal and end-user access to the SOA Suite resources should be configured.

Use the following procedure to configure the Oracle HTTP Server instances in the web tier, so they route requests correctly to the Oracle SOA Suite cluster. This procedure assumes that you have performed the Oracle HTTP Server configuration tasks described in Configuring Oracle HTTP Server to Route Requests to the Application Tier.

Configure the virtual host configuration files so that requests are routed properly to the Oracle SOA Suite clusters:

Log in to WEBHOST1 and change directory to the configuration directory for the first Oracle HTTP Server instance (ohs1):
```
cd WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/
```

Edit the wcp_vh.conf file and add the following directives inside the <VirtualHost> tags:

Note:

The URL 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.
Configure the port numbers appropriately as assigned for your static or dynamic cluster. Dynamic clusters with the Calculate Listen Port option selected will have incremental port numbers for each dynamic managed server created.
The WebLogicCluster directive needs only a sufficient number of redundant server:port combinations to guarantee initial contact in case of a partial outage. The actual total list of cluster members is retrieve automatically upon first contact with any given node.

# soa-infra
<Location /soa-infra>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# SOA inspection.wsil
<Location /inspection.wsil>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Worklist
<Location /integration>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# UMS prefs
<Location /sdpmessaging/userprefs-ui>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Default to-do taskflow
<Location /DefaultToDoTaskFlow>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# Workflow
<Location /workflow>
    WLSRequest ON
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

#Required if attachments are added for workflow tasks
 <Location /ADFAttachmentHelper> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

# SOA composer application 
 <Location /soa/composer> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>

 <Location /frevvo> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL OFF
    WLProxySSLPassThrough OFF
</Location>
</VirtualHost>

Copy the wcpinternal_vh.confand wcp_vh.conf files to the configuration directory for the second Oracle HTTP Server instance (ohs2):
```
WEB_DOMAIN_HOME/config/fmwconfig/components/ohs2/moduleconf/
```
Edit the wcpinternal_vh.conf and wcp_vh.conf to change any references to WEBHOST1 to WEBHOST2 in the <VirtualHost> directives.
Restart both Oracle HTTP servers.

Validating the Oracle SOA Suite URLs Through the Load Balancer

To validate the configuration of the Oracle HTTP Server virtual hosts and to verify that the hardware load balancer can route requests through the Oracle HTTP Server instances to the application tier:

Verify that the server status is reported as Running in the WebLogic Remote 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.
Verify that you can access these URLs:
- https://wcp.example.com:443/soa-infra
- https://wcp.example.com:443/integration/worklistapp
- https://wcp.example.com:443/sdpmessaging/userprefs-ui
- https://wcp.example.com:443/soa/composer

Post-Configuration Steps for Oracle SOA Suite

After you install and configure Oracle SOA Suite, consider the following post-configuration tasks.

Configuring Oracle Adapters for Oracle SOA Suite

If the Oracle SOA Suite applications that you are developing take advantage of any of the Oracle adapters for Oracle SOA Suite, then you should make sure that the adapters are configured to work efficiently and securely in the enterprise topology.

See the following topics for more information.

Enabling High Availability for Oracle File and FTP Adapters

If the Oracle SOA Suite applications that you are developing or deploying require the Oracle File and FTP Adapters, you must configure the adapters for high availability in the enterprise deployment topology.

Use the following sections to complete this task.

Understanding the Oracle File and FTP Adapter Configuration

The Oracle File and FTP adapters enable a BPEL process or an Oracle Mediator to read and write files on private file systems and on remote file systems through the File Transfer Protocol (FTP).

When configured properly, 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.

For general information about this task, see Configuring Oracle File and FTP Adapters in Understanding Technology Adapters. The instructions provided here are specific to the Oracle SOA Suite enterprise deployment.

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.

Configuring the Oracle File Adapter in the WebLogic Remote Console

To make the Oracle File Adapter highly available, first modify the Oracle File Adapter deployment descriptor for the connection-instance that corresponds to eis/HAFileAdapter.

To configure adapters, perform the following steps in the WebLogic Remote Console:

Create a deployment plan directory on shared storage (if it does not exist) as follows:
```
mkdir -p $DEPLOY_PLAN_HOME/soaedg_domain
```
Create a fileadapter control directory in the shared runtime folder as follows:
```
mkdir -p /u01/oracle/runtime/soaedg_domain/SOA_Cluster/fadapter
```
In the Monitoring Tree, navigate to Deployments > Application Management > File Adapter.
Click Create Plan (if it does not already have a plan) and use the DEPLOY_PLAN_HOME/domain_name/ as its directory.
After the new plan is displayed under the File Adapter, in the Monitoring Tree navigate to Deployments > Application Management > File Adapter.
Select Configuration > Outbound Connection Pool Groups.
Navigate to javax.resource.cci.ConnectionFactory > Outbound Connection Pool Instances.
Navigate to eis/HAFileAdapter > Properties.

Modify the values of the properties described in the following table:

Table 14-3 The following table describes modified parameters

Parameter	Description
controlDir	Enter the directory 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_RUNTIME/domain_name/cluster_name/fadapter
inboundDataSource	Set the value to `jdbc/SOADataSource`.
outboundDataSource	Set the value to `jdbc/SOADataSource`.
outboundDataSourceLocal	Set the value to `jdbc/SOALocalTxDataSource`. This is the data source where the schemas that corresponds to high availability are precreated.
outboundLockTypeForWrite	Set the value to `oracle` if you are using Oracle Database. By default the Oracle File and FTP Adapters use an in-memory mutex to lock outbound write operations. You must choose from the following values for synchronizing write operations: `memory`: The Oracle File and FTP Adapters use an in-memory mutex to synchronize access to the file system. `oracle`: The adapter uses Oracle Database sequence. `db`: The adapter uses a pre-created database table (`FILEADAPTER_MUTEX`) as the locking mechanism. You must use this option only if you are using a schema other than the Oracle Database schema. `user-defined`: The adapter uses a user-defined mutex. To configure the user-defined mutex, you must implement the mutex interface: `oracle.tip.adapter.file.Mutex` and then configure a new binding-property with the name `oracle.tip.adapter.file.mutex` and value as the fully qualified class name for the mutex for the outbound reference.
workingDirectory	Retain the default value.

Redeploy the Adapter using the console.
1. In the Monitoring Tree, navigate to Deployments > Application Management.
2. Select the FileAdapter deployment check box.
3. Click Update/Redeploy > Redeploy - Deployment Source and Plan on Server (it is not possible to use Update - Deployment Plan on Server because these are non-dynamic changes).
Ensure that the deployment plan is correct in the Plan Path filed.
Click Done.

Wait for the operation to complete.
After the operation is complete, check the values entered in the Monitoring > Deployments > Application Management > FileAdapter > Deployment plan.

Editing the JCA File Within the Composite Application

After you have configured the FileAdapter deployment in the Administration Console, you can edit the .jca file that is included in the composite applications to be deployed so that they can use the connection factory that was configured in the previous steps, as shown in Example 14-1.

Note:

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

Example 14-1 Example of the File Adapter .JCA File Modifications for an Enterprise Deployment

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

Configuring the Oracle FTP Adapter

If your application requires an FTP Adapter, then repeat the procedures Configuring the Oracle File Adapter in the Administration Console and Editing the JCA File Within the Composite Application, with the following differences:

Locate the FtpAdapter deployment in the list of deployments in the Administration Console.
Click FtpAdapter to display the Settings for the FtpAdapter page.
Click Configuration.
Click Outbound Connection Pools.
Expand javax.resource.cci.ConnectionFactory to see the configured connection factories.
Click eis/Ftp/HAFtpAdapter.

The Outbound Connection Properties for the connection factory appears.
Click Lock & Edit.
Modify the adapter properties for high availability. See **INTERNAL XREF ERROR**.
Update the ControlDir property so it points to the following location:
```
ORACLE_RUNTIME/domain_name/cluster_name/ftpadapter
```
Enter a shared storage location for the deployment plan. The directory structure is as follows:
```
DEPLOY_PLAN_HOME/wcpedg_domain/FtpAdapterPlan.xml
```

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 is established to only one random server. If that particular server goes down, no further messages are processed.

To avoid this issue, you can use the “cluster name” syntax in the FactoryProperties of the adapter instead of using the static list of members. The cluster name syntax is as follows:

cluster:t3://cluster_name

When you use cluster:t3://cluster_name, the invocation fetches the complete list of members in the cluster at any given time, thus avoiding any dependencies on the initial servers and accounting for every member that is alive in the cluster at that point of time. Note that you can use this cluster syntax only when the cluster is in the same domain.

Create a deployment plan directory on shared storage (if it does not exist) as follows:
Copy
```
mkdir -p $DEPLOY_PLAN_HOME/soaedg_domain
```
In the Monitoring Tree , navigate to Deployments > Application Management > JMS Adapter.
Create Plan (if it does not already have a plan) and use the DEPLOY_PLAN_HOME/domain_name/ as its directory.
After the new plan is displayed under the JMS Adapter, in the Monitoring Tree navigate to Deployments > Application Management > JMS Adapter.
Navigate to Configuration > Outbound Connection Pool Groups.
Navigate to oracle.tip.adapter.jms.IJmsConnectionFactory> Outbound Connection Pool Instances.
Click eis/wls/Queue > Properties.
Click the FactoryProperties field (click the corresponding cell under Property value), enter the following, all in one line, separated by semicolons. Adjust the values to match your cluster name, username and password:
```
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
java.naming.provider.url=cluster:t3s://SOA_Cluster;
java.naming.security.principal=soaedgadmin;
java.naming.security.credentials=<password>
```
Click Save after you update the properties.
Redeploy the Adapter using the console.
1. Navigate to Monitoring > Deployments > Application Management.
2. Select the JMSAdapter deployment check box.
3. Click Update/Redeploy > Redeploy - Deployment Source and Plan on Server (not possible to use Update - Deployment Plan on Server because these are non dynamic changes)
Ensure that the deployment plan is correct in the Plan Path filed.
Click Done.
Wait for the operation to complete.
After the operation is complete, check the values entered in the Monitoring > Deployments > Application Management > JMSAdapter > Deployment plan.

Enabling High Availability for the Oracle Database Adapter

To ensure High Availability while leveraging the Oracle Database Adapter, the Logical Delete Polling Strategy is used normally as it performs better than a physical delete. However, when you have a clustered environment where multiple nodes are polling for the same data, a single record might get processed more than once. To avoid this problem, Oracle Database Adapter uses a distributed polling technique that uses an Oracle Database feature called skip locking.

If you were using the Logical Delete Polling Strategy approach previously, you can 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.

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

Considerations for Sync-Async Interactions in a SOA Cluster

In a SOA cluster, the following scenarios are not supported:

Synchronous BPEL process with mid-process receive.
Synchronous BPEL process calling asynchronous services.
Callback from synchronous processes.

Updating FusionAppsFrontendHostUrl

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

To configure the appropriate URLs:

Log in to Oracle Enterprise Manager Fusion Middleware Control with the username and password that you specified in the boot.properties file. See Creating the boot.properties File.
In the left navigation tree, expand WebLogic Domain, and then click System MBean Browser.
Navigate to Application Defined Mbean > oracle.as.soainfra.config > WLS_SOA1 > WorkflowConfig > human-workflow.

Note:
In a clustered environment, there are multiple human-workflow Mbeans, one for every server in the cluster. Modify any one of them to update the property centrally in MDS for the entire cluster.
On the right panel, look for the FusionAppsFrontendHostUrl attribute.
For the FusionAppsFrontendHostUrl attribute, specify the value *=https://wcp.example.com:443.
Click Apply.

Backing Up the Configuration

It is an Oracle best practices recommendation to create a backup after you successfully extended a domain or at another logical point. Create a backup after you verify that the installation so far is successful. This is a quick backup for the express purpose of immediate restoration in case of problems in later steps.

The backup destination is the local disk. You can discard this backup when the enterprise deployment setup is complete. After the enterprise deployment setup is complete, you can initiate the regular deployment-specific Backup and Recovery process.

For information about backing up your configuration, see Performing Backups and Recoveries for an Enterprise Deployment.

14 Extending the Domain with Oracle SOA Suite

Variables Used When Configuring Oracle SOA Suite

Synchronizing the System Clocks

Installing the Software for an Enterprise Deployment

Starting the Oracle SOA Suite Installer on WCCHOST1

Navigating the Installation Screens

Installing Oracle SOA Suite on the Other Host Computers

Verifying the Installation

Reviewing the Installation Log Files

Checking the Directory Structure

Viewing the Contents of Your Oracle Home

Creating the Oracle SOA Suite Database Schemas

Starting the Repository Creation Utility (RCU)

Navigating the RCU Screens to Create the Schemas

Verifying Schema Access

Configuring SOA Schemas for Transactional Recovery

Extending the Enterprise Deployment Domain with Oracle SOA Suite

Starting the Configuration Wizard

Navigating the Configuration Wizard Screens to Extend the Domain with Oracle SOA Suite

Extending the Domain with Static Clusters

Targeting Adapters Manually

Propagating the Extended Domain to the Domain Directories and Machines

Packing Up the Extended Domain on WCCHOST1

Unpacking the Domain in the Managed Servers Domain Directory on WCCHOST1

Unpacking the Domain on WCCHOST2

Restarting and Validating Pre-existing Managed Servers

Modifying the Upload and Stage Directories to an Absolute Path in an Enterprise Deployment

Starting and Validating the WLS_SOA1 Managed Server

Starting the WLS_SOA1 Managed Server

Adding the SOAAdmin Role to the Administrators Group

Validating the Managed Server by Logging in to the SOA Infrastructure

Starting and Validating the WLS_SOA2 Managed Server

Configuring the Web Tier for the Extended Domain

Configuring Oracle HTTP Server for SOA in an Oracle WebCenter Portal Enterprise Deployment

Validating the Oracle SOA Suite URLs Through the Load Balancer

Post-Configuration Steps for Oracle SOA Suite

Configuring Oracle Adapters for Oracle SOA Suite

Enabling High Availability for Oracle File and FTP Adapters

Understanding the Oracle File and FTP Adapter Configuration

Configuring the Oracle File Adapter in the WebLogic Remote Console

Editing the JCA File Within the Composite Application

Configuring the Oracle FTP Adapter

Enabling High Availability for Oracle JMS Adapters

Enabling High Availability for the Oracle Database Adapter

Considerations for Sync-Async Interactions in a SOA Cluster

Updating FusionAppsFrontendHostUrl

Backing Up the Configuration