What criteria can be used to separate message flows between two or more channels on IBM MQ?

0
votes

We give support to an organization that uses IBM MQ (v9.0) to communicate to an external partner. It's a simple layout, a single local queue manager connected to an external one trough one single channel. Various applications use different queues to communicate trough this QM.

Last week, after solving a support ticket, my boss came to the conclusion that having one single channel to funnel all the messages from the different queues (and applications that use such queues) is not good.

I have to write a report detailing what criteria should we use to separate the message flows into different channels, and what benefits and inconveniences would this entail.

I'm fairly new to IBM MQ, and I'm having trouble finding information on this topic. So far I've read the official documentation and other bibliography and i have a superficial idea about it, but i cant find concrete information about this topic. Is separating message flows into different channels a good practice? What would be a good criteria to use?

1
ibm-mq
Using different channels to support different applications and/or class of service is a valid use case. Another possible item is message priority. If the receiving application and any XMITQs in between have MSGDLVSQ(PRIORITY), then messages with a higher priority will be delivered before messages of a lower priority. – JoshMc
For traffic between 2 queue managers, I generally look at message sizes and then categorize them. i.e. small and large so all application sending small messages are routed on channel 'A' and all other messages are routed on channel 'B'. But you could go with 3 categorizes i.e. small, medium & large messages. Going with a QMgr-To-QMgr channel for each application is a bit extreme but can be done. Note: Don't forget that each Receiver or Requester channel requires its own port number. – Roger
@Roger Can you explain why each Receiver/Requester channel would require it's own port number? – JoshMc
Ahh. I meant TCP Listener. I was thinking of truly separating the network traffic. – Roger
Thanks for the clarification. I think in some cases it is good to have different listeners for different traffic, for instance if you want to allow your admin tool traffic to hit the queue manager but not application traffic. Note that with the IPADDR attribute you can have the same port on multiple listeners (for instance different queue managers on the same host) as long as the interface is different where there is port overlap. I also recommend this when you have HW clusters and VIPs, if you listen only on the VIP it ensures that the apps can't use the wrong IP. – JoshMc

1 Answers

0
votes

Here is a good write up on channels and it discusses reasons for parallel channels. You may be able to use this in your report. MQ Channels

If you have applications with large messages that are of the fire-and-forget pattern it is common to put these on a different path than the real time apps that are of the request-response pattern.

Whether or not this configuration change will lessen the chance of problem tickets depends largely on what led to the issue. Good luck.