Performing OSM Post-Installation Tasks

OSM Client Configuration Post-Installation Tasks

The following sections provide post-installation instructions relating to the OSM Order Management web client and the OSM Task web client.

Enabling Graphical Display on UNIX or Linux Systems

To display graphical representations such as orchestration plans on UNIX or Linux systems, OSM requires an Xserver such as Xvfb (X virtual framebuffer), an X11 server that is available for most UNIX or Linux platforms.

The following steps apply to Oracle Solaris. For other operating systems, refer to the respective product documentation.

Obtain and install Xvfb for your operating system.

Refer to your OS product documentation for specifics on Xvfb. On Solaris, Xvfb is included in the SUNWxwsrv package.
Start the Xvfb X server.

When starting Xvfb, disable host-based access control restrictions by providing the -ac option on the command line. For example:
```
Xvfb :1 -ac
```
Set the value of the DISPLAY environment variable to the host where you want the display to show, and the display number. Export the DISPLAY variable. For example, in the sh shell, type:
```
export DISPLAY=localhost:1
```
Note:

This command assumes X server is running on display number 1 and on the same computer where WebLogic Server is running. If you have a different configuration, specify the IP address of the computer where the X server is running instead of localhost.
For convenience, you can place the Xvfb and DISPLAY setting commands in your user account configuration shell script or in the WebLogic Server startup script (startWebLogic.sh) so that they run when you start OSM.
If you are running on Solaris 5.10, add the following statement to the Java command line in the startWebLogic.sh file for your WebLogic server domain:
```
-Djava.awt.headless=true
```
If the above statement is missing from the Java command line, the following error may occur:
```
-X10: fatal IO error 22 (invalid argument) on X server "localhost:
```
In addition, performance and stability issues may occur when OSM accesses the server's display.

If you are running multiple instances of OSM on the same system, set up a dedicated Xvfb server for each instance.

To set up dedicated Xvfb servers for multiple instances of OSM:

Start one instance of the Xvfb server on display 1:
```
Xvfb :1
```
Set the value of the DISPLAY environment variable in the first WebLogic server domain instance to 1:
```
DISPLAY=localhost:1
```
Start the first WebLogic server domain instance.
Repeat steps 1 to 3 for each additional OSM instance running on the same system.

Note:

You must increment the Xvfb server display and the DISPLAY environment variable by one for each additional OSM instance. For example, the second instance would have a value of 2 for the Xvfb server display and the DISPLAY environment variable.

Connection, File Store, and Thread Configuration Post Installation Tasks

The following sections include post installation tasks for configuring connections, file stores, and threads.

Customizing OSM Run-Time Parameters

After installation, you may want to change OSM run-time parameters. For example, you can increase the number of rows in a worklist, or update the OSM administrator's e-mail address.

OSM run-time parameters are configured in the oms-config.xml file. You can access this file in the domain_home directory.

For details, see the chapter describing the oms-config.xml file in OSM System Administrator's Guide.

Preventing Connection Timeout Issues During Cartridge Deployment

When deploying large cartridges to an OSM system with many managed servers, you may receive cartridge deployment timeout errors. To resolve this error, increase the cartridge deployment timeout setting. The default cartridge deployment timeout setting is 600 seconds (10 minutes), but you can increase this value to a maximum of 3600 seconds (60 minutes).

To modify the default cartridge deployment timeout setting, change the value for the CartridgeDeploymentTransactionTimeout parameter in the domain_home/oms-config.xml file on each machine in the cluster. For example:

<oms-parameter>
<oms-parameter-name>com.mslv.oms.cartridgemgmt.DeployCartridgeMDB.CartridgeDeploymentTransactionTimeout</oms-parameter-name>
<oms-parameter-value>3600</oms-parameter-value>
</oms-parameter>

For more information about changing this oms-config.xml parameter, see OSM System Administrator's Guide.

To override this default setting for a specific cartridge, you can specify this parameter as an OSM Cartridge Management Variables in Design Studio. You must use the full parameter name.

com.mslv.oms.cartridgemgmt.DeployCartridgeMDB.CartridgeDeploymentTransactionTimeout

For more information, see the Design Studio Help.

Note:

If an order has stopped processing due to a timeout, the order must be aborted. It will not resume processing even after the timeout value has been increased.

Configuring OSM JDBC Connections

The OSM installer creates JDBC connections that enable WebLogic communication to the Oracle RAC database instances.

The Statement Timeout value specifies the amount of times before the database terminates SQL statements that are taking too long to complete. This value is the WebLogic Server domain Java transaction API (JTA) timeout value plus 2 seconds giving the database enough time to react to a JTA timeout. The oracle.jdbc.ReadTimeout value stops the database from reading a socket after the Statement Timeout. These values should not be modified without making corresponding changes to each other. For more information about setting the JTA timeout value, see "Preventing Connection Timeout when Using a Remote Database."

The Statement Cache Size value determines the number of SQL statements that can remain in the statement cache. In a production environment, you can start this value at 30 and increasing the value only if you cannot improve parse ratios by tuning the cursors. For a development environment, the default setting of 10 is enough.

To configure the OSM JDBC Connections, do the following:

Log in to the WebLogic Server Administration Console.

The WebLogic Administration Console is displayed.
Click Lock & Edit.
In Domain Structure, select Services, then Data Sources.

The Summary of JDBC Data Sources screen is displayed.
Select an OSM JDBC data source. The OSM JDBC data source are as follows:
```
osm_pool_sid_group_y
```
where sid is the Oracle RAC database instance system identifier and y is the group letter.

The Configuration tab is displayed
Click the Connection Pools tab.
Click Advanced.
In the Properties field, add the following:
```
oracle.jdbc.ReadTimeout=value
```
where value is the Statement Timeout value converted to milliseconds plus 2000 milliseconds.

For example, if the Statement Timeout value is 602 seconds, then the oracle.jdbc.ReadTimeout should be 604000 milliseconds.
In the Statement Cache Size field, enter a value from 30 to 40 in a production environment.
Click Save.
Repeat steps 3 to 9 for all other OSM JDBC connections.
Click Activate Changes.

Creating and Configuring Persistent File Stores

A persistent file store provides storage for WebLogic Server subsystems and services that require persistence. For example, a file store can store JMS messages. The OSM installer uses the default file store for each managed server and associated OSM JMS servers in the cluster.

Oracle recommends that you create a persistent file store for each managed server in the cluster and for the associated JMS server pairs of each managed server. If the managed servers are configured for whole server migration, ensure that the persistent stores are located in a shared directory.

To create and configure a persistent file store:

Create or ensure that a directory exists for the persistent file stores. The directory must exist on your system, so ensure that it is already created.

Note:

When a custom file store is targeted to a migratable target, the specified directory must be accessible from all candidate server members in the migratable target. For highest reliability, use a shared storage solution that is itself highly available, for example, a storage area network (SAN) or a dual-ported SCSI disk.
Log in to the WebLogic Server Administration Console.

The WebLogic Administration Console is displayed.
Click Lock & Edit.
In the Domain Structure tree, expand Services and select Persistent Stores.

The Summary of Persistent Stores page is displayed.
Click New and then click Create FileStore.

The Create a New File Store page is displayed.

Note:

After you create a file store you cannot rename it. You must delete it and create another one with a different name.
Enter the following:
- Name: The name of the file store.
- Target: The server instance or migratable target on which you want to deploy the file store.
  
  Note:
  
  In a clustered environment, it is recommended that you target a custom file store to the same migratable target as the migratable JMS server, so that a member server is not a single point of failure.
- Directory: The path name to the directory on the file system where the file store is kept.
Click OK.
On the Summary of Persistent Stores page, select the file store that you just created.
Click the Configuration tab and update Advanced parameters, as required:
- Logical Name: Optional name that can be used by subsystems that need a way to refer to different stores on different servers using the same name.
- Synchronous Write Policy: Specifies how this file store writes data to disk.
Click Save.
In the left pane, expand Services and then Messaging, and then select JMS Servers.

The Summary of JMS Servers page is displayed.
In an OSM cluster, the OSM installer creates the following JMS servers in pairs:
```
oms_jms_server_managed_server
osmJmsNonMigratableServer_managed_server
```
where managed_server is the managed server that the JMS server is associated with.

Note:

For a non-clustered managed server, the name of the JMS server is: oms_jms_server.

Select the one from the managed server pair that will use the custom file store.
On the settings page for the JMS server, click the Configuration tab, and then the General sub-tab.
In Persistent Store, select the custom file store that you want for the JMS server.
Click Save.

For more information about configuring general JMS server properties, see WebLogic Server Administration Console Help.
In the Change Center of the Administration Console, click Activate Changes.

Note:

Not all changes take effect immediately. For some changes you must restart WebLogic Server.
Repeat steps 11 to 16 for the other JMS server in the JMS server pair.
Repeat steps 3 to 16 for each managed server in the cluster.

Externalizing the Coherence Thread Configuration File

For better access and visibility to the osm-distributed and osm-invocation thread-count values, you can also put the osm-coherence-cache-config.xml in a location external to the oms.ear file where each WebLogic server can access it. In addition, doing this enables you to specify different osm-coherence-cache-config.xml files for each managed server with custom thread-count settings for each managed server if you require.

To externalize osm-coherence-cache-config.xml:

From the machine running the administration server, open a terminal.
Extract and modify the osm-coherence-cache-config.xml file from the oms.ear file as described in the previous procedure, but do not add the file back to security.gar.
Copy the file to domain_home/osm-coherence-cache-config.xml.
Extract the security.gar file from the oms.ear file using the following command.
```
jar xvf oms.ear security.gar
```
Extract the META-INF/coherence-application.xml directory and file using the following command.
```
jar xvf security.gar META-INF/coherence-application.xml
```

Open the coherence-application.xml file and replace the existing content with the following text:

<?xml version="1.0"?>
<coherence-application xmlns="http://xmlns.oracle.com/coherence/coherence-application">
        <cache-configuration-ref override-property="cache-config/OsmGar">META-INF/osm-coherence-cache-config.xml
</cache-configuration-ref>
</coherence-application>

Save coherence-application.xml and add it back to the security.gar file using the following command:
```
jar uvf security.gar META-INF/coherence-application.xml
```
Update the oms.ear file with the updated security.gar file using the following command:
```
jar uvf oms.ear security.gar
```
Log in to the WebLogic Server Administration Console.
In the Domain Structure tree, expand Environment, then click Servers.

The Summary of Servers screen is displayed.
Ensure that the managed servers in the OSM cluster are in the Running state.
In the Domain Structure tree click Deployments.

The Summary of Deployments screen is displayed.
Click Lock & Edit.
In the Name column, select the check box beside oms.
Click Update.

The Update Application Assistant screen appears.
In the Source path row, click Change Path.
In the Path field, enter the path to the modified oms.ear file.
From the Current Location area, select oms.ear.
Click Next.
Click Next.
Click Finish.
In the Domain Structure tree expand Environment, then click Coherence Clusters.

The Summary of Coherence Clusters screen is displayed.
From the Name Column, select osmCoherenceClusternnnn (where nnnn is a random number that OSM installer generates when it creates the coherence cluster for OSM).

The Configuration tab is displayed.
Click the Cache Configurations sub tab.
Click New.
In the Name field, enter a name.
In the JNDI Name field, enter OsmGar.
In the Cache Configuration File field, enter domain_home/osm-coherence-cache-config.xml.

For example:
```
/u01/app/oracle/config/domains/wls1213_domain/osm-coherence-cache-config.xml
```
Click Next.
In the Clusters table, select Part of the cluster, and the select all the managed servers in the cluster.
Click Finish.
click Activate Changes.
In the Domain Structure tree, expand Environment, then click Servers.

The Summary of Servers screen is displayed.
Restart all managed servers in the cluster.

Copying Metric Rule Files

A set of XML files called ADML files contains the metric rules that allow the system to collect aggregated metric data about your system. OSM Order Metrics Manager allows the data that the system gathers to be displayed in any metric client. The OSM installation includes an interface called Oracle Dynamic Monitoring Service (DMS), which displays this metric data in a set of metrics tables.

In some configurations, the Middleware_home location for the administration server is separate from Middleware_home locations for OSM managed servers. In this case, you must remotely copy the domain-oracle_comms_osm-11.0.xml file from the ADML directory of an OSM managed server to the ADML directory of the administration server.

The metric rules files are automatically installed in the correct directory when you first start the OSM server. Metric rules files are installed in the ADML directory, as in the following example:

Middleware_home/oracle_common/modules/oracle.dms/adml

If this directory is not accessible to the OSM server, you must copy the files using the procedure in this section.

Note:

You might have to run the procedure in this section several times. If the administration server does not share the domain directory or the Middleware_home directory with a managed server, the system does not create the oms_dms directory and you must copy ADML files manually to the administration server's Middleware_home directory.

To copy metric rules files:

Start an OSM WebLogic managed server.
Go to the domain_home/osm_dms directory.
Do one of the following:
- As a UNIX or Linux user with write permission to the ADML directory, run the following script:
```
copyAdmlFiles.sh
```
- As a Windows user with write permission to the ADML directory, run the following script:
```
copyAdmlFiles.bat
 
```
This script copies the ADML files domain-oracle_comms_osm-11.0.xml and server-oracle_comms_osm-11.0.xml to the Middleware_home/oracle_common/modules/oracle.dms/adml directory.

For a graphical representation of the metrics data, you can use the Oracle Communications Application Management Pack interface for Oracle Enterprise Manager Cloud Control 12c. For more information about installing and configuring Application Management Pack, see Oracle Application Management Pack for Oracle Communications System Administrator's Guide. For more information about Enterprise Manager, see Oracle Enterprise Manager Cloud Control Basic Installation Guide.

Note:

If you are using Internet Explorer 11 as the web browser to access Oracle Enterprise Manager Cloud Control 12.1.0.4, you must update Oracle Enterprise Manager Cloud Control 12.1.0.4 with the following patch:

Patch 20465665: MERGE REQUEST ON TOP OF 11.1.1.7.1 FOR BUGS 18680326 14739854 19933990

Download the patch from the Oracle support website at:

https://support.oracle.com

Instructions for applying the patch are provided in the patch Read me file.

