Overview

IBM® Sterling Selling and Fulfillment Suite (SSFS) focuses on two important capabilities: scalability and high availability. SSFS leverages these capabilities in application servers, databases, and Java™ Messaging Service (JMS).

With JMS clustering, multiple JMS servers form an active/active cluster. Message processing can be load-balanced across the members of the cluster. Load balancing allows more messages to be handled as JMS servers are added, providing a more scalable solution. If one of the cluster members fails, the messages are routed to other active cluster members, which ensures higher availability.

JMS forms an integral component of the SSFS. Agents and integration servers make use of the JMS to send and receive messages during the order fulfillment cycle. When there are a large number of orders flowing into SSFS, JMS clusters will facilitate faster sending and receiving of messages than a single JMS server, thereby reducing its total response time. This prevents the JMS server from becoming a bottleneck for performance, making SSFS more scalable. Also, when every order is time-bound and critical, every incoming or outgoing message is important. In case of a server failure, the other active JMS servers continue to accept requests and enable SSFS to work seamlessly, which makes it highly available.

Support for JMS clustering in SSFS

JMS cluster support in SSFS V9.2 enables customers to configure high availability and load balancing for JMS queues. SSFS V9.2 supports the following JMS providers:

• IBM® WebSphere Application Server (default messaging)
• IBM® WebSphere MQ
• Oracle™ WebLogic JMS
• TIBCO Enterprise Message Service (EMS)
• JBoss (EAP) Enterprise Application Platform Messaging

See the detailed system requirements document for the supported JMS provider versions and capabilities listed in the Resources.

Note: TIBCO EMS provides only high availability capabilities. It does not provide active/active or load-balancing capabilities.

Before you begin

Verify that the JMS provider you selected is installed and running with clustering services configured. You need a minimum of two servers to provide load balancing and fail-over support. Test the clustering support by using a standalone Java program. You can create a simple JMS sender and receiver code which has the ability to send and receive multiple messages to test the configuration.

General Recommendations

• For improved load balancing and high availability, configure separate JMS clusters for agents and integration servers. Lost messages are generated by SSFS in the event of a JMS server failure. The same is not true for integration servers.
• File stores and JDBC stores are frequently used to persist or store JMS messages. File stores will increase performance whereas JDBC stores are more reliable. Choose the appropriate data store for message persistence.
• If you use the JMS clustering feature to define multiple servers in the provider URLs as illustrated in Figure 1, Figure 2, and Figure 3, do not implement the backup JMS configuration.
• The provider URL (yfs.yfs.agent.override.providerurl or yfs.yfs.flow.override.providerurl), and Initial Context Factory (yfs.yfs.agent.override.icf or yfs.yfs.flow.override.icf) values change for every JMS provider. Applications Manager helps you choose the Initial Context Factory that maps directly to its corresponding class name.

Throughout the article, the examples, figures, and listings use IBM WebSphere Application Web Server (default messaging). When you use another supported JMS provider, Table 1 is useful for updating the customer_overrides.properties file.

Back to top

Configuring agents

You can configure JMS clustering for agents either by using the Applications Manager, or by providing a centralized configuration for all combined agents.

Using the Applications Manager

To configure the JMS cluster with the Applications Manager:

1. From the Configuration tab in the SSFS application console, launch the Applications Manager.
2. Select the appropriate agent transaction from the available Process Type options. To access the Process Type options, select Application Platform > Process Modeling > Process Type.
3. Create or update an agent criteria with the JMS clustering values for the clustered provider URL, and the Queue Connection Factory.

Figure 1 shows the values in the Applications Manager for an IBM WebSphere Application Server (default messaging) JMS cluster. It is a two node cluster across machines sys001 and sys002. You can also provide an IP address. The ports configured are the bootstrap ports.

Using the customer_overrides.properties file

The production environment defines the agent criteria, however it requires that you manually update each configuration with clustering information. SSFS provides the customer_overrides.properties file to update the clustering information of all of the agents in one location. The customer_overrides.properties file is installed in the INSTALLATION_HOME/properties directory.

Listing 1 illustrates JMS clustering information for agents in the customer_overrides.properties file.

			
#Agent configuration for JMS
yfs.yfs.agent.override.providerurl=corbaloc::sys001:9811,:sys002:2811
yfs.yfs.agent.override.icf=com.ibm.websphere.naming.WsnInitialContextFactory
yfs.yfs.agent.override.qcf=CLUSTER_QCF

Configuring backup JMS for agents

You can add high availability without changing an existing JMS environment by configuring a backup JMS server. This setup does not use the scaling capabilities of JMS because it is an active/passive cluster setup.

For example, the existing environment points to a WebSphere JMS server sys001 (corbaloc::sys001:9811 as provider URL and PRIMARY_QCF as QCF name). To add a JMS server sys002 (corbaloc::sys002:2811 as provider URL and BACKUP_QCF as QCF name), update the properties as shown in Listing 2 (this property is not set by default in SSFS).

Note: The JMS server on sys002 is accessed only if the primary server on sys001 fails.

