Writing MQe pub/sub applications

There are two aspects to writing an MQe application to drive an MQ broker application. These are:
Configuration
  1. Configure a bridge to provide access to the target MQ queue manager from the MQe network specifying the transformer class com.ibm.mqe.mqbridge.MQeJMSRFHTransformer. Also on the bridge queue manager, configure two bridge queues:
    • One to act as a proxy for the broker’s control queue SYSTEM.BROKER.CONTROL.QUEUE.
    • One to act as a proxy for the input queue of the appropriate message flow.
  2. On the source MQe queue manager, configure connections to the MQe bridge queue manager and the target broker queue manager (this latter connection being via the bridge queue manager).
  3. On the source MQe queue manager, configure two remote proxy queues:
    • One to act as a proxy for the broker’s control queue SYSTEM.BROKER.CONTROL.QUEUE.
    • One to act as a proxy for the input queue of the appropriate message flow.
Application development
  1. Construct an MQe message that will be transformed by the bridge into an MQ message suitable for the broker. This message will have a standard MQMD header and an RFH2 header, as well as a suitable payload.
  2. Send the subscription and un-subscription messages to the broker’s control queue. Send publication messages to the input queue of the appropriate message flow.

The message should be of the com.ibm.mqe.mqemqmessage.MQePubSubMsgObject class. Should it be necessary to use a bespoke WMQ MQMD, then values e message object, (for example, setCorrelationId, setMessageId, setExpiry, setFeedback, setReport, setUserId, and so on). The publish/subscribe operations are invoked through the methods publish, subscribe and unsubscribe.

Responses from the broker will be received as messages of the same class. The overall success of an operation is given by the getCompletionCode method; more detailed information is provided by getResponses. The broker never returns the publication data, but information on the nature of the original request is available through getActionType, getDestQueueMgr, getDestQueueName, getRetention and getTopics.

For messages that have been constructed, the following methods can be used to return information about the request: getMessage and getMessageData.

More information on the configuration details appropriate to a bridge is provided in the MQe publications, including the handling of replies back from the target MQ application.


Terms of use | WebSphere software

(c) Copyright IBM Corporation 2004, 2005. All rights reserved.