For more information about accessing the DMS interface to view metrics tables, as well as using Application Management Pack to graphically view metrics data, see the topic about metrics data in OSM System Administrator's Guide.

Relocating ADML Files Without Restarting the Server

Whether the files are copied automatically by the OSM server or manually, DMS locates the new ADML files when you restart the WebLogic servers. You can also have DMS locate the ADML files immediately, without restarting the servers.

To have DMS locate new ADML files without restarting the servers:

Do one of the following:
- If you are a UNIX or Linux user, run the following script:
```
Middleware_home/oracle_common/common/bin/wlst.sh
```
- If you are a Windows user, run the following script:
```
Middleware_home/oracle_common/common/bin/wlst.cmd
```
  Note:
  
  You cannot use the wlst.sh or wlst.cmd scripts in the WebLogic_home/common/bin directory because these scripts do not have the Oracle JRF extensions enabled.
At the command prompts, run the following command:
```
connect('user','password','t3://hostname:port')
```
where user is the user name of the WebLogic administrator, password is the password of the WebLogic administrator, hostname is the name of the administration server and port is the administration server port number. For more information about using WLST over a secure connection, see the security section of OSM System Administrator's Guide.
Load the metric rules files by running the following command:
```
reloadMetricRules()
```
The system loads the metric rules files in the ADML directory. This command shows the metric rules of all the managed servers and the administration server. If one of the OSM ADML files is missing from the reported files list for a server, ensure that the Middleware_home directory for that server has the ADML files correctly deployed.
Open the setDomainEnv.sh file from the domain_home/bin directory of the administration server.

Add the following string to the JAVA_OPTIONS property:

-Dweblogic.management.disableManagedServerNotifications=true

Registering Oracle HTTP Server Instance

To view metrics data using Application Management Pack, you must have Oracle HTTP Server configured and running in OSM. For more information, see Setting up an Oracle HTTP Server for OSM Cluster Load Balancing [Doc ID 1618630.1] knowledge article on the Oracle support website at:

https://support.oracle.com

You must also register the Oracle HTTP Server instance in OSM.

To register the Oracle HTTP Server instance:

Start an OSM WebLogic administration server.
Go to the bin directory of the Oracle HTTP Server instance, for example, OHS_Instance_HOME/bin.
Run the following command:
```
opmnctl registerinstance -adminHost hostname -adminPort port
```
where hostname is the name of the OSM WebLogic administration host machine and port is the port of the OSM WebLogic administration server.

The Oracle HTTP Server instance is registered in the OSM server.

Queue Configuration Post Installation Tasks

The following sections provide instructions for configuring OSM and solution queues after installing OSM.

Configuring Distributed Queues for an OSM Solution

In addition to the distributed queues that OSM creates during installation, you may need to create and configure your own custom distributed queues to support your particular OSM solution.

Use the following high-level steps to create and configure a distributed queue and its members:

Create the member queues, one per managed server pinned to each JMS server.
Create the distributed queue with equally-weighted member queues and target the distributed queue to the cluster.
Confirm that the distributed queue is accessible and visible to all managed servers in the cluster.

To create the member queues:

In the WebLogic Administration Console, expand Services, Messaging, and then select JMS Modules.
On the Summary of JMS Modules page, select oms_jms_module.

Note:

You must use the predefined JMS system module to allow the connection factory to deliver messages to the correct managed server. Do not create a new JMS system module.
On the Configuration page, above the Summary of Resources table, click New.
On the Create a New JMS System Module Resource page, select Queue and click Next.
On the JMS Destination Properties page, enter the name and JNDI name of the member queue, and then click Next.
Select the subdeployment you want to assign to the queue.

The number of subdeployments should equal the number of JMS servers, and hence managed servers configured in the cluster.
Upon selection of a subdeployment, the queue is automatically assigned to the correct JMS server.
Click Finish. The newly created member queue is displayed in the resources list.
Repeat steps 2-8 to create a queue for each managed server in the cluster.

For information about using JMS queues, see OSM System Administrator's Guide.

To create the distributed queue:

On the Configuration page, above the Summary of Resources table, click New.
On the Create a New JMS System Module Resource page, select Distributed Queue and click Next.
On the JMS Distributed Destination Properties page, do the following:
1. Enter the name and JNDI name of the distributed queue.
2. Ensure the Load Balancing Policy is set to Round-Robin.
3. Deselect Allocate Members Uniformly.
Click Next.
From the Members Available list, select the newly created queues and move them to the Chosen list.
Click Finish. The distributed queue is displayed in the resources list.

To confirm that the distributed queue is visible to each server in the cluster:

Navigate to the Summary of Servers page and select a managed server.
On the Configuration page, click the View JNDI Tree link.
Verify that the distributed queue is visible to the managed server.
Repeat steps 1-3 for each managed server in the cluster.

Configuring Separate Error Queues

Messages added to an error queue from an internal OSM queue are encoded, so you cannot determine which queue the error originated from. To assist in troubleshooting, you can create separate error queues with appropriate names for each of the internal OSM queues and target the OSM queues to these new error queues. For more information about creating queues, consult the Oracle WebLogic Server documentation.

OSM Integration with External Systems

The following sections describe OSM integration tasks between OSM, Oracle Communications ASAP, and Oracle Communications Unified Inventory Management (UIM). These integration tasks are also applicable for OSM integration with other remote applications.

Configuring Domain Trust

You should enable domain trust when SAF is configured, as it is needed for robust inter-domain communication using distributed destinations. Domain trust relies on the use of a shared password, which provides access to all domains that participate in the trust. Strict password management is critical.

If you use SAF without domain trust configured, you may experience unstable SAF behavior in your environment.

For details about enabling global trust, see "Enabling Global Trust" in Oracle Fusion Middleware Administering Security for Oracle WebLogic Server.

Integrating OSM and ASAP or IP Service Activator Using SAF Agent and JMS Bridging

To ensure reliable communication Oracle recommends that you create a Store-and-Forward (SAF) agent and JMS bridge between the Oracle Communications ASAP WebLogic server or Oracle Communications IP Service Activator WebLogic server and the OSM WebLogic server.

Figure 8-1 illustrates an example SAF and JMS bridge configuration between the web service interface on ASAP and a web service client on OSM. An example SAF and JMS bridge configuration between the web service interface on IP Service Activator and a web service client on OSM would appear the same.

Figure 8-1 SAF Agent and JMS Bridge Configuration Between OSM and ASAP

Description of "Figure 8-1 SAF Agent and JMS Bridge Configuration Between OSM and ASAP"

In this example, an OSM SAF agent sends requests to the ASAP request queue, and ASAP returns responses through the ASAP SAF agent to the OSM reply-to queue. In addition, ASAP sends work order state changes from the JSRP XVTEventTopic through a JMS bridge with a SAF agent to the OSM event queue.

For detailed instructions for creating SAF and JMS bridges between ASAP and OSM, see Configuring WebLogic Resources for OSM Integration With ASAP And UIM On Different Domains (Doc ID 1431235.1) knowledge article on the Oracle support website at:

https://support.oracle.com

This article is also applicable to IP Service Activator or to any other remote application that uses a WebLogic JMS server to send and receive web service or JMS messages.

