14 Extending the Domain with Oracle Service Bus

The procedures described in this chapter guide you through the process of extending the enterprise deployment topology with Oracle Service Bus (OSB).

About Configuring Oracle Service Bus in Its Own Domain

When you add Oracle Service Bus (OSB) to your enterprise topology, you can add it to the existing SOA domain, or you can create a new domain for OSB, separate from the Oracle SOA Suite domain.

For more information about the OSB topology, see About the Topology Options for Oracle Service Bus.

If you decide to configure Oracle Service Bus in a separate domain, then keep in mind the following when you use the instructions to add Oracle Service Bus to your topology:

  • Ignore any references to the SOA Managed Servers or the SOA Cluster. These elements of the domain only exist if you extend a domain that has already been extended with Oracle SOA Suite.

  • You must run the RCU to create the SOAINFRA schema for the Oracle Service Bus domain. This schemas is required by Oracle Service Bus. You must use a unique SOAINFRA schema and schema prefix for the Oracle Service Bus domain.

  • When you run the Configuration Wizard, the High Availability Options screen appears as described in Navigating the Configuration Wizard Screens to Extend the Domain with Oracle SOA Suite.

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

    In the case of static clusters, Oracle recommends that you select the following options:

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

    In the case of dynamic clusters, Oracle recommends that you complete the following steps:
    • Verify that Enable Automatic Service Migration is not selected.

    • Verify that JTA Transaction Log Persistence is set to Default Persistent Store.

    • Select JMS Server Persistence to JDBC Store.

    You can configure only JMS Server persistence for Dynamic Clusters by using the Configuration Wizard. You cannot configure Service Migration and JTA Transaction Logs Persistence for Dynamic Clusters by using the Configuration Wizard, you have to configure them manually. Instructions are covered in the later chapters of this guide.

Variables Used When Configuring Oracle Service Bus

As you perform the tasks in this chapter, you reference the directory variables that are 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

  • JAVA_HOME

  • WEB_DOMAIN_HOME

In addition, you reference the following virtual IP (VIP) addresses that are defined in Physical and Virtual IP Addresses Required by the Enterprise Topology:ADMINVHN

Actions in these topics are performed on the following host computers:

  • SOAHOST1

  • SOAHOST2

  • WEBHOST1

  • WEBHOST2

Support for Dynamic Clusters in Oracle Service Bus

Oracle Service Bus supports two different topologies: static clusters-based topology and dynamic clusters-based topology. When choosing the dynamic cluster topology, there are some differences with respect to the conventional static clusters configuration.

Static clusters, also called configured clusters, are conventional clusters where you manually configure and add each server instance. A dynamic cluster includes a new "server-template" object that is used to define a centralized configuration for all generated (dynamic) server instances. When you create a dynamic cluster, the dynamic servers are preconfigured and automatically generated for you. This feature enables you to scale up the number of server instances in the dynamic cluster when you need additional server capacity. You can simply start the dynamic servers without having to first manually configure and add them to the cluster.

The steps in this section include instructions to configure the domain for both static or dynamic topologies. The differences between the two types of configurations are listed below:
  • The Configuration Wizard process may differ for each case. For example, you should define server templates for dynamic clusters instead of servers.

  • For dynamic clusters, you should perform the server-specific configurations such as setting the listen address, configuring the upload and staging directories, or configuring the keystores in the server template instead of in the server.

  • Service migration is configured in a different way for dynamic clusters. Dynamic clusters do not use migratable targets, instead the JMS resources are targeted to the cluster. Specific procedure for configuring service migration for dynamic clusters is included in this guide.

Mixed clusters (clusters that contains both dynamic and configured server instances) are not supported in the Oracle SOA Suite enterprise deployment.

Overview of Adding OSB to the Topology

Before you add OSB to the topology, you must ensure that you have already performed the steps that are required to create an initial Infrastructure domain and then extended the domain to include Oracle SOA suite.

Table 14-1 lists and describes the high-level steps to extend an existing SOA domain or an existing Infrastructure domain for Oracle Service Bus.

Table 14-1 Steps for Extending a SOA Domain to Include Oracle Service Bus

Step Description More Information

Install Oracle Service Bus software.

Install OSB software on the target system.

Installing Oracle Service Bus Software

Optionally, install the SOAINFRA schema in a supported database.

OSB requires the SOAINFRA schema for the wlsbjmsrpDataSource data source. If you plan to run OSB in its own domain, then you must be sure that you have installed a separate SOAINFRA schema for OSB in a supported database.

Be sure to use a unique schema for the SOAINFRA schema that is used by the OSB domain.

Creating the Oracle SOA Suite Database Schemas

Optionally, create a new Infrastructure domain.

If you plan to run OSB in its own domain, then you must first create an Infrastructure domain, so you can extend that domain with OSB.

Creating the Initial Infrastructure Domain for an Enterprise Deployment

Run the Configuration Wizard to Extend the Domain.

Extend the SOA or Infrastructure domain to contain Oracle Service Bus components.

Extending the SOA or Infrastructure Domain to Include Oracle Service Bus

Propagate the Domain Configuration to the Managed Server Directory in SOAHOST1 and to SOAHOST2.

Oracle Service Bus requires some updates to the WebLogic Server start scripts. Propagate these changes by using the pack and unpack commands.

Propagating the Extended Domain to the Domain Directories and Machines

Start the Oracle Service Bus Servers.

Oracle Service Bus servers extend an already existing domain. As a result, the Administration Server and respective Node Managers are already running in SOAHOST1 and SOAHOST2.

Starting and Validating the WLS_OSB1 Managed Server

Validate the WLS_OSB Managed Servers.

Verify that the server status is reported as Running in the Admin Console and access URLs to verify status of servers.

Starting and Validating the WLS_OSB2 Managed Server

Configuring Oracle HTTP Server for the WLS_OSBn Managed Servers.

