John Edelmann
John Edelmann

Reputation: 181

Simple queue distribution scenario with pub/sub WMQ

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 …

Upvotes: 2

Views: 2926

Answers (1)

T.Rob
T.Rob

Reputation: 31832

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.

Upvotes: 5

Related Questions