Simple queue distribution scenario with pub/sub WMQ - ibm-mq

Question

Using WebSphere MQ I want to setup up a topic that uses queues, so that when an application or inbound cluster connection attempts to put a message to a “queue”, it
actually uses a topic, and publishes it to 2 subscriptions, which are
themselves 2 separate queues. In essence, I want to go from an inbound
queue by name, but map it to 2 separate queues, like
AF_TO_DAAS is the inbound topic/which today is an actual
cluster queue alias
=>Goes to AF_TO_APP1 and
=>Goes to AF_TO_APP2
Sort of like if these were queues on a distribution list I suppose.
Those two things are local queues.
I’m getting lost in the /topic/node business mapping it to subscriptions
and model queues and what not …

Answer 1

WebSphere MQ allows an alias to point to a queue or a topic. It also provides a means to create a durable subscription administratively. To accomplish this setup, you connect the dots by replacing the existing alias with one that points to a topic. Then use two administrative subscriptions to route publications to the two (or more) queues.
* First, define the topic
DEFINE TOPIC('AF_TO_DAAS.TOPIC') +
TOPICSTR('AF_TO_DAAS') +
REPLACE
* Now, create an alias over the topic.
* Sending apps think this is a queue.
DEFINE QALIAS('AF_TO_DAAS') +
TARGET('AF_TO_DAAS.TOPIC') +
TARGTYPE(TOPIC) +
REPLACE
* Queues for the two recvr apps
DEFINE QLOCAL('AF_TO_APP1') +
REPLACE
DEFINE QLOCAL('AF_TO_APP2') +
REPLACE
* Now set up adminsitrative subs to route
* messages to the two app queues.
DEFINE SUB('AF_TO_DAAS.SUB') +
TOPICSTR('') +
TOPICOBJ('AF_TO_DAAS.TOPIC') +
DEST('AF_TO_APP1') +
PSPROP(NONE) +
REPLACE
DEFINE SUB('AF_TO_APP2.SUB') +
TOPICSTR('') +
TOPICOBJ('AF_TO_DAAS.TOPIC') +
DEST('AF_TO_APP2') +
PSPROP(NONE) +
REPLACE
Because this is a publication, the messages will contain a property Top which contains the topic string. The PSPROP(NONE) in the subscription entries causes this to be suppressed so the messages look like the original publication.
Note also that the MQMD.MsgID on the publications is different than it is on the original message.