14 Extending the Domain with Oracle SOA Suite

You need to perform certain tasks in order to extend the enterprise deployment domain with the Oracle SOA Suite software.

Parent topic: Configuring the Enterprise Deployment

14.1 Variables Used When Configuring Oracle SOA Suite

While extending the domain with Oracle SOA Suite, you will be 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

  • OHS_DOMAIN_HOME

  • JAVA_HOME

  • ORACLE_RUNTIME

In addition, you'll be referencing the following virtual IP (VIP) address defined in Reserving the Required IP Addresses for an Enterprise Deployment:

  • ADMINVHN

Actions in this chapter will be performed on the following host computers:

  • WCPHOST1

  • WCPHOST2

  • WEBHOST1

  • WEBHOST2

  • WCCHOST1

  • WCCHOST2

14.2 Synchronizing the System Clocks

Before you extend the domain to include Oracle SOA Suite, verify that the system clocks on each host computer are synchronized. You can do this by running the date command simultaneously on all the hosts in each cluster.

Alternatively, there are third-party and open-source utilities you can use for this purpose.

14.3 Installing the Software for an Enterprise Deployment

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

14.3.1 Starting the Oracle SOA Suite Installer on WCCHOST1

To start the installation program:

  1. Log in to WCCHOST1.
  2. Go to the directory where you downloaded the installation program.
  3. Launch the installation program by invoking the java executable from the JDK directory on your system, as shown in the example below. 
    JAVA_HOME/bin/java -d64 -jar fmw_12.2.1.2.0_soa_generic.jar

    Be sure to replace the JDK location in these examples with the actual JDK location on your system.

    For information about downloading the software and locating the actual installer file name for your product, see Identifying and Obtaining Software Distributions for an Enterprise Deployment.

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

14.3.2 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’ve 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 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.

14.3.3 Verifying the Installation

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

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

14.3.3.2 Checking the Directory Structure

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

The addition of Oracle SOA Suite adds the following directory and sub-directories:

/u01/oracle/products/fmw/soa

bam
bin
bpm
common
integration
jlib
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.

14.3.3.3 Viewing the Contents of Your Oracle Home

You can also view the contents of your Oracle home using the viewInventory script. For more information, see Viewing the contents of an Oracle home in Installing Software with the Oracle Universal Installer.

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

For more information, 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.

Note:

In previous releases, the recommended enterprise topology included a colocated set of Oracle HTTP Server instances. In those releases, there was a requirement to install the Infrastructure on the Web Tier hosts (WEBHOST1 and WEBHOST2). However, for this release, the enterprise deployment topology assumes the Web servers are installed and configured in standalone mode, so they are not considered part of the application tier domain. For more information, see Configuring the Web Tier for an Enterprise Deployment

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

14.4.1 Starting the Repository Creation Utility (RCU)

To start the Repository Creation Utility (RCU):

  1. Navigate to the ORACLE_HOME/oracle_common/bin directory on your system.
  2. Make sure 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
  3. Start RCU:

    On UNIX operating systems:

    ./rcu

14.4.2 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 will generate 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.

Task 3   Providing Database Connection Details

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

In the Host Name field, enter the SCAN address of the Oracle RAC Database.

Enter the DBMS/Service details.

Enter the Schema Owner and Schema Password details.

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 will automatically select SOA Infrastructure. In addition, the following dependent schemas have already been installed with the Infrastructure and are grayed out:

  • Common infrastructure Services

  • User Messaging Service

  • Metadata Services

  • Weblogic Services

  • Oracle Platform Security Services

  • Audit Services

  • Audit Services Append

  • Audit Services Viewer

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

Tip:

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

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 are planning on using Oracle Healthcare, then enter YES for the Healthcare Integration variable.

If you are planning on using Oracle Healthcare, then enter YES for the Healthcare Integration variable.

For more information, see About the Custom Variables Required for the SOA Suite Schemas in Installing and Configuring Oracle SOA Suite and Business Process Management.

