This chapter describes the procedures for extending the domain to include Oracle Service Bus.
This chapter contains the following sections:
Section 11.1, "Overview of Adding Oracle Service Bus to a SOA Domain"
Section 11.2, "Installing the Required Oracle Service Bus Binaries"
Section 11.3, "Verifying Virtual IP Addresses for OSB Managed Servers"
Section 11.5, "Disabling Host Name Verification for the WLS_OSBn Managed Servers"
Section 11.6, "Configuring Oracle Coherence for the Oracle Service Bus Result Cache"
Section 11.7, "Configuring a Default Persistence Store for Transaction Recovery"
Section 11.10, "Configuring Network Channels for HTTP and T3 Clients via EoIB"
Section 11.12, "Configuring Oracle Traffic Director with the Extended Domain"
Section 11.13, "Setting the Front End HTTP Host and Port for OSB_Cluster"
Section 11.14, "Validating Access Through Oracle Traffic Director and Load Balancer"
Section 11.15, "High Availability for Oracle DB, File and FTP Adapters"
Section 11.16, "Configuring Server Migration for the WLS_OSB Servers"
Section 11.17, "Backing Up the Oracle Service Bus Configuration"
This section provides an overview of adding Oracle Service bus to an SOA domain. Table 11-1 lists and describes to high-level steps for extending a SOA domain for Oracle Service Bus.
Table 11-1 Steps for Extending a SOA Domain to Include Oracle Service Bus
| Step | Description | More Information |
|---|---|---|
|
Install Oracle Service Bus Binaries. |
Install Oracle Fusion Middleware Oracle Service Bus on SOAHOST1. |
Section 11.2, "Installing the Required Oracle Service Bus Binaries" |
|
Enable VIP5 on SOAHOST1 and VIP6 on SOAHOST2 |
Enable a virtual IP mapping for each of these hostnames on the two SOA Machines. |
Section 11.3, "Verifying Virtual IP Addresses for OSB Managed Servers" |
|
Run the Configuration Wizard to Extend the Domain |
Extend the SOA domain to contain Oracle Service Bus components |
|
|
Disable Host Name Verification for the WLS_OSBn Managed Server |
If you have not set up the appropriate certificates for hostname verification between the Administration Server, Managed Servers, and Node Manager, disable host name verification. |
Section 11.5, "Disabling Host Name Verification for the WLS_OSBn Managed Servers" |
|
Configure Oracle Coherence for the Oracle Service Bus Result Cache |
Use unicast communication for the Oracle Service Bus result cache. |
Section 11.6, "Configuring Oracle Coherence for the Oracle Service Bus Result Cache" |
|
Configure a Default Persistence Store for Transaction Recovery |
To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to a server and its backup servers. |
Section 11.7, "Configuring a Default Persistence Store for Transaction Recovery" |
|
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 using the pack and unpack commands. |
|
|
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. |
|
|
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. |
|
|
Configuring Oracle Traffic Director for the WLS_OSBn Managed Servers |
To enable Oracle Traffic Director to route to Oracle Service Bus console and Oracle Service Bus service, set the WebLogicCluster parameter to the list of nodes in the cluster. |
Section 11.12, "Configuring Oracle Traffic Director with the Extended Domain" |
|
Set the Front End HTTP Host and Port for OSB_Cluster |
Set the front end HTTP host and port for Oracle WebLogic Server cluster. |
Section 11.13, "Setting the Front End HTTP Host and Port for OSB_Cluster" |
|
Validating Access |
Verify that the server status is reported as Running. |
Section 11.14, "Validating Access Through Oracle Traffic Director and Load Balancer" |
|
Enable High Availability for Oracle File and FTP Adapters |
Make Oracle File and FTP Adapters highly available for outbound operations using the database mutex locking operation. |
Section 11.15, "High Availability for Oracle DB, File and FTP Adapters" |
|
Configure Server Migration for the WLS_OSB Servers |
The high availability architecture for an Oracle Service Bus system uses server migration to protect some singleton services against failures. |
Section 11.16, "Configuring Server Migration for the WLS_OSB Servers" |
|
Backing Up the Configuration |
Back up the domain configuration. This backup is for the purpose of an having an immediate restore available in the event of failures in future procedures. |
Section 11.17, "Backing Up the Oracle Service Bus Configuration" |
Before extending the current domain, ensure that your existing deployment meets the following 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. For more information see Section 14.8, "Backing Up the Oracle SOA Enterprise Deployment."
You have installed WL_HOME and MW_HOME (binaries) that contain Oracle Fusion Middleware SOA on a shared storage and they are available from SOAHOST1 and SOAHOST2.
You have already configured Node Manager, Admin Server, SOA Servers and WSM Servers as described in previous chapters to run a SOA system. You have already configured Server migration, transaction logs, coherence, and all other configuration steps for the SOA System.
To install Oracle Fusion Middleware Oracle Service Bus on SOAHOST1. A single installation is used for all the nodes in the domain. You install on SOAHOST1, and SOAHOST2 mounts the same mount point.
On Linux platforms, if the /etc/oraInst.loc file exists, check that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory. If the /etc/oraInst.loc file does not exist, skip this step.
Start the installer for Oracle Service Bus from the installation media:
./runInstaller
When the installer prompts you for a JRE/JDK location, enter the Oracle SDK location created in the Oracle WebLogic Server installation, for example, ORACLE_BASE/product/fmw/jrockit-jdk1.6.0_version. For more information, see Section 8.2.2, "Installing WebLogic Server Using the Generic Installer."
In the Welcome screen, click Next.
Note:
Since SOAHOST1 already contains the SOA Suite Oracle Home, an Oracle Inventory should already be present and used by this installation. In this case, the Specify Inventory Directory screen should not appear
In the Install Software Updates screen, choose Skip Software Updates and click Next.
In the Installation Location screen, provide the installation location for Oracle Service Bus. Select the previously installed Oracle Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name (osb), and click Next.
In the Installation Type, select Custom, and click Next.
In the Components to Install screen, DESELECT Oracle Service Bus IDE and Oracle Service Bus Examples, and click Next.
In the Prerequisite Checks screen, verify that all checks complete successfully, and click OK.
In the Product Home Location specify the WebLogic Server installation directory previously installed and click Next.
In the Installation Summary screen, click Install.
In the Installation Complete screen, click Finish.
Validate the installation by verifying that the following directories appear in the ORACLE_HOME_OSB directory (under osb) after installing Oracle Service Bus:
3rdparty
bin
cfgtoollogs
clone
common
config
dbscripts
diagnostics
financial
harvester
install
inventory
L10N
lib
modules
OPatch
osb
oui
soa
tools
The SOA domain uses virtual hostnames as the listen addresses for the Oracle Service Bus managed servers: SOAHOST1-PRIV-V2,SOAHOST2-PRIV-V2, SOAHOST1VHN2, SOAHOST2VHN2. Enable a virtual IP mapping for each of these hostnames on the two SOA Machines, VIP5 on SOAHOST1 and VIP6 on SOAHOST2, and correctly resolve the virtual hostnames in the network system that the topology uses (either by DNS Server, hosts resolution).
These virtual IPs and VHNs are required to enable server migration for the Oracle Service Bus Servers. Server migration must be configured for the Oracle Service Bus Cluster for high availability purposes. See Chapter 13, "Configure Server Migration for an Exalogic Enterprise Deployment" for more details on configuring server migration for the Oracle Service Bus servers.
Note:
Verify that you can ping the virtual hostnames from both WEBHOST1 and WEBHOST2 and from each one of the compute nodes in the topology as the chapter Chapter 3, "Configuring the Network for an Exalogic Enterprise Deployment" describes.
In this step, you extend the domain created in Chapter 9, "Extending the Domain for SOA Components" to contain Oracle Service Bus components. The steps reflected in this section would be very similar if Oracle Service Bus was extending a domain containing only an Admin Server and a WSM-PM Cluster, but some of the options, libraries and components shown in the screens could vary.
To extend the domain for Oracle Service Bus:
Change directory to the location of the Configuration Wizard. This is within the Oracle Service Bus directory. (All database instances should be up.)
cd ORACLE_COMMON_HOME/common/bin
Start the Configuration Wizard.
./config.sh
In the Welcome screen, select Extend an existing WebLogic domain, and click Next.
In the WebLogic Domain Directory screen, select the WebLogic domain directory:
ASERVER_HOME
Click Next.
In the Select Extension Source screen, select Extend my domain automatically to support the following added products and select the following products (the components required by Oracle SOA and Oracle WSM Policy Manager should already be selected and grayed out):
Oracle Service Bus OWSM Extension - 11.1.1.7 [osb]
Oracle Service Bus - 11.1.1.7 [osb]
WebLogic Advance Web Services JAX-RPC Extension
In the Configure JDBC Components Schema screen, do the following:
Select the OSB JMS reporting Provider schema.
For the Oracle RAC configuration for component schemas, select Convert to GridLink
Note:
If additional data sources, such as SOAINFRA, the server migration/leasing data source or OPSS data source, were configured for the domain, they appear here. You can select Next without modifying and testing them because the expectation is that they have already been verified and are working data sources.
Click Next. The Configure Gridlink RAC Component Schema screen appears.
In the Configure Gridlink RAC Component Schema screen accept the values for the data sources that are already present in the domain and click Next.
In the Test JDBC Component Schema screen, verify that the Oracle Service Bus JMS reporting datasources are correctly verified and click Next.
In the Select Optional Configuration screen, select the following:
JMS Distributed Destinations
Managed Servers, Clusters, and Machines
Deployments and Services
JMS File Store
Click Next.
In the Select JMS Distributed Destination Type screen leave the pre-existing JMS System Resources as they are and Select UDD from the drop down list for WseeJMSModule and JmsResources.
Click Next.
In the Configure Managed Servers screen, add the required managed servers for Oracle Service Bus.
Select the automatically created server and click Rename to change the name to WLS_OSB1.
Click Add to add another new server and enter WLS_OSB2 as the server name.
Give servers WLS_OSB1 and WLS_OSB2 the attributes listed in Table 11-2.
In the end, the list of managed servers should match Table 11-2.
Click Next.
| Name | Listen Address | Listen Port | SSL Listen Port | SSL Enabled |
|---|---|---|---|---|
|
WLS_SOA1(*) |
SOAHOST1-PRIV_V1 |
8001 |
n/a |
No |
|
WLS_SOA2(*) |
SOAHOST2-PRIV_V1 |
8001 |
n/a |
No |
|
WLS_WSM1 |
SOAHOST1-PRIV |
7010 |
n/a |
No |
|
WLS_WSM2 |
SOAHOST2-PRIV |
7010 |
n/a |
No |
|
WLS_OSB1 |
SOAHOST1-PRIV-V2 |
8011 |
n/a |
No |
|
WLS_OSB2 |
SOAHOST2-PRIV-V2 |
8011 |
n/a |
No |
In the Configure Clusters screen, add the Oracle Service Bus cluster (leave the present cluster as they are):
| Name | Cluster Messaging Mode | Multicast Address | Multicast Port | Cluster Address |
|---|---|---|---|---|
|
SOA_Cluster(*) |
unicast |
n/a |
n/a |
SOAHOST1-PRIV-V1:8001,SOAHOST2-PRIV-V1:8001 Note: The cluster address should be changed to the appropriate EoIB addresses if external clients are going to access the SOA servers. |
|
WSM-PM_Cluster |
unicast |
n/a |
n/a |
Leave it empty. |
|
OSB_Cluster |
unicast |
n/a |
n/a |
SOAHOST1-PRIV-V2:8011, SOAHOST2-PRIV-V2:8011 |
(*) - if you are extending a SOA domain
Click Next.
Note:
For asynch request/response interactions over direct binding, the SOA composites must provide their jndi provider URL for the invoked service to look up the beans for callback.
If soa-infra configuration properties are not specified, but the WebLogic Server Cluster address is specified, the cluster address from the JNDI provider URL is used. This cluster address can be a single DNS name which maps to the clustered servers' IP addresses or a comma separated list of server ip:port. Alternatively, the soa-infra configuration property JndiProviderURL/SecureJndiProviderURL can be used for the same purpose if explicitly set by users.
In the Assign Servers to Clusters screen, assign servers to clusters as follows:
SOA_Cluster - 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.
Confirm that the following entries appear:
| Name | Node Manager Listen Address |
|---|---|
|
SOAHOST1 |
SOAHOST1-PRIV |
|
SOAHOST2 |
SOAHOST2-PRIV |
|
ADMINHOST |
localhost |
Leave all other fields to their default values.
Click Next.
In the Assign Servers to Machines screen, assign servers to machines as follows:
ADMINHOST:
AdminServer
SOAHOST1
WLS_SOA1 (if extending a SOA domain)
WLS_WSM1
WLS_OSB1
SOAHOST2:
WLS_SOA2 (if extending a SOA domain)
WLS_WSM2
WLS_OSB2
Click Next.
In the Target Deployments to Clusters or Servers screen, ensure the following targets:
Target usermessagingserver and usermessagingdriver-email only to SOA_Cluster. (The usermessaging-xmpp, usermessaging-smpp, and usermessaging-voicexml applications are optional.)
Target the oracle.sdp.* and oracle.soa.* libraries only to SOA_Cluster.
Target the oracle.rules.* library only to AdminServer and SOA_Cluster.
Target the wsm-pm application only to WSM-PM_Cluster.
Target all Transport Provider Deployments to both the OSB_Cluster and the AdminServer.
Target the oracle.bpm.* library only to the SOA_Cluster.
Click Next.
In the Target Services to Clusters or Servers screen:
Target mds-owsm only to WSM-PM_Cluster and AdminServer.
Target mds-soa to SOA_Cluster.
Click Next.
In the Configure JMS File Stores screen, enter the shared directory location specified for your JMS stores as recommended in Section 4.2, "Shared Storage Recommendations for Exalogic Enterprise Deployments." For example:
ASERVER_HOME/jms
Select Direct-write policy for all stores.
Click Next.
In the Configuration Summary screen click Extend.
In the Extending Domain screen, click Done.
Restart the Administration Server for this configuration to take effect.
For the Exalogic enterprise deployment described in this guide, you set up the appropriate certificates to authenticate the different nodes with the Administration Server after you have completed the procedures to extend the domain for Oracle SOA Suite. You must disable the host name verification for the WLS_OSB1 and WLS_OSB2 managed servers to avoid errors when managing the different WebLogic Server instances. For more information, see Section 8.4.8, "Disabling Host Name Verification."
You enable host name verification again once the Exalogic enterprise deployment topology configuration is complete. For more information, see Section 13.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1."
By default, result caching uses multicast communication. Oracle recommends using unicast communication for the Oracle Service Bus result cache. Additionally, Oracle recommends separating port ranges for Coherence clusters used by different products. The ports for the Oracle Service Bus result cache Coherence cluster should be different from the Coherence cluster used for SOA.
To enable unicast for the Oracle Service Bus result cache Coherence infrastructure:
Log into Oracle WebLogic Server Administration Console. In the Change Center, click Lock & Edit.
In the Domain Structure window, expand the Environment node.
Click Servers.
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.
Click the Server Start tab.
Enter the following for WLS_OSB1 on a single line, no carriage returns:
-DOSB.coherence.localhost=SOAHOST1-PRIV-V2 -DOSB.coherence.localport=7890 -DOSB.coherence.wka1=SOAHOST1-PRIV-V2 -OSB.coherence.wka1.port=7890 -DOSB.coherence.wka2=SOAHOST2-PRIV-V2 -DOSB.coherence.wka2.port=7890
For WLS_OSB2, enter the following on a single line, no carriage returns:
-DOSB.coherence.localhost=SOAHOST2-PRIV-V2 -DOSB.coherence.localport=7890 -DOSB.coherence.wka1=SOAHOST1-PRIV-V2 -OSB.coherence.wka1.port=7890 -DOSB.coherence.wka2=SOAHOST2-PRIV-V2 -DOSB.coherence.wka2.port=7890
Note:
There should be no breaks in lines between the different -D parameters. Do not copy or paste the text from above to your Administration Console's arguments text field. This may result in HTML tags being inserted in the Java arguments. The text should not contain other text characters than those included the example above.
Save and activate the changes. You must restart Oracle Service Bus servers for these changes take effect.
Note:
The Coherence cluster used for Oracle Service Bus' result cache is configured above using port 7890. This port can be changed by specifying a different port (for example, 8089) with the following startup parameters:
-Dtangosol.coherence.wkan.port -Dtangosol.coherence.localport
For more information about Coherence Clusters see the Oracle Coherence Developer's Guide.
Ensure that these variables are passed to the managed server correctly by checking the server's output log.
Failure of the Oracle Coherence framework can prevent the result caching from working.
Each server has a transaction log that stores information about committed transactions that are coordinated by the server that may not have been completed. The WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to a server and its backup servers.
To set the location for the default persistence stores for:
Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node and then click the Servers node.
The Summary of Servers page appears.
Click the WLS_OSB1 server (represented as a hyperlink) in Name column of the table.
The settings page for the selected server appears and defaults to the Configuration tab.
Click the Services tab.
In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files.
The directory structure of the path is as follows:
ASERVER_HOME/tlogs
Click Save and Active Changes.
Repeat steps 3 through 6 for WLS_OSB2.
Note:
To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both WLS_OSB1 and WLS_OSB2 must be able to access this directory. This directory must also exist before you restart the servers.
Oracle Service Bus requires some updates to the WebLogic Server start scripts. Propagate these changes using the pack and unpack commands.
Create a backup copy of the managed server domain directory and the managed server applications directory.
To propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory:
Run the pack command on SOAHOST1 to create a template pack:
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ASERVER_HOME -template=soadomaintemplateExtOSB.jar -template_name=soa_domain_templateExtOSB
Run the unpack command on SOAHOST1 to unpack the propagated template to the domain directory of the managed server:
./unpack.sh -domain=MSERVER_HOME -overwrite_domain=true -template=soadomaintemplateExtOSB.jar -app_dir=APP_DIR
Note:
The -overwrite_domain option in the unpack command, allows unpacking a managed server template into an existing domain and existing applications directories. For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory they must be restored after this unpack operation.
Run the unpack command on SOAHOST2 to unpack the propagated template:
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=MSERVER_HOME/ -overwrite_domain=true -template=soadomaintemplateExtOSB.jar -app_dir=APP_DIR
Note:
The configuration steps provided in this Exalogic enterprise deployment topology are documented with the assumption that a private (per node) domain directory is used for each managed server.
Since Oracle Service Bus servers extend an already existing domain it is assumed that the Administration Server and respective Node Managers are already running in SOAHOST1 and SOAHOST2.
To start the added the WLS_OSB servers:
Log into the Oracle WebLogic Server Administration Console at:
http://ADMINVHN:7001/console
In the Domain Structure window, expand the Environment node, then select Servers.
The Summary of Servers page appears.
Click the Control tab.
Select WLS_OSB1 from the Servers column of the table.
Click Start. Wait for the server to come up and check that its status is reported as RUNNING in the Administration Console.
Repeat steps 2 through 5 for WLS_OSB2.
If your HTTP clients and T3 clients use the 10 Gb Ethernet network, you must create additional network channels for the OSB Servers on SOAHOST1 and SOAHOST2. For more information, for more details
To create a HTTP network channel for a Managed Server, such as WLS_OSB1, complete the following steps:
In your browser, go to http://ADMINVHN1:7001/console and log in as the administrator.
If you have not already done so, click Lock & Edit in the Change Center.
In the left pane of the Console, expand Environment, and then Servers to open the Summary of Servers page.
In the Servers table, click WLS_OSB1 to open the Settings for WLS_OSB1 page.
Select Protocols, Channels, then New.
Enter OSB_HTTPChannel as the name of the new network channel and select http as the protocol, then click Next.
Enter the following information in the Network Channel Addressing page:
Listen address: SOAHOST1VHN2
Note:
This address is the virtual host name assigned to the WLS_OSB1 Server using the BOND1 interface.
Listen port: 8011
External Listen Address: osb.mycompany.com
Note:
This address is the DNS name to access the application on the server.
External Listen Port: 80
Click Next. Select Enabled then HTTP Enabled for This Protocol in the Network Channel Properties page.
Select Finish.
To activate these changes, click Activate Changes in the Change Center of the Administration Console,.
You must repeat the preceding steps to create a network channel for the WLS_OSB2 Managed Servers on SOAHOST2 and enter the required properties that describes.
Note:
In this example, IP addresses are used as listen addresses. However, you can specify host names if they resolve to their corresponding floating IP addresses.
| Managed Server | Name | Protocol | Listen Address | Listen Port | External Listen Address |
|---|---|---|---|---|---|
|
WLS_OSB1 |
OSB_HTTPChannel |
HTTP |
SOAHOST1VHN2 |
|
|
|
WLS_OSB2 |
OSB_HTTPChannel |
HTTP |
SOAHOST2VHN2 |
|
|
To create a T3 network channel for the SOA Managed Servers, complete the following steps:
In your browser, go to http://ADMINVHN1:7001/console and log in as the administrator.
If you have not already done so, click Lock & Edit in the Change Center.
In the left pane of the Console, expand Environment and then Servers to open the Summary of Servers page.
In the Servers table, click WLS_OSB1 to open the Settings for WLS_OSB1 page.
Select Protocols, Channels, then New.
Enter OSB_T3Channel as the name of the new network channel and select T3 as the protocol, then click Next.
Enter the following information in the Network Channel Addressing page:
Listen address: SOAHOST1VHN2
Note:
This address is the virtual host name assigned to the WLS_OSB1 Server using the BOND1 interface.
Listen port: 8013
Note:
Remove the default external Listen port value.
Click Next. Select Enabled then HTTP Enabled for This Protocol in the Network Channel Properties page.
Select Finish.
To activate these changes, click Activate Changes in the Change Center of the Administration Console,.
You must repeat the preceding steps to create a network channel for the WLS_OSB2 Managed Servers on SOAHOST2 and enter the required properties that Table 11-5 describes.
Validate the WLS_OSB managed servers using the Oracle WebLogic Server Administration Console and by accessing URLs.
To validate the WLS_OSB managed server:
Verify that the server status is reported as Running in the Admin Console. If the server is shown as Starting or Resuming, wait for the server status to change to Started. If another status is reported (such as Admin or Failed), check the server output log files for errors. See Section 14.14, "Troubleshooting the Topology in an Enterprise Deployment." for possible causes.
Access the following URL to verify status of WLS_OSB1:
http://SOAHOST1-PRIV-V2:8011/sbinspection.wsil
With the default installation, this should be the HTTP response:
Access the following URL:
http://SOAHOST1-PRIV-V2:8011/alsb/ws/_async/AsyncResponseServiceJms?WSDL
With the default installation, this should be the HTTP response:
Access the equivalent URLs for:
http://SOAHOST2-PRIV-V2:8011/
Verify also the correct deployment of the Oracle Service Bus console to the Administration Server by accessing the following URL:
http://ADMINHOSTVHN:7001/sbconsole/
The Oracle Service Bus console should appear with no errors.
After you create the appropriate channels, configure Oracle Traffic Director to route to the OSB servers for the appropriate URIs.
Note:
(You created a virtual server for osb.mycompany.com and osbinternal.mycompany.com in Chapter 7, "Installing and Configuring Oracle Traffic Director for an Exalogic Enterprise Deployment."
To create the required virtual server routes:
Log into the Administration Console using the following URL:
https://OTDADMINVHN.mycompany.com:8989
Click the Configurations in the upper left corner of the page to view a list of available configurations.Select the configuration that you want to configure routes for.
In the Navigation pane, expand Virtual Servers and the osb.mycompany.com virtual server. Select Routes to open a list of routes that are defined for the virtual server.
To enable Oracle HTTP Server to route to the SOA_Cluster:
Click New Route to open the New Route dialog box.
In the Step 1: Route Properties screen, enter osb-route in the Name field.
In the Origin Server Pool drop-down menu, select osb-pool and click Next.
In the Step2: Condition Information screen, select the variable $uri from the Variable/Function drop-down list. Select = ~ in the Operator drop-down menu, then enter /sbinspection.wsil in the Value field.
Note:
You cannot use a joiner (and/or) for the first expression in the sequence.
Select OK then select Plus to add the next expression.
Note:
You can now select the joiner 'or'.
Select uri as the Variable /Function, = ~ as the Operator, and inspection.wsil as the Value. Select OK.
Add the rest of the conditions using the information in the preceding step.
Click Next and then Create Route.
Your route appears on the Routes and a Deployment Pending message appears in the main pane.
You can deploy the updated configuration immediately by selecting Deploy Changes, or wait until you make changes. See the topic Section 7.8, "Deploying the Configuration and Testing the Virtual Server Addresses" for more information.
To create a new route in the osbinternal.mycompany.com virtual server, repeat the preceding steps and conditions. You can copy the rules from the first route that you created. osb-pool
Set the front end HTTP host and port for Oracle WebLogic Server cluster using the WebLogic Server Administration Console.
To set the front end host and port:
In the WebLogic Server Administration Console, in the Change Center section, click Lock & Edit.
In the left pane, select Environment and then Clusters.
Select the OSB_Cluster.
Select HTTP.
Set the values for the following:
Frontend Host: osb.mycompany.com
Frontend HTTP Port: 80
Frontend HTTPS Port: 443
Note:
Verify that the preceding address is correct and available, that is, that the load balancing router is up. An incorrect value, such as http:// in the address or a trailing "/" in the host name, may prevent SOA from being accessible, even if you use virtual IPs to access it.
Click Save.
To activate the changes, click Activate Changes in the Change Center section of the Administration Console.
Restart managed servers WLS_OSB1 and WLS_OSB2.
Since you have already set the cluster address for the OSB_Cluster, the Oracle Service Bus URLs can only be verified once Oracle HTTP Server has been configured to route the Oracle Service Bus context URLs to the WebLogic Servers. Verify the URLs to ensure that appropriate routing and failover is working from the HTTP Server to the Oracle Service Bus components.
For information on configuring system access through the load balancer, see Section 3.3, "Configuring the Load Balancers."
To verify the URLs:
While WLS_OSB1 is running, stop WLS_OSB2 using the Oracle WebLogic Server Administration Console.
Access webhost2-priv-v1:7777/sbinspection.wsil and verify the HTTP response as indicated in Section 11.11, "Validating the WLS_OSB Managed Servers."
Start WLS_OSB2 from the Oracle WebLogic Server Administration Console.
Stop WLS_OSB1 from the Oracle WebLogic Server Administration Console.
Access osb.mycompany.com:7777/sbinspection.wsil and verify the HTTP response as indicated in section Section 11.11, "Validating the WLS_OSB Managed Servers."
Note:
Because the webhostn-priv-v1 addresses are internal to the Exalogic rack, you must start a browser from a node within the rack itself.
Note:
Since a front end URL has been set for the OSB_Cluster, the requests to the urls result in a re-route to the load balancer, but in all cases it should suffice to verify the appropriate mount points and correct failover in Oracle Traffic Director.
Verify this URLs using your load balancer address:
http://osb.mycompany.com:80/sbinspection.wsil
Oracle SOA Suite and Oracle Service Bus use the same database and File and FTP JCA adapters. You create the required database schemas for these adapters when you use the Oracle Repository Creation Utility for SOA. The required configuration for the adapters is described in section Section 9.12.1, "Enabling High Availability for Oracle File and FTP Adapters." The DB adapter does not require any configuration at the WebLogic Server resource level. If you are configuring 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 are deploying Oracle Service Bus as an extension to a WSM-PM and Admin Server domain, do the following:
Run RCU to seed the Oracle Service Bus database with the required adapter schemas (Select SOA Infrastructure, and SOA and BAM Infrastructure in RCU).
Perform the steps in, and the steps reflected in Section 9.12.1, "Enabling High Availability for Oracle File and FTP Adapters."
For more information on configuring server migration, Chapter 13, "Configure Server Migration for an Exalogic Enterprise Deployment."
Back up the Oracle Service Bus configuration. For more information, see Section 14.8, "Backing Up the Oracle SOA Enterprise Deployment."