| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite 11g Release 1 (11.1.1) Part Number E12036-08 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite 11g Release 1 (11.1.1) Part Number E12036-08 |
|
|
PDF · Mobi · ePub |
This chapter describes the procedures for extending the domain to include Oracle BPM.
This chapter contains the following section:
Section 10.1, "Overview of Extending the Domain to include Oracle BPM"
Section 10.2, "Option 1: Extending a Domain to Include SOA and BPM"
Section 10.3, "Option 2: Extending a SOA Domain to Include Oracle BPM"
You can install and configure Oracle BPM in a Fusion Middleware installation in the following two ways:
Extend an existing domain that contains an Administration Server (and optionally other non-SOA servers) to include SOA and BPM (in one single Configuration Wizard session). Table 10-1 summarizes this approach. For configuration steps, see Section 10.2, "Option 1: Extending a Domain to Include SOA and BPM."
Extend a domain that already contains SOA (and optionally other non-SOA servers) to BPM. Table 10-2 summarizes this approach. For configuration steps, see Section 10.3, "Option 2: Extending a SOA Domain to Include Oracle BPM."
Table 10-1 Steps for Extending tan existing Domain to include SOA and BPM
| Step | Description | More Information |
|---|---|---|
|
Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2 |
Enable a VIP mapping for each of the hostnames. |
Section 10.2.1, "Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2" |
|
Run the Configuration Wizard to Extend the Domain |
Run the Configuration Wizard from the SOA home directory to extend a domain containing an Administration Server and Oracle Web Services Manager to support SOA and BPM components. |
Section 10.2.2, "Running the Configuration Wizard on SOAHOST1 to Extend the Current Domain" |
|
Configure Oracle Coherence for Deploying Composites |
Configure Oracle Coherence in order to use unicast communication for deploying composites. |
Section 10.2.3, "Configuring Oracle Coherence for Deploying Composites" |
|
Setting Connection Destination Identifiers for B2B Queues |
Set the Create Destination Identifier (CDI) for JMS Destination Member calls. |
Section 10.2.4, "Setting Connection Destination Identifiers for B2B Queues" |
|
Disabling Host Name Verification for the WLS_SOAn Managed Servers |
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 BPM. |
Section 10.2.5, "Disabling Host Name Verification for the WLS_SOAn Managed Servers" |
|
Propagate the Domain Changes to the Managed Server Domain Directory |
Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory. |
Section 10.2.6, "Propagating the Domain Changes to the Managed Server Domain Directory" |
|
Start and Validate the WLS_SOA1 Managed Server |
Start and validate the WLS_SOA1 managed server using the Oracle WebLogic Server Administration Console. |
Section 10.2.7, "Starting and Validating the WLS_SOA1 Managed Server" |
|
Propagate the Domain Configuration to SOAHOST2 |
Propagate the Domain Configuration to SOAHOST2 Using the Unpack Utility. |
Section 10.2.8, "Propagating the Domain Configuration to SOAHOST2 Using the Unpack Utility" |
|
Extract the XEngine Files in SOAHOST2 |
To enable B2B's XEngine in SOAHOST2, extract the content of the XEngine tar manually. |
|
|
Start and Validate the WLS_SOA2 Managed Server |
Start the WLS_SOA2 managed server and check that it is configured correctly. |
Section 10.2.10, "Starting and Validating the WLS_SOA2 Managed Server" |
|
Configure the Oracle HTTP Server for WLS_SOAn Managed Servers |
Enable Oracle HTTP Server to route to the SOA_Cluster. |
Section 10.2.11, "Configuring Oracle HTTP Server for WLS_SOAn Managed Servers" |
|
Validating Access Through Oracle HTTP Server |
Verify that the server status is reported as Running. |
Section 10.2.12, "Validating Access Through Oracle HTTP Server" |
|
Setting the Frontend HTTP Host and Port |
Set the frontend HTTP host and port for the Oracle WebLogic Server cluster. |
|
|
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 10.2.14, "Configuring a Default Persistence Store for Transaction Recovery" |
|
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 10.2.15, "Enabling High Availability for Oracle File and FTP Adapters" |
Table 10-2 Steps for Extending an Existing Domain that Already includes SOA
| Step | Description | More Information |
|---|---|---|
|
Run the Configuration Wizard on SOAHOST1 to Extend a SOA Domain to Include BPM |
Run the Configuration Wizard from the SOA home directory to extend a domain containing an Administration Server and Oracle Web Services Manager to support SOA and BPM components. |
Section 10.3.1, "Running the Configuration Wizard on SOAHOST1 to Extend a SOA Domain to Include BPM" |
|
Propagate the Domain Configuration to the managed server directory in SOAHOST1 and to SOAHOST2 |
Oracle BPM Suite requires some updates to the WebLogic Server start scripts. Propagate these changes using the pack and unpack commands. |
|
|
Start the BPM Suite Components |
For configuration changes and start scripts to be effective, restart the WLS_SOAn server to which BPM has been added. |
|
|
Configure Oracle HTTP Server for the WLS_SOAn Managed Servers |
Enable Oracle HTTP Server to route to BPM web applications by setting the WebLogicCluster parameter to the list of nodes in the cluster. |
Section 10.3.4, "Configuring Oracle HTTP Server for the WLS_SOAn Managed Servers" |
|
Validating Access Through Oracle HTTP Server |
Verify URLs to ensure that appropriate routing and failover is working from the HTTP Server to the BPM Suite Components. |
Section 10.3.5, "Validating Access Through Oracle HTTP Server" |
Prerequisites for Extending the Domain to Include Oracle BPM
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.
To back up the existing Fusion Middleware Home and domain run the following command on SOAHOST1:
tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name
These commands create a backup of the installation files for both Oracle WebLogic Server and Oracle Fusion Middleware, as well as the domain configuration.
There is an existing WL_HOME and ORACLE_HOME installed in previous chapters on a shared storage.
This section describes how to extend a domain with SOA and BPM components using the Configuration Wizard. You can extend the resulting domain to add BAM. It is assumed that a SOA ORACLE_HOME (binaries) has already been installed, patched to latest patch set if applicable, and is available from SOAHOST1 and SOAHOST2. it is also assumed that a domain with an Administration Server has been created. This is the domain that is extended in this chapter to support SOA components.
Note:
Oracle strongly recommends reading the release notes for any additional installation and deployment considerations prior to starting the setup process.
This section contains the following topics:
Section 10.2.1, "Enabling VIP2 on SOAHOST1 and VIP3 on SOAHOST2"
Section 10.2.2, "Running the Configuration Wizard on SOAHOST1 to Extend the Current Domain"
Section 10.2.3, "Configuring Oracle Coherence for Deploying Composites"
Section 10.2.4, "Setting Connection Destination Identifiers for B2B Queues"
Section 10.2.5, "Disabling Host Name Verification for the WLS_SOAn Managed Servers"
Section 10.2.6, "Propagating the Domain Changes to the Managed Server Domain Directory"
Section 10.2.7, "Starting and Validating the WLS_SOA1 Managed Server"
Section 10.2.8, "Propagating the Domain Configuration to SOAHOST2 Using the Unpack Utility"
Section 10.2.10, "Starting and Validating the WLS_SOA2 Managed Server"
Section 10.2.11, "Configuring Oracle HTTP Server for WLS_SOAn Managed Servers"
Section 10.2.12, "Validating Access Through Oracle HTTP Server"
Section 10.2.14, "Configuring a Default Persistence Store for Transaction Recovery"
Section 10.2.15, "Enabling High Availability for Oracle File and FTP Adapters"
Associate the WLS_SOA1 Server and WLS_SOA2 with virtual hostnames (SOAHOST1VHN1 and SOAHOST2VHN1). Check that these virtual hostnames are enabled by DNS or /etc/hosts resolution in your system and that they map to the appropriate VIPs (VIP2 and VIP3). These procedures are required for server migration.
To enable the virtual IP on Linux:
Run the ifconfig command as root:
/sbin/ifconfig <interface:index> IPAddress netmask netmask /sbin/arping -q -U -c 3 -I interface IPAddress
For example:
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
Enable your network to register the new location of the virtual IP, for example:
/sbin/arping -q -U -c 3 -I ethX 100.200.140.206
Validate that the address is available by pinging it from another node, for example
/bin/ping 100.200.140.206
In this example ethX is the ethernet interface (eth0 or eth1) and Y is the index (0, 1, 2).
Run the Configuration Wizard from the SOA home directory to extend a domain containing an Administration Server and Oracle Web Services Manager to support SOA and BPM components.
To extend the domain for Oracle BPM:
Ensure that the database where you installed the repository is running. For Oracle RAC databases, Oracle recommends all instances remain running, so that the validation check later in the process is more reliable.
Change the directory to the location of the Configuration Wizard. This is within the SOA home directory.
cd ORACLE_COMMON_HOME/common/bin
Start the Oracle Fusion Middleware 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 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:
Select the following products:
Oracle BPM Suite - 11.1.1.0 [soa]
Oracle SOA Suite - 11.1.1.0 [soa] (this should be selected automatically when selecting Oracle BPM Suite)
Oracle WSM Policy Manager 11.1.1.0 [oracle_common] (this should be selected automatically when selecting Oracle BPM Suite)
Oracle Enterprise Manager - 11.1.1.0 [oracle_common]
Oracle JRF - 11.1.1.0 [oracle_common] (this should be selected automatically and grayed out)
If you accidentally deselect some of the targets, make sure the following are selected:
Oracle SOA
Oracle BPM Suite
Click Next.
In the Configure JDBC Component Schema screen, do the following:
Select SOA Infrastructure, User Messaging Service, and SOA MDS Schema.
Select Configure selected component schemas as RAC multi data source schemas in the next panel.
Figure 10-1 Configure JDBC Component Schema Screen
Click Next.
The Configure RAC Multi Data Source Component Schema screen is displayed. In this screen, enter values for the fields below, specifying the connect information for the Oracle RAC database that was seeded with RCU. Enter this information for each schema (you can select multiple schemas and specify values that are common to all):
Figure 10-2 Configure RAC Multi Data Source Component Schema Screen
In this screen, do the following:
You can select all schemas and enter values that are common to all. Leave the OWSM MDS Schema information as it is, since it was already configured in Chapter 8.
Enter values for the following fields, specifying the connect information for the Oracle RAC database that was seeded with RCU. Enter this information for each schema:
Enter the host name, instance name, and port for the first Oracle RAC DB instance.
Click Add.
Repeat for each Oracle RAC instance.
Driver: Select Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11.
Service Name: Enter the service name of the database, for example, soaedg.mycompany.com
Username: Enter the complete user name (including the prefix) for the schemas. You can enter a value with all schemas selected (like the prefix) and then select each schema individually to change the rest of the schema name
Password: Enter the password to use to access the schemas.
Click Next.
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 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 all Fusion Middleware Components' JMS Modules.
Note:
Oracle does not support using WDDs for Fusion Middleware components
In the Configure Managed Servers screen, add the required managed servers.
A server named soa_server1 is created automatically. Rename this to WLS_SOA1 and add a new server named WLS_SOA2. Give these servers the attributes listed in Table 10-3. Do not modify the other servers that appear in this screen; leave them as they are.
Table 10-3 Managed Servers
| Name | Listen Address | Listen Port | SSL Listen Port | SSL Enabled |
|---|---|---|---|---|
|
WLS_SOA1 |
SOAHOST1VHN1 |
8001 |
n/a |
No |
|
WLS_SOA2 |
SOAHOST2VHN1 |
8001 |
n/a |
No |
Click Next.
In the Configure Clusters screen, add the cluster listed in Table 10-4. Do not modify the other clusters that display in this screen; leave them as they are.
Table 10-4 Cluster
| Name | Cluster Messaging Mode | Multicast Address | Multicast Port | Cluster Address |
|---|---|---|---|---|
|
SOA_Cluster |
unicast |
n/a |
n/a |
SOAHOST1VHN1:8001,SOAHOST2VHN1:8001 |
Click Next.
In the Assign Servers to Clusters screen, assign servers to clusters as follows:
SOA_Cluster:
WLS_SOA1
WLS_SOA2
Click Next.
In the Configure Machines screen, do the following:
Click Delete to remove the default LocalMachine.
Click the Unix Machine tab. SOAHOST1 and SOAHOST2 machines appear with the following entries Table 10-5):
Leave all other fields to their default values.
Click Next.
In the Assign Servers to Machines screen, assign the servers to machines according to the following table:
Table 10-6 Assigning Servers to Machines
| Server | Machine |
|---|---|
|
AdminServer |
ADMINHOST |
|
WLS_SOA1 |
SOAHOST1 |
|
WLS_SOA2 |
SOAHOST2 |
|
WLS_WSM1 |
SOAHOST1 |
|
WLS_WSM2 |
SOAHOST2 |
Click Next.
In the Target Deployments to Clusters or Servers screen, ensure the following targets:
Target WSM-PM only to WSM-PM_Cluster.
Target the oracle.sdp.*, oracle.bpm.*, and oracle.soa.* deployments only to SOA_Cluster.
The oracle.rules.* library should be targeted only to Admin Server and SOA_Cluster.
Target the oracle.wsm.seedpolicies library only to WSM-PM_Cluster and SOA_Cluster (if the SOA_Cluster is going to contain any webservices itself).
Click Next.
In the Target Services to Clusters or Servers screen, target the mds-owsm, mdw-owsm-rac0 and mds-owsm-rac1 datasources to the WSM-PM_Cluster and the AdminServer and Click Next.
In the Configure JMS File Stores screen, enter the shared directory location specified for your JMS stores as recommended in Section 4.3, "About Recommended Locations for the Different Directories." For example:
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
Select Direct-write policy for all stores.
Click Next.
In the Configuration Summary screen click Extend.
In the Creating Domain screen, click Done.
You must restart the Administration Server for this configuration to take effect. to restart the Administration Server, use the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."
Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication in SOA 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 SOA enterprise deployments where multiple IPs 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 SOA system from starting. The deployment framework must be properly customized for the network environment on which the SOA 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 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 (SOAHOST1VHN1 and 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 10-3).
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.
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 10-3 Setting the Host Name Using the Start Server Tab of Oracle WebLogic Server Administration Console
Use the Administration Console to specify a host name used by Oracle Coherence.
To add the host name used by Oracle Coherence:
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 & Edit.
Click the Server Start tab (illustrated in Figure 10-3).
Enter the following for WLS_SOA1 and WLS_SOA2 into the Arguments field.
Note:
There should be no breaks in lines between the different -D parameters. Do not copy or paste the text to your Administration Console's arguments text field. It 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.
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=SOAHOST1VHN1 -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.
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=SOAHOST1VHN1 -Dtangosol.coherence.wka2=SOAHOST2VHN1 -Dtangosol.coherence.localhost=SOAHOST2VHN1
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 & 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:
B2B_OUT_QUEUE: jms/b2b/B2B_IN_QUEUE
B2B_IN_QUEUE: jms/b2b/B2B_OUT_QUEUE
B2BBroadcastTopic: jms/b2b/B2BBroadcastTopic
XmlSchemaChangeNotificationTopic: jms/fabric/XmlSchemaChangeNotificationTopic
Click Save and Active Changes.
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 BPM. Therefore, you must disable the host name verification for the WLS_SOAn managed server to avoid errors when managing the different WebLogic Servers. You enable host name verification again once the Enterprise Deployment topology configuration is complete. See Section 13.3, "Enabling Host Name Verification Certificates for Node Manager in SOAHOST1" for more information.
To disable host name verification:
Log in to Oracle WebLogic Server Administration Console.
Click Lock & 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 Steps 4 through 8 for the WLS_SOA2 server.
Save and activate the changes.
This change requires a restart of the Administration Server and Node Managers.
To restart the Administration Server see Section 8.4.3, "Starting the Administration Server on SOAHOST1.".
To restart Node Manager on SOAHOST1see Section 9.5.2, "Restarting the Node Manager on SOAHOST1."
Repeat for Node Manager in SOAHOST2
Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory.
To propagate start scripts and classpath configuration:
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:
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/ domain_name/aserver/domain_name -template=soadomaintemplateExtSOABPM.jar -template_name=soa_domain_templateExtSOABPM
Run the unpack command on SOAHOST1 to unpack the propagated template to the domain directory of the managed server:
./unpack.sh -domain=ORACLE_BASE/admin/ domain_name/mserver/domain_name -overwrite_domain=true -template=soadomaintemplateExtSOABPM.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.
Note:
The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.
Start and validate the WLS_SOA1 managed server using the Oracle WebLogic Server Administration Console.
To start the WLS_SOA1 managed server and check that it is configured correctly:
Start the WLS_SOA1 managed server using the Oracle WebLogic Server Administration Console as follows:
Expand the Environment node in the Domain Structure window.
Choose Servers.
The Summary of Servers screen appears.
Click the Control tab.
Select WLS_SOA1, then click Start.
Verify that the server status is reported as Running. 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 Chapter 16, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.
Access the following URLs:
http://SOAHOST1VHN1:8001/soa-infra/ to verify status of WLS_SOA1.
http://SOAHOST1VHN1:8001/soa/composer/ to verify status of SOA process composer.
http://SOAHOST1VHN1:8001/integration/worklistapp/ to verify status of the worklist application.
http://SOAHOST1VHN1:8001/b2bconsole/ to verify status of B2B.
http://SOAHOST1VHN1:8001/sdpmessaging/userprefs-ui/ to verify status of messaging system preferences
http://SOAHOST1VHN1:8001/bpm/composer/ and login to the composer application.
http://SOAHOST1VHN1:8001/bpm/workspace/ and login to the workspace application.
To propagate the domain configuration to SOAHOST2:
Run the following command on SOAHOST1 to copy the template file created in the previous step to SOAHOST2.
cd ORACLE_COMMON_HOME/common/bin scp soadomaintemplateExtSOABPM.jar oracle@node2:ORACLE_COMMON_HOME/common/bin
Run the unpack command on SOAHOST2 to unpack the propagated template:
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -overwrite_domain=true -template=soadomaintemplateExtSOABPM.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.
Note:
The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.
To enable B2B's XEngine in SOAHOST2, you need to extract the content of the XEngine tar manually:
cd ORACLE_HOME/soa/thirdparty/edifecs
tar -xzvf XEngine.tar.gz
To start the WLS_SOA2 managed server and check that it is configured correctly:
Start the WLS_SOA2 managed server using the Oracle WebLogic Server Administration Console as follows:
Expand the Environment node in the Domain Structure window.
Choose Servers.
The Summary of Servers screen appears.
Click the Control tab.
Select WLS_SOA2 and then click Start.
Verify that the server status is reported as Running. 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 Chapter 16, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.
Access the following URLs:
http://SOAHOST2VHN1:8001/soa-infra to verify status of WLS_SOA2.
http://SOAHOST2VHN1:8001/soa/composer to verify status of soa process composer.
Note:
The configuration is incorrect if no policies or assertion templates appear.
http://SOAHOST2VHN1:8001/integration/worklistapp to verify status of the worklist application.
http://SOAHOST2VHN1:8001/b2bconsole to verify status of B2B.
http://SOAHOST2VHN1:8001/sdpmessaging/userprefs-ui to verify status of messaging system preferences
http://SOAHOST2VHN1:8001/bpm/composer and login to the composer application.
http://SOAHOST2VHN1:8001/bpm/workspace and login to the workspace application.
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.
Some example 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.
To enable Oracle HTTP Server to route to the SOA_Cluster, which contains the WLS_SOAn managed servers, set the WebLogicCluster parameter to the list of nodes in the cluster.
To enable Oracle HTTP Server to route to the SOA_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>
# 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>
#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>
# BPM
<Location /bpm/composer>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# BPM
<Location /bpm/workspace>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
Make sure the httpd.conf file located in the same directory as the mod_wl_ohs file contains the following lines:
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName https://soa.mycompany.com:443
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName admin.mycompany.com:80
ServerAdmin you@your.address
RewriteEngine On
RewriteOptions inherit
</VirtualHost>
Note:
Values such as soa.mycompany.com:443, 7777, admin.mycompany:80, and you@youraddress that are noted in this document serve as examples only. Enter values based on the actual environment.
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
Verify that the server status is reported as Running. 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 16.13, "Troubleshooting the Topology in an Enterprise Deployment" 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://WEBHOST1:7777/soa-infra
http://WEBHOST2:7777/soa-infra
http://WEBHOST1:7777/soa/composer
http://WEBHOST2:7777/soa/composer
http://WEBHOST1:7777/integration/worklistapp
http://WEBHOST2:7777/integration/worklistapp
http://WEBHOST1:7777/sdpmessaging/userprefs-ui
http://WEBHOST2:7777/sdpmessaging/userprefs-ui
http://WEBHOST1:7777/b2bconsole
http://WEBHOST2:7777/b2bconsole
http://WEBHOST1:7777/bpm/composer
http://WEBHOST2:7777/bpm/composer
http://WEBHOST1:7777/bpm/workspace
http://WEBHOST2:7777/bpm/workspace
You can also verify these URLs using your load balancer address:
http://soa.mycompany.com:80/soa-infra
http://soa.mycompany.com:80/soa/composer
http://soa.mycompany.com:80/integration/worklistapp
http://soa.mycompany.com:80/sdpmessaging/userprefs-ui
http://soa.mycompany.com:80/b2bconsole
http://soa.mycompany.com:80/bpm/composer
http://soa.mycompany.com:80/bpm/workspace
For information on configuring system access through the load balancer, see Section 3.3, "Configuring 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: soa.mycompany.com
Frontend HTTPS Port: 443
Frontend HTTP Port: 80
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.
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 to http. Since the load balancer redirects HTTP to HTTPS this causes the following exception when testing webservices functionality 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 soa.mycompany.com (443/https) for external services and soainternal.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 soa.mycompany.com (443/https) in the Enterprise Deployment architecture. When only internal services are to be invoked, this can be set to soainternal.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.
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:
The recommended location is a dual-ported SCSI disk or on a Storage Area Network (SAN).
To set the location for the default persistence stores:
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 operations described in this section are 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 Oracle 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:
The steps and configuration options for the FTP adapter are exactly the same as the options for the file adapter. The connection factory to be used for FTP HA configuration is eis/Ftp/HAFtpAdapter which appears under the Outbound Connection Pools for the FTPAdapter deployment.
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 10-4.
Figure 10-4 Oracle WebLogic Server Console - Settings for javax.resource.cci.Connectionfactory Page
Click on Lock & 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 in the following directory:
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/SOADataSource. 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:
<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 to eis/HAFileAdapter for the connection factory.
The introduction of skip locking has superseded the previous best practice of using LogicalDeletePollingStrategy or DeletePollingStrategy with a unique MarkReservedValue on each polling node, and setting MaxTransactionSize. 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}.
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.
For more information, see "Scalability" and "Polling Strategies" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
In this step, you extend the domain created in Section 9, "Extending the Domain for SOA Components" to include Oracle BPM.
Prerequisites for Extending the SOA Domain to Include Oracle BPM
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.
To back up the existing Fusion Middleware Home and domain:
tar -cvpf fmwhomeback.tar ORACLE_BASE/product/fmw tar -cvpf domainhomeback.tar ORACLE_BASE/admin/domain_name/aserver/domain_name
These commands create a backup of the installation files for both Oracle WebLogic Server and Oracle Fusion Middleware, as well as the domain configuration.
There is an existing WL_HOME and SOA ORACLE_HOME (binaries) are installed in previous chapters on a shared storage and are available from SOAHOST1 and SOAHOST2 (this is required before the WebLogic Configuration Wizard steps are performed to extend the domain).
Node Manager, Admin Server, SOA Servers and WSM Servers exist and have been configured as described in previous chapters to run a SOA system. Server migration, transaction logs, coherence, and all other configuration steps for the SOA System have already been performed and will be used by BPM. BPM is added as a superset of the existing configuration.
This section contains the following topics:
Section 10.3.1, "Running the Configuration Wizard on SOAHOST1 to Extend a SOA Domain to Include BPM"
Section 10.3.4, "Configuring Oracle HTTP Server for the WLS_SOAn Managed Servers"
Section 10.3.5, "Validating Access Through Oracle HTTP Server"
Run the Configuration Wizard from the SOA home directory to extend a domain containing an Administration Server and Oracle Web Services Manager to support SOA and BPM components.
Change the directory to the location of the Configuration Wizard. This is within the SOA home directory. Domain extensions are run from the node where the Administration Server resides.
cd ORACLE_COMMON_HOME/common/bin
Start the Oracle Fusion Middleware 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 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:
Select the following product:
Oracle BPM Suite - 11.1.1.0 [soa]
In the Configure JDBC Component Schema screen, accept existing values (schemas created in the existing SOA system) and click Next.
BPM uses the same DataSources as the existing soa-infra system.
In the Optional Configuration screen, select the following:
JMS Distributed Destinations
Deployments and Services
Click Next.
In the Select JMS Distributed Destination Type screen, select UDD from the drop down list for BPMJMSModule. Leave existing modules as they are.
In the Target Deployments to Clusters or Servers screen, ensure the following targets:
Target WSM-PM only to WSM-PM_Cluster.
Target usermessagingserver and usermessagingdriver-email only to SOA_Cluster. (The usermessaging-xmpp, usermessaging-smpp, and usermessaging-voicexml applications are optional.)
Target the oracle.sdp.*, oracle.bpm.*, and oracle.soa.* libraries only to SOA_Cluster.
Target the oracle.rules.* library to SOA_Cluster and Admin Server.
Target the oracle.wsm.seedpolicies library only to WSM-PM_Cluster and SOA_Cluster.
Click Next.
In the Target Services to Clusters or Servers screen, target the mds-owsm, mds-owsm-rac0 and mds-owsm-rac1 datasources to the WSM-PM_Cluster and the AdminServer and click Next.
In the Configure JMS File Stores screen, enter the shared directory location specified for your JMS stores as recommended in Section 4.3, "About Recommended Locations for the Different Directories." For example:
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
Select Direct-write policy for all stores.
Click Next.
In the Configuration Summary screen click Extend.
In the Creating Domain screen, click Done.
You must restart the Administration Server for this configuration to take effect. To restart the Administration Server, use the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."
Oracle BPM Suite requires some updates to the WebLogic Server start scripts. Propagate these changes using the pack and unpack commands.
To propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory:
Create a backup copy of the managed server domain directory and the managed server applications directory.
Run the pack command on SOAHOST1 to create a template pack:
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/ domain_name/aserver/domain_name -template=soadomaintemplateExtBPM.jar -template_name=soa_domain_templateExtBPM
Run the unpack command on SOAHOST1 to unpack the propagated template to the domain directory of the managed server:
./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -overwrite_domain=true -template=soadomaintemplateExtBPM.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.
Copy the template to SOAHOST2:
cd ORACLE_COMMON_HOME/common/bin scp soadomaintemplateExtBPM.jar oracle@SOAHOST2:/ORACLE_HOME/common/bin
Run the unpack command on SOAHOST2 to unpack the propagated template:
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name/ -overwrite_domain=true -template=soadomaintemplateExtBPM.jar -app_dir=ORACLE_BASE/admin/ domain_name/mserver/applications
Note:
The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.
For configuration changes and start scripts to be effective, you must restart the WLS_SOAn server to which BPM has been added. Since BPM extends an already existing SOA system, the Administration Server and respective Node Managers are already running in SOAHOST1 and SOAHOST2.
To start the added BPM components:
Restart the WLS_SOA1 managed server:
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_SOA1 from the Servers column of the table.
Click Shutdown. Wait for the shutdown to complete (refresh the WebLogic Server Console page to verify shutdown status).
Click Start.
Repeat steps a-f for WLS_SOA2.
To enable Oracle HTTP Server to route to BPM web applications, you must set the WebLogicCluster parameter to the list of nodes in the cluster.
To set the parameter:
Add the following lines to the ORACLE_BASE/ admin/instance_name/config/OHS/component_name/mod_wl_ohs.conf file:
# BPM
<Location /bpm/composer >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
# BPM
<Location /bpm/workspace >
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN1:8001,SOAHOST2VHN1:8001
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
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
Since the cluster address for the SOA_Cluster has already been set in the previous chapter, the BPM system can only be verified once Oracle HTTP Server has been configured to route the BPM context URLs to the WebLogic Servers. Verify URLs to ensure that appropriate routing and failover is working from the HTTP Server to the BPM Suite Components.
For information on configuring system access through the load balancer, see Section 3.3, "Configuring the Load Balancer."
To verify the URLs:
While WLS_SOA is running, stop WLS_SOA1 using the Oracle WebLogic Server Administration Console.
Access WebHost1:7777/bpm/composer and WebHost1:7777/bpm/workspace to verify the appropriate functionality for BPM project Composer.
Start WLS_SOA1 from the Oracle WebLogic Server Administration Console.
Stop WLS_SOA2 from the Oracle WebLogic Server Administration Console.
Access WebHost1:7777/bpm/composer and WebHost1:7777/bpm/workspace to verify the appropriate functionality for BPM Workspace.
You can also verify these URLs using your load balancer address:
http://soa.mycompany.com:80/bpm/composer
http://soa.mycompany.com:80/bpm/workspace
After you have verified that the extended domain is working, back up the domain configuration. This is a quick backup for the express purpose of immediate restore in case of failures in future procedures. Back up the configuration to the local disk. This backup can be discarded once you have completed the enterprise deployment. Once you have completed the enterprise deployment, you can initiate the regular deployment-specific backup and recovery process.
For information about backing up the environment, see "Backing Up Your Environment" in the Oracle Fusion Middleware Administrator's Guide. For information about recovering your information, see "Recovering Your Environment" in the Oracle Fusion Middleware Administrator's Guide.
To back up the domain configuration:
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 are located in the following directory:
ORACLE_BASE/ admin/domain_name
To back up the Administration Server run the following command on SOAHOST1:
tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
Note:
Back up ORACLE_HOME if any changes are made to the XEngine configuration that is part of your B2B setup. These files are located in the following directory:
ORACLE_HOME/soa/thirdparty/edifecs/XEngine
To back up ORACLE_HOME:
tar -cvpf fmwhomeback.tar MW_HOME
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|