Description of GUID-554E46ED-DF49-4FBD-AA5B-421D84C702B4-default.gif follows
Description of the illustration GUID-554E46ED-DF49-4FBD-AA5B-421D84C702B4-default.gif
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.

Task 8   Completing Schema Creation

Navigate through the remainder of the RCU screens to complete schema creation. When you reach the Completion Summary screen, click Close to dismiss RCU.

Task 9   Verifying the Schema Creation

To verify that the schemas were created successfully, and to verify the database connection details, use SQL*Plus or another utility to connect to the database, using the SOAINFRA schema name and the password you provided.

For example:

./sqlplus

SQL*Plus: Release 12.1.0.1.0 Production on Wed Aug 31 05:41:31 2016

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Enter user-name: FMW1221_SOAINFRA
Enter password: soainfra_password

Connected to:
Oracle Database 11g Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

14.4.3 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 Repository Creation Utility.

To configure the SOA schemas for transactional recovery privileges:

  1. Log on to SQL*Plus as a user with sysdba privileges. For example: 
    sqlplus "/ as sysdba"
  2. 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>

14.5 Extending the Enterprise Deployment Domain with Oracle SOA Suite

You need to perform the following tasks for extending the existing enterprise deployment domain with the Oracle SOA Suite software.

14.5.1 Starting the Configuration Wizard

To start the Configuration Wizard:

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

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

Follow the instructions in the following sections to create and configure the domain for the topology, with static clusters.

14.5.2.1 Extending the Domain with Static Clusters

Follow the instructions in this section to create and configure the domain for the topology with static clusters.

Note:

You can use the same procedure described in this section to extend an existing domain with static clusters. If your needs do not match the instructions given in the procedure, be sure to 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 you created when 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 - 12.2.1.2.0 [soa]

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

Task 3   Specifying the Database Configuration Type

On the Database Configuration Type screen, select RCU Data.

All fields are pre-populated, because you already configured the domain to reference the Fusion Middleware schemas that are required for the Infrastructure domain.

Verify and ensure that credentials in all the fields are the same that you have provided while configuring 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 operating succeeded:

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 4   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 click Next.

Task 5   Providing the GridLink Oracle RAC Database Connection Details

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

Element Description and Recommended Value

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

In the ONS Host field, enter the SCAN address for the Oracle RAC database.

In the Port field, enter the ONS Remote port (typically, 6200).

Enable Fan

Verify that the Enable Fan check box is selected, so the database can receive and process FAN events.
Task 6   Testing the JDBC Connections

Use the JDBC Component Schema Test screen to test the data source connections 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 7   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.

For more information, see Keystore in Creating WebLogic Domains Using the Configuration Wizard.

Task 8   Selecting Advanced Configuration

To complete domain configuration for the topology, select the following options on the Advanced Configuration screen:

  • Topology

    Add, Delete, or Modify Settings for Server Templates, Managed Servers, Clusters, Virtual Targets, and Coherence.

  • File Store

Task 9   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 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:

  1. Rename the default Oracle SOA Suite Managed Server to WLS_SOA1.

  2. Click Add to create a new Oracle SOA Suite Managed Server, and name it WLS_SOA2.

    Tip:

    The server names recommended here will be used throughout this document; if you choose different names, be sure to replace them as needed.

  3. Use the information in GUID-87AD8F24-E00A-48D4-AC30-56F0CB8CD838.htm#GUID-26CDA9CD-E110-431D-BE23-4AEEFC997B66__GUID-579F94E8-DCA0-486A-B006-5555CCB429F9to 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.

Server Name Listen Address Listen Port Enable SSL SSL Listen Port Server Groups

WLS_SOA1

WCCHOST1

8001

No

Disabled

SOA-MGD-SVRS-ONLY

WLS_SOA2

WCCHOST2

8001

No

Disabled