Note:

When using the above instructions with any remote application other than ASAP, remember to change any reference to ASAP to the remote application for which you are creating bridges. For example, change ASAP to IPSA.

Integrating OSM and UIM Using SAF Agent

Oracle recommends that you create a SAF agent between the UIM WebLogic server and the OSM WebLogic server. Oracle recommends this SAF agent for the web service interfaces to ensure reliable communication.

Figure 8-2 illustrates an example SAF configuration between the web service interface on UIM and a web service client on OSM.

Figure 8-2 SAF Agent Configuration Between OSM and UIM

Description of "Figure 8-2 SAF Agent Configuration Between OSM and UIM"

In this example, an OSM SAF agent sends requests to the UIM request queue, and UIM returns responses through the UIM SAF agent to the OSM reply-to queue.

For detailed instructions for creating SAF agents between UIM and OSM, see Configuring WebLogic Resources for OSM Integration With ASAP And UIM On Different Domains (Doc ID 1431235.1) knowledge article on the Oracle support website at:

https://support.oracle.com

This article is applicable to any remote application that uses a WebLogic JMS server to send and receive web service messages.

Changing the WebLogic Server or Oracle RAC Database Size

The following sections describe how to change the number of managed servers in a cluster or the Oracle RAC database size.

Connecting Oracle RAC with JDBC Multi Data Source

During installation, the OSM installer prompts for the database parameters of the Oracle RAC instances and automatically creates the appropriate configuration in a JDBC multi data source. If you decide to manually configure your JDBC data source, you must understand the following discussion.

At the application layer, OSM maintains WebLogic Server order affinity. That is, all processing of an order is performed exclusively by one WebLogic Server instance, to minimize serialization. The OSM application cannot ensure all database operations for a particular order maintained by a WebLogic Server instance are directed to the same Oracle RAC instance. Thus, the approach to preserve Database Server order affinity is to have each WebLogic Server instance connect to only one Oracle RAC instance at any instant.

OSM uses a multi data source consisting of two data sources, each of which connects to an Oracle RAC database instance. Using the failover algorithm, the first data source is the primary data source and the other data source is the secondary data source. Under normal operation, only the primary data source is connected and used. When the primary data source fails, the multi data source chooses the next available data source as the primary data source.

The failover algorithm is used in both active-passive and active-active topologies. However, the configuration of the data source members within the multi data source is different:

In active-passive Oracle RAC, all instances in the WebLogic Server cluster are configured to the PREFERRED Oracle RAC database instance as the primary data source, and to the AVAILABLE Oracle RAC database instance as the secondary. Upon database failure, all WebLogic Server instances transition from the PREFERRED Oracle RAC database instance to the AVAILABLE Oracle RAC database instance.

Figure 8-3 illustrates this configuration.

Figure 8-3 Data Source Configuration for Oracle RAC Active-Passive

Description of "Figure 8-3 Data Source Configuration for Oracle RAC Active-Passive"
In active-active Oracle RAC, WebLogic Server instances are partitioned. Half of the WebLogic Server instances are configured to one Oracle RAC database instance as the first data source and to the other Oracle RAC database instance as the second data source. The other half in the WebLogic Server cluster are configured with the sequence of the Oracle RAC database instances swapped. As a result, if one of the Oracle RAC database instances fails, half the WebLogic Server instances failover to the remaining Oracle RAC database instance, which is already handling the database operations of half of the WebLogic Server cluster.

Figure 8-4 illustrates this configuration.

Figure 8-4 Data Source Configuration for Oracle RAC Active-Active

Description of "Figure 8-4 Data Source Configuration for Oracle RAC Active-Active"

In the active-active Oracle RAC configuration, the use of the failover algorithm (as opposed to a load-balancing algorithm) may appear counter-intuitive. However, keep in mind that load balancing in an active-active Oracle RAC configuration is not managed at the multi data source layer, but rather by partitioning the instances in the WebLogic Server cluster. There is no dynamic load balancing between WebLogic instances and database instances.

The relationship of a WebLogic instance and database instance in an active-active Oracle RAC configuration is many-to-one. That is, more than one WebLogic instance may choose the same database instance as its primary database instance, but a WebLogic instance cannot choose more than one database instance as its primary database instance. When you add a new database instance, you can either reassign an existing WebLogic instance to it, or create a new WebLogic instance.

WebLogic Server instances must be partitioned appropriately to load-balance with active-active Oracle RAC. The recommended approach is to have an even number of physical application servers with the same hardware dimensioning and weight. You should monitor the performance of your WebLogic and database instances to ensure they are not overloaded or under utilized. You can add more WebLogic instances to a database instance that is not fully utilized, or reassign a WebLogic instance to another database instance that is overloaded.

When a WebLogic Server cluster resizes, the ownership of an order is reassigned. The cache transfer of records from one database instance to another has a temporary impact on performance.

Adding Oracle RAC Instances

You can add a Oracle RAC instance to your environment in the following roles:

As an additional passive backup instance in an active-passive environment.
As a passive backup instance in an active-active environment. The new instance connects to the existing WebLogic partitions through new secondary data sources connected to the existing multi data sources.

Figure 8-5 shows an example of adding a third Oracle RAC instance as a backup in an active-active environment. The figure shows the new Oracle RAC instance and data sources in bold. Note that no WebLogic partition uses RAC3 as a primary instance.

Figure 8-5 Data Sources for a Third Backup Oracle RAC Instance in an Active-Active Environment

Description of "Figure 8-5 Data Sources for a Third Backup Oracle RAC Instance in an Active-Active Environment"
As an active instance in an active-active environment. Choose this option for higher availability. The new instance connects to:
- A new WebLogic group through a new primary data source configured in a new multi data source.
- The existing WebLogic groups through new secondary data sources configured in existing multi data sources.
Figure 8-6 shows an example of adding a third Oracle RAC instance as an active member of an active-active environment. The figure shows the new elements in bold. Note that each Oracle RAC instance serves as a primary instance for a new WebLogic group.

Figure 8-6 Data Sources for a Third Active Oracle RAC Instance in an Active-Active Environment

Description of "Figure 8-6 Data Sources for a Third Active Oracle RAC Instance in an Active-Active Environment"

See the following for more information:

For grouping and adding new managed servers, see the WebLogic Server documentation and "Adding a New Managed Server to a Clustered Environment."
For adding a new Oracle RAC instance and partitioning the OSM database schema, see the Oracle Database documentation and OSM System Administrator's Guide.
For adding new data sources and multi data sources, see "Manually Configuring Additional Data Sources for an Oracle RAC Instance."

Manually Configuring Additional Data Sources for an Oracle RAC Instance

OSM supports high availability in the database layer through configuration of Oracle Real Application Clusters (Oracle RAC) for either:

Failover, also known as warm standby or active-passive Oracle RAC.
Load balancing, or active-active Oracle RAC.

Each WebLogic Server instance in the OSM cluster interacts with Oracle RAC through a WebLogic multi data source configured for failover with multiple data sources, one for each Oracle RAC instance. This setup is used for both active-passive and active-active configurations. In an active-active configuration, load balancing is achieved by evenly distributing the clustered server nodes into groups in an alternating fashion.

