Integration performance tuning for WebSphere Commerce and Sterling Order Management

Improve response time and throughput

This article describes the integration and performance tuning of WebSphere® Commerce V7 Feature Enhancement Pack 5 and IBM® Sterling Order Management V9.2. The article provides business stakeholders, architects, administrators, and performance engineers with key tuning and configuration information to improve integration performance.

Charek Chen (charekc@ca.ibm.com), Software Performance Analyst, IBM

Charek Chen is a Software Performance Analyst with the IBM WebSphere Commerce development team. Charek has 13 years of experience in the IT industry, including roles in Java development, customer support, test automation, and services.



Vijaya Bashyam (vbashyam@us.ibm.com), Advisory Software Engineer, IBM

Vijaya's photoVijaya Bashyam is a Senior member of the Sterling Selling and Fulfillment Suite systems team. She is also a member of the performance testing team and a key contributor to SSFS-WCE integration testing. Vijaya joined the systems team 4 years ago and has contributed to the success of multiple releases, including a benchmark for the DB2 9.7 and DB2 9.8 pureScale Systems. She has excellent functional knowledge of the SSFS application and is often involved in providing support to the Global Services Team. Before joining PE/SVT, Vijaya resided with the Functional QA team for the SSFS application. Vijaya and has been with IBM since August 2010.



Lei Sun (sunlei@cn.ibm.com), Senior Software Engineer, IBM

Lei's photgraphLei Sun joined IBM in 2003. Before that, Lei worked for six years as a Software Developer on multimedia software and network search engines. Today, Lei focuses primarily on performance testing, capacity planning, and infrastructure architecture for WebSphere Commerce. Lei received his Bachelor of Science in Computer Science from Xi'an JiaoTong University in 1996 and a Master of Science in Computer Science from Peking University in 2001.



25 January 2013

Introduction

WebSphere Commerce is an IBM enterprise e-commerce platform. It is a complete software solution for creating business-to-consumer and business-to-business web sites. Some of the WebSphere Commerce competitive features include:

  • Precision marketing
  • Intelligent search with Apache Solr
  • Store models for mobile devices
  • Workspace management of store activities and assets
  • Default integration with social commerce, analytics, and back-end systems

WebSphere Commerce represents one channel for business transactions but there are also processes for orders and inventory from physical stores and warehouses. A complex issue arises when you are determining how to coordinate common data and business functions that are used by all these channels and their systems. Sterling Selling and Fulfillment Suite (SSFS) addresses this complex issue. SSFS is a dedicated back-end system of components that provides lifecycle management of orders, inventory, and other business data. For integration with WebSphere Commerce, the Sterling Order Management component is used. It is designed to centralize and offer greater functionality beyond the standard features of WebSphere Commerce.

WebSphere Commerce Feature V7 Feature Pack 5 supports integration with Sterling Order Management V9.2. Both products are based on known industry standards for exchanging information across different software systems. These industry architecture standards include:

  • Service-oriented architecture (SOA) - Service-oriented architecture is an approach to designing software that communicates as services. It is then possible to create new composite applications and end-to-end processes from these services.
  • Web services - Web services are a feature of SOA that define an interface for services and a format for message exchange.
  • Enterprise Service Bus (ESB) - Enterprise Service Bus is an implementation of the SOA design principles. It provides a middle layer infrastructure to manage the exchange of information between systems and software components.
  • Java Messaging Services (JMS) - JMS is a framework that is based on the Java™ programming language and allows the message senders and receivers to interact with a message provider. These JMS services can be hosted within an ESB product.

In Figure 1, WebSphere Commerce and Sterling Order Management are integrated through the WebSphere Enterprise Service Bus. WebSphere Commerce communicates requests to Sterling Order Management through the WebSphere Enterprise Service Bus, and then the responses from Sterling Order Management are sent through the WebSphere Enterprise Service Bus. A mixture of web services and JMS calls are used in the exchange. In the WebSphere Enterprise Service Bus, the mediation module transforms the messages and performs other tasks to support the flow between the two systems. The mediation flow of the module defines the web service requesters and providers through export and import endpoints and uses queues to organize and hold incoming and outgoing JMS messages.