SOA-MGD-SVRS-ONLY
Task 10   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:

  1. Click the Add button.

  2. Specify SOA_Cluster in the Cluster Name field.

  3. From the Dynamic Server Groups drop-down list, select Unspecified.

Note:

By default, server instances in a cluster communicate with one another 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 11   Assigning Server Templates

Click Next to continue.

Task 12   Configuring Dynamic Servers
Verify that all dynamic server options are disabled for clusters that are to remain as static clusters.

  1. Confirm that the Dynamic Cluster, Calculated Listen Port, and Calculated Machine Names checkboxes on this screen are unchecked.

  2. Confirm the Server Template selection is Unspecified.

  3. Click Next.

Task 13   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:

  1. In the Clusters pane, select the cluster to which you want to assign the servers; in this case, SOA_Cluster.

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

  3. 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 14   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 15   Verifying the Existing Machines

Click Next to proceed.

Task 16   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 17   Configuring Virtual Targets

Click Next to proceed to the next screen.

Task 18   Configuring Partitions

Click Next to proceed to the next screen.

Task 19   Configuring File Store

In the JMS File Stores screen, assign the following directory for each of the SOA Persistence stores, including UMS and BPM file stores:

ORACLE_RUNTIME/domain_name/SOA_Cluster/jms

Note:

Create the jms folder before starting the managed servers.

In this example, replace ORACLE_RUNTIME with the value of the variable for your environment. Replace domain_name with the name you assigned to the domain. Replace SOA_Cluster with the name you assigned to the cluster.

Task 20   Reviewing Your Configuration Specifications and Configuring the Domain

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

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.

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

Task 21   Writing Down Your Domain Home and Administration Server URL

The Configuration Success screen will show the following items about the domain you just configured, including:

  • Domain Location

  • Administration Server URL

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

Click Finish to dismiss the Configuration Wizard.

Task 22   Start the Administration Server

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

14.6 Configuring a Default Persistence Store for Transaction Recovery

Oracle WebLogic Server uses the transaction logs to recover from system crashes or network failures.

Each Managed Server uses a transaction log that stores information about committed transactions that are coordinated by the server and that may not have been completed.

Oracle WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the Managed Servers within a cluster, store the transaction log in a location accessible to each Managed Server and its backup server.

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. All Managed Servers in the cluster must be able to access this directory. This directory must also exist before you restart the server.

The recommended location is a dual-ported SCSI disk or on a Storage Area Network (SAN). Note that it is important to set the appropriate replication and backup mechanisms at the storage level to guarantee protection in cases of a storage failure.

This information applies for file-based transaction logs. You can also configure a database-based persistent store for translation logs. For more information, see Using JDBC Persistent Stores for TLOGs and JMS in an Enterprise Deployment.

14.6.1 Configuring a Default Persistence Store for Transaction Recovery with a static cluster

To set the location for the default persistence stores for each managed server in a static cluster, complete the following steps:

  1. Log into the Oracle WebLogic Server Administration Console:

    ADMINVHN:7001/console

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

  3. For each of the Managed Servers in the cluster:

    1. In the Domain Structure window, expand the Environment node, and then click the Servers node.

      The Summary of Servers page appears.

    2. Click the name of the server (represented as a hyperlink) in the Name column of the table.

      The settings page for the selected server appears and defaults to the Configuration tab.

    3. On the Configuration tab, click the Services tab.

    4. In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files.

      For the enterprise deployment, use the ORACLE_RUNTIME directory location. This subdirectory serves as the central, shared location for transaction logs for the cluster. For more information, see File System and Directory Variables Used in This Guide.

      For example:

      ORACLE_RUNTIME/domain_name/cluster_name/tlogs

      In this example, replace ORACLE_RUNTIME with the value of the variable for your environment. Replace domain_name with the name you assigned to the domain. Replace cluster_name with the name of the cluster you just created.

    5. Click Save.

  4. Complete step 3 for all servers in the SOA_Cluster.

  5. Click Activate Changes.

Note:

You will validate the location and the creation of the transaction logs later in the configuration procedure.