To enable Oracle HTTP Server to route to Oracle Service Bus console and Oracle Service Bus service, set the WebLogicCluster parameter to the list of nodes in the cluster.

Configuring Oracle HTTP Server for the Oracle Service Bus

Validating Access Through Oracle HTTP Server.

Verify that the server status is reported as Running.

Validating the Oracle Service Bus URLs Through the Load Balancer

Enable High Availability for Oracle File and FTP Adapters.

Make Oracle File and FTP Adapters highly available for outbound operations by using the database mutex locking operation.

Enabling High Availability for Oracle DB_ File and FTP Adapters

Backing up the Oracle Service Bus Configuration.

To back up the domain configuration for immediate restoration in case of failures in future procedures.

Backing Up the Configuration

Prerequisites for Extending the Domain to Include Oracle Service Bus

Before you extend the current domain, ensure that your existing deployment meets the necessary prerequisites.

  • Back up the installation. If you have not yet backed up the existing Fusion Middleware Home and domain, Oracle recommends backing it up now.

    To back up the existing Fusion Middleware Home and domain, see Performing Backups and Recoveries in the SOA Enterprise Deployments.

  • Verify that you have installed the Infrastructure and SOA software binaries in an Oracle home on shared storage and they are available from SOAHOST1 and SOAHOST2.

  • If Oracle Service Bus is being configured in the same domain as SOA, then the appropriate SOAINFRA schema (used by the wlsbjmsrpDataSource) is already available. If OSB is being configured in its own domain, then you must run RCU to install the SOAINFRA schema in a supported database by using a different schema prefix than the SOAINFRA schema used by the SOA domain.

  • You have already configured Node Manager, Administration Server, (optionally SOA Servers) and WSM Servers as described in previous chapters to run a SOA system. Optionally, you may have already configured Server migration, transaction logs, coherence, and all other configuration steps for the SOA System.

  • If you haven't done so already, verify that the system clocks on each host computer are synchronized. You can do this by running the date command simultaneously on the hosts in each cluster.

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

Installing Oracle Service Bus Software

You can install Oracle Service Bus in an enterprise deployment by using the OSB Installer.

Starting the Oracle Service Bus Installer

To start the installation program, perform the following steps.

  1. Log in to the target system, SOAHOST1.
  2. Go to the directory in which you downloaded the installation program.
  3. Set the path for the java executable:
    export JAVA_HOME=JAVA_HOME
    export PATH=$JAVA_HOME/bin:$PATH
    

    In this example, replace JAVA_HOME with the value this variable listed in File System and Directory Variables Used in This Guide and entered in the Enterprise Deployment Workbook.

  4. Launch the installation program by entering the following command:
    java -d64 -jar fmw_12.2.1.3.0_osb.jar
    

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

Navigating the OSB Installation Screens

Table 14-2 provides description of each installation program screen.

Table 14-2 OSB Installation Screens

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.

If you plan to extend the existing SOA domain, then install the OSB software into the existing Oracle home, where the SOA software has already been installed.

If you plan to configure OSB in a separate domain, then install the OSB software in the Infrastructure Oracle home.

Installation Type

Use this screen to select the type of installation and consequently, the products and feature sets that you want to install.

For this topology, select Service Bus.

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 following documents in Roadmap for Verifying Your System Environment in Installing and Configuring the Oracle Fusion Middleware Infrastructure.

Installation Summary

Use this screen to verify the installation options that you select. If you want to save these options to a response file, click Save Response File and provide the location and name of the response file. Response files can be used later in a silent installation situation.

For more information about silent or command-line installation, see Using the Oracle Universal Installer in Silent Mode in Installing Software with the Oracle Universal Installer.

Click Install to begin the installation.

Installation Progress

This screen allows you to see the progress of the installation.

Installation Complete

This screen appears when the installation is complete. Review the information on this screen, then click Finish to dismiss the installer.

Installing the Software on Other Host Computers

If you have configured a separate shared storage volume or partition for SOAHOST2, then you must also install the software on SOAHOST2. For more information, see Shared Storage Recommendations When Installing and Configuring an Enterprise Deployment.

Note that the location where you install the Oracle home (which contains the software binaries) varies, depending upon the host. To identify the proper location for your Oracle home directories, refer to the guidelines in File System and Directory Variables Used in This Guide.

Validating the OSB 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 you selected during the installation.

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

ls --format=single-colum ORACLE_HOME/osb/
bin
common
config
doc
financial
L10N
lib
modules
osb
plugins
tools

For more information about the directory structure post the installation process, 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.

Extending the SOA or Infrastructure Domain to Include Oracle Service Bus

You can use the Configuration Wizard to extend the existing enterprise deployment SOA domain with the Oracle Service Bus. You have to perform a series of additional tasks to complete the extension.

Extending the domain involves the following tasks.

Starting the Configuration Wizard

Note:

If you added any customizations directly to the start scripts in the domain, those are overwritten by the configuration wizard. To customize server startup parameters that apply to all servers in a domain, you can create a file called setUserOverridesLate.sh and configure it, 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 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.

To begin domain configuration:

  1. Shut down the Administration Server to prevent any configuration locks, saves, or activations from occurring during the configuration of the domain.
  2. Navigate to the following directory and start the WebLogic Server Configuration Wizard.
    ORACLE_HOME/oracle_common/common/bin
    ./config.sh

Navigating the Configuration Wizard Screens to Extend the Domain with Oracle Service Bus

In this step, you extend the domain created in Extending the Domain with Oracle SOA Suite , and add the Oracle Service Bus software components and Managed Servers.

The steps reflected in this section would be very similar if Oracle Service Bus was extending a domain containing only an Administration Server and a WSM-PM Cluster, but some of the options, libraries, and components shown in the screens could vary.

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

Extending the Domain with Static Clusters