Figure 1. WebSphere Commerce and Sterling Order Management integration
WebSphere Commerce and Sterling Order Management integration

This article and Table 1 focus on the performance tuning of the three integrated default features available for the WebSphere Commerce starter store Aurora.

Table 1. Integration operations in Aurora starter store
Operation initiated by WebSphere Commerce Description WebSphere Commerce request Sterling Order Management response Default communication mode
Check inventory availability and reserve inventory The product page displays the inventory status. The order summary page determines the order item inventory availability before order submission. Web services over HTTP Web services over HTTP Synchronous
Transfer order When an order is submitted, it is copied to Sterling Order Management. Web services over HTTP JMS message Asynchronous
Order status and details Opening a previous order retrieves the orders details from Sterling Order Management. Web services over HTTP Web services over HTTP Synchronous

Understanding performance goals, requirements, and quantifiable metrics

Performance goals are normally defined as part of non-functional requirements (NFR) or service level agreements (SLA). Some of your business requirements affect the performance of the WebSphere Commerce and Sterling Order Management integration. For example, having accurate real-time inventory checking reduces system performance due to the frequency of requests if not cached. For order processing, one of the strategies to avoid congesting system resources is to complete them later in batches. The following are some examples of when performance analysis is needed to choose the best solution for a business requirement.

In a WebSphere Commerce and Sterling Order Management integration, we can measure the latency of requests and throughput of transactions as indicators of overall performance. Latency is the time to process a request and optionally provide a response or acknowledgement. In an integrated system, requests can be initiated by user interaction with the system or by software component communication internally though web services or messaging.

It is important to understand the different behaviors of synchronous and asynchronous communication. In synchronous communication the request is expected to be either processed immediately or to be queued in order. The request initiator in synchronous communication waits for a response and then will attempt to resend or abort the transaction after a timeout. However, in asynchronous communication the immediate processing of the request is not required. Instead the processing of an asynchronous communication request takes place at a later scheduled time and not necessarily in order with other requests. This different behavior means that synchronous communication is best if you have a business requirement to provide real-time updates. While asynchronous communication is best to allow for batch processing where controlled utilization of the system is possible.

An important metric to measure is the throughput or the rate of time which it takes the system to complete work. The unit of work might be a single request or a sequence of requests that form a business transaction. Throughput is an indicator of the processing capability efficiency of the system. As more work is added, throughput increases until it reaches a maximum rate. Beyond this point, the rate will either level, increase minimally, or actually decrease. This change in rate is because available processing resources haven been fully used. Additional work is queued, leading to increased latency, and reduced throughput.

In Table 2, for the WebSphere Commerce and Sterling Order Management integration, we are interested in the response time for inventory requests, the response time for retrieving order details, and the throughput for the orders that are created and transferred.

Table 2. Performance metrics
Operation that is initiated by WebSphere Commerce Performance measurement Comments
Transfer order Includes the average orders that are placed per hour and the average order transfer time to Sterling Order Management.The rate of the completed orders on WebSphere Commerce and the creation timestamp difference between the WebSphere Commerce and Sterling Order Management order record.
Check inventory availability and reserve inventory Includes the product page and inventory Ajax request response time, if made separately. Inventory can be configured to be cached to avoid requests.
Order status and details Includes the order detail page response time. The Aurora Account page lists a brief history of past orders. Opening up a specific order retrieves details.

