8 Upgrading a Clustered SOA Environment
- Upgrading a Clustered Topology
- Understanding the SOA Cluster Upgrade Topology
- Using Secured Task Forms in a Clustered Topology
The task form is a Java Server Page XML (.jspx) file that you create in the Oracle JDeveloper designer where you created the SOA composite containing the human task. - Propagating Domain Configuration to Another Host
After verifying that the upgrade was sucessful, use these steps to propagate the newly upgraded files to another host. - Post-Upgrade Tasks for Cluster Upgrades
Upgrading a Clustered Topology
Table 8-1 lists the steps required to upgrade the example clustered, multi-host Oracle SOA Suite topology illustrated in Figure 8-1.
Table 8-1 Oracle SOA Suite and BPM Cluster Upgrade Roadmap
Task | For More Information |
---|---|
Review the upgrade topology, and identify |
|
Shut down the Administration Server, all the Managed Servers, and the Node Managers running on |
|
Perform a complete upgrade of your 11g deployment on |
See Upgrading SOA Suite and Business Process Management from 11g See Also: If Business Activity Monitoring (BAM) is part of your domain, see Upgrading a SOA with Oracle BAM Domain to 12c If Oracle Service Bus (OSB) is part of your domain, see Upgrading Oracle Service Bus (without Oracle SOA Suite) from 11g |
After a successful upgrade, propagate the domain configuration of To do this, you must pack the domain on |
|
Restart the Administration Server and the Managed Servers on |
|
Perform any additional post-upgrade configuration tasks for your environment. |
Parent topic: Upgrading a Clustered SOA Environment
Understanding the SOA Cluster Upgrade Topology
Figure 8-1 shows a sample topology of a clustered Oracle SOA Suite deployment with SOA, Oracle Web Services Manager (OWSM), Oracle Service Bus (OSB) and Oracle Business Activity Monitoring (Oracle BAM) in separate clusters across two application hosts, SOAHOST1 and SOAHOST2. The Oracle HTTP Server, Administration Server, Oracle Enterprise Manager Fusion Middleware Control and database are shared with both hosts.
Specifically, this chapter describes the steps required to upgrade a WebLogic domain that contains multiple WebLogic Server clusters that are scaled out to multiple host computers. You can apply the concepts and procedures in this chapter to your own specific Oracle SOA Suite environment.
The steps required to upgrade this sample topology are described in the next section in Table 8-1.
Note:
If you are upgrading Oracle BAM with SOA, see Upgrading a SOA with Oracle BAM Domain to 12c.
Parent topic: Upgrading a Clustered SOA Environment
Using Secured Task Forms in a Clustered Topology
The task form is a Java Server Page XML (.jspx) file that you create in the Oracle JDeveloper designer where you created the SOA composite containing the human task.
If your SOA composite includes a human task form, or if task forms are deployed on non-SOA servers, then you must secure the task form after the upgrade.
Parent topic: Upgrading a Clustered SOA Environment
Propagating Domain Configuration to Another Host
After verifying that the upgrade was sucessful, use these steps to propagate the newly upgraded files to another host.
After you have completed your single node upgrade on SOAHOST1
, use these steps to propagate the newly upgraded files to another node (in this example the secondary host is called SOAHOST2
).
- Executing the pack command on the server where the Admin Server and one of the Managed Servers is installed.
- Executing the unpack Command from the 12c Oracle Home on SOAHOST2.
- Copying the template file created on SOAHOST 1 to SOAHOST2.
- Completing the following verification steps after the unpack.
Parent topic: Upgrading a Clustered SOA Environment
Executing the pack command on the server where the Admin Server and one of the Managed Servers is installed.
In our sample topology, you would execute the following on SOAHOST1
:
cd
/12c_ORACLE_HOME/oracle_common/common/bin
./pack.sh -domain=/
11g_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true
In this example:
-
12c_ORACLE_HOME refers the actual path to the 12c Oracle home directory (the installation directory for the 12c (12.2.1.3.0)bits).
-
Replace 11g_DOMAIN_HOME with the actual path to the upgraded domain directory.
-
domainupgradetemplate.jar
is a sample name for the jar file you are creating, which will contain the domain configuration files. -
domainupgradetemplate
is the name assigned to the domain template file. -
By default, the
domainupgradetemplate
is created in the current directory where you ran the pack command. In this example, it would be created in the following directory, but you can specify a full path for the template jar file as part of the-template
argument to the pack command:ORACLE_COMMON_HOME/common/bin/
The pack
command creates a template archive (.jar) file that contains a snapshot of either an entire domain or a subset of a domain. You can use a template that contains a subset of a domain to create a Managed Server domain directory hierarchy on a remote machine.
Parent topic: Propagating Domain Configuration to Another Host
Executing the unpack Command from the 12c Oracle Home on SOAHOST2.
unpack
command to create a full domain (or a subset of a domain) used for a Managed Server domain directory on the remote machine. You may use unpack only with a template compatible with your current installation.
Note:
Do not attempt to unpack the domain on top of an existing domain. Oracle recommends that you unpack the contents of the domain upgrade template jar file into a new domain location.It is important to note that even if you use the -overwrite_domain=true
argument when unpacking the domain, the contents of the existing domain will remain in place and will cause issues with when starting the servers. For this reason, Oracle recommends that you unpack the domain template jar file into a new location, or, manually delete the contents of the existing location before you unpack.
A sample unpack command code snippet is shown below.
cd /12c_ORACLE_HOME/oracle_common/common/bin
./unpack.sh -template=domainupgradetemplate.jar - domain=
NEW_DOMAIN_LOCATION
In this example:
-
12c_ORACLE_HOME refers the actual path to the 12c Oracle home directory, the installation directory for the 12c (12.2.1.3.0).
-
Replace NEW_DOMAIN_LOCATION with the actual path to the upgraded domain directory.
-
domainupgradetemplate.jar
is a sample name for the jar file you are creating, which will contain the domain configuration files. -
domainupgradetemplate
is the name assigned to the domain template file.
Parent topic: Propagating Domain Configuration to Another Host
Copying the template file created on SOAHOST 1 to SOAHOST2.
Use the following command to copy from SOAHOST1 the domain upgrade template JAR file created during the upgrade.
scp soadomaintemplate.jar company@SOAHOST2:12c_ORACLE_HOME/oracle_common/common/bin
Parent topic: Propagating Domain Configuration to Another Host
Completing the following verification steps after the unpack.
-
Verify that WL_HOME, SOA_ORACLE_HOME, UMS_ORACLE_HOME in setDomainEnv.sh script from 11g domain are pointing to 12c.
-
Start the Node Manager, WebLogic Administration Server, and the Managed Servers on SOAHOST1 and SOAHOST2 in the following order:
-
On SOAHOST1 and SOAHOST2, start the Node Manager.
-
On SOAHOST1, start the WebLogic Administration Server.
-
On SOAHOST1 and SOAHOST2, start the Managed Servers.
-
For more information, see Starting Servers and Processes. Carefully review the order in which Managed Servers should be started.
If you cannot start the servers or experience other technical issues, see Troubleshooting the Upgrade
Note:
During the upgrade, the Node Manager configuration files (nodermanager.properties, for example) are moved from 11g_DOMAIN_HOME/wlserver_10.3/ location to the 11g_ORACLE_HOME/ domains/DOMAIN_HOME/nodemanager location. Therefore, the node manager in 12c has to be started from the 11g_DOMAIN_HOME domain directory.
Parent topic: Propagating Domain Configuration to Another Host
Post-Upgrade Tasks for Cluster Upgrades
After a successful cluster upgrade, you may need to perform additional post-upgrade configurations tasks. Perform only those tasks that pertain to your clustered environment.
- Starting the Admin Server and SOA Managed Servers
Restart the Oracle WebLogic Administration server and any other SOA Managed servers. - Removing OWSM Targets from SOA and OSB Clusters
- Updating OWSM Cross-Component Wiring
- Reapplying an EDNTopic to SOA JMS Module After Cluster Upgrade
- Preventing Duplicate Messages When Using JMS Transport Proxy Service
Parent topic: Upgrading a Clustered SOA Environment
Starting the Admin Server and SOA Managed Servers
Restart the Oracle WebLogic Administration server and any other SOA Managed servers.
Start the Administration Server
When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.
To start an Administration Server, use the following script:
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows)DOMAIN_HOME\bin\startWebLogic.cmd
When prompted, enter your user name, password and the URL of the administration server
Start the Managed Servers
Start the WebLogic Server Managed Servers with the following script:
(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
When prompted, enter your user name and password.
- Oracle Web Services Manager (OWSM) Managed Server
-
Service-Oriented Architecture (SOA) Managed Server
-
Oracle Service Bus (OSB) Managed Server
-
Business Activity Monitoring (BAM) Managed Server
Note:
The startup of a Managed Server will typically start the applications which are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.Parent topic: Post-Upgrade Tasks for Cluster Upgrades
Removing OWSM Targets from SOA and OSB Clusters
If your 12c domain includes an Oracle Web Services Manager (OWSM) in its own cluster and you have extended that domain with a SOA cluster and an OSB cluster, then post upgrade you must manually untarget the wsm-pm from the SOA and OSB clusters.
To remove the owsm-pm target from the SOA and OSB clusters:
-
Log in to the WebLogic Server Administration Console 12c.
Enter the following URL in a browser:
http://host name:port_number/console
The port number is the port number of the Administration Server. By default, the port number is 7001.
The login page is displayed.
-
Select Deployments from Domain Structure.
-
Select wsm-pm under Deployments.
-
In the settings for wsm-pm, select Targets.
-
Select wsm-pm component of type Enterprise Application and select Change Targets.
-
Uncheck SOA cluster and OSB cluster.
-
When prompted, click Yes to apply the changes.
-
REQUIRED: Once the wsm-pm is targeted only to the OWSM cluster, you must rewire the components as described in Updating OWSM Cross-Component Wiring.
Parent topic: Post-Upgrade Tasks for Cluster Upgrades
Updating OWSM Cross-Component Wiring
After you have removed OWSM targets from SOA and OSB clusters as described in Removing OWSM Targets from SOA and OSB Clusters, you must rewire the OWSM Policy Manager components as described below:
-
Start the Administration (admin) server and one OWSM server.
-
Log in to the Oracle Enterprise Manager Fusion Middleware Control 12c console and navigate to the Cross Components Wiring > Components option.
-
Select OWSM Policy Manager from the list of available components:
-
From the Service End Points table, select the OWSM Policy Manager t3 connection entry and click Publish. The status will change from Out of Sync to Published.
-
Select OWSM Agent from the Component Type list. Select the t3 connection entry and click Bind.
-
Verify that the Service Type for the service end point is OWSM Policy Manager.
-
Repeat steps 5 and 6 to Bind the remaining component types. In this example, you will select com.oracle.ess and Fusion Middleware Control.
Parent topic: Post-Upgrade Tasks for Cluster Upgrades
Reapplying an EDNTopic to SOA JMS Module After Cluster Upgrade
After upgrading a SOA Cluster domain to 12.2.1, the upgraded SOA JMS module may be missing the EDNTopic. If the JMS module is missing the EDNTopic, you must manually add the topic or UDD for this topic using the Administration Console or WLST.
See the Administration Console online help for more information on reapplying the EDNTopic.
Parent topic: Post-Upgrade Tasks for Cluster Upgrades
Preventing Duplicate Messages When Using JMS Transport Proxy Service
In a 12c cluster domain, jmsServers are targeted to migratable targets, which is different from the default behavior in 11g where jmsServers were targeted to an individual server.
When you configure a 12c proxy service based on the JMS transport, set the topic distribution mode to One-Copy-Per-Application or One-Copy-Per-Server. To prevent duplicate messages, do not use Compatibility mode in a clustered environment.
Parent topic: Post-Upgrade Tasks for Cluster Upgrades