Follow the instructions in this section to extend the domain for Oracle Service Bus, 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 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 that Update Domain Using Product Templates is selected, then select the following templates:

  • Oracle Service Bus - 12.2.1.3.0 [osb]

    The following additional templates should already be selected, because they were used to create the initial domain:

    • Oracle SOA Suite-12.2.1.3.0 [soa] (if you are extending a SOA domain)

    • Oracle Enterprise Manager - 12.2.1.3.0 [em]

    • Oracle WSM Policy Manager - 12.2.1.3.0 [oracle_common]

    • Oracle JRF - 12.2.1.3.0 [oracle_common]

    • WebLogic Coherence Cluster Extension - 12.2.1.3.0 [wlserver]

    The ODSI XQuery 2004 Components - 12.1.3.0 [oracle_common] template is also automatically selected when you select Oracle Service Bus template.

    Note:

    There is no 12.2.1.3.0 template for ODSI. The 12.1.3.0 template works for your 12.2.1 configuration.

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 that the Vendor is Oracle and the 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 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 OSB JMS Reporting Provider component schema.

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

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

These values are required when connecting to Oracle 11g databases but optional when connecting to Oracle database 12c and higher. If you are using an Oracle 12c database, the ONS list is automatically provided from the database to the driver.

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 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 7   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/OSB_Cluster/jms. Shared location is required to resume JMS and JTA in a failover scenario.

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

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

  2. Click Add to create a new Managed Server, and name it WLS_OSB2.

    Tip:

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

  3. Use the information in Table 14-3 to fill in the rest of the columns for each Managed Server.

  4. Select OSB-MGD-SVRS-ONLY as the server group for the OSB Servers. Deselect OSB-MGD-SVRS-COMBINED that is selected by default.

  5. Click Next.

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

Table 14-3 Configuring the Oracle Service Bus Managed Servers in the Configuration Wizard

Name Listen Address Listen Port SSL Listen Port SSL Enabled Server Groups

WLS_SOA1

SOAHOST1

8001

n/a

No

SOA-MGD-SVRS-ONLY

WLS_SOA2

SOAHOST2

8001

n/a

No

SOA-MGD-SVRS-ONLY

WLS_WSM1

SOAHOST1

7010

n/a

No

JRF-MAN-SVR

WSMPM-MAN-SVR

WLS_WSM2

SOAHOST2

7010

n/a

No

JRF-MAN-SVR

WSMPM-MAN-SVR

WLS_OSB1

SOAHOST1

8011

n/a

No

OSB-MGD-SVRS-ONLY

WLS_OSB2

SOAHOST2

8011

n/a

No

OSB-MGD-SVRS-ONLY

The WLS_SOA Managed Servers appear if you extend an existing Oracle SOA Suite domain with Oracle Service Bus.

Task 9   Configuring a Cluster

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

You also set the Frontend Host property for the cluster, which ensures that, when necessary, WebLogic Server redirects web services callbacks and other redirects to soa.example.com on the load balancer rather than the address in the HOST header of each request.

For more information about the soa.example.com virtual server address, see Configuring Virtual Hosts on the Hardware Load Balancer.

Use the Clusters screen to create a new cluster:

  1. Click the Add button.

  2. Specify OSB_Cluster in the Cluster Name field.

  3. Specify osb.example.com in the Frontend Host field.

  4. Specify 80 as the Frontend HTTP Port and 443 as the Frontend HTTPS port.

  5. 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 10   Assigning Server Templates

Click Next to continue.

Task 11   Configuring Dynamic Servers

Click Next to continue.

Task 12   Assigning Managed Servers to the Cluster

On the Assign Servers to Clusters screen, assign servers to clusters as follows:

Note that the WLS_SOA Managed Servers appear only if you extend an existing Oracle SOA Suite domain with Oracle Service Bus.

  • SOA_Cluster (If you are extending a SOA domain):

    • WLS_SOA1

    • WLS_SOA2

  • WSM-PM_Cluster:

    • WLS_WSM1

    • WLS_WSM2

  • OSB_Cluster:

    • WLS_OSB1

    • WLS_OSB2

Click Next.

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

Task 13   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 14   Verifying the Existing Machines

Confirm that the following entries appear:

Name Node Manager Listen Address

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

ADMINVHN

Leave all other fields to their default values.

Click Next.

Task 15   Assigning Servers to Machines

On the Assign Servers to Machines screen, assign servers to machines as follows:

  • ADMINHOST:

    • AdminServer

  • SOAHOST1

    • WLS_SOA1 (if extending a SOA domain)

    • WLS_WSM1

    • WLS_OSB1

  • SOAHOST2:

    • WLS_SOA2 (if extending a SOA domain)

    • WLS_WSM2

    • WLS_OSB2

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

Task 16   Configuring Virtual Targets

Click Next.

Task 17   Configuring Partitions

Click Next.

Task 18   Reviewing Your Configuration Specifications and Configuring the Domain

The Configuration Summary screen contains the 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, 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 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 Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control.

Click Finish to dismiss the Configuration Wizard.

Task 20   Start the Administration Server

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

After you have completed extending the domain with static clusters, go to Propagating the Extended Domain to the Domain Directories and Machines.

Extending the Domain with Dynamic Clusters

Follow the instructions in this section to extend the domain for Oracle Service Bus, with dynamic 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 Service Bus-12.2.1.3.0 [osb]

    The following additional templates should already be selected, because they were used to create the initial domain:

    • Oracle SOA Suite-12.2.1.3.0 [soa] (if you are extending a SOA domain)

    • Oracle Enterprise Manager-12.2.1.3.0 [em]

    • Oracle JRF-12.2.1.3.0 [oracle_common]

    • Oracle WSM Policy Manager-12.2.1.3.0 [oracle_common]

    • WebLogic Coherence Cluster Extension-12.2.1.3.0 [wlserver]

    The ODSI XQuery 2004 Components - 12.1.3.0 [oracle_common] template is also automatically selected when you select Oracle Service Bus template.

    Note:

    There is no 12.2.1.3.0 template for ODSI. The 12.1.3.0 template works for your 12.2.1 configuration.

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 that the Vendor is Oracle and the 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 4   Specifying JDBC Component Schema Information

On the JDBC Component Schema screen, select OSB JMS Reporting Provider component schema.

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

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

These values are required when connecting to Oracle 11g databases but optional when connecting to Oracle database 12c and higher. If you are using an Oracle 12c database, the ONS list is automatically provided from the database to the driver.

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 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 7   Selecting Advanced Configuration

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

Note:

JMS 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 JMS File Stores in Task 3, "Configuring High Availability Options", you have to select the File Stores option 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 8   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".

Static Managed Server definitions are not needed for dynamic cluster configurations. To remove the default Managed Server, complete the following steps:
  1. Delete the default Managed Server.

  2. Click Next to proceed to the next screen.

Task 9   Configuring a Cluster

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

You also set the Frontend Host property for the cluster, which ensures that, when necessary, WebLogic Server redirects web services callbacks and other redirects to soa.example.com on the load balancer rather than the address in the HOST header of each request.

For more information about the soa.example.com virtual server address, see Configuring Virtual Hosts on the Hardware Load Balancer.

Use the Clusters screen to create a new cluster:

  1. Click the Add button.

  2. Specify OSB_Cluster in the Cluster Name field.

  3. Specify osb.example.com in the Frontend Host field.

  4. Specify 80 as the Frontend HTTP Port and 443 as the Frontend HTTPS port.

  5. From the Dynamic Server Groups drop-down list, select OSB-DYN-CLUSTER-ONLY.

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 10   Assigning Server Templates

Use the Server Templates screen to configure the template:

  1. Verify that osb-server-template is selected in the Name field.

  2. Specify 8010 in the Listen Port field.

  3. Leave the Enable SSL option unchecked.

  4. Click Next.

Task 11   Configuring Dynamic Servers

Use the Dynamic Clusters screen to configure the required clusters:

  1. Specify OSB_Cluster in the Cluster Name field.

  2. Specify WLS_OSB in the Server Name Prefix field.

  3. From the Server Template drop-down list, select osb-server-template.

  4. Specify 2 in the Dynamic Cluster Size field.

  5. Specify SOAHOST* in the Machine Name Match Expression field and select Calculated Machine Names.

    Note:

    The dynamic cluster Calculated Machine Names and Machine Name Match Expression attributes control how server instances in a dynamic cluster are assigned to a machine. If the Calculated Machine Names attribute is set to False, the dynamic servers are not assigned to a machine. If the Calculated Machine Names attribute is set to True, the Machine Name Match Expression attribute is used to select the set of machines that is used for the dynamic servers. If the Machine Name Match Expression attribute is not set, all the machines in the domain are selected. Assignments are made by using a round robin algorithm.

    To make things easier regardless of your actual physical hostname, Oracle recommends that you use SOAHOSTn as your WebLogic machine names, where n is a sequential number. This is explained in Task 18, "Creating Machines" of configuring the infrastructure domain. This convention makes it easy for dynamic clusters to determine where to start each cluster member. If you want to follow this convention, in the Machine Match Expression field, enter SOAHOST*.

    If you do not adopt this convention, the cluster members are started on each machine that you define in Task 18, "Creating Machines", including that of ADMINHOST. This situation is undesirable as you would end up with two cluster members that run on the same physical server but are attached to two different domain homes.

  6. Select the Calculated Listen Ports and Dynamic Cluster fields.

    Note:

    Dynamic clusters with the Calculated Listen Port option selected have incremental port numbers for each dynamic managed server that is created automatically: dynamic server 1 will use Listen Port+1, dynamic server 2 will use Listen Port+2.

    Since the Listen Port configured is 8010 and calculated ports is checked, OSB dynamic servers use the following port numbers:

    • WLS_OSB1 server listens in 8011 port

    • WLS_OSB2 server listens in 8012 port

  7. Click Next.

Note:

The Configuration Wizard does not allow you to specify a specific listen address for dynamic servers. For information about setting a specific listen address for WebLogic servers that are members of a dynamic cluster, see Configuring Listen Addresses in Dynamic Cluster Server Templates.

Task 12   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 13   Verifying the Existing Machines

Confirm that the following entries appear:

Name Node Manager Listen Address

SOAHOST1

SOAHOST1

SOAHOST2

SOAHOST2

ADMINHOST

ADMINVHN

Leave all other fields to their default values.

Click Next.

Task 14   Assigning Servers to Machines

Click Next.

Task 15   Configuring Virtual Targets

Click Next.

Task 16   Configuring Partitions

Click Next.

Task 17   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 , 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 18   Writing Down Your Domain Home and Administration Server URL

The Configuration Success screen shows the following items about the domain 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 Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control.

Click Finish to dismiss the Configuration Wizard.

Task 19   Start the Administration Server

If the Admin Server was running during the domain extension process, restart the server before you continue to ensure that the changes that you have made to the domain have been applied.

Note:

When you configure OSB as a dynamic cluster, you have to activate the cluster leasing that is needed for OSB singleton applications (that is Aggregator) correctly. By default, the leasing configuration is not performed by the Configuration Wizard for the dynamic cluster. Therefore, if you start the OSB managed servers before you configure the leasing to OSB_Cluster, you see messages such as the following in the logs:

<Warning> <oracle.osb.statistics.statistics> <OSB-473015> <As Automatic Service Migration enabled in Domain, selection of Aggregation Server delayed till Aggregator Singleton is activated. This may happen either during start of all managed servers or migration of Aggregator Singleton due to failure of managed server where it is activated. If this message did not stop after sometime, check managed servers are running. If not, contact Oracle Support.>
<Error> <oracle.osb.statistics.statistics> <OSB-473003> <Aggregation Server Not Available. Aggregator stub was null>
<Error> <oracle.osb.statistics.statistics> <OSB-473003> <Aggregation Server Not Available. Failed to get remote aggregator