The main factors that influence the throughput and response time are workload, system capacity, and the configuration and tuning parameters. The WebSphere Commerce system delivers outgoing messages that are based on the scheduler subsystem or web service calls. Scheduled messages can be tuned to increase the flow to WebSphere Enterprise Service Bus. The WebSphere Enterprise Service Bus infrastructure uses a Java virtual machine to host JMS and web services. The key resources that are involved are the heap memory allocation, thread pools, and connection pools to support the services. The Sterling Order Management server can run agents which are processes that change the status, the state of order, and the inventory objects. There are also thread pools that are used to handle the incoming requests from WebSphere Enterprise Service Bus.


Tuning WebSphere Commerce

The WebSphere Commerce application runs in a Java virtual machine that is hosted by a WebSphere Application Server. There are many settings in the Java virtual machine and WebSphere Application Server that influence the potential throughput and latency for a workload. The information in Table 3 contains key WebSphere Commerce configuration and tuning parameters from a test environment with IBM Java™ runtime and IBM POWER7® and IBM System x® hardware.

Table 3. WebSphere configuration and tuning parameters
Parameter nameRecommended or default Comments and performance benefit Where to change the WebSphere Application Server
CPU cores for each JVM or server 2 This is the number of JVMs or servers to be created for a specified number of CPU cores. With a 32 core physical machine, 16 JVMs or servers could be created as a WebSphere Application Server vertical cluster. However, some cores are reserved for the operating system and other processes so 15 JVMs servers or less is recommended. By allocating enough JVMs or servers, you avoid under-utilizing CPU on large servers. For more information, refer to the creating clusters documentation in the WebSphere Commerce information center, see Resources.
JVM Heap size (64-bit JVM) Minimum 1024-MB

Maximum 2048-MB
Distribute a physical machine's memory or LPAR's memory according to the number of JVMs created. Remember to reserve some for the operating system and other processes. If default dynamic cache is used, the cache entries occupy memory from each JVM, so the minimum and maximum should be increased. A properly sized heap means less garbage collection process issues that would impact response times and CPU utilization. Application servers > name of server > Process definition > Java virtual machine, under Initial and Maximum heap size
JVM nursery size (64-bit JVM) Minimum 512-MB

Maximum 1024-MB
The WebSphere Commerce JVM uses generational garbage collection which divides the heap into a nursery and a tenure space. The nursery is for temporary and short-lived objects which are applicable for most transactions. Application servers > name of server > Process definition > Java virtual machine, under Generic JVM arguments

-XmnsAAAm (for min)

-XmnxBBBm (for max)
Web container minimum and maximum thread pool size Minimum 25

Maximum 25

Do not Allow thread allocation beyond the maximum thread size
The web container thread pool handles HTTP requests to servlets, JavaServer Pages, and web services. This means that all web browser requests go to this pool. To determine an appropriate range, conduct a workload test to find the utilization of threads, and if they are dependent on the number of database connections. Application servers > name of server > Thread pools > WebContainer
Default thread pool size Minimum 20

Maximum 30
The default thread pool is used by the WebSphere Commerce processes such as scheduler, auditing, and publishing. Ensure that the number of concurrent scheduler jobs is less than the maximum size of the default thread pool. Application servers > name of server > Thread pools > Default
JDBC minimum and maximum connection pool size Minimum 40

Maximum 50
Activity from all thread pools (web container, default, and others) should have an available database connection with a buffer. Data sources > Name of WebSphere Commerce data source > Connection pools
eis/JCAHTTP-WS minimum and maximum thread pool size Minimum 1

Maximum 10
This is the thread pool responsible for sending out web service calls to WebSphere Enterprise Service Bus. Enterprise Applications > name of WebSphere Commerce instance > Manage Modules > Enablement-JCAHTTP-WSConnector.rar > WebSphere Commerce_instancename. Enablement-JCAHTTP- WSConnector > J2C connection factories > Enablement-JCAHTTP- WSConnector.rar > Connection pools
JDBC data source prepared statement cache size 250 This is a cache of prepared SQL statements for each JDBC connection. Preparing an SQL statement has compilation overhead so a cache improves throughput. The prepared statement cache can be monitored for discards to help determine an appropriate size. Data sources > Name of WebSphere Commerce data source > WebSphere Application Server data source properties

