Inbound messages over WebSphere MQ

The WebSphere MQ adapter allows you to integrate back-end and external systems with WebSphere Commerce using WebSphere MQ. The WebSphere MQ adapter allows WebSphere Commerce to receive messages from back-end systems and external systems. The messages sent may be either XML messages or legacy messages.

You can set up WebSphere MQ through the use of MQ Java in one of two modes:

bindings mode: WebSphere Commerce is installed on the same machine as the WebSphere MQ server and it connects to the WebSphere MQ server through WebSphere MQ Java using the Java Native Interface (JNI). Since communication is through direct JNI calls to the queue manager API rather than through a network, bindings mode provides better performance than client mode done using network connections.
client mode: WebSphere Commerce is installed on one machine and the WebSphere MQ server is installed on a back-end system.

To verify WebSphere MQ connections, queues, and channels, run test programs to put messages into and get messages from WebSphere MQ queues. For details, refer to your WebSphere MQ documentation.

Listener for WebSphere MQ

The Listener for WebSphere MQ is a component of WebSphere Commerce that enables integration with back-end systems by processing inbound messages via MQ.

The Listener for WebSphere MQ has a set of predefined messages that help integrate WebSphere Commerce business processing with back-end or external system processing. Each incoming message activates processes within WebSphere Commerce to update database tables or perform other operations. In addition to the existing pre-defined messages, the listener supports message extensions and new messages. Note that the Embedded Messaging Server is only available in the WebSphere Commerce Developer Edition.

See Enabling the Listener for WebSphere MQ for more information.

Parallel versus serial message processing in the Listener for WebSphere

The Listener for WebSphere MQ can process inbound messages in two ways:

Serial processing: Each message is put in a line, or queue, and handled one after another. In this method, each message must wait until processing of the previous message is complete.
Parallel processing: A number of messages can be processed at the same time. Instead of each message having to wait for the previous one to be completed, many of them can be run simultaneously.

Although parallel processing generally results in faster throughput, it is not suitable for all types of requests. There are some situations in which the serial nature of the transactions must be preserved. For example, if a new customer registers at your store, then makes a correction to their address information, then makes a purchase order, you would want the order of these transactions to be preserved when processing them. You could not perform the address modification or the purchase order unless the account had already been created. Likewise, you would not want to fulfill a purchase order without having the correct shipping information.

Although it is generally preferable to use parallel processing where possible, you will have to decide where it is appropriate to use this method on your data.