14.7 Propagating the Extended Domain to the Domain Directories and Machines

You need to perform the following steps for propagating the domain configuration to the SOA Suite Managed Servers.

Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the Managed Server domain directory. To propagate the domain configuration to the SOA Suite Managed Servers:
  1. Create a copy of the Managed Server domain directory and the Managed Server applications directory.
  2. Run the following pack command on WCCHOST1 to create a template pack: 
    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

    In this example:

    • Replace ASERVER_HOME with the actual path to the domain directory you created on the shared storage device.

    • Replace full_path with the complete path to the location where you want to create the domain template jar file. You will need to reference this location when you copy or unpack the domain template jar file. It is recommended to choose a shared volume other than ORACLE_HOME, or write to /tmp/ and copy the files manually between servers.

      You must specify a full path for the template jar file as part of the -template argument to the pack command:

      SHARED_CONFIG_DIR/domains/template_filename.jar

    • wcpdomaintemplateExtSOA.jar is a sample name for the JAR file you are creating, which will contain 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.

  3. Run the following unpack command on WCCHOST1 to propagate the template created in the preceding step to the MSERVER_HOME directory: 
    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME 
            -template=/full_path/wcpdomaintemplateExtSOA.jar 
            -app_dir=APPLICATION_HOME 
            -overwrite_domain=true

    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 will be unpacked.

    • wcpdomaintemplateExtSOA.jar is the directory path and name of the template you created when you ran the pack command to pack up the domain on the shared storage device.

    • The -overwrite_domain=true argument is necessary when you are 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.

    • Replace APPLICATION_HOME with the complete path to the Application directory for the domain on local storage.

    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.

  4. If the full path to the packed jar file is on a shared volume available to the other servers, skip this step, otherwise, run the following command on WCCHOST1 to copy the template pack created in step 1 to WCCHOST2, WCPHOST1, and WCPHOST2: 
    scp /full_path/edgdomaintemplateExtSOA.jar oracle@WCCHOST2:/full_path/
scp /full_path/edgdomaintemplateExtSOA.jar oracle@WCPHOST1:/full_path/
scp /full_path/edgdomaintemplateExtSOA.jar oracle@WCPHOST2:/full_path/
  5. Run the following unpack command on each of the remote hosts to deploy the domain template copied in the preceding step to the MSERVER_HOME directory: 
    cd ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME 
            -template=/full_path/wcpdomaintemplateExtSOA.jar 
            -app_dir=APPLICATION_HOME 
            -overwrite_domain=true

    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 will be unpacked.

    • wcpdomaintemplateExtSOA.jar is the directory path and name of the template you created when you ran the pack command to pack up the domain on the shared storage device.

    • The -overwrite_domain=true argument is necessary when you are 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.

    • Replace APPLICATION_HOME with the complete path to the Application directory for the domain on local storage.

    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.

14.8 Updating the NodeManager Configuration After Unpacking the Domain

When extending a domain, the nodemanager.properties file in MSERVER_HOME may be overwritten with some values from the nodemanager.properties file for ASERVER_HOME. Specifically, the ListenAddress and/or CustomIdentityAlias values can be reset.

Notes::

For the MSERVER_HOME/nodemanager/nodemanager.properties file on each host:
  1. Verify the correct ListenAddress parameter value and reset it, if required. 
    grep ListenAddress MSERVER_HOME/nodemanager/nodemanager.properties
  2. Confirm the list of configured Identity Aliases from the domain configuration file as a reference for the next command. 
    grep server-private-key-alias ASERVER_HOME/config/config.xml | sort | uniq
  3. Verify the current CustomIdentityAlias parameter value. 
    grep CustomIdentityAlias MSERVER_HOME/nodemanager/nodemanager.properties
  4. Reset the CustomIdentityAlias parameter value to the correct alias string appropriate for the current host, if required.
  5. Restart the nodemanager process: 
    kill `ps -eaf | grep weblogic.NodeManager | grep MSERVER_HOME | grep -v grep | awk '{print $2}' `
