This chapter describes how to use the Configuration Wizard to extend the domain to include SOA components. You created in the domain in Chapter 4, "Creating a Domain."
Important:
Oracle strongly recommends that you read the release notes for any additional installation and deployment considerations prior to starting the setup process.Note:
Follow the steps in this chapter only if you want to run SOA components on SOAHOST1 and SOAHOST2. If you do not want to run SOA components in your WebCenter topology, you can skip this chapter.This chapter contains the following sections:
Section 5.1, "Installing Oracle Fusion Middleware for SOA Home"
Section 5.2, "Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2"
Section 5.5, "Configuring Oracle Coherence for Deploying Composites"
Section 5.6, "Setting Connection Destination Identifiers for B2B Queues"
Section 5.7, "Disabling Host Name Verification for the WLS_SOAn Managed Server"
Section 5.9, "Propagating the Domain Changes to the Managed Server Domain Directory"
Section 5.10, "Starting the WLS_SOA1 Managed Server on SOAHOST1"
Section 5.12, "Propagating the Domain Configuration to SOAHOST2 Using the unpack Utility"
Section 5.14, "Starting and Validating the WLS_SOA2 Managed Server"
Section 5.15, "Configuring Oracle HTTP Server for the WLS_SOAn Managed Servers"
Section 5.16, "Validating Access Through Oracle HTTP Server"
Section 5.18, "Setting the WLS Cluster address for Direct Binding/RMI invocations to composites"
Section 5.20, "Configuring a Default Persistence Store for Transaction Recovery"
Section 5.21, "Enabling High Availability for Oracle File and FTP Adapters"
You must install Oracle Fusion Middleware for SOA on both SOAHOST1 and SOAHOST2. These nodes will run managed servers configured with SOA components.
Start the installer for Oracle Fusion Middleware for SOA.
SOAHOST1> 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, MW_HOME/jrockit_160_<version>.
In the Welcome screen, click Next.
In the Prerequisite Check screen, verify that the checks complete successfully, and click Next.
Specify the installation location. Select the previously installed Middleware Home from the drop-down list. For the Oracle Home directory, enter the directory name (soa).
Click Next.
In the Installation Summary screen, click Install.
In the Installation Complete screen, click Finish.
The SOA domain uses virtual hostnames as the listen addresses for the SOA managed servers. You must enable A VIP mapping each of these hostnames on the two SOA Machines, (VIP2 on SOAHOST1 and VIP3 on SOAHOST2), and must be correctly resolve the virtual hostnames in the network system used by the topology (either by DNS Server, hosts resolution).
To enable the VIP, follow the steps described in Section 4.3, "Enabling VIP1 in SOAHOST1."These VIPs and VHNs are required to enable server migration for the SOA Servers. Server migration must be configured for the SOA System for high availability purposes. Refer to Chapter 9, "Server Migration" of the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for more details on configuring server migration for the SOA servers.
In this step, you extend the domain created in Chapter 4, "Creating a Domain" to contain SOA components. In this section we are assuming that the SOA deployment uses the same database service (wcedg.mycompany.com) as the WebCenter deployment. However, a deployment may choose to use a different database service specifically for SOA such as soaedg.mycompany.com.
Note:
You must back up the current domain before extending the domain. You may use the backup to recover in case any errors were made in the domain extension. See Oracle Fusion Middleware Administrator's Guide.Note:
Oracle SOA uses Quartz to maintain its jobs and schedules in the database. The system clocks for the SOA WebLogic cluster must be synchronized to enable Quartz jobs to run correctly across the cluster.Change directory to the location of the Configuration Wizard. This is within the SOA home directory. (It is recommended that all database instances should be up.)
SOAHOST1> cd ORACLE_HOME/common/bin
Start the Configuration Wizard.
SOAHOST1> ./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 (ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>
), and click Next.
In the Select Extension Source screen, do the following:
Select Extend my domain automatically to support the following added products.
Select the following products:
Oracle SOA Suite 11.1.1.0
The following products should already be selected, and grayed out. They were selected when you created in domain in Section 4.4, "Running the Configuration Wizard on SOAHOST1 to Create a Domain."
Basic WebLogic Server Domain
Oracle Enterprise Manager
Oracle WSM Policy Manager
Oracle JRF
Click Next.
If you get a "Conflict Detected" message that Oracle JRF is already defined in the domain, select the Keep Existing Component option and click OK.
In the Configure JDBC Component Schema screen (Figure 5-1), do the following:
Select the SOA Infrastructure, User Messaging Service, and SOA MDS Schema rows in the table.
Select Configure selected component schemas as RAC multi data source schemas in the next panel.
Click Next.
Figure 5-1 Configure JDBC Component Schema Screen
In the Configure RAC Multi Data Source Component Schema screen (Figure 5-2), do the following:
Select SOA Infrastructure.
Enter values for the following fields, specifying the connect information for the RAC database that was seeded with RCU.
Driver: Select Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11.
Service Name: Enter the service name of the database; for example, wcedg.mycompany.com
.
Username: Enter the complete user name (including prefix) for the schemas. The user names shown in Figure 5-2 assume that soedg
was used as prefix for schema creation from RCU.
Password: Enter the password to use to access the schemas.
Click Add and enter the details for the first RAC instance.
Repeat for each RAC instance.
Deselect SOA Infrastructure.
Select User Messaging Service.
Repeat steps b, c, and d for the User Messaging Schema.
Deselect User Messaging Service.
Select SOA MDS Schema.
Repeat steps b, c, and d for the SOA MDS Schema.
Leave the OWSM MDS Schema information as it is.
Click Next
Figure 5-2 Configure RAC Multi Data Source Component Schema Screen
In the Test JDBC Data Sources screen, the connections should be tested automatically. The Status column displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen and correct your entries.
Click Next when all the connections are successful.
In the Select Optional Configuration screen, select the following:
JMS Distributed Destinations
Managed Servers, Clusters, and Machines
Deployments and Services
Click Next.
In the Select JMS Distributed Destination Type screen:
Select UDD from the drop down list for UMSJMSystemResource.
Select UDD from the drop down list for SOAJMSModule.
In the Configure Managed Servers screen, add the required managed servers.
A server called soa_server1
is created automatically. Rename this to WLS_SOA1 and give it the attributes listed in Table 5-1. Then, add a new server called WLS_SOA2. The WLS_WSM1 and WLS_WSM2 managed servers should already be present because they are part of the domain that you are extending. In the end, the list of managed servers should match that in Table 5-1.
Name | Listen Address | Listen Port | SSL Listen Port | SSL Enabled |
---|---|---|---|---|
WLS_SOA1 |
SOAHOST1VHN1 |
8001 |
n/a |
No |
WLS_SOA2 |
SOAHOST2VHN1 |
8001 |
n/a |
No |
WLS_WSM1 |
SOAHOST1 |
7010 |
n/a |
No |
WLS_WSM2 |
SOAHOST2 |
7010 |
n/a |
No |
Click Next.
In the Configure Clusters screen, add the following clusters:
Name | Cluster Messaging Mode | Multicast Address | Multicast Port | Cluster Address |
---|---|---|---|---|
SOA_Cluster |
unicast |
n/a |
n/a |
Leave it empty. |
WSM-PM_Cluster |
unicast |
n/a |
n/a |
Leave it empty. |
Click Next.
In the Assign Servers to Clusters screen, assign servers to clusters as follows:
SOA_Cluster:
WLS_SOA1
WLS_SOA2
WSM-PM_Cluster:
WLS_WSM1
WLS_WSM2
Click Next.
In the Configure Machines screen, do the following:
Delete the LocalMachine that appears by default.
Click the Unix Machine tab. The following entries appear (listed in Table 5-3):
Leave all other fields to their default values.
Click Next.
In the Assign Servers to Machines screen, assign servers to machines as follows:
ADMINHOST:
AdminServer
SOAHOST1:
WLS_SOA1
WLS_WSM1
SOAHOST2:
WLS_SOA2
WLS_WSM2
Click Next.
In the Target Deployments to Clusters or Servers screen, ensure the following targets:
usermessagingserver and usermessagingdriver-email should be targeted only to SOA_Cluster. (The usermessaging-xmpp, usermessaging-smpp, and usermessaging-voicexml applications are optional.)
The oracle.sdp.*, and oracle.soa.* libraries should be targeted only to SOA_Cluster.
The oracle.rules.* library should be targeted only to Admin Server and SOA_Cluster.
The wsm-pm application should be targeted only to WSM-PM_Cluster.
The oracle.wsm.seedpolicies library should be targeted only to WSM-PM_Cluster.
Target this library to the SOA_Cluster also only if you are planning to deploy WebLogic WebServices to it.
Click Next.
In the Target Services to Clusters or Servers screen, ensure the following targets:
Target JOC Startup Class and JOC Shutdown Class only to WSM-PM_Cluster.
Target mds-owsm, mds-owsm-rac0, and mds-owsm-rac1 to both WSM-PM_Cluster and AdminServer.
Click Next.
In the Configuration Summary screen click Extend.
Note:
Click OK to dismiss the warning dialog about the domain configuration ports conflicting with the host ports. This warning appears because of the existing WSM-PM installation.In the Extending Domain screen, click Done.
You must restart the Administration Server for this configuration to take effect.
Restart the Administration Server using the procedure in Section 4.5, "Creating boot.properties for the Administration Server on SOAHOST1."
Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication instead in SOA enterprise deployments. Use unicast if you disable multicast communication for security reasons.
Note:
An incorrect configuration of the Oracle Coherence framework that is used for deployment may prevent the SOA system from starting. The deployment framework must be properly customized for the network environment on which the SOA system runs. Oracle recommends the following configuration described in this section.Enabling Communication for Deployment Using Unicast Communication
Multicast communication enables Oracle Fusion Middleware SOA to discover all of the members of a cluster to which to it deploys composites dynamically. However, unicast communication does not enable nodes to discover other cluster members in this way. Consequently, you must specify the nodes that belong to the cluster. You do not need to specify all of the nodes of a cluster, however. You need only specify enough nodes so that a new node added to the cluster can discover one of the existing nodes. As a result, when a new node has joined the cluster, it is able to discover all of the other nodes in the cluster. Additionally, in configurations such as SOA enterprise deployments where multiple IPs are available in the same box, you must configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.
Tip:
To guarantee high availability during deployments of SOA composites, specify enough nodes so that at least one of them is running at any given time.Specify the nodes using the tangosol.coherence.wka
<n>
system property, where <n>
is a number between 1 and 9. You can specify up to 9 nodes. Start the numbering at 1. This numbering must be sequential and must not contain gaps. In addition, specify the host name used by Oracle Coherence to create a cluster through the tangosol.coherence.localhost
system property. This local host name should be the virtual host name used by the SOA server as the listener addresses (SOAHOST2VHN1and SOAHOST2VHN1). Set this property by adding the -Dtangosol.coherence.localhost
parameters to the Arguments field of the Oracle WebLogic Server Administration Console's Server Start tab (Figure 5-2).
Note:
SOAHOST1VHN1 is the virtual host name that maps to the virtual IP where WLS_SOA1 listening (in SOAHOST1). SOAHOST2VHN1 is the virtual host name that maps to the virtual IP where WLS_SOA2 is listening (in SOAHOST2).Figure 5-3 Setting the Host Name Using the Start Server Tab of Oracle WebLogic Server Administration Console
To add the host name used by Oracle Coherence, complete these steps:
Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node.
Click Servers. The Summary of Servers page appears.
Click the name of the server (WLS_SOA1 or WLS_SOA2, which are represented as hyperlinks) in Name column of the table. The settings page for the selected server appears.
Click Lock and Edit.
Click the Server Start tab (illustrated in Figure 5-3).
Enter the following for WLS_SOA1 and WLS_SOA2 into the Arguments field.
For WLS_SOA1, enter the following:
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST1VHN1
For WLS_SOA2, enter the following:
-Dtangosol.coherence.wka1=SOAHOST2VHN1 -Dtangosol.coherence.wka2=SOAHOST1VHN1 -Dtangosol.coherence.localhost=SOAHOST2VHN1
Note:
The Coherence cluster used for deployment uses port 8088 by default. This port can be changed by specifying a different port (for example, 8089) with the -Dtangosol.coherence.wkan.port and -Dtangosol.coherence.localport startup parameters. For example:WLS_SOA1 (enter the following into the Arguments field on a single line, without a carriage return):
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST1VHN1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
WLS_SOA2 (enter the following into the Arguments field on a single line, without a carriage return):
-Dtangosol.coherence.wka1=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST2VHN1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
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.Click Save and Activate Changes.
Note:
You must ensure that these variables are passed to the managed server correctly. (They should be reflected in the server's output log.) Failure of the Oracle Coherence framework can prevent the soa-infra application from starting.Note:
The multicast and unicast addresses are different from the ones used by the WebLogic Server cluster for cluster communication. SOA guarantees that composites are deployed to members of a single WebLogic Server cluster even though the communication protocol for the two entities (the WebLogic Server cluster and the groups to which composites are deployed) are different.Oracle B2B uses specific JMS Destination Member calls, and requires setting the Create Destination Identifier (CDI) for these calls to succeed. To set up the CDI:
Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Services node, and then the Messaging node.
Click JMS Modules, and then SOAJMSModule.
Click Lock and Edit.
Click the dist_B2BEventQueue_auto, Configuration, and the General tab, and then click Advanced.
In the Create Destination Identifier field, add the following jndi name for the queue:
jms/b2b/B2BEventQueue
Repeat these steps, creating the following Create Destination Identifiers for the queues listed below:
dist_B2B_OUT_QUEUE_auto : jms/b2b/B2B_OUT_QUEUE
dist_B2B_IN_QUEUE_auto : jms/b2b/B2B_IN_QUEUE
dist_B2BBroadcastTopic_auto : jms/b2b/B2BBroadcastTopic
dist_XmlSchemaChangeNotificationTopic_auto : jms/fabric/XmlSchemaChangeNotificationTopic
Click Save and Active Changes.
This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server (see Chapter 7, "Setting Up Node Manager"). If you have not configured the server certificates, you will receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the Enterprise Deployment topology configuration is complete as described in Chapter 7, "Setting Up Node Manager."
To disable host name verification, complete these steps:
Log in to Oracle WebLogic Server Administration Console.
Click Lock and Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page appears.
Select WLS_SOA1 (represented as a hyperlink) from the Names column of the table. The Settings page appears.
Select the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to None.
Click Save.
Repeat these steps for the WLS_SOA2 managed server.
Save and activate the changes.
To restart the Node Manager on SOAHOST1:
Stop Node Manager by stopping the process associated with it:
If it is running in the foreground in a shell, simply use CTRL+C.
If it is running in the background in the shell, find the associate process and use the kill
command to stop it. For example:
SOAHOST1> ps -ef | grep NodeManager orcl 9139 9120 0 Mar03 pts/6 00:00:00 /bin/sh ./startNodeManager.sh SOAHOST1>kill -9 9139
Start Node Manager:
SOAHOST1> ./startNodeManager.sh
To propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory:
Create a copy of the managed server domain directory and the managed server applications directory.
Run the pack
command on SOAHOST1 to create a template pack using the following commands:
SOAHOST1> cd ORACLE_COMMON_HOME/common/bin SOAHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/admin/<domain_name>/aserver/<domain_name> -template=soadomaintemplateExtSOA.jar -template_name=soa_domain_templateExtSOA
Run the unpack
command on SOAHOST1 to unpack
the propagated template to the domain directory of the managed server using the following command:
SOAHOST1> ./unpack.sh -domain=ORACLE_BASE/admin/<domain_name>/mserver/<domain_name> -overwrite_domain=true -template=soadomaintemplateExtSOA.jar -app_dir=ORACLE_BASE/admin/<domain_name>/mserver/applications
Note:
The-overwrite_domain
option in the unpack command, allows unpacking a managed server template into an existing domain and existing applications directories. For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory, they must be restored after this unpack operation.To start the WLS_SOA1 managed server on SOAHOST1, complete these steps:
Access the Administration Console at http://ADMINVHN:7001/console
.
Click Servers.
Open the Control tab.
Select WLS_SOA1.
Click Start.
Note:
ADMINVHN is the virtual host name that maps to the virtual IP where the Administration Server is listening (in SOAHOST1).To validate the WLS_SOA1 managed server, complete these steps:
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 11.6, "Troubleshooting"for possible causes.
Access http://SOAHOST1VHN1:8001/soa-infra/
to verify status of WLS_SOA1.
Access http://SOAHOST1VHN1:8001/b2bconsole/
to verify status of B2B.
Access http://SOAHOST1VHN1:8001/integration/worklistapp/
to verify status of the worklist application. Before verifying access is granted, ensure that the WLS_WSM1 managed server is up and running.
Note:
Notice that, although the WLS_SOA1 server may be up, some applications may be in a failed state. Therefore, Oracle recommends verifying the URLs above and watch for errors pertaining each individual application in the server's output file.To propagate the domain configuration, complete these steps:
Run the following command on SOAHOST1 to copy the template file created in the previous step to SOAHOST2.
SOAHOST1> cd ORACLE_HOME/common/bin SOAHOST1> scp soadomaintemplateExtSOA.jar oracle@node2:ORACLE_HOME/common/bin
Run the unpack
command on SOAHOST2 to unpack the propagated template.
SOAHOST2> cd ORACLE_HOME/common/bin ./unpack.sh-domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/-template=soadomaintemplateExtSOA.jar -overwrite_domain=true-app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
Note:
The-overwrite_domain
option in the unpack command, allows unpacking a managed server template into an existing domain and existing applications directories. For any file that is overwritten, a backup copy of the original is created. If any modifications had been applied to the start scripts and ear files in the managed server domain directory, they must be restored after this unpack operation.Perform the steps in Section 5.8, "Restarting the Node Manager on SOAHOST1" on SOAHOST2.
Perform these steps to start the WLS_SOA2 managed server and check that it is configured correctly:
Start the WLS_SOA2 managed server using the Administration Console.
Verify that the server status is reported as "Running" in the 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 11.6, "Troubleshooting" for possible causes.
Access http://SOAHOST2VHN1:8001/soa-infra
.
Access http://SOAHOST2VHN1:8001/b2bconsole
to verify status of B2B.
Access http://SOAHOST2VHN1:8001/integration/worklistapp/
to verify status of the worklist application. Before verifying access is granted, ensure that at least one of the managed servers (WLS_WSM1 or WLS_WSM2) is up and running.
Note:
Although the WLS_SOA1 server may be up, some applications may be in a failed state. Therefore, Oracle recommends verifying the URLs above and watch for errors pertaining each individual application in the server's output file.To enable Oracle HTTP Server to route to the SOA_Cluster, which contains the WLS_SOAn managed servers, you must set the WebLogicCluster
parameter to the list of nodes in the cluster.
On WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_BASE/ admin/<instance_name>/config/OHS/<component_name>/mod_wl_ohs.conf file:
# SOA soa-infra app <Location /soa-infra> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # SOA inspection.wsil <Location /inspection.wsil> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # Worklist <Location /integration> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # B2B <Location /b2bconsole> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # UMS prefs <Location /sdpmessaging/userprefs-ui> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # Default to-do taskflow <Location /DefaultToDoTaskFlow> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # Workflow <Location /workflow> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # UMS parlay <Location /sdpmessaging/parlayx> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # UMS WS <Location /ucs/messaging/webservice> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> #Required if attachments are added for workflow tasks <Location /ADFAttachmentHelper> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location> # SOA composer application <Location /soa/composer> SetHandler weblogic-handler WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 WLProxySSL ON WLProxySSLPassThrough ON </Location>
Note:
The entry for/workflow
is optional. It is for workflow tasks associated with ADF task forms. The /workflow
URL itself can be a different value, depending on the form.Restart Oracle HTTP Server on WEBHOST1 and WEBHOST2:
WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1 WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2
The servers specified in the WebLogicCluster
parameter are only important at startup time for the plug-in. The list needs to provide at least one running cluster member for the plug-in to discover other members of the cluster. Note that the listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.
Sample scenarios:
Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member will be discovered on the fly at runtime.
Example 2: You have a three-node cluster but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.
If you list all members of the cluster, then you guarantee you can route to the cluster, assuming at least one member is running when Oracle HTTP Server is started.
For more information on configuring the WebLogic Server plug-in, see the Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server guide.
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 11.6, "Troubleshooting" for possible causes.
Verify that you can access these URLs, where 'webhostN'
specifies the name of each Oracle HTTP Server host (for example, WEBHOST1
, WEBHOST2
):
http://webhostN:7777/soa-infra
http://webhostN:7777/integration/worklistapp
http://webhostN:7777/b2bconsole
http://webhostN:7777/sdpmessaging/userprefs-ui
http://webhostN:7777/soa/composer
Validate SOA_Cluster through both Oracle HTTP Server instances.
Refer to load balancer configuration to access the system through the load balancer.
You must set the frontend HTTP host and port for the Oracle WebLogic Server cluster:
In the WebLogic Server Administration Console, in the Change Center section, click Lock & Edit.
In the left pane, choose Environment in the Domain Structure window and then choose Clusters. The Summary of Clusters page appears.
Select the SOA_Cluster cluster.
Select HTTP.
Set the values for the following:
Frontend Host: wc.mycompany.com
Frontend HTTPS Port: 443
Frontend HTTP Port: 80
Click Save.
To activate the changes, click Activate Changes in the Change Center section of the Administration Console.
Restart the servers to make the Frontend Host directive in the cluster effective.
Note:
When HTTPS is enabled in the load balancer and the load balancer terminates SSL (the SOA servers receive only HTTP requests, not HTTPS), as suggested in this guide, the endpoint protocol for webservices is set tohttp
. Since the load balancer redirects HTTP to HTTPS this causes the following exception when testing webservices fucntionality in Oracle Enterprise Manger Fusion Middleware Control:
(javax.xml.soap.SOAPException: oracle.j2ee.ws.saaj.ContentTypeException)
To resolve this exception, update the URL endpoint:
In the Enterprise Manager Test Page, check Edit Endpoint URL.
Within the endpoint URL page:
Change http
to https
.
Change the default port number (say 80) to SSL port (say 443).
Note:
If you do not set the frontend HTTP host and port, you get the following message when trying to retrieve a document definition XSD from Oracle B2B:An error occured while loading the document definitions. java.lang.IllegalArgumentException: Cluster address must be set when clustering is enabled.
The SOA system calculates the callback URL as follows:
If a request to SOA originates from an external or internal service, then SOA uses the callback URL specified by the client.
If a request to an external or internal asynchronous service originates from SOA, the callback URL is determined using the following method, in decreasing order of preference:
Use callbackServerURL
specified as a binding property for the specific reference. (You can set this when modeling the composite or at runtime using the MBeans). This allows different service calls to have different callback URLs. That is, a callback URL from an external service can be set to be different than one to an internal service In the context of the Enterprise Deployment architecture, typically this will be wc.mycompany.com
(443/https) for external services and wcinternal.mycompany.com
(7777/http) for internal services. At runtime, this property is set using the System MBean Browser, through the corresponding binding mbean. To add a specific URL, add a callbackServerURL
property to its Properties attribute, then invoke the save operation.
Use the callback URL as specified in soa-infra-config.xml. In this case, only one address can be specified. When a mix of both external and internal services can be invoked, this should be set to wc.mycompany.com
(443/https) in the Enterprise Deployment architecture. When only internal services are to be invoked, this can be set to wcinternal.mycompany.com
(7777/http).
Use the callback URL as the frontend host specified in WLS for the SOA_Cluster. In this case, too, only one address can be specified and the recommendation is same as the one for soa-infra-config.xml.
Use the local host name as provided by WLS MBean APIs. This is not recommended in HA environments such as Enterprise Deployment.
When using direct binding composites, you must set the WLS Cluster address for the SOA_Cluster. To set the WLS Cluster address:
In the WebLogic Server Administration Console, in the Change Center section, click Lock & Edit.
In the left pane, choose Environment from the Domain Structure window, and then choose Clusters. The Summary of Clusters page appears.
Select the SOA_Cluster cluster.
In the Configuration, General tab, enter the following in the Cluster Address field:
SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
Click Save.
To activate the changes, click Activate Changes in the Change Center section of the Administration Console.
Restart the servers for the Frontend Host directive to take effect in the cluster.
Note:
For asynch request/response interactions over direct binding, the SOA composites must provide their jndi provider URL for the invoked service to look up the beans for callback.If soa-infra config properties are not specified, but the WLS Cluster address is specified, the cluster address from the JNDI provider URL is used. This cluster address can be a single DNS name which maps to the clustered servers' IP addresses or a comma separated list of server ip:port. Alternatively, the soa-infra config property JndiProviderURL/SecureJndiProviderURL
can be used for the same purpose if explicitly set by users.
Configure the location for all of the persistence stores as a directory that is visible from both nodes. For more information see Section 2.3, "Shared Storage and Recommended Directory Structure." You must then change all of the persistent stores to use this shared base directory as follows:
Log into the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Services node and then click the Persistence Stores node. The Summary of Persistence Stores page appears.
Select the persistence store (represented as a hyperlink) from the Name column of the table. The Settings page for the persistence store appear.
In the Configuration tab, enter the location on a persistent storage solution (such as NAS or SAN) that is available to other servers in the cluster in the Directory field. Specifying this location enables pending JMS messages to be sent. The location should follow the following directory structure:
ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/jms
Note:
Both WLS_SOA1 and WLS_SOA2 must be able to access this directory. This directory must also exist before you restart the server.Click Save and activate changes.
Restart the servers to make the change in the persistent stores effective.
Each server has a transaction log that stores information about committed transactions that are coordinated by the server that may not have been completed. The WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to a server and its backup servers.
Note:
Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).To set the location for the default persistence store, complete these steps:
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 name of the server (represented as a hyperlink) in Name column of the table. The settings page for the selected server appears and defaults to the Configuration tab.
Click the Services tab.
In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:
ORACLE_BASE/admin/<domain_name>/<soa_cluster_name>/tlogs
Click Save.
Note:
To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both WLS_SOA1 and WLS_SOA2 must be able to access this directory. This directory must also exist before you restart the server.The Oracle File and FTP Adapters enable a BPEL process or an Oracle Mediator to read and write files on local file systems and on remote file systems through FTP (File Transfer Protocol). These adapters support high availability for an active-active topology with Oracle BPEL Process Manager and Oracle Mediator service engines for both inbound and outbound operations. To make Oracle File and FTP Adapters highly available for outbound operations, use the database mutex locking operation as described in "High Availability in Outbound Operations" in Oracle Fusion Middleware User's Guide for Technology Adapters. The database mutex locking operation enables these adapters to ensure that multiple references do not overwrite one another if they write to the same directory.
Note:
The operation described above is necessary only if your application requires these adapters.Note:
The File Adapter picks up a file from the inbound directory, processes it, and then outputs a file to the output directory. Because the File Adapter is non-transactional, files can be processed twice. As a result, it is possible to get duplicate files when there is failover in the RAC backend or in the SOA managed servers.Use the following procedure to make an outbound Oracle File or FTP Adapter service highly available using database table as a coordinator:
Note:
You must increase global transaction timeouts if you use database as a coordinator.Create Database Tables
You are not required to perform this step since the database schemas are pre-created as a part of soainfra.
Modify Deployment Descriptor for Oracle File Adapter
Modify Oracle File Adapter deployment descriptor for the connection-instance corresponding to eis/HAFileAdapter
from the Oracle WebLogic Server console:
Log into your Oracle WebLogic Server console. To access the console navigate to http://
servername
:portnumber
/console
.
Click Deployments in the left pane for Domain Structure.
Click FileAdapter under Summary of Deployments on the right pane.
Click the Configuration tab.
Click the Outbound Connection Pools tab, and expand javax.resource.cci.ConnectionFactory to see the configured connection factories.
Click eis/HAFileAdapter. The Outbound Connection Properties for the connection factory corresponding to high availability is displayed.
The connection factory properties appear as shown in Figure 5-4.
Figure 5-4 Oracle WebLogic Server Console - Settings for javax.resource.cci.Connectionfactory Page
Click on Lock and Edit. After this, the property value column becomes editable (you can click on any of the rows under "Property Value" and modify its value).
The new parameters in connection factory for Oracle File and FTP Adapters are as follows:
controlDir
: Set it to the directory structure where you want the control files to be stored. You must set it to a shared location if multiple WebLogic Server instances run in a cluster. Structure the directory for shared storage as follows:
ORACLE_BASE/admin/<domain_name>/<cluster_name>/fadapter
inboundDataSource:
Set the value to jdbc/SOADataSource
. This is the data source, where the schemas corresponding to high availability are pre-created. The pre-created schemas can be found under ORACLE_HOME/ rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql
. If you want to create the schemas elsewhere, use this script. You must set the inboundDataSource property accordingly if you choose a different schema.
outboundDataSource
: Set the value to jdbc/SOADataSource
. This is the data source where the schemas corresponding to high availability are pre-created. The pre-created schemas can be found under ORACLE_HOME/ rcu/integration/soainfra/sql/adapter/createschema_adapter_oracle.sql
. If you want to create the schemas elsewhere, use this script. You must set the outboundDataSource property if you choose to do so.
outboundDataSourceLocal
: Set the value to jdbc/SOALocalTxDataSource
. This is the datasource where the schemas corresponding to high availability are pre-created.
outboundLockTypeForWrite:
Set the value to oracle
if you are using Oracle Database. By default the Oracle File and FTP Adapters use an in-memory mutex to lock outbound write operations. You must choose from the following values for synchronizing write operations:
memory
: The Oracle File and FTP Adapters use an in-memory mutex to synchronize access to the file system.
oracle: The adapter uses Oracle Database sequence.
db
: The adapter uses a pre-created database table (FILEADAPTER_MUTEX
) as the locking mechanism. You must use this option only if you are using a schema other than the Oracle Database schema.
user-defined
: The adapter uses a user-defined mutex. To configure the user-defined mutex, you must implement the mutex interface: "oracle.tip.adapter.file.Mutex"
and then configure a new binding-property with the name "oracle.tip.adapter.file.mutex"
and value as the fully qualified class name for the mutex for the outbound reference.
Click Save after you update the properties. The Save Deployment Plan page appears.
Enter a shared storage location for the deployment plan. The directory structure is as follows:
ORACLE_BASE/admin/<domain_name>/<cluster_name>/dp/Plan.xml
Click Save and Activate.
Configure BPEL Process or Mediator Scenario to use the connection factory as shown in the following example (in the jca file included in the composite for the binding component):
<adapter-config name="FlatStructureOut" adapter="File Adapter" xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata"> <connection-factory location="eis/HAFileAdapter" adapterRef=""/> <endpoint-interaction portType="Write_ptt" operation="Write"> <interaction-spec className="oracle.tip.adapter.file.outbound.FileInteractionSpec"> <property../> <property../> </interaction-spec> </endpoint-interaction> </adapter-config>
Note:
The location attribute is set toeis/HAFileAdapter
for the connection factory.If you are using Logical Delete polling, and you set MarkReservedValue
, skip locking is not used.
Formerly, the best practice for multiple Oracle Database Adapter process instances deployed to multiple Oracle BPEL Process Manager, or Oracle Mediator nodes was essentially using LogicalDeletePollingStrategy
or DeletePollingStrategy
with a unique MarkReservedValue
on each polling node, and setting MaxTransactionSize
.
However, with the introduction of skip locking in this release that approach has now been superseded. If you were using this approach previously, you can simply remove (in db.jca) or clear (Logical Delete Page of wizard) the MarkReservedValue, and you automatically get skip locking.
The benefits of using skip locking over a reserved value include:
Skip locking scales better in a cluster and under load.
All work is in one transaction (as opposed to update/reserve, then commit, then select in a new transaction), so the risk of facing a non-recoverable situation in a high availability environment is minimized.
No unique MarkReservedValue
must be specified. Previously, for this to work you would have to configure a complex variable, such as R${weblogic.Name-2}-${IP-2}-${instance}
.
For more information, see "Scalability" and "Polling Strategies" in Oracle Fusion Middleware User's Guide for Technology Adapters.
After you have verified that the extended domain is working, back up the installation. This is a quick backup for the express purpose of immediate restore in case of problems in the further steps. The backup destination is the local disk. This backup can be discarded once the enterprise deployment setup is complete. At this point, the regular deployment-specific backup and recovery process can be initiated. The Oracle Fusion Middleware Administrator's Guide provides further details. For information on describing the Oracle HTTP Server data that must be backed up and restored, refer to the "Backup and Recovery Recommendations for Oracle HTTP Server" section in this guide. For information on how to recover components, see "Recovery of Components" and "Recovery After Loss of Component" sections in the guide. For recommendations specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" in the guide. Also refer to the Oracle Database Backup and Recovery Guide for information on database backup.
To back up the installation a this point, complete these steps:
Back up the web tier:
Shut down the instance using opmnctl
.
ORACLE_BASE/admin/<instance_name>/bin/opmnctl stopall
Back up the Middleware Home on the web tier using the following command (as root):
tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME
Back up the Instance Home on the web tier using the following command (as root):
tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE
Start the instance using opmnctl
:
ORACLE_BASE/admin/<instance_name>/bin/opmnctl startall
Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or OS tools such as tar
for cold backups if possible.
Back up the Administration Server domain directory to save your domain configuration. The configuration files all exist under the ORACLE_BASE/ admin/<domain_name>
directory.
SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/<domain_name>
Note:
ORACLE_HOME should be backed up if any changes are made to the XEngine configuration that are part of your B2B setup. These files are located underORACLE_HOME/soa/thirdparty/edifecs/XEngine
. To back up ORACLE_HOME, execute the following command:
SOAHOST1> tar -cvpf fmwhomeback.tar MW_HOME