After you complete the leasing configuration for the cluster, these messages disappear. The configuration of the leasing is performed later. See Verifying the Appropriate Targeting and Configuration for OSB Singleton Services.

Propagating the Extended Domain to the Domain Directories and Machines

After you have extended the domain with the OSB instances, and you have restarted the Administration Server on SOAHOST1, you must then propagate the domain changes to the domain directories and systems.

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

Refer to the following sections for more information.

Summary of the Tasks Required to Propagate the Changes to the Other Domain Directories and Machines

Table 14-4 summarizes the steps required to propagate the changes to all the domain directories and systems.

Table 14-4 Summary of Tasks Required to Propagate the Domain Chanegs to Domain Directories and Machines

Task Description More Information

Pack up the Extended Domain on SOAHOST1

Use the pack command to create a new template jar file that contains the new OSB Servers configuration.

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

Packing Up the Extended Domain on SOAHOST1

Unpack the Domain in the Managed Servers Directory on SOAHOST1

Unpack the template jar file in the Managed Servers directory on SOAHOST1 local storage.

Unpacking the Domain in the Managed Servers Domain Directory on SOAHOST1

Unpack the Domain on SOAHOST2

Unpack the template jar file in the Managed Servers directory on the SOAHOST2 local storage.

Unpacking the Domain on SOAHOST2

Starting and Validating the WLS_OSB1 Managed Server

After you extend the domain, restart the Administration Server, and propagate the domain to the other hosts, use the following procedure to start the WLS_OSB1 server and validate if the server is configured successfully:

Starting the WLS_OSB1 Managed Server
  1. Enter the following URL into a browser to display the Fusion Middleware Control login screen:
    http://ADMINVHN:7001/em
    

    Note:

    If you have already configured web tier, use http://admin.example.com/console.

  2. Log in to Fusion Middleware Control by 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_OSB1 Managed Server, and click Start Up on the Oracle WebLogic Server toolbar.

    Note:

    OSB 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 OSB servers are started.

  5. When the startup operation is complete, navigate to the Domain home page and verify that the WLS_OSB1 Managed Server is up and running.
Adding the MiddlewareAdministrators Role to the Enterprise Deployment Administration Group

Before you validate the Oracle Service Bus configuration on the WLS_OSB1 Managed Server, add the Oracle Service Bus MiddlewareAdministrators administration role to the enterprise deployment administration group (SOA Administrators) and add the IntegrationAdministrators group in the external LDAP directory.

To perform this task, refer to Configuring Roles for Administration of Oracle SOA Suite Products.

Validating the Managed Server

After you add the MiddlewareAdministrator role to the SOA Administrators group, you can validate the configuration of the Oracle Service Bus software on the WLS_OSB1 Managed Server as follows:

  1. Use your web browser to navigate to the following URL:
    http://SOAHOST1:8011/sbinspection.wsil

    Replace SOAHOST1 with the value of this variable in the Enterprise Deployment Workbook. For more information about the physical IP (IP) and virtual IP (VIP) addresses required for the Administration server and each of the managed servers, see Physical and Virtual IP Addresses Required by the Enterprise Topology.

  2. Log in by using the enterprise deployment administration user (SOA Administrators).

    With the default installation, this should result in the following HTTP response to the Web services call:

    <ins:inspection xmlns:ins="http://schemas.xmlsoap.org/ws/2001/10/inspection/"/>
    

Starting and Validating the WLS_OSB2 Managed Server

Follow similar steps as in the previous section for WLS_OSB2:

  1. Log in to Fusion Middleware Control by using the Administration Server credentials.
  2. In the Target Navigation pane, expand the domain to view the Managed Servers in the domain.
  3. Select only the WLS_OSB2 Managed Server, and click Start Up on the Oracle WebLogic Server tool bar.
  4. When the startup operation is complete, navigate to the Domain home page and verify that the WLS_OSB2 Managed Server is up and running. Access the equivalent URLs for the WLS_OSB2:

    For static clusters:

    http://SOAHOST2:8011/sbinspection.wsil

    For dynamic clusters:

    http://SOAHOST2:8012/sbinspection.wsil
  5. Verify the correct deployment of the Oracle Service Bus console to the Administration Server by accessing the following URL:
    http://ADMINVHN:7001/servicebus/

Verifying the Appropriate Targeting and Configuration for OSB Singleton Services

Oracle Service Bus uses some singleton services that should run only in one of the WLS servers in the OSB_Cluster. These singleton services are:
  • Aggregator

  • SLA Alert Manager

  • Poller transports (Email, File, FTP, and SFTP pollers)

This is controlled by the global property OSB Singleton Components Automatic Migration, which exposed in Enterprise Manager, in the Global Settings section of the Service Bus configuration. When activated, it uses the WebLogic Singleton Framework to guarantee the singleton behavior and automatic migration of these OSB singleton services.

Similar to server or service migration, a database leasing is a requirement for the OSB Singleton Components Automatic Migration to work properly. The OSB Singleton Components Automatic Migration checkbox does not automatically define the leasing datasource, it just marks these applications as singletons.

This OSB global property is checked by default for the SOA Enterprise Deployment topologies, which are:
  • Dynamic clusters

  • Static clusters where Automatic Service Migration was enabled by using the Configuration Wizard.

For static OSB clusters where Automatic Service Migration is not enabled by using the Configuration Wizard, and you define it manually afterward, you must also check OSB Singleton Components Automatic Migration manually.

To guarantee the appropriate Singleton behavior for OSB:

Verify that the OSB Singleton Components Automatic Migration option is checked:

  1. Log in to Oracle Fusion Middleware Enterprise Manager. In a browser, go to the following URL:
    http://ADMINVHN:7001/em
    
  2. Navigate to SOA > service-bus (AdminServer) > Global Settings.

    The property OSB Singleton Components Automatic Migration must be checked by default for the SOA EDG topologies.

Verify that the appropriate targeting exists by following these steps:

  1. In a browser, go to the following URL:
    http://ADMINVHN:7001/console
    
  2. Log in as the administrator.

  3. In the Domain Structure tree on the left, click Deployments.

  4. Find the Aggregator Singleton Marker Application. Verify that the value in the Targets column of the table is OSB_Cluster.

Verify that the leasing datasource is defined for the OSB_Cluster:

  1. In a browser, go to the following URL:
    http://ADMINVHN:7001/console
  2. Log in as the administrator.

  3. In the Domain Structure, expand Environment, and then click Clusters.

  4. Click OSB_Cluster.

  5. Click the Migration tab.

  6. Verify that Database is selected in the Migration Basis drop-down menu and the leasing datasource Data Source For Automatic Migration is defined.

    If database leasing is not defined (for example, for dynamic clusters, database leasing is not defined by default), see Setting the Leasing Mechanism and Data Source for an Enterprise Deployment Cluster for instructions to configure it.

Note:

It is assumed that at the time of configuring the domain with the Config Wizard, for static clusters, the Enable Automatic Service Migration option is checked in the High Availability Options screen. If the option is not checked, Service Bus Domain Singleton Marker Application is targeted directly to the first server of the cluster WLS_OSB1 and this server hosts the singleton services. Oracle does not recommend this approach because it does not provide automatic migration of the OSB singletons services in case of a failure.

Modifying the Upload and Stage Directories to an Absolute Path

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. See Modifying the Upload and Stage Directories to an Absolute Path in an Enterprise Deployment.

Configuring Listen Addresses When Using Dynamic Clusters

The default configuration for dynamic managed servers in dynamic clusters is to listen on all available network interfaces. In most cases, the default configuration may be undesirable. To limit the listen address to a specific address when you use dynamic clusters, see Configuring Listen Addresses in Dynamic Cluster Server Templates. Reverify the test URLs that are provided in the previous sections after you change the listen address and restart the clustered managed servers.

Configuring the Web Tier for the Extended Domain

It is important to understand how to configure the web server instances on the web tier so that they route requests for both public and internal URLs to the proper clusters in the extended domain.

Note:

If you add custom endpoints in OSB, make sure that you add the appropriate URLs to the OHS or the OTD configuration. For example, if you add a proxy service such as RNOWOSB/, you must add the following URL to osb_vh.conf for the services to be available through OHS/OTD:
<Location /RNOWOSB>
 	WLSRequest ON
	WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
	WLProxySSL ON
	WLProxySSLPassThrough ON
</Location>
Alternatively, Oracle recommends that you create a unique root context in the web tier and use that as the base path for all proxy services. For example, if the root context is /endpoint, the configured endpoint URL is osb.example.com/endpoint/RNOWOSB/. This avoids the need to alter the web tier config file with every new endpoint and also benefits from a single resource configuration for SSO, if OAM is used.
<Location /endpoint>
	WLSRequest ON
	WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
	WLProxySSL ON
	WLProxySSLPassThrough ON
</Location>

Configuring Oracle Traffic Director for the Extended Domain

If you have configured Oracle Traffic Director for this domain, you might be required to add additional origin server pools, virtual servers, or routes to the Oracle Traffic Director configuration. To understand the Oracle Traffic Director requirements for each Oracle Fusion Middleware product and for instructions on adding origin server pools, virtual servers, and routes, see Defining Oracle Traffic Director Virtual Servers for an Enterprise Deployment.

Configuring Oracle HTTP Server for the Oracle Service Bus

To configure the Oracle HTTP Server instances in the web tier so that they route requests correctly to the Oracle Service Bus cluster, use the following procedure to create an additional Oracle HTTP Server configuration file that creates and defines the parameters of the soa.example.com virtual server.

This procedure assumes that you have performed the Oracle HTTP Server configuration tasks described in Configuring Oracle HTTP Server for Administration and Oracle Web Services Manager.

To set the parameter:

  1. 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
    
  2. Create a new configuration file, called osb_vh.conf file, and add the following <VirtualHost> directive to the file:
    <VirtualHost WEBHOST1:7777>
        ServerName https://osb.example.com:443
        ServerAdmin you@your.address
        RewriteEngine On
        RewriteOptions inherit
    </VirtualHost>
    
  3. Add the following directives inside the <VirtualHost> tags:

    Note:

    Configure the port numbers appropriately, as assigned for your static or dynamic cluster. Dynamic clusters with the Calculate Listen Port option selected have incremental port numbers for each dynamic managed server that you create.

    The WebLogicCluster directive needs only a sufficient number of redundant server:port combinations to guarantee an initial contact in case of a partial outage. The actual total list of cluster members is retrieved automatically on the first contact with any given node.

    <Location /sbinspection.wsil>
      WLSRequest ON
      WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
      WLProxySSL ON
      WLProxySSLPassThrough ON
    </Location>
    
    <Location /sbresource>
      WLSRequest ON
      WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
      WLProxySSL ON
      WLProxySSLPassThrough ON
    </Location>
    
    <Location /osb>
      WLSRequest ON
      WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
      WLProxySSL ON
      WLProxySSLPassThrough ON
    </Location>
    
    <Location /alsb>
      WLSRequest ON
      WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
      WLProxySSL ON
      WLProxySSLPassThrough ON
    </Location>
    
    <Location /default>
      WLSRequest ON
      WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
      WLProxySSL ON
      WLProxySSLPassThrough ON
    </Location>

    The osb_vh.conf file appears as it does in Example 14-1.

  4. Add the following entry to the admin_vh.conf file within the <VirtualHost> tags:
    <Location /sbconsole >
      WLSRequest ON
      WebLogicHost ADMINVHN
      WeblogicPort 7001
    </Location>
    
    <Location /servicebus>
      WLSRequest ON
      WebLogicHost ADMINVHN
      WeblogicPort 7001
    </Location>
    
    <Location /lwpfconsole >
      WLSRequest ON
      WebLogicHost ADMINVHN
      WeblogicPort 7001
    </Location>
    

    The admin_vh.conf file appears as it does in Example 14-2.

  5. Log in to WEBHOST2 and copy the osb_vh.conf file and the admin_vh.conf file to the configuration directory for the second Oracle HTTP Server instance (ohs2):
    WEB_DOMAIN_HOME/config/fmwconfig/components/OHS/ohs2/moduleconf
    
  6. Edit the osb_vh.conf file and change any references to WEBHOST1 to WEBHOST2 in the <VirtualHost> directives.
  7. Restart Oracle HTTP Servers on WEBHOST1 and WEBHOST2.

Example 14-1 osb_vh.conf file

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

<Location /sbinspection.wsil >
  WLSRequest ON
  WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
  WLProxySSL ON
  WLProxySSLPassThrough ON
</Location>

<Location /sbresource >
  WLSRequest ON
  WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
  WLProxySSL ON
  WLProxySSLPassThrough ON
</Location>

<Location /osb >
  WLSRequest ON
  WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
  WLProxySSL ON
  WLProxySSLPassThrough ON
</Location>

<Location /alsb >
  WLSRequest ON
  WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
  WLProxySSL ON
  WLProxySSLPassThrough ON
</Location>

<Location /default>
 WLSRequest ON
 WebLogicCluster SOAHOST1:8011,SOAHOST2:8011
 WLProxySSL ON
 WLProxySSLPassThrough ON
 </Location>
 </VirtualHost>

Example 14-2 admin_vh.conf file

# The admin URLs should only be accessible via the admin virtual host 

<VirtualHost WEBHOST1:7777>
    ServerName admin.example.com:80
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

# Admin Server and EM
<Location /console>
    WLSRequest ON
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /consolehelp>
    WLSRequest ON
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /em>
    WLSRequest ON
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /sbconsole >
    WLSRequest ON
    WebLogicHost ADMINVHN
    WeblogicPort 7001
</Location>

<Location /servicebus>
    WLSRequest ON
    WebLogicHost ADMINVHN
    WeblogicPort 7001
   </Location>

<Location /lwpfconsole >
  WLSRequest ON
  WebLogicHost ADMINVHN
  WeblogicPort 7001
</Location>
</VirtualHost>

Configuring the WebLogic Proxy Plug-In

Set the WebLogic Plug-In Enabled parameter for the OSB cluster.

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

    The Configuration: General tab is displayed.

  5. Scroll down to the Advanced section and expand it.
  6. Click Lock and Edit.
  7. Set the WebLogic Plug-In Enabled to yes.
  8. Click Save, and then click Activate Changes. Restart the OSB servers for the changes to be effective.

Validating the Oracle Service Bus URLs Through the Load Balancer

Verify the Oracle Service Bus URLs to ensure that appropriate routing and failover is working from the hardware load balancer to the HTTP Server instances to the Oracle Service Bus components.

To verify the URLs:

  1. While WLS_OSB1 is running, stop WLS_OSB2 by using the Oracle WebLogic Server Administration Console.
  2. Access the following URL and verify the HTTP response as indicated in Starting and Validating the WLS_OSB2 Managed Server:
    https://osb.example.com/sbinspection.wsil
  3. Start WLS_OSB2 from the Oracle WebLogic Server Administration Console.
  4. Stop WLS_OSB1 from the Oracle WebLogic Server Administration Console.
  5. Access the same URL and verify the HTTP response as indicated in Starting and Validating the WLS_OSB2 Managed Server.

    Note:

    Since a front end URL has been set for the OSB_Cluster, the requests to the urls result in a reroute to the LBR, but in all cases it should suffice to verify the appropriate mount points and correct failover in Oracle HTTP Server.

  6. Verify this URL by using your load balancer address:
    https://osb.example.com:443/sbinspection.wsil
    

    You can also verify http://admin.example.com:80/servicebus.

Post-Configuration Tasks for Oracle Service Bus

After you install and configure Oracle Service Bus in the domain, consider the following post-configuration tasks.

Enabling High Availability for Oracle DB, File and FTP Adapters

Oracle SOA Suite and Oracle Service Bus use the same database, file, and FTP JCA adapters.

You create the required database schemas for these adapters when you use the Oracle Repository Creation Utility before you configure Oracle SOA Suite. The database adapter does not require any configuration at the WebLogic Server resource level.

The required configuration for the other adapters is described in section Enabling High Availability for Oracle File and FTP Adapters.

If you configure Oracle Service Bus as an extension of a SOA domain, you do not need to add to the configuration already performed for the adapters.

If you deploy Oracle Service Bus as an extension to an Oracle Fusion Middleware Infrastructure domain (without Oracle SOA Suite), perform the steps as described in Enabling High Availability for Oracle File and FTP Adapters.

Considerations for Poller Transports

OSB provides native Poller transports that are not transactional in nature. These transports poll a source directory, FTP server, or email server for new messages and push the processing payloads to the required JMS destinations. Email, File, FTP, and SFTP fall in this category.

Poll-based transports use a transport poller thread that is pinned to a Managed Server. All Managed Servers in a cluster can process the pertaining payload, but only one server can poll for the message. To protect the system from outages, the poller thread must be configured as an application-scoped singleton and the involved JMS destinations must be highly available.

The Poller Transport singleton behavior, similar to the other OSB singleton services, is controlled by the property OSB Singleton Components Automatic Migration. This property is checked by default for the SOA Enterprise Deployment topologies, which are:
  • Dynamic clusters.

  • Static clusters where Automatic Service Migration was enabled by using the Configuration Wizard.