Tuning WebSphere Commerce for Sterling Order Management integration

In Figure 2, the transfer of an order from WebSphere Commerce to Sterling Order Management begins with the WebSphere Commerce scheduler system.

  1. An order record is created in the orders table when the first item is added to the user's shopping cart. When an order is submitted, a record in the busevent table is created. This business event is named OrderSubmission and the checked column value is set to -10 to indicate that the event has not been processed.
  2. The RaiseECEvent scheduler job periodically processes business events. When processing the OrderSubmission busevent with integration enabled, records for the msgstore table are created. The OrderSubmission business event checked value is updated to -15 to indicate that the event has been processed.
  3. The SendTransactedMsg job works on records that are found in the msgstore table and periodically forwards data to the WebSphere Enterprise Service Bus with web services over HTTP transport.
  4. Sterling Order Management then responds to WebSphere Commerce with an order status update.
Figure 2. Order transfer
Order transfer

The throughput of transferring orders is impacted by the frequency and parameter settings of the RaiseECEvent, the SendTransactMsg jobs, and the number of scheduler threads assigned.

In Table 4, the parameters for each scheduler to control how long it can execute per instance.

Table 4. Scheduler jobs that are involved with order transfer
Scheduler job Parameter Parameter value
SendTransactedMsg numOfMessages Specify the number of messages to be processed by each job invocation.
RaiseECEvent maxSeconds Specify the maximum number of seconds each job invocation should run for.

There is another common parameter for all scheduler jobs: schedule interval. This is the sccinterval column in the schconfig table. It is used to control the interval between the start of the scheduled job instances. By choosing a combination of the two listed parameters in Table 4, you can control the parallel execution of these two jobs and increase the throughput of the WebSphere Commerce to Sterling Order Management order transfer. For example, with the RaiseECEvent job, if maxSeconds is more than sccinterval, then more than one instance of RaiseECEvent can run in parallel.

For SendTransactedMsg, it is more difficult to control the parallelism with the numOfMessages parameter. Contact WebSphere Commerce support to obtain a software update to add the parameter maxSeconds to SendTransactedMsg for better parallel execution control, see Resources.

The default sccinterval value is 300 seconds for the RaiseECEvent and SendTransactedMsg scheduler jobs. You can shorten this interval to enable higher concurrency or throughput of transferring orders. For example, by setting maxSeconds=600 and sccinterval =10, you can have at most 60 threads of each scheduler at the same time.

By default, scheduled jobs run randomly on any JVM within a WebSphere Commerce cluster. To improve the performance of the order transfer, it is better to assign a dedicated JVM for RaiseECEvent and SendTransactedMsg. For instructions refer to the "Configuring the scheduler to run a job on an instance or a cluster" topic on the WebSphere Commerce information center, see Resources. After assigning a dedicated JVM to run the scheduler for the order transfer, remove the scheduler from the store-front workload, and change the webserver plugin-cfg.xml so that the scheduler only serves the order transfer scheduler job work.

To achieve high throughput of order transfer, you can also disable any unnecessary events for the RaiseECEvent scheduler job. There are many default business events that are generated during order flow. You can disable any unused order business events,but leave the order submission event enabled since it triggers the order transfer. To disable unused events, you can modify the following section in the wc-server.xml file for the com.ibm.commerce.event.impl.ECEventEnableComponent

Listing 1. Enabling and disabling order business events
<component
compClassName="com.ibm.commerce.event.impl.ECEventEnableComponent"
enable="true" name="Order Submission Event">
<property display="false">
<event name="OrderSubmission"/>
</property>
</component>

<component
compClassName="com.ibm.commerce.event.impl.ECEventEnableComponent"
enable="false" name="Order Creation Event">
<property display="false">
<event name="OrderCreation"/>
</property>
</component>