During installation, the OSM installer automatically creates the appropriate data source configuration for the first Oracle RAC instance. You can let it automatically configure data sources for additional Oracle RAC instances, or you can choose to manually configure additional data sources after installation.

If you choose to manually configure additional data sources after installation, the Installer automatically creates the following:

Two data sources: osm_pool_rac1_group_a and osm_pool_rac1_group_b.
Two multi data sources: oms_pool_group_a and oms_pool_group_b

You must configure additional data sources as described in "Manually Creating and Configuring Data Sources." The number of additional data sources you configure depends on the number of Oracle RAC instances and your environment's configuration type.

For a second Oracle RAC instance:

In an active-passive configuration, create one new data source.
In an active-active configuration, create two new data sources.

For additional Oracle RAC instances beyond the second:

In an active-passive configuration, the new Oracle RAC instance is an additional backup instance. Create one new data source to connect the existing multi data sources to the new Oracle RAC instance.
In an active-active configuration, the new Oracle RAC instance can be one of the following:
- A passive backup instance. Create new data sources connecting each existing multi data source to the new Oracle RAC instance. See Figure 8-6 for a detailed example.
- An active instance. Create a new multi data source and 2n-1 new data sources, where n is the total number of Oracle RAC instances. Of the new data sources, n connect the new multi data source to the Oracle RAC instances, and n-1 connect the existing multi data sources to the new Oracle RAC instance.
  
  For example, if you are adding a third Oracle RAC instance, you would create five new data sources: three to connect the new multi data source to each Oracle RAC instance, and two to connect the existing multi data sources to the new Oracle RAC instance.
  
  See Figure 8-6 for a detailed example.

Manually Creating and Configuring Data Sources

To create and configure additional data sources for an Oracle RAC instance:

Log in to the WebLogic Administration Server Console.
In the Domain Structure tree, expand Services, JDBC, then select Data Sources.
On the Summary of JDBC Data Sources page, click New.
On the JDBC Data Sources Properties page, do the following:
- Enter a name for the JDBC data source.
  - If you have an active-passive configuration, name the data source osm_pool_n where n is the number of the new Oracle RAC instance.
    
    For example, if you are adding a third Oracle RAC instance, name the new data source osm_pool_3.
  - If you have an active-active configuration, name the data source osm_pool_racn_group_x, where n and x represent the Oracle RAC instance and WebLogic group that the data source connects.
    
    For example, if you are adding a third Oracle RAC instance, one of the new data sources will be called osm_pool_rac3_group_c. It connects to the third Oracle RAC instance and the WebLogic group called group_c.
- Enter a unique JNDI name for the data source in either configuration. For example, oracle/communications/osm/internal/jdbc/pool_3.
- Select Oracle as the database type.
- Click Next.
Select one of the following non-XA thin drivers and click Next:
- If your Oracle RAC database is configured with a remote listener (the default), select *Oracle's Driver (Thin) for RAC Service-Instance connections; Versions: 10 and later.
- If your Oracle RAC database is configured with local listeners, select *Oracle's Driver (Thin) for Instance connections; Versions: 9.0.1 and later.
On the Transaction Options page, do the following:
1. Ensure the default option Supports Global Transactions is selected.
2. Select the Logging Last Resource option.
3. Click Next.
On the Connection Properties page, specify the service name, database name, host, and port of the additional Oracle RAC instance based on one of the following scenarios:
- If your Oracle RAC database is configured with a remote listener and server-side load balancing (the default):
  1. Specify the same the host, port, and service name as those specified for the existing data sources.
  2. Specify the unique instance name of the new Oracle RAC instance. The instance name is required in order to override server-side load balancing. See "Listener Considerations for Oracle RAC" for a full discussion of listener functionality.
  For example, if an existing data source URL is:
```
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host1.oracle.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl)(INSTANCE_NAME=orcl1)))
```
  The new data source URL will specify the same host, port, and service name, and a unique instance name, as follows:
```
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host1.oracle.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl)(INSTANCE_NAME=orcl2)))
```
- If your Oracle RAC database is configured with local listeners only:
  1. Specify either a different host or port than the host or the port of the existing data sources.
  2. Specify either the same service name or a unique instance name, depending on which the existing data sources specify. If the existing data sources specify both, the new data source must as well.
  For example, if the existing data source URL is:
```
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host1.oracle.com)(PORT=1521)))(CONNECT_DATA=(INSTANCE_NAME=orcl1)))
```
  The new data source URL will specify a different host, and only specify the instance name, as follows:
```
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host2.oracle.com)(PORT=1521)))(CONNECT_DATA=(INSTANCE_NAME=orcl2)))
```
- Enter the OSM database schema user name and password, and then confirm the password.
- Click Next.
On the Test Database Connection page, do one of the following:
- Review the connection parameters and click Test Configuration.
  
  WebLogic attempts to create a connection from the administration server to the database. Results are displayed at the top of the page. If the test is unsuccessful, you should correct any configuration errors and retry the test.
  
  Click Next.
- If the JDBC driver you selected is not installed on the administration server, click Next to skip this step.
On the Select Targets page, do one of the following:
- If you have an active-passive configuration, target the new data source to the entire cluster.
- If you have an active-active configuration, target the data source to one group in the cluster.
  
  For example, in Figure 8-6, the new data sources ending in group_a are targeted to the group_a servers, the new data sources ending in group_b are targeted to the group_b servers, and the new data sources ending in group_c are targeted to the group_c servers.
Click Finish.

Your configuration is saved and the data source is deployed to the cluster.
Configure the connection properties for the new data source. See "Configuring Connection Pool Properties."
Repeat the previous steps for each required new data source.
Add the new data sources to multi data sources. See "Adding Data Sources to Multi Data Sources."

Configuring Connection Pool Properties

In addition to the properties you defined in the previous section, you must configure the data source's connection pool properties.

To configure the connection pool properties, do the following:

Select the data source and navigate to the Connection Pool tab.
In the Properties list, enter oracle.net.CONNECT_TIMEOUT=10000.
In the Initial Capacity field, enter 0.
Click Advanced options.
Select the Test Connections on Reserve check box.
In the Test Frequency field, enter 300.
In the Test Table Name field, enter SQL SELECT 1 FROM DUAL.
In the Seconds to Trust an Idle Pool Connection, enter 10.
In the Shrink Frequency field, enter 900.
Save your changes.

Adding Data Sources to Multi Data Sources

You can make all data source and multi data source changes in a single edit session. You do not have to activate your changes between steps.

For any number of new Oracle RAC instances, add the new data sources to the existing multi data sources as described in "Adding Data Sources to an Existing Multi Data Source." For Oracle RAC instances beyond the second instance, you must also create a new multi data source, and add some of the new data sources to it, as described in "Creating a New Multi Data Source."

Note:

Oracle recommends that you shut down all managed servers before changing the order of the data sources as described in the procedure below because the order affects the name of the Oracle Coherence cluster when OSM starts.

Adding Data Sources to an Existing Multi Data Source

To add new data sources to an existing multi data source:

In the Domain Structure tree, expand Services, then select Data Sources.
On the Summary of Data Sources page, click a multi data source name.

Click the Configuration Data Sources tab, and do one of the following:

For an active-passive configuration, move the data source that you want to include in the multi data source to the Chosen list.

For an active-active configuration, add the data sources to the multi data sources in an rotating order so that no data source appears in the same rank twice.

For example, if you have three multi data sources, the data sources must appear in the order shown in Table 8-1.

Table 8-1 Example Data Source Order

Multi Data Source	Data Source List
oms_pool_group_a	osm_pool_rac1_group_a osm_pool_rac3_group_a osm_pool_rac2_group_a
oms_pool_group_b	osm_pool_rac2_group_b osm_pool_rac1_group_b osm_pool_rac3_group_b
oms_pool_group_c	osm_pool_rac3_group_c osm_pool_rac2_group_c osm_pool_rac1_group_c

See "Adding Oracle RAC Instances" for an illustration of how these data sources and multi data sources connect to Oracle RAC instances and WebLogic partitions.

Save your changes.
Repeat the previous steps for each multi data source.

Creating a New Multi Data Source

To create a new multi data source and add the new data sources to it:

In the Domain Structure tree, expand Services, then select Data Sources.
On the Summary of Data Sources page, click New and select Multi Data Source.
On the Configure the Multi Data Source page, enter the following information:
- Name: Enter oms_pool_group_x where x is the next letter in a sequence.
  
  For example, if your existing multi data sources are oms_pool_group_a and oms_pool_group_b, name the new multi data source oms_pool_group_c.
- JNDI Name: Enter the JNDI path to where this JDBC data source will be bound.
- Algorithm Type: Select Failover.
On the Select Targets page, do one of the following:
- If you have an active-passive configuration, target the new multi data source to the entire WebLogic cluster.
- If you have an active-active configuration, target the multi data source to the same group in the WebLogic cluster that you targeted most of your new data sources to (typically a newly-added WebLogic server group).
  
  For example, in Figure 8-6, the new multi data source oms_pool_group_c is targeted to the same WebLogic server group as the new data sources rac3_group_c, rac1_group_c, and rac2_group_c.
On the Select Data Source Type page, select the Non-XA Driver option.
On the Add Data Sources page, add the data sources in an order that alternates with that of the existing multi data sources. See Table 8-1 for an example with three multi data sources.
Click Finish.

Adding a New Managed Server to a Clustered Environment

To add a new managed server to a clustered environment:

Ensure that the managed servers and the cluster are created. For information on how to add managed servers, see Oracle Fusion Middleware documentation.
Ensure that the managed servers have been assigned to the cluster, and that OSM is installed on the cluster.
Create a new managed server and do the following:
1. If a proxy is used in the cluster configuration, add the new managed server's IP address and port number to the proxy server's configuration. For example, if you use a WebLogic HTTP proxy, update the WebLogicCluster parameter in the domain_home/apps/OracleProxy4_proxyserver_proxy/WEB-INF/web.xml file (where proxyserver is the proxy server name) and redeploy the proxy for the change to take effect.
2. If the cluster address of the cluster is set, update it with the new managed server's IP address and port number.
If you are adding a new managed server to an Oracle Real Application Cluster (Oracle RAC) active-active deployment, consider the following:

Load balancing is achieved by dividing WebLogic managed servers into groups that interact through a multi data source with the same primary and failover Oracle RAC instances, but in reverse order. You must decide to which group the new managed server should belong based on which Oracle RAC instance you want to be the primary one for that server (the others will be used for failover). You then add the managed server to the targets of the multi data source and the regular data sources that correspond to that group; for example, osm_pool_group_a, osm_pool_rac1_group_a, and osm_pool_rac2_group_a. For load balancing purposes, it is recommended that you distribute managed servers evenly between the groups (see Figure 8-4).
Based on the persistent store you selected when you first installed OSM (for more information, see "Performing an Interactive Installation of OSM"), do one of the following:
1. If you use the default persistent store (not recommended), skip this step.
2. If you use custom file stores, create a new file store for the new server. For more information, see "Creating and Configuring Persistent File Stores."
3. If you use JDBC stores, create a new JDBC store and associate it with the data source targeted to the new server. If you do not use Oracle RAC, this is the CP-oms_pool data source. If you use Oracle RAC, choose the multi data source targeted to the new server.
  
  Note:
  
  MS2 in the following steps indicates the name of the managed server.
Create a JMS server with the following settings:
- Name = oms_jms_server_MS2
  
  Note:
  
  The name of the JMS server must always be set to oms_jms_server_ManagedServerName where ManagedServerName is the exact name of the managed server.
- Target = MS2
- PersistentStore = oms_jms_store_MS2
  
  (required for custom file stores but not for the default persistent store or the JDBC store)
Start the new managed server.
Open the domain_home/config/config.xml file.

In the section for the new server, before </server>, add the following:

<web-service>
<messaging-queue-mdb-run-as-principal-name>oms-internal</messaging-queue-mdb-run-as-principal-name>
</web-service>

Save and close the file.
Create a subdeployment under the JMS module oms_jms_module with the following settings:
- Name = oms_jms_server_MS2
- Target = oms_jms_server_MS2
Create a JMS template queues under the JMS module oms_jms_module
- Name = osmJmsNonMigratableTemplate_managed_server
- Destination Key = OsmDescendingPriorityDestinationKey
- Quota =oms_ws_cluster_correlates.Quota
- JNDIName = oracle/communications/ordermanagement/WebServiceClusterCorrelateQueue_MS2
Create the following queues under the JMS module oms_jms_module:
- Queue
  - Name = oms_behavior_queue_MS2
  - SubDeploymentName = oms_jms_server_MS2
  - Quota = oms_behavior_queue.Quota
  - JNDIName = mslv/oms/oms1/internal/jms/behaviors_MS2
- Queue
  - Name = oms_events_MS2
  - SubDeploymentName = oms_jms_server_MS2
  - Quota = oms_events.Quota
  - JNDIName = mslv/oms/oms1/internal/jms/events_MS2
- Queue
  - Name = OrchestrationDependenciesQueue_MS2
  - SubDeploymentName = oms_jms_server_MS2
  - Quota = OrchestrationDependenciesQueue.Quota
  - JNDIName = oracle/communications/ordermanagement/OrchestrationDependenciesQueue_MS2
- Queue
  
  Note:
  
  If you are using JSM service migration, you must configure the oms_cartridge_deploy_MS2 queue as described in "Configuring a New Managed Server that uses JMS Service Migration."
  
  For all those not using JSM service migration, use the queue configuration described here.
  - Name = oms_cartridge_deploy_MS2
  - SubDeploymentName = oms_jms_server_MS2
  - Quota = oms_cartridge_deploy.Quota
  - Local JNDIName = mslv/provisioning/internal/ejb/deployCartridgeQueue
    
    Note:
    
    For this queue, you must provide a local JNDI name rather than a global JNDI name.
    
    If you use the WebLogic Server Administration Console to create the queue, do not enter a value in the JNDI Name field while creating the queue. Instead, after you have created the queue, enter the local JNDI name in the Local JNDI Name field under the Advanced section on the Settings for oms_cartridge_deploy_MS2 screen.