nohup MSERVER_HOME/bin/startNodeManager.sh > MSERVER_HOME/nodemanager/nodemanager.out 2>&1 &
For more information, see Configuring Node Manager to Use the Custom Keystores.

14.9 Restarting and Validating Pre-existing Managed Servers

It is necessary to restart the managed servers for the pre-existing components after the domain has been extended and unpacked to the MSERVER_HOME directories on all of the servers.

Restart the managed servers for the pre-existing components now that the domain has been extended and unpacked to the MSERVER_HOME directories on all of the servers.
  1. From the WebLogic Server Console, restart the WLS_WSMn Managed Servers for the WebServices Manager Policy Manager.
  2. From another browser window, verify the WSM-PM application is responding by successfully loading the URL: 
    http://wcpinternal.example.com/wsm-pm/validator
  3. Start other pre-existing managed servers as necessary. Other product functionality will not be needed at this stage.

14.10 Modifying the Upload and Stage Directories to an Absolute Path

After configuring the domain and unpacking 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.

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

To update these directory paths for all the Managed Servers in the Managed Server domain home directory:

  1. Log in to the Oracle WebLogic Server Administration Console.

  2. In the left navigation tree, expand Domain, and then Environment.

  3. Click Lock & Edit.

  4. Navigate to and edit the appropriate objects for your cluster type.

    1. For Static Clusters, navigate to Servers and click on the name of the Managed Server to be edited.

  5. 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 directory path for the MSERVER_HOME directory; If using static clusters, update with the correct name of the Managed Server you are editing.

    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.

  6. When you have modified all of the appropriate objects, click Activate Changes.

  7. Restart all Managed Servers effected by these change.

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

14.11.1 Starting the WLS_SOA1 Managed Server

To start the WLS_SOA1 Managed Server:

  1. Enter the following URL into a browser to display the Fusion Middleware Control login screen: 
    http://ADMINVHN:7001/em
  2. Log in to Fusion Middleware Control using the Administration Server credentials.
  3. In the Target Navigation pane, expand the domain to view the Managed Servers in the domain.
  4. 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.

  5. When the startup operation is complete, navigate to the Domain home page and verify that the WLS_SOA1 Managed Server is up and running.

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

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

  1. Use your Web browser to navigate to the following URL: 
    http://WCCHOST1:8001/soa-infra/
  2. Log in 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"

14.12 Starting and Validating the WLS_SOA2 Managed Server

After validating 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 the validation URL, enter the following URL in your web browser and log in using the enterprise deployment administrator user (weblogic_soa):

http://WCCHOST2:8001/soa-infra/

14.13 Validating the Location and Creation of the Transaction Logs

After WLS_SOA1 and WLS_SOA2 are up and running, verify that the transaction log directory and transaction logs were created as expected.

Run the following command to verify, based on the steps you performed in Configuring a Default Persistence Store for Transaction Recovery:

ls -al ORACLE_RUNTIME/domain_name/cluster_name/tlogs

  • _WLS_WLS_SOA1000000.DAT

  • _WLS_WLS_SOA2000000.DAT

14.14 Configuring Oracle HTTP Server 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.

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

  1. Log in to WEBHOST1 and change directory to the configuration directory for the first Oracle HTTP Server instance (ohs1): 
    cd OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/moduleconf/
  2. Edit the wcpinternal_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.

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

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

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

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

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

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

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

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

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

 <Location /frevvo> 
    WLSRequest ON 
    WebLogicCluster WCCHOST1:8001,WCCHOST2:8001 
    WLProxySSL ON
    WLProxySSLPassThrough ON
</Location>
</VirtualHost>
  4. Copy the wcpinternal_vh.confand wcp_vh.conf files to the configuration directory for the second Oracle HTTP Server instance (ohs2): 
    OHS_DOMAIN_HOME/config/fmwconfig/components/ohs2/moduleconf/
  5. Edit the wcpinternal_vh.conf and wcp_vh.conf to change any references to WEBHOST1 to WEBHOST2 in the <VirtualHost> directives.
  6. Restart both Oracle HTTP servers.