Listing 2 illustrates backup agent JMS configuration in the customer_overrides.properties file.

			
#Agent configuration for primary JMS server
yfs.yfs.agent.override.providerurl=corbaloc::sys001:9811
yfs.yfs.agent.override.icf=com.ibm.websphere.naming.WsnInitialContextFactory
yfs.yfs.agent.override.qcf=PRIMARY_QCF


#Agent configuration for backup JMS server
yfs.yfs.agent.backup.providerurl=corbaloc::sys002:2811
yfs.yfs.agent.backup.icf=com.ibm.websphere.naming.WsnInitialContextFactory
yfs.yfs.agent.backup.qcf=BACKUP_QCF

Back to top

Configuring integration servers

You can configure JMS integration servers individually with the Applications Manager, or you can configure JMS integration servers all at once with the customer_overrides.properties file.

Using the Applications Manager

To configure the integration servers using the Applications Manager:

1. From the Configuration tab in the SSFS application console, launch the Applications Manager.
2. Select the appropriate agent transaction from the available Process Type options. To access the Process Type options, select Application Platform > Process Modeling > Process Type.
3. Create or update the JMS clustering related values for the clustered provider URL, the Queue Connection Factory and the clustered queue under the Runtime tab.
4. Set up the clustering configuration for a service in the JMS Sender and Receiver for a service definition as it is illustrated in Figure 2 and Figure 3. The Agent Criteria Details window in the Application Manager shows a two node cluster across machines sys001 and sys002. You can also provide an IP address. The ports configured are the bootstrap ports.

Note: The JMS Sender and JMS Receiver have to be defined separately as two action components in SSFS. You can configure services as a JMS Sender, JMS Receiver, or both as required by the business logic defined in the service handler.

Using the customer_overrides.properties file

You can configure JMS clustering by updating the customer_overrides.properties file. The values in this file will override the values in all service definitions, thereby eliminating the manual effort to update the configuration of each service.

Listing 3 shows an example of clustering information for integration servers in the customer_overrides.properties file.

			
#Integration Server configuration for JMS
yfs.yfs.flow.override.providerurl=corbaloc::sys001:9811,:sys002:2811
yfs.yfs.flow.override.icf=com.ibm.websphere.naming.WsnInitialContextFactory
yfs.yfs.flow.override.qcf=CLUSTER_QCF

Configuring backup JMS for Integration Servers

To configure high availability for integration servers in the Applications Manager use the Use Backup JMS option available in the Reconnect tab in the JMS Sender Properties window, as shown in Figure 2.

This is similar to the backup agents setup mentioned earlier, with the exception that this can be configured only through the Applications Manager and not through the customer_overrides.properties file. This option applies only to the JMS Sender.

Figure 4 shows the configuration in the service details screen within the Applications Manager. As illustrated, there is an additional tab with options to reconnect to the primary JMS server. The Retry Interval field specifies the time threshold that elapses before the application tries to reconnect to the primary JMS server. If the server is up, the rest of the message processing routes through the primary JMS server, which makes the current JMS server a backup. The Retry Interval field default is 600 seconds.

Back to top

Verify your configuration

Now that you have completed the configuration for JMS clustering in SSFS, you need to verify your configuration.

1. Start the agent or integration server. Verify that the messages are sent and received seamlessly. An agent JVM generates the messages and sends them to a JMS queue. The execution threads receive the messages, and perform the desired action.
2. Monitor the distributed JMS queues for connections. You should see load balancing happening seamlessly according to the configured load balancing policy.
3. To test failover, bring down one of the JMS servers. The existing transactions are committed or rolled back according to the current status of the transaction. The agent or integration server JVMs reconnect to one of the other cluster members.
4. To test the backup JMS, bring down the primary server. The existing transactions are committed or rolled back according to the current status of the transaction. The agent or integration server JVMs reconnect to the secondary server.

Back to top

Conclusion

The article provides information and recommendations on how to get JMS clustering working with SSFS. JMS clustering support is available only in SSFS V9.2. For more information about other high availability and load balancing features, see the "Performance Management" and "High Availability" sections in the official product documentation for SSFS V9.2 listed in the Resources.

Resources

Learn

• "Detailed system requirements" for Sterling Selling and Fulfillment Suite for information about the supported versions of JMS providers.
  
  
• "WebSphere MQ Queue Manager Clusters" describes how to configure WebSphere MQ clusters.
  
  
• "Workload balancing with WebSphere MQ Clusters" provides examples of workload balancing.
  
  
• IBM Sterling Selling and Fulfillment Suite 9.2 product documentation.
  
  
• In the developerWorks Commerce area, get the resources you need to advance your knowledge of Commerce products.
  
  
• Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
  
  
• Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
  
  
• Follow developerWorks Commerce communities.
  
  
• Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
  
  

Get products and technologies

• Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
  
  

Discuss

• Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
  
  

About the author

Aswin Kumar is a Senior Staff Performance Engineer working with the Customer Experience team in the Industry Solutions division. Over the years, he has designed and executed performance tests for the IBM Sterling suite of products, specifically Order Management and Warehouse Management.

Rate this article

Comments

Back to top

Table of contents

• Overview
• Support for JMS clustering in SSFS
• Configuring agents
• Configuring integration servers
• Verify your configuration
• Conclusion
• Resources
• About the author
• Comments

Dig deeper into Commerce on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers