Inbound messages over IBM MQ
The IBM MQ adapter allows you to integrate back-end and external systems with WebSphere Commerce using IBM MQ. The IBM 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 IBM 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 IBM 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 IBM MQ connections, queues, and channels, run test programs to put messages into and get messages from IBM MQ queues. For details, refer to your IBM MQ documentation.
Listener for IBM MQ
The Listener for IBM MQ is a component of WebSphere Commerce that enables integration with back-end systems by processing inbound messages via MQ.
The Listener for IBM 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.
Parallel versus serial message processing in the Listener for WebSphere
The Listener for IBM 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.