Example 14-1 Sample Content for the wcpinternal_vh.conf File

Note:

The following sample configuration files content only includes SOA Suite and Oracle WebServices Manager resources. Resources for other products that may have been configured in prior chapters are not represented here.
<VirtualHost WEBHOST1:7777>
    ServerName http://wcpinternal.example.com:80
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

# WSM-PM 
<Location /wsm-pm>
     WebLogicCluster WCPHOST1:7010,WCPHOST2:7010
     WLSRequest ON
     WLProxySSL OFF
     WLProxySSLPassThrough OFF
</Location>

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

Example 14-2 Sample Content for the wcp_vh.conf File

<VirtualHost WEBHOST1:7777>
    ServerName http://wcp.example.com:443
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

# WSM-PM 
<Location /wsm-pm>
     WebLogicCluster WCPHOST1:7010,WCPHOST2:7010
     WLSRequest ON
     WLProxySSL ON
     WLProxySSLPassThrough ON
</Location>

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

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

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

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

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

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

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

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

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

14.14.2 Configuring the WebLogic Proxy Plug-In

Before you can validate that requests are routed correctly through the Oracle HTTP Server instances, you must set the WebLogic Plug-In Enabled parameter for the clusters you just configured.

  1. Log in to the Oracle WebLogic Server Administration Console.
  2. In the Domain Structure pane, expand the Environment node.
  3. Click Lock & Edit in the Change Center.
  4. Click Clusters.
  5. Select the cluster to which you want to proxy requests from Oracle HTTP Server.

    The Configuration: General tab is displayed.

  6. Scroll down to the Advanced section and expand it.
  7. Set WebLogic Plug-In Enabled to yes.
  8. Click Save.
  9. If more than one cluster was deployed for the latest domain extension, repeat steps 4 through 8 until all the clusters are consistently updated.
  10. Click Activate Changes in the Change Center.
  11. Restart all Managed Servers in all of the clusters that you modified in this chapter.

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

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

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

14.15 Post-Configuration Steps for Oracle SOA Suite

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

14.15.1 Enabling SSL Communication Between the SOA Servers and the Hardware Load Balancer

After you extend the domain with Oracle SOA Suite, you should also ensure that the Administration Server and Managed Servers can access the front-end, SSL URL of the hardware load balancer.

This will allow SOA Composite applications and web services to invoke callbacks and other communications with the front-end, secure URL.

For more information, see Enabling SSL Communication Between the Middle Tier and the Hardware Load Balancer.

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

14.15.3 Updating the Workflow Front End Address for Appropriate Task Display

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

This process can be completed once and will take effect for all SOA servers.

To configure the appropriate URLs:

  1. Log in to Oracle Enterprise Manager Fusion Middleware Control with the username and password you specified in the Updating the boot.properties File and Restarting the System section.
  2. From the WebLogic Domain drop-down menu, select System MBean Browser.
  3. In the Mbean navigation, expand Application Defined MBeans > oracle.as.soainfra.config > Server: WLS_SOA1 > WorkflowConfig, and then click human-workflow.
  4. In the FusionAppsFrontendHostUrl field, enter the following:

    *=https://wcp.example.com:443

  5. Click Apply.

14.16 Enabling Automatic Service Migration and JDBC Persistent Stores for Oracle SOA Suite

To ensure that Oracle SOA Suite is configured for high availability, configure the Oracle SOA Suite Managed Servers for automatic service migration.

For more information on enabling automatic service migration, see Configuring Automatic Service Migration in an Enterprise Deployment.

For additional high availability, you can also configure your transaction logs store and JMS store in a database. For more information, see Using JDBC Persistent Stores for TLOGs and JMS in an Enterprise Deployment.