<component
compClassName="com.ibm.commerce.event.impl.ECEventEnableComponent"
enable="false" name="Order Item Creation Event">
<property display="false">
<event name="OrderItemCreation"/>
</property>
</component>

<component
compClassName="com.ibm.commerce.event.impl.ECEventEnableComponent"
enable="false" name="Order Item Update Event">
<property display="false">
<event name="OrderItemUpdate"/>
</property>
</component>

In Listing 1, you enabled the event for order submission which triggers the order transfer and disabled the other order events that are not used. The benefit of this change is that the RaiseECEvent process does not have to work with so many database rows.

For an IBM DB2® database, when your order transfer throughput achieves 30 - 50 orders per sec, a bottleneck can be created on the database msgstore table that is used by the SendTransactedMsg scheduler job. This bottleneck phenomenon causes the package cache SQL statistics to indicate high "lock-wait" for the SQL used by SendTransactedMsg:

Listing 2. SQL used by SendTransactedMsg
SELECT 
T1.MSGID, T1.MESSAGEINDEX, T1.TRANSPORT_ID, 
T1.RETRIES, T1.STOREENT_ID, T1.EXPIRY, T1.OPTCOUNTER, 
T1.MESSAGE FROM MSGSTORE T1 WHERE MSGID = ? AND RETRIES = ? FOR UPDATE WITH RS

In Listing 3, you solve the bottleneck issue by creating an index. However, you will need to redo the runstats on the msgstore table and the new index.

Listing 3. Solve the bottleneck issue
CREATE INDEX I0009999 ON msgstore ( MSGID ASC, RETRIES ASC)

Tuning WebSphere Enterprise Service Bus

The communication between WebSphere Commerce and Sterling Order Management by WebSphere Enterprise Service Bus is XML intensive computing. So it is important to leave enough JVM heap for WebSphere Enterprise Service Bus server. If you are using a 32-bit JVM, it is recommended that you use the following JVM heap parameters:

  • Max Heap size: 1536-MB
  • Generic JVM arguments: ${IBMSCMX} ${IBMGCPOLICY_GENCON} ${IBMJITPMC} -Xmn768m

The communication between WebSphere Commerce and Sterling Order Management can be either asynchronous or synchronous. Asynchronous communication is done through the SIBus within the WebSphere Enterprise Service Bus server (JMS); synchronous communication is done through a web container (SOAP over HTTP). To achieve high throughput for synchronous communication jobs, you can consider a topology change for WebSphere Enterprise Service Bus server. For asynchronous communication jobs, you can change the following tuning parameters as seen in Table 5 (most are for SIBus only) to achieve high throughput.

Table 5. WebSphere Enterprise Service Bus tuning parameters
Parameter name DescriptionLocationDefault valueRecommend value
WebContainer Thread pool size (max) The web container thread pool in WebSphere Enterprise Service Bus handles incoming HTTP requests for Web services. The usage of the web container thread pool can be monitored by enabling PMI statistics Application servers > name of server >Thread pools > WebContainer 50 100
JMS connection pool size

(SIBus only)
The JMS connection pool size in WebSphere Enterprise Service Bus handles message requests such as order transfer. The usage of the JMS connection pool can be monitored by enabling PMI statistics. Resources\JMS\Queue connection factories > WebSphere CommerceToSterling Order Management MediationModule. Sterling Order ManagementAPIsImport_ QCF > Connection pools: Maximum connections. 10 50
MDB ActivationSpec:

maxConcurrency

(SIBus only)
This is used to specify the number of threads available to process messages. Resources\JMS\Activation specifications > WebSphere Commerce ToSterling Order Management Mediation Module.Sterling Order Management APIsExport_AS

Resources\JMS\Activation specifications > WebSphere CommerceToSterling Order Management Mediation Module. Sterling Order Management APIsImport_AS
1 10
MDB ActivationSpec:

maxBatchSize

