| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Changing a message per subscription |
« View previous topic :: View next topic » |
| Author |
Message
|
| simonalexander2005 |
 Posted: Wed Aug 21, 2019 8:20 am Post subject: Changing a message per subscription |
 |
|
Acolyte
Joined: 13 Jun 2016
Posts: 55
|
IIB10/MQ8 (soon to be upgraded to 9)
We have an XML message which we generate in IIB, and publish to a topic. The message is identical for all recipients except for the text content of a single element which needs to be unique per subscriber.
Is there a way to include something in the message which is interpreted by the subscription into text when the copy of the message is sent out? Options I can see so far are:
1. Don't use pub/sub at all, and just generate hundreds of copies of the message, using a database to store the subscriber info and where to send each message
2. I can see the MQ Publish Exit (https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.ref.dev.doc/q108130_.htm) which looks like it may be able to do what I want; but I've seen many warnings on this forum about the folly of exits, and how there's nearly always a better way
3. Any other built-in options that I've missed?
Thank you for any advice or suggestions you can give |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 21, 2019 9:21 am Post subject: Re: Changing a message per subscription |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| simonalexander2005 wrote: |
| I2. I can see the MQ Publish Exit (https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.ref.dev.doc/q108130_.htm) which looks like it may be able to do what I want; but I've seen many warnings on this forum about the folly of exits, and how there's nearly always a better way |
Wise words.
Assume for a moment a magic dohicky that edits published messages before they're delivered to a subscriber. Assume that the publisher can modify the message so it includes :
| Code: |
<SubscriberSpecificText>{EDIT_THIS_BECAUSE_OF_THE_BRACES}</SubscriberSpecificText>
|
and the dohicky knows that anything between { and } is an edit target.
How would this thing determine what to replace for a given subscriber? What are the rules? Is it based on subscriber name? Subscription? It clearly can't be based on the payload. What text needs to be inserted?
It's important because if this is based on some key/value lookup on an external-to-MQ data store, using the exit moves from dangerously unwise to utterly, utterly suicidal.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| simonalexander2005 |
| Posted: Thu Aug 22, 2019 12:52 am Post subject: |
|
|
Acolyte
Joined: 13 Jun 2016
Posts: 55
|
| Quote: |
| and the dohicky knows that anything between { and } is an edit target. |
Actually, it's always the same message structure (apart from the message type itself, which could vary), so we'll just have known blank tags which the "dohicky" would enter the data in between.
Each subscription would require a different code, so it would be possible to use data found in the MQSBC structure directly - perhaps the subscription name
e.g.
Message published to topic:
| Code: |
| <OneOfVariousMessageTypes><CommonMessageHeader><Recipient id=""></Recipient></CommonMessageHeader><MessageBody>...</MessageBody></OneOfVariousMessageTypes> |
Then a Subscription named "0001_99" could generate:
| Code: |
| <OneOfVariousMessageTypes><CommonMessageHeader><Recipient id="99">0001</Recipient></CommonMessageHeader><MessageBody>...</MessageBody></OneOfVariousMessageTypes> |
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 22, 2019 4:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| simonalexander2005 wrote: |
| Quote: |
| and the dohicky knows that anything between { and } is an edit target. |
Actually, it's always the same message structure (apart from the message type itself, which could vary), so we'll just have known blank tags which the "dohicky" would enter the data in between.
Each subscription would require a different code, so it would be possible to use data found in the MQSBC structure directly - perhaps the subscription name
e.g.
Message published to topic:
| Code: |
| <OneOfVariousMessageTypes><CommonMessageHeader><Recipient id=""></Recipient></CommonMessageHeader><MessageBody>...</MessageBody></OneOfVariousMessageTypes> |
Then a Subscription named "0001_99" could generate:
| Code: |
| <OneOfVariousMessageTypes><CommonMessageHeader><Recipient id="99">0001</Recipient></CommonMessageHeader><MessageBody>...</MessageBody></OneOfVariousMessageTypes> |
|
Bad design. The subscription can change the message when it gets it to replace the {do hicky}.
This should have nothing to do with a subscription point.
If all that changes between different subscribers is the {do hicky} let the subscriber fix that part. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| simonalexander2005 |
| Posted: Thu Aug 22, 2019 5:03 am Post subject: |
|
|
Acolyte
Joined: 13 Jun 2016
Posts: 55
|
Yes, I know, but it's what we've got. Unfortunately the subscribing system instances can't be changed, and require this data to be already set (to prove that it is the intended instance of the receiving system for the message - otherwise it rejects it as it's not the intended recipient, in its eyes).
So I have to do this somehow. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 22, 2019 6:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| simonalexander2005 wrote: |
Yes, I know, but it's what we've got. Unfortunately the subscribing system instances can't be changed, and require this data to be already set (to prove that it is the intended instance of the receiving system for the message - otherwise it rejects it as it's not the intended recipient, in its eyes). |
This wrecks your proposed solution. If this data is effectively a security feature to prove that this is a message addressed to the receiving system, adding the data based on the subscription is pointless and possibly dangerous.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