- Queue
  - Name = oms_order_updates_MS2
  - SubDeploymentName = oms_jms_server_MS2
  - Quota = oms_order_updates.Quota
  - JNDIName = mslv/provisioning/internal/ejb/orderupdates_MS2
- Queue
  - Name = oms_ws_requests_MS2
  - SubDeploymentName = oms_jms_server_MS2
  - Quota = oms_ws_requests.Quota
  - JNDIName = oracle/communications/ordermanagement/WebServiceQueue_MS2
- Queue
  - Name = oms_ws_cluster_requests_MS2
  - SubDeploymentName = oms_jms_server_MS2
  - Quota = oms_ws_cluster_requests.Quota
  - JNDIName = oracle/communications/ordermanagement/WebServiceClusterRequestQueue_MS2
- Queue
  - Name = oms_ws_cluster_responses_MS2
  - SubDeploymentName = oms_jms_server_MS2
  - Quota = oms_ws_cluster_responses.Quota
  - JNDIName = oracle/communications/ordermanagement/WebServiceClusterResponseQueue_MS2
- Queue
  - Name = oms_ws_cluster_correlates_MS2
  - SubDeploymentName = oms_jms_server_MS2
  - Quota =oms_ws_cluster_correlates.Quota
  - JNDIName = oracle/communications/ordermanagement/WebServiceClusterCorrelateQueue_MS2
Set the JMSPriority destination key for the oms_ws_requests_MS2 queue as follows:
1. In the WebLogic Server Administration Console, in the Domain Structure tree, expand Services, then expand Messaging, and select JMS Modules.
2. From the JMS Modules table, select oms_jms_module.
3. From the Summary of Resources table, select oms_ws_requests_MS2.
4. In the Destination Keys section, move DestinationKey-JMSPriority to the Chosen list.
5. Save the destination key settings.
Create the following topics under the JMS module oms_jms_module:
- Topic
  - Name = oms_order_events_MS2
  - SubDeploymentName = oms_jms_server_MS2
  - Quota = oms_order_events.Quota
  - JNDIName = mslv/provisioning/external/orderevents_MS2
- Topic
  - Name = oms_signal_topic_MS2
  - SubDeploymentName = oms_jms_server_MS2
  - Quota = oms_signal_topic.Quota
  - JNDIName = mslv/oms/oms1/internal/jms/InternalSignalTopic_MS2
Add the following member queues and topics to the following distributed queues:
- Add member queue oms_behavior_queue_MS2 to distributed queue oms_distributed_behavior_queue
- Add member queue oms_events_MS2 to distributed queue oms_distributed_events_queue
- Add member queue OrchestrationDependenciesQueue_MS2 to distributed queue oms_distributed_orchestration_dependencies_queue
- Add member queue oms_order_events_MS2 to distributed topic oms_distributed_order_events_queue
- Add member queue oms_order_updates_MS2 to distributed queue oms_distributed_order_updates_queue
- Add member queue oms_ws_requests_MS2 to distributed queue oms_distributed_ws_requests_queue
- Add member queue oms_ws_cluster_requests_MS2 to distributed queue oms_distributed_cluster_ws_requests_proxy_queue
- Add member queue oms_ws_cluster_responses_MS2 to distributed queue oms_distributed_cluster_ws_response_proxy_queue
- Add member queue oms_ws_cluster_correlates_MS2 to distributed queue oms_distributed_cluster_ws_correlates_queue
- Add member topic oms_signal_topic_MS2 to distributed topic oms_distributed_signal_topic
If an Order-to-Activate cartridge is already deployed, run ant task config_All.
Add the new managed server well-known address IP address and port number to the Coherence configuration file.

Configuring a New Managed Server that uses JMS Service Migration

When adding a new managed server, if you are using JMS service migration, you must perform the following procedure when creating the oms_cartridge_deploy_managed_server queue (where managed_server is the name of the managed server for which the queue belongs).

Note:

Oracle recommends that you use whole server migration, rather than JMS service migration, to address your high-availability needs. For more information, see "Understanding Whole Server Migration for High Availability."

To configure a new managed server that uses JMS service migration:

Create a JMS server with the following settings:
- Name = osmJmsNonMigratableServer_managed_server
- Target = MS2
Create a subdeployment with the following settings under the JMS module oms_jms_module:
- Name = osmJmsNonMigratableServer_managed_server
- Target = The JMS server you created in step 1
Create a JMS template queues under the JMS module oms_jms_module.
- Name = osmJmsNonMigratableTemplate_managed_server
- Destination Key = OsmDescendingPriorityDestinationKey
Create a queue with the following settings under the JMS module oms_jms_module:
- Name = oms_cartridge_deploy_MS2
- Template =The template you created in step 3
- SubDeploymentName = The JMS server you created in step 2
- Local JNDIName = mslv/provisioning/internal/ejb/deployCartridgeQueue
  
  Note:
  
  For this queue, you must provide a local JNDI name rather than a global JNDI name.
  
  If you use the WebLogic Server Administration Console to create the queue, do not enter a value in the JNDI Name field while creating the queue. Instead, after you have created the queue, enter the local JNDI name in the Local JNDI Name field under the Advanced section on the Settings for oms_cartridge_deploy_MS2 screen.

Removing a Managed Server from a Clustered Environment

When you remove a managed server from a clustered environment, you must first delete the related queues, then remove the managed server using the WebLogic Administration Console. See "Preparing to Remove a Managed Server from a Clustered Environment" and "Removing a Managed Server from a WebLogic Cluster" for more information.

Preparing to Remove a Managed Server from a Clustered Environment

Before you can remove an OSM WebLogic server from a cluster, you must remove membership of the following queues from the distributed queues, and then delete the queues:

oms_behavior_queue_ManagedServer
oms_events_ManagedServer
oms_order_updates_ManagedServer
oms_ws_cluster_correlates_ManagedServer
oms_ws_cluster_requests_ManagedServer
oms_ws_cluster_responses_ManagedServer
oms_ws_requests_ManagedServer
OrchestrationDependenciesQueue_ManagedServer
oms_cartridge_deploy_ManagedServer

The following is the list of distributed queues from which you must remove membership of the above listed queues:

oms_distributed_behavior_queue
oms_distributed_cluster_ws_correlates_queue
oms_distributed_cluster_ws_requests_proxy_queue
oms_distributed_cluster_ws_response_proxy_queue
oms_distributed_events_queue
oms_distributed_orchestration_dependencies_queue
oms_distributed_order_updates_queue
oms_distributed_ws_requests_queue

If you have installed an Order-to-Activate cartridge, remove the membership of the following queues from the Order-to-Activate distributed queues and then delete the queues:

OSM_FalloutQueue_ManagedServer
OSM_PIPFalloutQueue_ManagedServer
OSM_ORPFalloutQueue_ManagedServer
OSM_InBoundMessageRecoveryQueue_ManagedServer
OSM_WebServiceFindTroubleTicketCFResponseQueue_ManagedServer
OSM_WebServiceFalloutCFResponseQueue_ManagedServer
AIA_CreateCustomerQueue_ManagedServer
AIA_CreateCustomerResponseQueue_ManagedServer
AIA_CreateProvisioningOrderQueue_ManagedServer
AIA_CreateProvisioningOrderResponseQueue_ManagedServer
AIA_CreateBillingOrderQueue_ManagedServer
AIA_CreateBillingOrderResponseQueue_ManagedServer
AIA_UpdateFulfillmentOrderQueue_ManagedServer
AIA_UpdateSalesOrderQueue_ManagedServer
AIA_CreateTroubleTicketRequestQueue_ManagedServer
AIA_CreateTroubleTicketResponseQueue_ManagedServer
AIA_UpdateTroubleTicketRequestQueue_ManagedServer
OSM_OrderActivityQueue_ManagedServer
OSM_WebServiceFalloutLFResponseQueue_ManagedServer
AIA_CreateErrorFaultQueue_ManagedServer
OSM_WebServiceResponseQueue_ManagedServer
OSM_ServiceProvisioningUpdateQueue_ManagedServer
OSM_LFAbortOrderPropagationRespQueue_ManagedServer
OSM_WebServiceRetryResponseQueue_ManagedServer

The following is the list of Order-to-Activate distributed queues from which you must remove the membership of the above listed queues:

Distributed_FalloutQueue
Distributed_OSM_PIPFalloutQueue
Distributed_OSM_ORPFalloutQueue
Distributed_OSM_InBoundMessageRecoveryQueue
Distributed_OSM_WebServiceFindTroubleTicketCFResponseQueue
Distributed_OSM_WebServiceFalloutCFResponseQueue
Distributed_AIA_CreateCustomerQueue
Distributed_AIA_CreateCustomerResponseQueue
Distributed_AIA_CreateProvisioningOrderQueue
Distributed_AIA_CreateProvisioningOrderResponseQueue
Distributed_AIA_CreateBillingOrderQueue
Distributed_AIA_CreateBillingOrderResponseQueue
Distributed_AIA_UpdateFulfillmentOrderQueue
Distributed_AIA_UpdateSalesOrderQueue
Distributed_AIA_CreateTroubleTicketRequestQueue
Distributed_AIA_CreateTroubleTicketResponseQueue
Distributed_AIA_UpdateTroubleTicketRequestQueue
Distributed_OSM_OrderActivityQueue
Distributed_OSM_WebServiceFalloutLFResponseQueue
Distributed_AIA_UpdateFulfillmentOrderQueue
Distributed_AIA_CreateErrorFaultQueue
Distributed_OSM_WebServiceResponseQueue
Distributed_OSM_ServiceProvisioningUpdateQueue
Distributed_OSM_LFAbortOrderPropagationRespQueue
Distributed_OSM_WebServiceRetryResponseQueue

Removing a Managed Server from a WebLogic Cluster

To remove an OSM managed server from a WebLogic cluster:

Shut down the Oracle database server or servers used by your OSM instance.
Log in to the WebLogic Administration Console.

The WebLogic Administration Console is displayed.
Click Environment.
Click Servers.

The Summary of Servers screen is displayed.
Click Control.
Select all managed servers. Do not select the administration server (followed by "(admin)" in the list).

Note:

Note which OSM managed server you want to remove.
Click Shutdown.
Select Force Shutdown Now.

The State changes from RUNNING to SHUTDOWN.
Click Services.
Click JMS Modules.

The JMS Modules screen is displayed.
Click oms_jms_module.

The Settings for oms_jms_module screen is displayed.
For every OSM or Order-to-Activate distributed queue, do the following:
1. Click the distributed_queue, where distributed_queue is the name of the OSM distributed queue.
  
  The Settings for distributed_queue screen is displayed.
2. Click Members.
  
  The Distributed Queue Members screen is displayed.
3. Select the queue_managed_server, where queue is the OSM or Order-to-Activate queue and managed_server is the managed server you want to remove.
4. Click Delete.
Delete every queue_managed_server or topic_managed_server, where queue and topic are the names of the OSM queues and topics and managed_server is the managed server you want to remove.
If the managed server you are removing is configured with JMS service migration, remove the osmJmsNonMigratableTemplate_managed_server template associated to the managed server you want to delete.
Click Subdeployments.

The Subdeployments screen is displayed.
Select the oms_jms_server_ManagedServer you want to delete.

If the managed server you are removing is configured with JMS service migration, also select the osmJmsNonMigratableServer_managed_server subdeployment associated to the managed server you want to delete.

Note:

You cannot delete a managed server subdeployment until there are no resources associated with it. If any resources still appear, either delete the resource if it is a queue, or remove the managed server from the member list if it is a distributed queue.
Click Delete.
Click Services.
Click JMS Servers.

The Summary of JMS Servers screen is displayed.
Select the oms_jms_server_ManagedServer you want to delete.

If the managed server you are removing is configured with JMS service migration, also select the osmJmsNonMigratableServer_managed_server JMS server associated to the managed server you want to delete.
Click Delete.
Click Environment.
Click Servers.

The Summary of Servers screen is displayed.
Select the managed server you want to delete.
Click Delete.
Click Environment.
Click Clusters.

The Summary of Clusters screen is displayed.
Click the name of the cluster that the managed server you deleted was associated with.
In the Clusters Address field, remove the IP address and port number for the managed server you deleted.
In the Number of Servers In Cluster Address field, reduce the number by one.
Click Save.
If a proxy is used in the cluster configuration, delete the managed server's IP address and port number from the proxy server's configuration. For example, if you use a WebLogic HTTP proxy, update the WebLogicCluster parameter in the domain_home/apps/OracleProxy4_proxyserver_proxy/WEB-INF/web.xml file (where proxyserver is the proxy server name) and redeploy the proxy.
Save and close the file.
Pack and redeploy the oms.ear file as described in OSM Developer's Guide.

8 Performing OSM Post-Installation Tasks

OSM Client Configuration Post-Installation Tasks

Enabling Graphical Display on UNIX or Linux Systems

Connection, File Store, and Thread Configuration Post Installation Tasks

Customizing OSM Run-Time Parameters

Preventing Connection Timeout Issues During Cartridge Deployment

Configuring OSM JDBC Connections

Creating and Configuring Persistent File Stores

Externalizing the Coherence Thread Configuration File

Copying Metric Rule Files

Relocating ADML Files Without Restarting the Server

Registering Oracle HTTP Server Instance

Queue Configuration Post Installation Tasks

Configuring Distributed Queues for an OSM Solution

Configuring Separate Error Queues

OSM Integration with External Systems

Configuring Domain Trust

Integrating OSM and ASAP or IP Service Activator Using SAF Agent and JMS Bridging

Integrating OSM and UIM Using SAF Agent

Deploying Custom Plug-Ins When Running on Managed Server

Changing the WebLogic Server or Oracle RAC Database Size

Connecting Oracle RAC with JDBC Multi Data Source

Adding Oracle RAC Instances

Manually Configuring Additional Data Sources for an Oracle RAC Instance

Manually Creating and Configuring Data Sources

Configuring Connection Pool Properties

Adding Data Sources to Multi Data Sources

Adding a New Managed Server to a Clustered Environment

Configuring a New Managed Server that uses JMS Service Migration

Removing a Managed Server from a Clustered Environment

Preparing to Remove a Managed Server from a Clustered Environment

Removing a Managed Server from a WebLogic Cluster