(SIBus only)
This refers to how many messages can be allocated to a message endpoint in one batch for serial delivery. Resources\JMS\Activation specifications > WebSphere Commerce To Sterling Order Management Mediation Module. Sterling Order Management APIsExport_AS

Resources\JMS\Activation specifications > WebSphere Commerce To Sterling Order Management Mediation Module. Sterling Order Management APIs Import_AS
10 100
Messaging engine custom properties

(SIBus only)
This setting is in KB and allows the caching of data that the messaging engine might otherwise need to read from the message data store such as DB2 or Oracle. Application servers > server1 > Messaging engines > name of node and server-SCA. APPLICATION. cell name. Bus > Custom properties: Not set sib.msgstore.cached DataBufferSize= 10000000

Tuning Sterling Order Management

The orders from the WebSphere Commerce system flow as XML messages into the WebSphere Enterprise Service Bus queue. They are processed in Sterling Order Management with an integration server that reads each message XML as input to the Sterling Order Management createOrder API.

Upon successful creation of the order in the Sterling Order Management database, an ON_SUCCESS event is raised by the createOrder API to post the XML containing the details of the order into a WebSphere Enterprise Service Bus queue. This queue is later read by the WebSphere Commerce application to render the details of the order in the user interface.

The rate of orders coming into the Sterling Order Management system is measured by the orders that are created in the YFS_ORDER_HEADER and the corresponding order lines in YFS_ORDER_LINE table every hour. Figure 3 represents the rate of order flow per hour over an extended run.

Figure 3. Sterling Order Management order and order line rate
Sterling Order Management order and order line rate

Figure 4 shows the response times that are measured by the statistics monitor over a 10-minute interval.

Figure 4. Sterling Order Management Order API response time
Sterling Order Management Order API response time

Tuning Issues

These are some of the known performance tuning issues that are found in both the Sterling Order Management database and JVM.

Multi-threaded JMS writes

During the integration testing on Sterling Order Management V9.1, the findInventory API call is configured as an asynchronous service with the WebSphere Enterprise Service Bus JMS queue separating the transaction boundary. The input to the WebSphere Enterprise Service Bus queue was coming from WebSphere Commerce availability request to the Sterling Order Management system. Once Sterling Order Management receives the request, the findInventory API is called to compute the availability and the output is written to the WebSphere Enterprise Service Bus queue to be consumed as the WebSphere Commerce availability response.

A problem became noticeable once the number of threads that are processed by the findInventory JVM was increased from 5 to 40 to achieve higher number of requests from WebSphere Commerce. The JVM thread dumps revealed that all the threads were waiting for one thread to complete the writing of the message in the JMS. The reasoning behind the waits by the other thread turned out to be the JMS writes were performed in a synchronous block, enabling only one thread to write at a time. Once identified, a patch was provided that reduced the average response time of findInventory API calls by up to 50%.

This change applies to Sterling Order Management V9.1 only, since the availability call is implemented as an asynchronous service. In V9.2, the availability calls are made synchronously with the external authentication servlet directly from WebSphere Commerce.

WebSphere Commerce order summary page slowness

During an investigation of integration, the WebSphere Commerce order summary page is displayed at a slower than normal rate. The WebSphere Commerce summary page calls out to the Sterling Order Management getOrderList API to get the order summary from the Sterling Order Management database. Further tracing of this API revealed that the degradation is due to full table scans performed on the table YFS_ORDER_HEADER that stores the order header level information such as order number, buyer information, and payment information. The query that showed a higher cost was reduced down to 1/10th cost by adding a non-unique index on a few columns. Depending on the data that is required for the order summary, creating a new index can be beneficial to response times.

Incorrect item data usage

