This chapter describes Oracle Communications Order and Service Management (OSM) post-installation tasks.
The following sections provide post installation instructions relating to the OSM Order Management Web client and the OSM Task web client.
To display graphical representations such as Gantt charts and 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.The following sections include post installation tasks for configuring connections, file stores, and threads.
After installation, you may want to change OSM runtime parameters. For example, you can increase the number of rows in a worklist, or update the OSM administrator's e-mail address.
OSM runtime 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.
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.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 sufficient 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 sufficient.
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.
Click Activate Changes.
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 make sure it is already created.
Note:
Do not locate the JMS Persistent Store data file on a ZFS file system. Locating the persistent store on a ZFS file system can impact the JMS messaging subsystem's performance. By default, the JMS file store is located in the domain directory, so Oracle recommends that the domain directory be located on a UFS file system. If your business needs require that the WebLogic Server domain be located on a ZFS file system, you should modify the domain configuration to locate the file store on a UFS file system. See the WebLogic Server documentation for more information about this configuration.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 need to 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.
After you install OSM, you must configure threads counts to ensure performance. You can tune these threads in the osm-coherence-cache-config.xml in the oms.ear file Oracle recommends that you externalize the osm-coherence-cache-config.xml file for tuning procedures described in "OSM Pre-Production Testing and Tuning".
To set these values, do the following:
From the machine running the administration server, open a terminal.
Copy the domain_home/servers/AdminServer/upload/oms/app/oms.ear file to another folder (where AdminServer is the name of the administration server.).
Extract the security.jar file using the following command.
jar xvf oms.ear security.jar
Extract the osm-coherence-cache-config.xml file using the following command.
jar xvf security.jar osm-coherence-cache-config.xml
Open the osm-coherence-cache-config.xml file and set the osm-invocation thread-count to a value as follows.
<invocation-scheme> <scheme-name>osm-invocation</scheme-name> <service-name>osm-invocation</service-name> <thread-count>thread_count</thread-count> <autostart>false</autostart> </invocation-scheme>
Where thread_number is determined based on the following calculation 7+((the number of Managed Servers-1)*3). For example, clusters with 2, 4, 6, or 16 managed servers would require 10, 16, 22 and 52 threads respectively.
Set the osm-distributed thread-count to a value as follows: between 10 and 15 (the default is 4).
For example:
<distributed-scheme> <scheme-name>osm-distributed</scheme-name> <service-name>DistributedCache</service-name> <thread-count system-property="tangosol.coherence.distributed.threads">thread_number</thread-count> <backing-map-scheme> <local-scheme> <scheme-ref>osm-backing-map</scheme-ref> </local-scheme> </backing-map-scheme> <autostart>true</autostart> </distributed-scheme>
Where thread_number is a value between 10 and 15.
Save osm-coherence-cache-config.xml and add it back to the security.jar file using the following command:
jar uvf security.jar osm-coherence-cache-config.xml
Log in to the WebLogic Server Administration Console.
In the Domain Structure tree 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.
After the oms.ear file has been updated, click Activate Changes.
In the Domain Structure tree click Servers.
The Summary of Servers screen is displayed.
Restart all managed servers in the cluster.
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 from the oms.ear file as described in the previous procedure, but do not add the file back to the security.jar.
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 folder 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
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.
Setting coherence thread values too low can result in stuck threads. To monitor threads in the OSM WebLogic server console:
Log into the OSM WebLogic server.
The WebLogic Administration Console is displayed.
Click Server.
The Summary of Servers is displayed.
Select any OSM server.
Click the Monitoring tab.
Click the Threads sub-tab.
The Self-Tuning Thread Pool Threads table is displayed listing the names of the threads associated to the server. If you see stuck threads, increase the osm-invocation and osm-distributed thread-count values as described in this section. In some cases, you may have to increase the thread-count values beyond 15 to resolve stuck thread issues.
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_12.1.3/adml
If this directory is not accessible to the OSM server, you need to 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_12.1.3/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 My Oracle Support Web site at:
Instructions for applying the patch are provided in the patch Readme 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.
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 script from the domain_home/bin directory of the administration server.
Add the following string to the JAVA_OPTIONS property:
-Dweblogic.management.disableManagedServerNotifications=true
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 My Oracle Support Web site at:
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.
The following sections provide instructions for configuring OSM and solution queues after installing OSM.
If you are going to use the Account Manager feature, you must use design Studio to create an additional SAF agent in WebLogic Server. For instructions on how to create the queue, see the information about creating an Accounts SAF agent in Oracle Communications Design Studio Modeling OSM Processes Help.
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.
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:
Enter the name and JNDI name of the distributed queue.
Ensure the Load Balancing Policy is set to Round-Robin.
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:
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.
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
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 My Oracle Support Web site at:
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.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
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 My Oracle Support Web site at:
This article is applicable to any remote application that uses a WebLogic JMS server to send and receive Web Service messages.
If OSM is running on a WebLogic managed server, the behaviorBuild.properties file must be configured to specify the URL of the administration server (for example, http://hostname:port).
From the system prompt, execute the command ant deploy
.
In the WebLogic Administration Console, perform the following steps:
Undeploy the custom plug-in from the administration server.
Deploy the custom plug-in to the managed server.
Target the custom plug-in to the managed server.
The following sections describe how to change the number of managed servers in a cluster or the Oracle RAC database size.
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
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
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.
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
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
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".
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 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, "Data Sources for a Third Active Oracle RAC Instance in an Active-Active Environment" 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, "Data Sources for a Third Active Oracle RAC Instance in an Active-Active Environment" for a detailed example.
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:
Ensure the default option Supports Global Transactions is selected.
Select the Logging Last Resource option.
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):
Specify the same the host, port, and service name as those specified for the existing data sources.
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:
Specify either a different host or port than the host or the port of the existing data sources.
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, "Data Sources for a Third Active Oracle RAC Instance in an Active-Active Environment", 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".
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.
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 |
|
oms_pool_group_b |
|
oms_pool_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, "Data Sources for a Third Active Oracle RAC Instance in an Active-Active Environment", 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.
To add a new managed server to a clustered environment:
Ensure that the managed servers and the cluster are created. 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:
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.
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, "Data Source Configuration for Oracle RAC Active-Active").
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:
If you use the default persistent store (not recommended), skip this step.
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".
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:
In the WebLogic Server Administration Console, in the Domain Structure tree, expand Services, then expand Messaging, and select JMS Modules.
From the JMS Modules table, select oms_jms_module.
From the Summary of Resources table, select oms_ws_requests_MS2.
In the Destination Keys section, move DestinationKey-JMSPriority to the Chosen list.
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.
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):
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.
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.
Before you can remove an OSM WebLogic server from a cluster, you must remove membership of the following queues from the distributed queues listed in Table 8-2, 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
Table 8-2 Distributed Queues to Remove Membership
Queue Name |
---|
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 listed in Table 8-3, 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
Table 8-3 Order-to-Activate Queues to Delete
Queue Name |
---|
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 |
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:
Click the distributed_queue, where distributed_queue is the name of the OSM distributed queue.
The Settings for distributed_queue screen is displayed.
Click Members.
The Distributed Queue Members screen is displayed.
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.
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.