| Author |
Message
|
| walterA |
 Posted: Sun Dec 06, 2015 10:41 am Post subject: Consume messages by multiple apps: how to design |
 |
|
Novice
Joined: 22 Sep 2015
Posts: 20
|
Hello, can someone help me with this.
I will have an external system that will be sending messages through MQ channel to be consumed by my company internal applications. So the design would look like this.
System A (external)| Remote Q1/Q Manager 1 -----> MQ Channel -----> Local Q1/Q Manager 2 | System B (Internal)
Now the problem is there might be multiple internal applications who are interested in events from the external system A. For the beginning it there will be only one consumer, but I need to design it to be able to add more consumers in the future.
How can I do this?
I believe I can use publisher subscriber for this? but how does it work when the producer is located remotely?
Thank you |
|
| Back to top |
|
 |
| zpat |
| Posted: Sun Dec 06, 2015 1:48 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Just arrange for the queue at your end to be a topic alias queue.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Dec 06, 2015 2:03 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Do you mean multiple consumers - each consuming one message - as a transaction?
Does the consumer app send a reply back to the producer app?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| walterA |
| Posted: Sun Dec 06, 2015 7:06 pm Post subject: |
|
|
Novice
Joined: 22 Sep 2015
Posts: 20
|
| bruce2359 wrote: |
Do you mean multiple consumers - each consuming one message - as a transaction?
Does the consumer app send a reply back to the producer app? |
There are multiple applications within the company. They might be interested in events from the vendor. Two or more applications can consume the same event. I need to design a system when the messages/events come to the system from the external vendor and they can be used by multiple applications enterprise -wide.
There is no response back to the producer. It's only one-way flow from the vendor to the company. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Dec 06, 2015 8:47 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
What do you mean by "event?"
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Dec 06, 2015 10:55 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| bruce2359 wrote: |
| What do you mean by "event?" |
By event, I would assume specifc content of the message.
some form of content based routing would be the ideal solution but probable overkill for this size of operation.
Sending the message to an Alias Q with a Topic as its destination is probably the best solution.... until the OP comes back and says that the Message ID is important to one application.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| walterA |
| Posted: Mon Dec 07, 2015 3:40 pm Post subject: |
|
|
Novice
Joined: 22 Sep 2015
Posts: 20
|
An event is the same as a message
So the system will look like this?
System A (external)| Remote Q1/Q Manager 1
|
MQ Channel
|
Alias Q/ Q Manager 2 (internal)
|
Topic
| | |
loaclQ1 localQ2 localQN
| | |
app#1 app#2 app#N
Thank you |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Dec 07, 2015 10:28 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
You are missing one step.
The Topic is the first part of a Pub/Sub setup.
You can publish all the messages you like on a topic but if there are no subscribers they could just disappear (not in a cloud of smoke but the metaphor is useful)
The missing bit is the subscription. Each of the queues (localQ1.... localQn) will be defined in 1..n subscriptions that refer to the topic (input) and the queue name (output).
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Dec 08, 2015 1:23 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Ensure the PSMODE enabled (only need do this once).
ALTER QMGR PSMODE(ENABLED)
Define topic object with fixed topic string (of your choice)
DEFINE TOPIC(TEST.DUP) TOPICSTR('/MQ/DUPLICATE/TEST1') DURSUB(YES) REPLACE
Define topic alias queue using topic object
DEFINE QALIAS(TEST.ALIAS) DEFPSIST(YES) TARGTYPE(TOPIC) TARGET(TEST.DUP) REPLACE
Define local queues to receive the messages (they could also be remote queues as needed)
DEFINE QLOCAL(TEST.QUEUE1) DEFPSIST(YES) REPLACE
DEFINE QLOCAL(TEST.QUEUE2) DEFPSIST(YES) REPLACE
Define admin durable subscriptions
DELETE SUB(TEST.SUB1)
DEFINE SUB(TEST.SUB1) DEST(TEST.QUEUE1) TOPICOBJ(TEST.DUP) PSPROP(NONE)
DELETE SUB(TEST.SUB2)
DEFINE SUB(TEST.SUB2) DEST(TEST.QUEUE2) TOPICOBJ(TEST.DUP) PSPROP(NONE)
Now - just put a message to TEST.ALIAS and it should appear on both local queues.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Dec 08, 2015 4:27 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Note: With the Pub/Sub solution, the MQMD structure of the message is not replicated to the copied queues (a new MQMD is created for each copied message).
<VendorPlug>
There is a commercial solution called MQ Message Replication that will clone both the message data and MQMD of each incoming message.
</VendorPlug>
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Dec 09, 2015 4:24 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| RogerLacroix wrote: |
Note: With the Pub/Sub solution, the MQMD structure of the message is not replicated to the copied queues (a new MQMD is created for each copied message).
<VendorPlug>
There is a commercial solution called MQ Message Replication that will clone both the message data and MQMD of each incoming message.
</VendorPlug>
Regards,
Roger Lacroix
Capitalware Inc. |
which was why I posted
| smdavies99 wrote: |
Sending the message to an Alias Q with a Topic as its destination is probably the best solution.... until the OP comes back and says that the Message ID is important to one application. |
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Dec 09, 2015 10:02 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
2 points:
(A) If the OP was not interested in MsgId but maybe PutDate and/or PutTime (or some other field of the MQMD) then it is important to know
(B) It was a vendor plug for a different approach
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| walterA |
| Posted: Sat Dec 12, 2015 12:44 pm Post subject: |
|
|
Novice
Joined: 22 Sep 2015
Posts: 20
|
Thank you so much for the answers! It is very helpful.
if I use durable subscriptions, do I need to use persistent messages in the local queues? I need to make sure that no messages will be lost.
Also, are there any other options for this model? E.g. what if to implement a (java) listener instead of the alias Q and from there distribute messages to other internal queues or topics?
Thank you! |
|
| Back to top |
|
|
| zpat |
| Posted: Sat Dec 12, 2015 1:46 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
Regardless of the design, use persistent messages to avoid risk of loss if that is important.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Dec 13, 2015 12:40 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| walterA wrote: |
Also, are there any other options for this model? E.g. what if to implement a (java) listener instead of the alias Q
|
Why? Pleaxe give us your reasoning behing this question
| walterA wrote: |
and from there distribute messages to other internal queues or topics?
Thank you! |
A Properly designed PUB/SUB Topic heirarchy will do this for you. Please go read the MQ Documentation on the subject especially Topic Strings.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