As part of the early test cycle in WebSphere Commerce Feature Pack 5, there was a sudden slowness in the findInventory API call which is sometimes caused by a response time greater than 3 seconds. A tracing of the API call found that the code spent a considerable amount of time verifying if an item ID also exists as a global item ID for another item. This global identifier is used in the vendor managed inventory scenario and not under ordinary order transfer circumstances. In the data set that was used for YFS_ITEM, all the 1 million items contained a unique global item identifier which caused the code to go into a loop 1 million times. By making that column null in the YFS_ITEM table the testing then resulted in an improvement and a rapid retrieval of the availability in WebSphere Commerce.

Reprocess error tuning

If orders were lost between the transfer from WebSphere Commerce to Sterling Order Management, another attempt for the information needed to be tried. This meant a new round-trip order transfer request is initiated by WebSphere Commerce. To avoid the loss of additional time, the reprocessing of an error is done in Sterling Order Management. This change allows you to avoid the time loss associated with resending from WebSphere Commerce.

Order item caching

One frequently accessed table in Sterling Order Management for order flow integration is YFS_ITEM. This table is cached by default in Sterling Order Management. However, the default cache entry number (10,000) does not meet the catalog volume in some systems. This can cause performance issues for low cache-hit-ratio workloads. Ideally, the cache entry size is large enough to contain most frequently used SKUs (stock-keeping unit) and leave a buffer for infrequently accessed ones. For example, if your total catalog volume is 1M SKUs and 3% are frequently accessed, you can set the cache entry size as 30K. Listing 4 and Listing 5 are configuration examples that change the cache entry size for YFS_ITEM table.

Increase table cache size for YFS_ITEM from 10K to 30K for the Sterling Order Management application server.

Listing 4. Edit the yfs_local/properties/customer_overrides.properties
dbclassCache.YFS_ITEM.count.size=30000
dbclassCache.YFS_ITEM.select.size=30000
dbclassCache.YFS_ITEM.list.size=30000
dbclassCache.YFS_ITEM.object.size=30000

Increase table cache size for YFS_ITEM from 10K to 30K for RTAM agent.

Listing 5. Edit the yfs/properties/customer_overrides.properties
dbclassCache.YFS_ITEM.count.size=30000
dbclassCache.YFS_ITEM.select.size=30000
dbclassCache.YFS_ITEM.list.size=30000
dbclassCache.YFS_ITEM.object.size=30000

NOTE: After you increase the cache entry size, you need to monitor the JVM heap usage and adjust the heap size to prevent out-of-memory issues.


Configuring topology

The simplest topology for a WebSphere Commerce and Sterling Order Management integration is to have a stand-alone server for each tier: WebSphere Commerce, WebSphere Enterprise Service Bus, and Sterling Order Management. However, a single tiered system limits the maximum capacity and possible throughput. You need to consider clustering for each tier when you meet a bottleneck to achieve higher throughput.

For the WebSphere Enterprise Service Bus tier, changing a stand-alone WebSphere Enterprise Service Bus server to a cluster can improve the capacity to process synchronous communication jobs. You can also set up two stand-alone WebSphere Enterprise Service Bus servers if you do not want to set up a WebSphere Enterprise Service Bus cluster. On the WebSphere Commerce side, you can point the inventory integration to one WebSphere Enterprise Service Bus server and point order integration to another WebSphere Enterprise Service Bus server. The result is that the synchronous workload for inventory calls is separated from the order transfer workload.

Another option is to have two stand-alone WebSphere Enterprise Service Bus servers with each one of them handling both inventory and order traffic. An IBM HTTP server can be used to split the traffic between the two stand-alone WebSphere Enterprise Service Bus servers.

Either of the two configurations can be enhanced for better fail-over by clustering the stand-alone WebSphere Enterprise Service Bus. However, setting up the WebSphere Enterprise Service Bus cluster might not increase the capacity to process asynchronous communication jobs since only one SIBus can be enabled within a WebSphere Enterprise Service Bus cluster. Therefore, you need to consider the setup of two WebSphere Enterprise Service Bus servers (each with one SIBus enabled) or two WebSphere Enterprise Service Bus clusters to increase the capacity for JMS-based communication.

