Create a new JMS Server for UMS: for example, UMSJMSServer_N. Use the For BPM Systems only For BPM systems only

11-4 Oracle Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Name the new managed server WLS_SOAn, where n is a number that identifies the new managed server. In this case, assume that you are adding a new server to Node 1, where WLS_SOA1 was running. The remainder of the steps assume that you are adding a new server to SOAHOST1, which is already running WLS_SOA1. 2. For the listen address, assign the host name or IP to use for this new managed server. If you are planning to use server migration as recommended for this server, enter the VIP also called a floating IP to enable it to move to another node. The VIP should be different from the one used by the managed server that is already running. 3. For WLS_WSM servers, run the Java Object Cache configuration utility again to include the new server in the JOC distributed cache as described in Section 4.17, Configuring the Java Object Cache for Oracle WSM. You can use the same discover port for multiple WSM-PM servers in the same node. Repeat the steps provided in Section 4.17 for each WSM-PM server and the server list is updated. 4. Create JMS servers for SOA and UMS on the new managed server. a. Use the Oracle WebLogic Server Administration Console to create a new persistent store for the new SOAJMSServer which will be created in a later step and name it, for example, SOAJMSFileStore_N. Specify the path for the store as recommended in Section 2.3, Shared Storage and Recommended Directory Structure as the directory for the JMS persistent stores: ORACLE_BASE admindomain_namecluster_namejmsSOAJMSFileStore_N

b. Create a new JMS server for SOA: for example, SOAJMSServer_N. Use the

SOAJMSFileStore_N for this JMS server. Target the SOAJMSServer_N server to the recently created managed server WLS_SOAn. c. Create a new persistence store for the new UMS JMS server which will be created in a later step and name it, for example, UMSJMSFileStore_N. Specify the path for the store as recommended in Section 2.3, Shared Storage and Recommended Directory Structure as the directory for the JMS persistent stores: ORACLE_BASE admindomain_namecluster_namejmsUMSJMSFileStore_N

d. Create a new JMS Server for UMS: for example, UMSJMSServer_N. Use the

UMSJMSFileStore_N for this JMS server. Target the UMSJMSServer_N server to the recently created managed server WLS_SOAn. Note: This directory must exist before the managed server is started or the start operation will fail. Note: This directory must exist before the managed server is started or the start operation will fail. Note: It is also possible to assign SOAJMSFileStore_N as the store for the new UMS JMS servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps. Managing the Topology 11-5

e. For BPM Systems only

: Create a new persistence store for the new BPMJMSServer, for example, BPMJMSFileStore_N. Specify the path for the store. This should be a directory on shared storage as recommended in Section 2.3, Shared Storage and Recommended Directory Structure. ORACLE_BASEadmindomain_namecluster_namejmsBPMJMSFileStore_ N.

f. For BPM systems only

: Create a new JMS Server for BPM, for example, BPMJMSServer_N. Use the BPMJMSFileStore_N for this JMSServer. Target the BPMJMSServer_N Server to the recently created Managed Server WLS_ SOAn. g. Target the UMSJMSSystemResource to the SOA_Cluster as it may have changed during extend operations. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click UMSJMSSytemResource and open the Targets tab. Make sure all of the servers in the SOA_Cluster appear selected including the recently cloned WLS_SOAn. h. Update the SubDeployment Targets for SOA, UMS and BPM JMS Modules if applicable to include the recently created JMS servers. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Oracle WebLogic Server Administration Console. The JMS Modules page appears. Click on the JMS module for SOA: SOAJMSModule, for BPM: BPMJMSMOdule and for UMS: UMSSYtemResource represented as a hyperlink in the Names column of the table. The Settings page for module appears. Open the SubDeployments tab. The subdeployment for the deployment module appears. Click on it. Add the new JMS Server for UMS add UMSJMSServer_N, for SOA add SOAJMSServer_N. Click Save and Activate. 5. Configuring Oracle Coherence for deploying composites for the new server as described in Section 5.5, Configuring Oracle Coherence for Deploying Composites. Note: This directory must exist before the managed server is started or the start operation fails. You can also assign SOAJMSFileStore_N as store for the new BPM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps. Note: This subdeployment module name is a random name in the form of SOAJMSServerXXXXXX, UMSJMSServerXXXXXX, or BPMJMSServerXXXXXX, resulting from the Configuration Wizard JMS configuration for the first two servers WLS_SOA1 and WLS_ SOA2. 11-6 Oracle Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter 6. Configure the persistent store for the new server. This should be a location visible from other nodes as recommended in Section 2.3, Shared Storage and Recommended Directory Structure. From the Administration Console, select the Server_name , and then the Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files. 7. Disable host name verification for the new managed server. Before starting and verifying the WLS_SOAN managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in SOAHOSTn. If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required the hostname verification settings is propagated to the cloned server. To disable host name verification:

a. In the Oracle Fusion Middleware Enterprise Manager Console, select Oracle