When checked, an application-scoped singleton for the poller is deployed to the cluster. Similar to server or service migration, a leasing is a requirement for the OSB Singleton Components Automatic Migration to work properly. This checkbox does not automatically define the leasing datasource, it just marks the applications as singletons. If the leasing datasource is not already configured and this checkbox is activated, ensure that you configure the leasing datasource. See Verifying the Appropriate Targeting and Configuration for OSB Singleton Services.

You can verify that your poller transport is configured as an application-scoped singleton for OSB Singleton Components Automatic Migration by following these steps:

  1. In a browser, go to the following URL:
    http://ADMINVHN:7001/console
  2. Log in as the administrator.

  3. In the Domain Structure tree on the left, click Deployments..

  4. Verify that there is a singleton application deployed for the transport poller. Example: SB_FILE_Proxy_*

  5. Verify that the value in the Targets column of the table is OSB_Cluster.

For the high availability of this transport services, it is required to protect the pertaining JMS destinations (used for payload processing) from failures. This can be done by using different alternatives:
  • When you use WebLogic static clusters:
    • Configure Automatic Service Migration (ASM) for the OSB migratable targets. In the case of a failure, the affected JMS and JTA services are migrated automatically to another member of the cluster. Oracle recommends this approach.

    • Configure Whole Server Migration for the OSB cluster. In this case, the entire WLS server, including its JMS and JTA services, are restarted in another node.

  • When you use dynamic clusters, the pertaining services are handled and migrated, as required, by the dynamic cluster infrastructure, if the migration policy of the persistent stores is configured to the required value.

Configuring Specific Oracle Service Bus Services for an Enterprise Deployment

To use IBM WebSphere MQ Connection resources and the MQ Transport in Oracle Service Bus, you must add the MQ client libraries to the classpath.

One option is to copy the required MQ libraries to the following location in the domain home directory:

DOMAIN_HOME/lib

This is also the case for custom assertions and JBoss integration services:

  • When you use JBoss initial context factory classes, make sure to include the class and any dependent classes in the DOMAIN_HOME/lib directory.

  • Similarly, for custom assertions, create the required jar file with the assertion and add the jar to the DOMAIN_HOME/lib directory.

Further, to use these services in an enterprise deployment, you must add the required libraries to the Administration Server domain home (ASERVER_HOME/lib) and the Managed Server domain home (MSERVER_HOME/lib).

For more information about configuring and developing services for Oracle Service Bus, see Getting Started with the Oracle Service Bus Console in Developing Services with Oracle Service Bus.

Enabling SSL Communication Between the Oracle Service Bus Servers and the Hardware Load Balancer

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

This allows Oracle Service Bus Web services and other services to invoke callbacks and other communications with the front-end, secure URL. See Enabling SSL Communication Between the Middle Tier and the Hardware Load Balancer.

Enabling JDBC Persistent Stores for Oracle Service Bus

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.

Follow these guidelines to ensure that you use JDBC stores, when you use static or dynamic clusters:

  • For static clusters

    If you have made the following selections in the High Availability Options screen, as recommended in this guide for static clusters, then JDBC persistent stores are already configured for both JMS and TLOGS:

    • Set JTA Transaction Log Persistence to JDBC TLog Store.

    • Set JMS Server Persistence to JMS JDBC Store.

  • For dynamic clusters

    You can configure only JMS Server persistence for dynamic clusters by using the Configuration Wizard. JTA Transaction Logs Persistence must be configure manually, if required. If you have made the following selections in the High Availability Options screen, as recommended in this guide for dynamic clusters, then JDBC persistent stores are already configured for JMS.

    • Set JMS Server Persistence to JMS JDBC Store.

    • Verify that JTA Transaction Log Persistence is set to Default Persistent Store.

    Additional steps are needed to configure JTA Transaction Log with JDBC store. See Roadmap for Configuring a JDBC Persistent Store for TLOGs.

In case you did not select JDBC for JMS and TLOGS persistent in the High Availability Options screen, you can still configure JDBC stores manually in a post step. For specific instructions to configure them manually, see Using JDBC Persistent Stores for TLOGs and JMS in an Enterprise Deployment.

Note:

The High Availability Options screen appears during the Configuration Wizard session for the first time when you create a cluster that uses Automatic Service Migration or JDBC stores or both. All subsequent clusters that are added to the domain by using the Configuration Wizard, automatically apply the selected HA options.

Enabling Automatic Service Migration for Oracle Service Bus

To ensure that Oracle Service Bus (OSB) is configured for high availability, you must configure the OSB Servers for service migration.

Follow these guidelines to ensure that you provide the required high availability for Weblogic services when you use static or dynamic clusters:

  • For static clusters

    Automatic Service Migration is already configured if you select Enable Automatic Service Migration with Database Basis in the High Availability Options screen.

    The Database Leasing is already configured and the migratable targets are created with the appropriate policies for the cluster. If you have implemented these settings, validate the configuration, as described in Validating Automatic Service Migration in Static Clusters.

    In case you do not select this option during the Configuration Wizard session, you can configure automatic migration manually in a post step. For instructions to complete the steps for static clusters, see Configuring Automatic Service Migration in an Enterprise Deployment.

  • For dynamic clusters

    You cannot configure Service Migration for dynamic clusters by using the Configuration Wizard, it needs to be configured manually. The following steps are needed:

    • Configure the database leasing for the cluster.

    • Set the appropriate migration policies for JTA Service and JMS Persistent Stores.

    For instructions to complete the steps for dynamic clusters, see Configuring Automatic Service Migration in an Enterprise Deployment.

Note:

The High Availability Options screen appears during the Configuration Wizard session for the first time when you create a cluster that uses Automatic Service Migration or JDBC stores or both. All subsequent clusters that are added to the domain by using the Configuration Wizard, automatically apply the selected HA options.

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.