On the Sterling Order Management side, the inventory-related calls are served by an Sterling Order Management application server, which is running on WebSphere Application Server. You can change the stand-alone Sterling Order Management server to a WebSphere Application Server cluster if you meet a capacity bottleneck on inventory calls. To set up Sterling Order Management application server cluster, you need to configure the web server (IBM HTTP server) to route the request. To make the two-way SSL certificate continue to work with an Sterling Order Management application cluster, you need to add the parameter in Listing 6 to the web server's httpd.conf file:

Listing 6. Add parameter to the httpd.conf file
<VirtualHost *:9443>
SSLEnable
SSLProtocolDisable SSLv2
#
# SSLClientAuth necessary to require 2 way auth using http server as endpoint
SSLClientAuth Required
</VirtualHost>

NOTE: It is easier to increase the capacity for an RTAM agent. You start multiple copies of the agent and then there are multiple instances running to process the workload in parallel.


Monitoring performance

To observe the all tuning parameters that are discussed in WebSphere Commerce tuning, the WebSphere Application Server provides the Performance Monitoring Infrastructure (PMI) to track statistics that are related to performance and resource consumption.

Monitoring WebSphere Commerce and WebSphere Application Server

WebSphere Application Server provides a built-in performance viewer in the administrative console. PMI statistics are selectively enabled under Monitoring and Tuning > Performance Monitoring Infrastructure (PMI) > server name. Or PMI statistics can be viewed real-time and saved under Monitoring and Tuning > Performance Viewer > Current activity. A recommended alternative is the WebSphere Application Server Performance Tuning Toolkit (PTT). PTT is a stand-alone application that can connect to a WebSphere server or cluster and provide a customizable dashboard of PMI statistics. Using wsadmin Jython or Jacl scripts, you can also periodically collect PMI stats and save them into a comma-separated value (CSV) file for later analysis in a spreadsheet or integration with another tool.

Monitoring WebSphere Enterprise Service Bus

Since the WebSphere Enterprise Service Bus runs within the WebSphere Application Server, the Performance Viewer is also available for WebSphere Enterprise Service Bus specific PMI statistics. There is also a separate application that is called the Service Integration Bus Performance which is similar to PTT. It is a stand-alone application that connects to a WebSphere Enterprise Service Bus server and allows a customizable view of ESB-related PMI statistics.

Monitoring Sterling Selling and Fulfillment Suite

There are multiple ways to monitor SSFS including: specific APIs, agents, application servers, and logs. For more information about the various monitoring methods, refer to the "Monitoring" topic on the SSFS information center, see Resources. For more recommendations on scalability requirements, performance features, and auditing capabilities, refer to the "General Recommendations" topic on the SSFS information center, see Resources.


Conclusion

The integration of WebSphere Commerce and Sterling Order Management provides a multi-channel e-commerce solution with the lifecycle management of orders and inventory. This integration is based on a service-oriented architecture that uses WebSphere Enterprise Service Bus as its connecting infrastructure. To achieve high performance for response times and throughput, modify how requests and responses are exchanged, and remember that asynchronous JMS and synchronous web services are used for inventory and order operations. WebSphere Commerce, WebSphere Enterprise Service Bus, and Order Sterling Managment have their own configuration and parameters that influence the flow of these operations in the system. To scale the integrated environment for a larger capacity, you will need additional servers or a clustered setup that is dedicated to the specific operations or the distribution of the entire workload.


Acknowledgements

The writers want to acknowledge the following people for providing information and reviewing the content in this article: Robert Dunn(dunn@ca.ibm.com), Jianwei Song (jianweis@ca.ibm.com), and Michael Cho (mcheecho@ca.ibm.com).

Resources

Learn

Get products and technologies

Discuss

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

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Commerce on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Commerce, WebSphere
ArticleID=856282
ArticleTitle=Integration performance tuning for WebSphere Commerce and Sterling Order Management
publish-date=01252013