This chapter describes how to extend the domain created in Chapter 8, "Creating a Domain for an Enterprise Deployment," to include Oracle SOA Suite components and the Oracle WSM Policy Manager Server, using the Fusion Middleware Configuration Wizard.
This chapter contains the following sections:
Section 12.1, "Overview of Extending the Domain to Include Oracle SOA Suite Components"
Section 12.2, "Enabling VIP2 on WCCHOST1 and VIP3 on WCCHOST2"
Section 12.3, "Extending the Domain for Oracle SOA Suite Components"
Section 12.5, "Configuring Oracle Coherence for Deploying Composites"
Section 12.6, "Completing Postconfiguration and Verification Tasks for Oracle SOA Suite"
Section 12.7, "Configuring the Java Object Cache for Oracle Web Services Manager"
Section 12.8, "Configuring Oracle HTTP Server with the Extended Domain"
Section 12.9, "Configuring a Default Persistence Store for Transaction Recovery"
Section 12.10, "Configuring Node Manager for the WLS_SOA Managed Servers"
Notes:
Oracle SOA Suite is required only if your enterprise deployment topology includes Oracle WebCenter Content: Imaging.
Before starting the setup process, read the Oracle Fusion Middleware Release Notes for your platform for additional installation and deployment information.
The instructions in this chapter are based on an assumption that a SOA Oracle home (binaries) has already been installed and is available from WCCHOST1 and WCCHOST2 and that a domain with an Administration Server has been created. This is the domain that will be extended to support Oracle SOA Suite components.
Extend the Oracle WebLogic Server domain to include Oracle SOA Suite components. Table 12-1 lists the steps for configuring Oracle SOA Suite and other tasks required for extending the domain for Oracle SOA Suite components.
Table 12-1 Steps for Extending the Domain for Oracle SOA Suite Components
Step | Description | More Information |
---|---|---|
Prepare for extending the domain for Oracle SOA Suite components |
Enable a virtual IP address mapping for each of the host names for the Oracle SOA Suite WebLogic Server cluster. |
Section 12.2, "Enabling VIP2 on WCCHOST1 and VIP3 on WCCHOST2" |
Extend the domain for Oracle SOA Suite components |
Extend the WebLogic Server domain you created in Chapter 8, "Creating a Domain for an Enterprise Deployment." |
Section 12.3, "Extending the Domain for Oracle SOA Suite Components" |
Configure Oracle Coherence for deploying composites |
Configure Oracle Coherence to use unicast communication for deploying composites. |
Section 12.5, "Configuring Oracle Coherence for Deploying Composites" |
Complete postconfiguration and verification tasks |
Follow these instructions for disabling host name verification, restarting Node Manager, propagating the domain configuration, starting and validating the Managed Servers, and validating GridLink data sources. |
Section 12.6, "Completing Postconfiguration and Verification Tasks for Oracle SOA Suite" |
Configure the Java Object Cache (JOC) among all the servers running Oracle Web Services Manager (Oracle WSM) |
Configure a local cache to increase the performance of Oracle WSM. |
Section 12.7, "Configuring the Java Object Cache for Oracle Web Services Manager" |
Configure Oracle HTTP Server with the extended domain |
Configure the Oracle HTTP Server with the Managed Servers, validate access, set the front-end HTTP host and port, and set the WebLogic Server cluster address for SOA_Cluster. |
Section 12.8, "Configuring Oracle HTTP Server with the Extended Domain" |
Configure a default persistence store |
Configure a default persistence store for transaction recovery. |
Section 12.9, "Configuring a Default Persistence Store for Transaction Recovery" |
Configure host name verification for communication between Node Manager and the Managed Servers in the domain |
Use certificates for the different addresses communicating with the Administration Server and other servers. |
Section 12.10, "Configuring Node Manager for the WLS_SOA Managed Servers" |
Configure server migration for the Oracle SOA Suite Managed Servers |
Specify the Oracle SOA Suite Managed Server names, host names, and cluster name for migration. |
vSection 12.11, "Configuring Server Migration for the WLS_SOA Managed Servers" |
Back up the Oracle SOA Suite configuration |
Back up the newly extended domain configuration. |
The Oracle WebCenter Content domain uses virtual host names as the listen addresses for the Oracle SOA Suite Managed Servers. If you have not previously done so, you must enable a virtual IP address mapping from VIP2 to WCCHOST1VHN1 on WCCHOST1 and from VIP3 to WCCHOST2VHN1 on WCCHOST2, and you must correctly resolve the virtual host names in the network system used by the topology, with either DNS Server or /etc/hosts
resolution.
To enable the virtual IP addresses, follow the procedure described in Section 6.6, "Enabling Virtual IP Addresses" if you have not yet completed it. These virtual IP addresses and virtual host names are required to enable server migration for the Oracle SOA Suite servers. You can configure server migration for the Oracle SOA Suite servers later for high availability purposes. For more information about configuring server migration, see Chapter 17, "Configuring Server Migration for an Enterprise Deployment."
Use the Configuration Wizard to extend the domain created in Chapter 8, "Creating a Domain for an Enterprise Deployment" to support Oracle Web Services Manager and Oracle SOA Suite components.
Notes:
If you have not backed up the domain created in Chapter 8, "Creating a Domain for an Enterprise Deployment," back up the current domain before extending it for Oracle SOA Suite components. You may use the backup to recover in case any errors are made in the domain extension. See "Backing Up Your Environment" in the Administrator's Guide.
To extend the domain for Oracle SOA Suite components:
Make sure that the database where you installed the repository is running.
For Oracle RAC databases, it is recommended that all instances are running, so that the validation check later on becomes more reliable.
Shut down all Managed Servers in the domain.
On WCCHOST1, change the directory to the location of the Fusion Middleware Configuration Wizard. This is within the Oracle Common home directory (domain extensions are run from the node where the Administration Server resides).
cd ORACLE_COMMON_HOME/common/bin
Start the Configuration Wizard:
./config.sh
On the Welcome screen, select Extend an Existing WebLogic Domain, and click Next.
On the Select a WebLogic Domain Directory screen, select the WebLogic Server domain directory (ASERVER_HOME
), and click Next.
On the Select Extension Source screen, which Figure 12-1 shows, perform the following steps:
Select Extend my domain automatically to support the following added products.
Select these products:
Oracle SOA Suite
Oracle WSM Policy Manager
The following products are grayed out if they were selected when you created the domain (Section 8.3) or extended it for WebCenter Content (Section 10.2) or Inbound Refinery (Section 11.2).
Basic WebLogic Server Domain
Oracle Universal Content Management - Inbound Refinery
Oracle Universal Content Management - Content Server
Oracle Enterprise Manager Plugin for IBR
Oracle Enterprise Manager
Oracle JRF
Figure 12-1 Select Extension Source Screen for Oracle SOA Suite
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.
On the Configure JDBC Component Schema screen, which Figure 12-2 shows, perform the following steps:
Select the rows SOA Infrastructure, User Messaging Service, OWSM MDS Schema, and SOA MDS Schema.
For the RAC configuration, you can select Convert to GridLink or Convert to RAC multi data source (described in Appendix A, "Using Multi Data Sources with Oracle RAC"). For the instructions given here, select Convert to GridLink.
After you select a RAC configuration, all selected schemas are grayed.
Figure 12-2 Configure JDBC Component Schema Screen for Oracle SOA Suite
Click Next.
On the Configure GridLink RAC Component Schema screen, which Figure 12-3 shows, perform the following steps:
Select only the SOA Infrastructure row.
Figure 12-3 Configure GridLink RAC Component Schema Screen for Oracle SOA Suite
Enter values for the following fields, specifying the connection information for the GridLink RAC database that was seeded through RCU:
Driver: Select Oracle's Driver (Thin) for GridLinkConnections; Versions: 11 and later.
Service Name: Enter the service name of the Oracle RAC database in lowercase letters, followed by the domain name; for example, wccedg.example.com
.
Username: Enter the complete user name for the database schema owner of the corresponding component.
This book uses WCC
as the prefix of user names for the database schemas.
Password: Enter the password for the database schema owner.
Select Enable FAN.
Enable SSL: Leave this option deselected.
If you select SSL to enable Oracle Notification Service (ONS) notification encryption, provide the appropriate Wallet File and Wallet Password details.
Service listener: Enter the Oracle Single Client Access Name (SCAN) address and port for the Oracle RAC database being used. The protocol should be TCP
.
Oracle recommends that you use a SCAN address to specify the Service Listener (and OSN Host) so you do not need to update a GridLink data source containing a SCAN address if you add or remove Oracle RAC nodes. To determine the SCAN address, query the remote_listener
parameter in the database:
SQL>show parameter remote_listener; NAME TYPE VALUE ----- ------ ------- remote_listener string db-scan.example.com:1521
Note:
For Oracle Database 11g, use the virtual IP address and port of each database instance listener, as in these examples:wccdbhost1-vip.example.com (port 1521) wccdbhost2-vip.example.com (1521)
ONS Host: Enter here also the SCAN address for the RAC database and the ONS remote port, as reported by the database:
[orcl@WCCDBHOST2 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016
Note:
For Oracle Database 11g, use the host name and port of each database's ONS service, as in these examples:wccdbhost1.example.com (port 6200) wccdbhost2.example.com (6200)
Select each data source, one at a time, and enter appropriate values for the user names and passwords.
Ensure that all values are correct for all schemas (SOA Infrastructure, User Messaging Service, OWSM MDS Schema, and SOA MDS Schema), and then click Next.
Note:
Oracle recommends using the database used for Oracle Identity Management (see Chapter 18, "Integrating with Oracle Identity Management") to store the Oracle WSM policies. It is therefore expected that you will use the Oracle Identity Management database information that has been seeded through RCU (as recommended in Chapter 3, "Preparing the Network for an Enterprise Deployment") to store the WSM metadata and that this Oracle Identity Management database information will be used on this screen for the OWSM MDS schemas. (This database connection information will be different from the one used for the rest of the Oracle SOA Suite schemas.)On the Test JDBC Component Schema screen, (Figure 12-4), select each schema, and then click Test Connections.
The Connection Results Log displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen, correct your entries, and then retry the test.
Figure 12-4 Test JDBC Component Schema Screen for Oracle SOA Suite
Click Next when all the connections are successful.
On the Select Optional Configuration screen, select the following options:
JMS Distributed Destination
Managed Servers, Clusters and Machines
Deployments and Services
JMS File Store
Click Next.
On the Select JMS Distributed Destination Type screen, perform the following steps:
Select UDD from the drop-down list for UMSJMSystemResource.
Select UDD from the drop-down list for SOAJMSModule.
Select UDD from the drop-down list for BPMJMSModule.
If an override warning appears, click OK to acknowledge it.
On the Configure Managed Servers screen, add the required Managed Servers.
A server called soa_server1
is created automatically. Rename this to WLS_SOA1 and add a new server called WLS_SOA2. Give these servers the attributes listed in Table 12-2. Do not modify any other servers that are shown on this screen.
Table 12-2 Managed Servers for Oracle SOA Suite
Name | Listen Address | Listen Port | SSL Listen Port | SSL Enabled |
---|---|---|---|---|
WLS_SOA1 |
WCCHOST1VHN1 |
8001 |
n/a |
No |
WLS_SOA2 |
WCCHOST2VHN1 |
8001 |
n/a |
No |
Click Next.
On the Configure Clusters screen, add SOA_Cluster
, which Table 12-3 describes.
Table 12-3 Cluster Configuration for Oracle SOA Suite
Name | Cluster Messaging Mode | Multicast Address | Multicast Port | Cluster Address |
---|---|---|---|---|
SOA_Cluster |
unicast |
n/a |
n/a |
WCCHOST1VHN1:8001,WCCHOST2VHN1:8001 |
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 callbacks.If soa-infra config 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 either a single DNS name that maps to the IP addresses of the clustered servers 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.
On the Assign Servers to Clusters screen, assign the following servers to SOA_Cluster:
WLS_SOA1
WLS_SOA2
Do not modify any other assignments that appear on this screen.
Click Next.
On the Configure Machines screen, delete LocalMachine, which appears by default, open the Unix Machine tab, and click Next.
You do not need to add any machines here. The machines configured earlier, as described in Section 10.2, "Extending the Domain for WebCenter Content," will be used for all Managed Servers configured on WCCHOST1 and WCCHOST2.
On the Assign Servers to Machines screen, assign servers to machines as follows:
ADMINHOST:
AdminServer
WCCHOST1:
WLS_SOA1
WCCHOST2:
WLS_SOA2
Click Next.
On the Target Deployments to Clusters or Servers screen, make sure that targeting is done as follows:
The usermessagingserver and usermessagingdriver-email deployments are targeted only to SOA_Cluster. (The usermessaging-xmpp, usermessaging-smpp, and usermessaging-voicexml applications are optional.)
WSM-PM is targeted only to SOA_Cluster.
The oracle.rules#*, oracle.sdp.*, and oracle.soa.* libraries are targeted only to SOA_Cluster.
EM Application is targeted only to AdminServer.
Click Next.
On the Target Services to Clusters or Servers screen, select all OPSS-related data sources to be deployed to SOA_Cluster, as Figure 12-5 shows:
opss-audit-viewDS
opss-audit-DBDS
opss-DBDS
Figure 12-5 Target Services to the SOA Cluster
Click Next.
On the Configure JMS File Stores screen (Figure 12-6), enter the shared directory location specified for your JMS stores, as recommended in Section 4.4, "Recommended Locations for Different Directories." For example:
ASERVER_HOME/SOA_Cluster/jms
This directory should be created before you extend the domain.
In the reference topology, ASERVER_HOME
is the /u01/oracle/config/domains/WCCDomain
directory.
Figure 12-6 JMS File Stores for the SOA Cluster
Click Next.
On the Configuration Summary screen, click Extend.
The domain is extended to include the Oracle SOA Suite components.
On the Extending Domain screen, click Done.
You need to restart the Administration Server to make the domain extension changes take effect, using the Node Manager nmKill
and nmStart
commands through the Oracle WebLogic Scripting Tool (WLST), as described in Section 10.3, "Restarting the Administration Server." You can use the Administration Console instead of nmKill
to stop the Administration Server. Log in to the Administration Console using the credentials for the weblogic
user.
Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication instead in Oracle SOA Suite enterprise deployments. Use unicast if you disable multicast communication for security reasons.
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 Oracle SOA Suite enterprise deployments where multiple IP addresses are available in the same system, you must configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.
Note:
An incorrect configuration of the Oracle Coherence framework used for deployment may prevent the Oracle SOA Suite system from starting. The deployment framework must be properly customized for the network environment on which the Oracle SOA Suite system runs. Oracle recommends the configuration described in this section.Specify the nodes using the tangosol.coherence.wka
n
system property, where n
is a number in the range 1
to 9
. You can specify up to 9 nodes as Well Known Addresses, but the cluster can have more than 9 nodes. Start the numbering at 1. This numbering must be sequential and must not contain gaps.
Tip:
To guarantee high availability during deployments of Oracle SOA Suite composites, specify enough nodes so that at least one of them is running at any given time.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 Oracle SOA Suite server as the listener addresses (WCCHOST1VHN1 and WCCHOST2VHN1). Set this property by adding the -Dtangosol.coherence.localhost
parameter to the Arguments field on the Server Start tab of the Oracle WebLogic Server Administration Console, shown in Figure 12-7.
Note:
WCCHOST1VHN1 is the virtual host name that maps to the virtual IP address where WLS_SOA1 is listening (in WCCHOST1). WCCHOST2VHN1 is the virtual host name that maps to the virtual IP address where WLS_SOA2 is listening (in WCCHOST2).Use the Administration Console to add a host name for Oracle Coherence to use.
To specify the host name used by Oracle Coherence:
Log in to the WebLogic Server Administration Console.
In the Domain Structure tree on the left, expand the Environment node.
Click Servers.
On the Summary of Servers page, click the name of the server (WLS_SOA1 or WLS_SOA2, which are represented as hyperlinks) in the Name column of the table.
On the settings page for the selected server, click Lock & Edit.
On the Configuration tab, click the Server Start tab (illustrated in Figure 12-7).
Enter the following parameters for WLS_SOA1 and WLS_SOA2 in the Arguments field.
Note:
There should be no breaks in lines between the different-D
parameters. Do not copy or paste the text to the Arguments text field in your Administration Console because this could result in HTML tags being inserted into the Java arguments. The text should not contain other text characters than those included the example that follows.For WLS_SOA1, enter the following text (on a single line, without a carriage return):
-Dtangosol.coherence.wka1=WCCHOST1VHN1 -Dtangosol.coherence.wka2=WCCHOST2VHN1 -Dtangosol.coherence.localhost=WCCHOST1VHN1
For WLS_SOA2, enter the following text (on a single line, without a carriage return):
-Dtangosol.coherence.wka1=WCCHOST1VHN1 -Dtangosol.coherence.wka2=WCCHOST2VHN1 -Dtangosol.coherence.localhost=WCCHOST2VHN1
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) using the-Dtangosol.coherence.wkan.port
and -Dtangosol.coherence.localport
startup parameters; for example:
WLS_SOA1 (enter the following text into the Arguments field on a single line, without a carriage return):
-Dtangosol.coherence.wka1=WCCHOST1VHN1 -Dtangosol.coherence.wka2=WCCHOST2VHN1 -Dtangosol.coherence.localhost=WCCHOST1VHN1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
WLS_SOA2 (enter the following text into the Arguments field on a single line, without a carriage return):
-Dtangosol.coherence.wka1=WCCHOST1VHN1 -Dtangosol.coherence.wka2=WCCHOST2VHN1 -Dtangosol.coherence.localhost=WCCHOST2VHN1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
For more information about Coherence clusters, see the Oracle Coherence Developer's Guide.
Click Save and Activate Changes.
Notes:
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.
The multicast and unicast addresses are different from the ones used by the WebLogic Server cluster for cluster communication. Oracle SOA Suite 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.
Figure 12-7 Setting the Host Name on the Start Server Tab of the Administration Console
After extending the domain with the Configuration Wizard and configuring Oracle Coherence, follow these instructions for postconfiguration and validation. The following sections describe how to do postconfiguration and verification tasks for Oracle SOA Suite:
Section 12.6.1, "Disabling Host Name Verification for the WLS_SOAn Managed Servers"
Section 12.6.2, "Propagating the Domain Configuration to WLS_SOA1 and WLS_SOA2"
Section 12.6.3, "Starting and Validating the WLS_SOA1 Managed Server"
Section 12.6.4, "Starting and Validating the WLS_SOA2 Managed Server"
Section 12.6.5, "Validating GridLink Data Sources for Oracle SOA Suite"
For the 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_SOA1 and WLS_SOA2 Managed Servers to avoid errors when managing the different WebLogic Server instances. For more information, see Section 8.4.5, "Disabling Host Name Verification."
You enable host name verification again once the enterprise deployment topology configuration is complete. For more information, see Section 16.3, "Enabling Host Name Verification Certificates for Node Manager."
Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the Managed Server domain directory.
To propagate the domain configuration to the Oracle SOA Suite Managed Servers:
Create a copy of the Managed Server domain directory and the Managed Server applications directory.
Run the following pack
command on WCCHOST1 to create a template pack:
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ASERVER_HOME -template=edgdomaintemplateSOA.jar -template_name=edgdomain_templateSOA
In the reference topology, ORACLE_COMMON_HOME
is the /u01/oracle/products/fmw_home/oracle_common
directory, and ASERVER_HOME
is the /u01/oracle/config/domains/WCCDomain
directory.
Run the following unpack
command on WCCHOST1 to propagate the template created in the preceding step to the WLS_SOA1 domain directory:
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateSOA.jar -app_dir=APPLICATION_HOME -overwrite_domain=true
In the reference topology, MSERVER_HOME
is the /u02/oracle/config/domains/WCCDomain
directory, and APPLICATION_HOME
is the /u01/oracle/config/applications/WCCDomain
directory.
Notes:
Make sure to run unpack
from the ORACLE_COMMON_HOME
/common/bin/
directory, not from WL_HOME
/common/bin/
.
The APPLICATION_HOME
directory gets backed up with this unpack
command.
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 following command on WCCHOST1 to copy the template pack created in step 2 to WCCHOST2:
scp edgdomaintemplateSOA.jar oracle@WCCHOST2:ORACLE_COMMON_HOME/common/bin
Run the following unpack
command on WCCHOST2 to unpack the propagated template to the WLS_SOA2 Managed Server domain directory:
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=MSERVER_HOME -template=edgdomaintemplateSOA.jar -app_dir=APPLICATION_HOME –overwrite_domain=true
Notes:
Make sure to run unpack
from the ORACLE_COMMON_HOME
/common/bin/
directory, not from WL_HOME
/common/bin/
.
The APPLICATION_HOME
directory gets backed up with this unpack
command.
Restart the Administration Server to make these changes take effect, stopping it with the nmKill
command, or with the Administration Console, and then starting it with the nmStart
command, as described in Section 10.3, "Restarting the Administration Server." Log in to the Administration Console using the credentials for the weblogic
user.
You can start and validate the WLS_SOA1 Managed Server through the Administration Console.
To start the WLS_SOA1 Managed Server on WCCHOST1:
Log in to the Oracle WebLogic Server Administration Console at http://admin.example.com:7001/console
.
Start the WLS_SOA1 Managed Server through the WebLogic Server Administration Console, as follows:
Expand the Environment node in the Domain Structure tree on the left.
Click Servers.
On the Summary of Servers page, click the Control tab.
Select WLS_SOA1 from the Servers column of the table.
Click Start.
Verify that the server status is reported as Running
in the Administration Console.
If the server is shown as Starting
or Resuming
, wait for the server status to change to Started
.
If another status is reported (such as Admin
or Failed
), check the server output log files for errors. For possible causes, see Section 19.13, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology."
Access the following URLs:
Access http://WCCHOST1VHN1:8001/soa-infra
to verify the status of WLS_SOA1.
Access http://WCCHOST1VHN1:8001/wsm-pm
to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data store opens.The configuration is incorrect if no policies or assertion templates appear.
Access http://WCCHOST1VHN1:8001/integration/worklistapp
to verify the status of the worklist application.
After you start the WLS_SOA2 Managed Server, you can validate it by verifying its status through the WebLogic Server Administration Console and some URLs.
Note:
Before starting the WLS_SOA2 Managed Server using the WebLogic Server Administration Console, make sure Node Manager is running. Section 19.8.1, "Assumptions and Procedure," says to start it, in Step 3, "Start Node Manager in WCCHOST2."If Node Manager is not running, restart it on WCCHOST2, as described in Section 8.4.2, "Starting Node Manager on WCCHOST1."
To start and validate the WLS_SOA2 Managed Server:
Start the WLS_SOA2 Managed Server using the WebLogic Server Administration Console, as follows:
Expand the Environment node in the Domain Structure tree on the left.
Click Servers.
On the Summary of Servers page, open the Control tab.
Select WLS_SOA2 and then click Start.
Verify that the server status is reported as Running
in the Administration Console. If the server is shown as Starting
or Resuming
, wait for the server status to change to Started
. If another status is reported (such as Admin
or Failed
), check the server output log files for errors. See Section 19.13, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology" for possible causes.
Access the following URLs:
Access http://WCCHOST2VHN1:8001/soa-infra
to verify the status of WLS_SOA2.
Access http://WCCHOST2VHN1:8001/wsm-pm
to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data store opens.
Note:
The configuration is incorrect if no policies or assertion templates appear.Access http://WCCHOST2VHN1:8001/integration/worklistapp
to verify the status of the worklist application.
After the servers are started, verify that the GridLink data sources are correctly configured and that the ONS setup is correct. Perform this procedure for every GridLink data source created.
To verify the configuration of a GridLink data source for Oracle SOA Suite:
Log in to the WebLogic Server Administration Console.
In the Domain Structure tree, expand Services, then click Data Sources.
Click the name of a GridLink data source that was created.
Click the Monitoring tab.
Click the Testing tab (Figure 12-8), select one of the servers, and click Test Data Source.
Figure 12-8 Testing a GridLink Data Source for Oracle SOA Suite
The test should be successful if the configuration is correct.
Repeat the test for every WebLogic Server instance that uses the GridLink data source.
To verify the configuration of ONS for a GridLink data source for Oracle SOA Suite:
In the Domain Structure tree on the Administration Console, expand Services, then click Data Sources.
Click the name of a GridLink data source that was created.
Click the Monitoring tab.
Click the name of the server (WLS_SOA1
).
Click the ONS tab and then the Testing tab (Figure 12-9).
Select a server, and click Test ONS.
Figure 12-9 Testing the ONS Configuration for Oracle SOA Suite
The test should be successful if the configuration is correct. If the ONS test fails, verify that the ONS service is running in the Oracle RAC database nodes:
[orcl@WCCDBHOST1 ~]$ srvctl status scan_listener SCAN Listener LISTENER_SCAN1 is enabled SCAN listener LISTENER_SCAN1 is running on node WCCDBHOST1 SCAN Listener LISTENER_SCAN2 is enabled SCAN listener LISTENER_SCAN2 is running on node WCCDBHOST2 SCAN Listener LISTENER_SCAN3 is enabled SCAN listener LISTENER_SCAN3 is running on node WCCDBHOST2 [orcl@WCCDBHOST1 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016 [orcl@WCCDBHOST1 ~]$ srvctl status nodeapps | grep ONS ONS is enabled ONS daemon is running on node: WCCDBHOST1 ONS daemon is running on node: WCCDBHOST2
Repeat the ONS test for every WebLogic Server instance that uses the GridLink data source.
The Java Object Cache (JOC) should be configured among all the servers running Oracle Web Services Manager (Oracle WSM). This local cache is provided to increase the performance of Oracle WSM. The Java Object Cache can be configured using the MW_HOME
/oracle_common/bin/configure-joc.py
script. This is a Python script, which can be used to configure JOC in the Managed Servers. The script runs in WLST online mode and expects the Administration Server to be up and running.
For the configuration of JOC ports for Oracle products, Oracle recommends using ports in the 9988 to 9998 range.
Note:
After you configure the Java Object Cache using the WLST commands orconfigure-joc.py
script, all affected Managed Servers should be restarted, using the WebLogic Server Administration Console, for the configurations to take effect.To configure the Java Object Cache for Oracle WSM:
Connect to the Administration Server using the command-line Oracle WebLogic Scripting Tool (WLST); for example:
MW_HOME/oracle_common/common/bin/wlst.sh
$ connect()
Enter the WebLogic Server Administrator user name, password, and server URL (t3://ADMINVHN:7001
) when prompted.
After connecting to the Administration Server using WLST, start the script using the execfile
command, for example:
wls:/domain_name/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")
Specifically, for enterprise deployment environments, the first cluster option in step 2 should be used. Here is a walkthrough for using configure-joc.py
for enterprise deployment environments (see the following text for the script input parameters):
Execfile("MW_HOME/oracle_common/bin/configure-joc.py").
Enter Hostnames (eg host1,host2) : WCCHOST1VHN1,WCCHOST2VHN1
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : SOA_Cluster
.
Enter Discover Port : 9991
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n
After configuring the Java Object Cache using WLST commands or the configure-joc.py
script, restart all affected Managed Servers, using the WebLogic Server Administration Console, for the configurations to take effect.
The input parameters are prompted by the script. The script can be used to perform the following optional JOC configurations:
Configure JOC for all specified Managed Servers for a given cluster. Enter y
when the script prompts whether you want to specify a cluster name, and also specify the cluster name and discover port, when prompted. This discovers all the Managed Servers for the given cluster and configures the JOC. The discover port is common for the entire JOC configuration across the cluster. For example:
Do you want to specify a cluster name (y/n) <y> Enter Cluster Name : SOA_Cluster Enter Discover Port : 9991
Configure JOC for all specified Managed Servers. Enter n
when the script prompts whether you want to specify a cluster name, and also specify the Managed Server and discover port, when prompted. For example:
Do you want to specify a cluster name (y/n) <y>n Enter Managed Server and Discover Port (eg WLS_SOA1:9991, WLS_SOA21:9991) : WLS_SOA1:9999,WLS_SOA2:9999
This example configures JOC only for the specified Managed Servers (that is, WLS_SOA1 and WLS_SOA2). The discover port is specified with the Managed Server (for example, WLS_SOA1:2222
).
Exclude JOC configuration for some Managed Servers. The script allows you to specify the list of Managed Servers for which the JOC configuration DistributeMode
will be set to false
. Enter y when the script prompts whether you want to exclude any servers from JOC configuration, and enter the Managed Server names to be excluded, when prompted. For example:
Do you want to exclude any server(s) from JOC configuration (y/n) <n>y Exclude Managed Server List (eg Server1,Server2) : WLS_SOA1,WLS_SOA2
Disable the distribution mode for all Managed Servers. The script allows you to disable the distribution to all the Managed Servers for a specified cluster. Specify false
when the script prompts for the distribution mode. By default, the distribution mode is set to true
.
After propagating the domain configuration to WCCHOST2, configure the Oracle HTTP Server with the extended domain.
This section includes the following topics:
Section 12.8.1, "Configuring Oracle HTTP Server for the WLS_SOA Managed Servers"
Section 12.8.3, "Validating Access Through the Load Balancer"
To enable Oracle HTTP Server to route to SOA_Cluster, which contains the WLS_SOAn Managed Servers, you must set the WebLogicCluster
parameter to the list of nodes in the cluster.
To configure Oracle HTTP Server for the WLS_SOA Managed Servers:
For each of the web servers on WEBHOST1 and WEBHOST2, add the following lines to the ORACLE_INSTANCE
/config/OHS/ohs1/moduleconf/wccinternal_vh.conf
and ORACLE_INSTANCE
/config/OHS/ohs2/moduleconf/wccinternal_vh.conf
files:
# WSM-PM <Location /wsm-pm> WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001 SetHandler weblogic-handler WLProxySSL OFF WLProxySSLPassThrough OFF </Location> # SOA soa-infra app <Location /soa-infra> WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001 SetHandler weblogic-handler WLProxySSL OFF WLProxySSLPassThrough OFF </Location> # SOA inspection.wsil <Location /inspection.wsil> WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001 SetHandler weblogic-handler WLProxySSL OFF WLProxySSLPassThrough OFF </Location> # Worklist <Location /integration/> WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001 SetHandler weblogic-handler WLProxySSL OFF WLProxySSLPassThrough OFF </Location> # UMS prefs <Location /sdpmessaging/userprefs-ui> WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001 SetHandler weblogic-handler WLProxySSL OFF WLProxySSLPassThrough OFF </Location> # Default to-do taskflow <Location /DefaultToDoTaskFlow/> WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001 SetHandler weblogic-handler WLProxySSL OFF WLProxySSLPassThrough OFF </Location> # Workflow <Location /workflow> WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001 SetHandler weblogic-handler WLProxySSL OFF WLProxySSLPassThrough OFF </Location> #SOA Composer <Location /soa/composer> WebLogicCluster WCCHOST1VHN1:8001,WCCHOST2VHN1:8001 SetHandler weblogic-handler WLProxySSL OFF WLProxySSLPassThrough OFF </Location>
In the reference topology, ORACLE_INSTANCE
is the /u02/oracle/config/web1
or /u02/oracle/config/web2
directory.
Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2:
/u02/oracle/config/webN/bin/opmnctl restartproc ias-component=ohsX
For WEBHOST1, use web1
for ias-component
and for WEBHOST2 use web2
.
The servers specified in the WebLogicCluster
parameter are important only 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. Please 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 run time.
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 Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server Guide.
You must set the front-end HTTP host and port for the Oracle WebLogic Server cluster hosting the Oracle SOA Suite servers.
To set the front-end HTTP host and port for the Oracle SOA Suite cluster:
Log in to the WebLogic Server Administration Console.
Go to the Change Center section and click Lock & Edit.
Expand the Environment node in the Domain Structure tree on the left.
Click Clusters.
On the Summary of Servers page, select SOA_Cluster.
Open the HTTP tab.
Set the following values:
Frontend Host: wccinternal.example.com
Frontend HTTP Port: 80
Click Save.
Click Activate Changes in the Change Center section of the Administration Console.
Restart the WLS_SOA1 and WLS_SOA2 Managed Servers, using the WebLogic Server Administration Console, to make the front-end host directive in the cluster take effect.
Verify that the server status is reported as Running
in the Administration Console. If the server is shown as Starting
or Resuming
, wait for the server status to change to Started
. If another status is reported (such as Admin
or Failed
), check the server output log files for errors. For possible causes, see Section 19.13, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology."
Validate access to SOA_Cluster
using the following URLs:
http://wccinternal.example.com/soa-infra
http://wccinternal.example.com/integration/worklistapp
http://wccinternal.example.com/sdpmessaging/userprefs-ui
http://wccinternal.example.com/soa/composer
http://wccinternal.example.com/wsm-pm
For information on configuring system access through the load balancer, see Section 3.3, "Load Balancers."
Each server has a transaction log that stores information about the committed transactions coordinated by the server that may not have been completed. Oracle WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the Managed Servers within a cluster, store the transaction logs in a location accessible to each server and its backup servers.
Note:
The recommended location is on a dual-ported SCSI disk or on a Storage Area Network (SAN).To set the locations of the default persistence stores for the Oracle SOA Suite Managed Servers:
Log in to the WebLogic Server Administration Console.
In the Change Center section of the page, click Lock & Edit.
In the Domain Structure tree on the left, expand the Environment node, and then click the Servers node.
On the Summary of Servers page, click the name of the server WLS_SOA1 (represented as a hyperlink) in the Name column of the table. The settings page for the selected server opens and defaults to the Configuration tab.
On the Configuration tab, click the Services tab (not the top-level Services tab).
In the Default Store section of the page, enter the path to the folder where the default persistence store will store its data files. The directory structure of the path follows:
ASERVER_HOME/SOA_Cluster/tlogs/
In the reference topology, ASERVER_HOME
is the /u01/oracle/config/domains/WCCDomain
directory.
Repeat steps 4, 5, and 6 for the WLS_SOA2 server.
Click Save and Activate Changes.
Restart the WLS_SOA1 and WLS_SOA2 Managed Servers, using the WebLogic Server Administration Console.
After WLS_SOA1 and WLS_SOA2 are restarted, verify that the following DAT
files are created in this directory:
ASERVER_HOME/SOA_Cluster/tlogs/
_WLS_WLS_SOA1000000.DAT
_WLS_WLS_SOA2000000.DAT
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. Also, the directory must exist before you restart the servers.Oracle recommends using host name verification for communication between Node Manager and the servers in the domain. This requires the use of certificates for the different addresses communicating with the Administration Server and other servers. For more details, see Chapter 16, "Setting Up Node Manager for an Enterprise Deployment." The procedures in that chapter must be performed for the Oracle WebCenter Content deployment.
The procedures in Section 16.3, "Enabling Host Name Verification Certificates for Node Manager," must be performed for the hosts and Oracle SOA Suite Managed Servers in the following table.
Host Name (HOST) | Virtual IP Address (VIP) | Server Name (WLS_SERVER) |
---|---|---|
WCCHOST1 | WCCHOST1VHN1 | WLS_SOA1 |
WCCHOST2 | WCCHOST2VHN1 | WLS_SOA2 |
For server migration of Oracle SOA Suite Managed Servers, you need to associate these servers with the specified virtual host names. Check that these virtual host names are enabled by DNS or /etc/hosts
resolution in your system and that they map to the appropriate virtual IP addresses. For more information, see Section 3.4, "IP Addresses and Virtual IP Addresses."
Server migration is required for proper failover of the Oracle SOA Suite components in the event of failure in any of the WCCHOST1 and WCCHOST2 nodes. See Chapter 17, "Configuring Server Migration for an Enterprise Deployment" for further details. For Oracle SOA Suite, use the following values for the variables in that chapter:
Server names:
WLS_SERVER1: WLS_SOA1
WLS_SERVER2: WLS_SOA2
Host names:
HOST1: WCCHOST1
HOST2: WCCHOST2
Cluster name:
CLUSTER: SOA_Cluster
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 that point, the regular deployment-specific backup and recovery process can be initiated. The 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 that guide. For information on how to recover components, see the "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" section in the guide. For information about database backup, see the Oracle Database Backup and Recovery Guide.
To back up the installation at this point:
Back up Oracle Web Tier on WEBHOST1:
Shut down the instance using opmnctl
:
/u02/oracle/config/webN/bin/opmnctl stopall
Back up the Middleware home for Oracle Web Tier with the following command (as root):
tar -cvpf BACKUP_LOCATION/web.tar MW_HOME
Back up the Oracle instance for Oracle Web Tier with the following command:
tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE
Start the instance with opmnctl
:
cd /u02/oracle/config/webN/bin
opmnctl startall
Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or operating system tools such as tar for cold backups if possible.
Back up the Administration Server and Managed Server domain directories to save your domain configuration. The configuration files all exist in the /u01/oracle/config/domains/WCCDomain directory. Run the following command on WCCHOST1 to create the backup:
tar -cvpf edgdomainback.tar /u01/oracle/config/domains/WCCDomain