Communicating with a Queue Manager outside Cluster!!

1. You already have a Queue Manager cluster (named JOSEPH) setup with 2 Queue Managers with names QM1 and QM2 and all the requires channels are setup for communication between QM1 and QM2
2. You have QM3, which is outside the cluster
3. QM2 has a Queue [Q2] defined at cluster level.
In this tutorial, let us send message from QM3’s Q3 to QM2’s Q2 and in the reverse path.
In this case one of your Queue Managers should act as a gateway. Say for example, lets make QM1 as the gateway for cluster and QM3 is outside cluster.
Steps:
1. The queue manager outside the cluster must have a QREMOTE definition for each queue in the cluster that it wants to put messages to.
    DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM2) XMITQ(TQ1) [in this case Q2 is a cluster queue and i want to put message from QM3 -> QM2]
2. QM3 must have a SDR channel and TX queue to QM1 and QM1 should have corresponding RCVR channel
For replies:
3. The gateway (QM1) advertises a queue-manager alias for the queue manager outside the cluster. It advertises this alias to the whole cluster by adding the cluster attribute to its queue-manager alias definition.
DEFINE QREMOTE(QM3) RNAME(‘ ‘) RQMNAME(QM4) CLUSTER(JOSEPH)
4. QM1 must have a SDR channel and TX queue to QM4 and QM4 should have corresponding RCVR channel.
Observe the below diagram, to understand the setup

Now, you need to define the following, for communicating from QM3 to Cluster and Cluster to QM3.
on QM1:
DEFINE QL(TQ3) USAGE(XMITQ)
DEFINE LISTENER(QM1_LIST) TRPTYPE(TCP) PORT(1111)
DEFINE CHANNEL(TO.QM3) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘localhost(3333)’) XMITQ(TQ3)
DEFINE CHANNEL(TO.QM1) CHLTYPE(RCVR) TRPTYPE(TCP)CONNAME(‘localhost(1111)’)
DEFINE QREMOTE(QM3) RNAME(‘ ‘) RQMNAME(QM3) XMITQ(TQ3) CLUSTER(JOSEPH)
on QM2:
DEFINE QL(Q2) CLUSTER(JOSEPH)
DEFINE LISTENER(QM2_LIST) TRPTYPE(TCP) PORT(2222)
on QM3:
DEFINE QL(Q3)
DEFINE QL(TQ1) USAGE(XMITQ)
DEFINE LISTENER(QM3_LIST) TRPTYPE(TCP) PORT(3333)
DEFINE CHANNEL(TO.QM1) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘localhost(1111)’) XMITQ(TQ1)
DEFINE CHANNEL(TO.QM3) CHLTYPE(RCVR) TRPTYPE(TCP)CONNAME(‘localhost(3333)’)
DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(QM2) XMITQ(TQ1)
Start all the listeners on QM1/2/3 and Ensure all channels are running. First test that you are able to communicate between QM1 and QM2.
Then, you should be able to put messages
QM3[Q3] –> QM2[Q2]
QM2[Q2] –> QM3[Q3]
Similarly, if you have any queue on QM1, create corresponding QREMOTE on QM3(which is outside).


Questions :

1.      Follow up Question …. If QM1 should die what happens to QM3? Can QM3 be configured to reattach to a live QM in the cluster to live on?

ANS: the communication between QM1 and QM3 is point-to-point . So if QM1 is not reachable, no communication b/n QM1QM3.

Websphere MQ Quick reference

MQSC: indicates a runmqsc command, which can be executed while in runmqsc [QmgrName] or  as one line command using:
echo command | runmqsc [QmgrName]
on Unix platforms add double quotes:
echo “command” | runmqsc [QmgrName]

All about MQinput Node !!

MQInput node

Use the MQInput node to receive messages from clients that connect to the broker by using the WebSphere® MQ Enterprise Transport, and that use the MQI and AMI application programming interfaces.

Purpose

The MQInput node receives a message from a WebSphere MQ message queue that is defined on the broker's queue manager. The node uses MQGET to read a message from a specified queue, and establishes the processing environment for the message. If appropriate, you can define the input queue as a WebSphere MQ clustered queue or shared queue.
Message flows that handle messages that are received across WebSphere MQ connections must always start with an MQInput node. You can set the properties of the

node to control the way in which messages are received, by causing appropriate MQGET options to be set. For example, you can indicate that a message is to be processed under transaction control. You can also request that data conversion is performed on receipt of every input message.

If you include an output node in a message flow that starts with an MQInput node, the output node can be any one of the supported output nodes, including user-defined output nodes; you do not need to include an MQOutput node. You can create a message flow that receives messages from WebSphere MQ clients and generates messages for clients that use any of the supported transports to connect to the broker, because you can configure the message flow to request that the broker provides any conversion that is necessary.
If you create a message flow to use as a subflow, you cannot use a standard input node; you must use an Input node as the first node to create an In terminal for the subflow.
If your message flow does not receive messages across WebSphere MQ connections, you can choose one of the supported input nodes.

Connecting the terminals

The MQInput node routes each message that it retrieves successfully to the Out terminal. If this action fails, the message is retried. If the backout count is exceeded (as defined by the BackoutThreshold attribute of the input queue), the message is routed to the Failure terminal; you can connect nodes to this terminal to handle this condition. If you have not connected the Failure terminal, the message is written to the backout queue.
If the message is caught by this node after an exception has been thrown further on in the message flow, the message is routed to the Catch terminal. If you have not connected the Catch terminal, the message loops continually through the node until the problem is resolved.
You must define a backout queue or a dead-letter queue (DLQ) to prevent the message from looping continually through the node.

Configuring for coordinated transactions

When you include an MQInput node in a message flow, the value that you set for Transaction mode defines whether messages are received under sync point:

• If you set the property to Automatic, the message is received under sync point if the incoming message is marked as persistent; otherwise, it is not received under sync point. Any message that is sent subsequently by an output node is put under sync point, as determined by the incoming persistence property, unless the output node has overridden this explicitly.
• If you set the property to Yes (the default), the message is received under sync point; that is, within a WebSphere MQ unit of work. Any messages that are sent subsequently by an output node in the same instance of the message flow are put under sync point, unless the output node has overridden this explicitly.
• If you set the property to No, the message is not received under sync point. Any messages that are sent subsequently by an output node in the message flow are not put under sync point, unless an individual output node has specified that the message must be put under sync point.

The MQOutput node is the only output node that you can configure to override this option.

MQGET buffer size

The MQGET buffer size is implemented internally by the broker and you cannot change it. The following description is provided for information only. You must not rely on it when you develop your message flows, because the internal implementation might change.

When the node initializes, it sets the size of the default buffer for the first MQGET to 4 KB. The MQInput node monitors the size of messages and increases or reduces the size of the buffer:

1. If an MQGET fails because the message is larger than the size of the buffer, the node immediately increases the size of the buffer to accommodate the message, issues the MQGET again, and zeros a message count.
2. When 10 messages have been counted since the increase in the size of the buffer, the compares the size of the largest of the 10 messages with the size of the buffer. If the size of the largest message is less than 75% of the size of the buffer, the buffer is reduced to the size of the largest of the 10 messages. If an MQGET fails during the 10 messages because the message is larger than the size of the buffer, the node takes action 1.

For example, if the first message that the node receives is 20 MB, and the next 10 messages are each 14 MB, the size of the buffer is increased from 4 KB to 20 MB and remains at 20 MB for 10 messages. However, after the 10th message the size of the buffer is reduced to 14 MB.