| Author |
Message
|
| gfrench |
 Posted: Thu May 01, 2014 3:53 am Post subject: Dynamically Publishing a Message without an RFH2 header |
 |
|
Acolyte
Joined: 10 Feb 2002
Posts: 71
|
Simple requirement, I want to look at the content of a message and publish based on that content. I dont want an RFH2 header and I dont want to have to predefine all the topic objects.
If I use the publish node i get the RFH2 header
I've tried using an MQOutput node, using destination list and using queue name as topic to topic string, but it fails (2085) because the broker doesn't know I want it to open an object type topic not queue.
Is what I want to do possible?
Thanks for any advise. |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Thu May 01, 2014 4:32 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Hi Graham,
I think you are going to have to define the topics then you can write the message to an Alias Q where the TARGTYPE=TOPIC and the TARGET is the topic you want to publish to.
for example
| Code: |
def qa(ORDER_DATA.PUB) +
descr('Alias for Order update Publishing Messages') +
defpsist(YES) +
target(ORDER.DATA.PUBLISH) +
targtype(TOPIC) +
replace
|
I don't think that there is a way to do it totally dynamically. There has to be somewhere for the subscribers to be know to MQ.
Enjoy...
_________________
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: Thu May 01, 2014 5:16 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
But that makes it non-dynamic and means defining a topic alias queue for every possible topic string.
What GF wants to do - is entirely supported by WMQ 7 features.
The problem is that WMB does not seem to use these WMQ 7 pub/sub features and still uses the old style of JMS queued pub/sub.
Why is WMB living in the past?
WMQ does not have to know about subscribers in order to publish - you can publish to any topic string - whether there are subscribers or not - the whole point of pub/sub is to de-couple the message sender and receiver(s).
_________________
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.
Last edited by zpat on Thu May 01, 2014 5:17 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 01, 2014 5:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Subscribers and publishers are entirely separate.
Topic objects are conveniences and security points, not in any way required to either publish or subscribe.
The RFH2 header should be silently translated into message properties as of v7.0.1 and later of MQ. That is, if one doesn't want one's subscriber applications to have to worry about an RFH2, one should adjust the neccessary PSPROPs to make sure they don't, at the subscriber side.
Broker, *of course*, doesn't know anything about message properties. Unless they've finally done something in the v10 open beta...
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=20925 |
|
| Back to top |
|
|
| zpat |
| Posted: Thu May 01, 2014 7:08 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
AFAIK, using PSPROP(NONE) on the subscription will suppress the addition of pub/sub properties into the message headers.
However this does not turn a message published as a JMS message (MQRFH2) into a non-JMS message (MQSTR).
It would seem to be the case that one can only publish a JMS message from WMB (other than by using topic alias queues).
If this is not true please tell me how.
_________________
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 |
|
|
| gfrench |
| Posted: Thu May 01, 2014 7:11 am Post subject: |
|
|
Acolyte
Joined: 10 Feb 2002
Posts: 71
|
Almost need a cut and paste of the MQOutput node to create a new MQPublish node. Change the object type in the code to topic, a tidyup of configurable properties (queue becomes topic/topic string) and extend the use of LocalEnvironment to cover LocalEnvironment.Destination.Publish.DestinationData.topic
Anyone want to write a plugin or 10.0.1? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 01, 2014 7:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| I suppose I meant PROPCTL not PSPROP. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 01, 2014 11:18 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Wouldn't defining a subscription with PSPROP(MSGPROP) do the trick ?
In any case with the latest client you can request message properties in handle. Yes you have to change a little bit the way you did program... so what? Time to upgrade your programming skills.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Thu May 01, 2014 1:49 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
No, I want bog-standard MQSTR messages from WMB pub/sub.
No way should the subscribers have to make a special effort to handle JMS headers just because IBM haven't modernised the WMB publication node to use the MQ v7 API.
In any case you are assuming we even have access to the source code of the consuming applications.
(Incidentally GF and myself are working at the same place...).
_________________
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 |
|
|
| fjb_saper |
| Posted: Thu May 01, 2014 7:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
So you mean to say that setting the PSPROP(NONE|MSGPROP) on the subscription and setting the PROPCTL(NONE|ALL) on the subscription queue did not do the trick?
Notice that with the second option you do not loose the information in the message properties but you will have to code for "properties in handle", whereas with the none option you will strip the message of its properties...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gfrench |
| Posted: Thu May 01, 2014 10:48 pm Post subject: |
|
|
Acolyte
Joined: 10 Feb 2002
Posts: 71
|
| I'll have a play around with these options and see what they do. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu May 01, 2014 10:49 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I don't want to modify the queue either. Someone is bound to forget about the need for it, and it will be an accident waiting to happen.
I just want WMB to use WMQ v7 pub/sub API - is that really too much to ask?
_________________
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: Thu May 01, 2014 11:57 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| zpat wrote: |
I just want WMB to use WMQ v7 pub/sub API - is that really too much to ask? |
But WMQ 7 is going EOL so you are SOL
ducks to avoid incoming missiles  (it is friday after all)
_________________
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 |
|
|
| gfrench |
| Posted: Fri May 02, 2014 5:44 am Post subject: |
|
|
Acolyte
Joined: 10 Feb 2002
Posts: 71
|
The results of my findings:-
With a two queues and two subscription psprop(none) and psprop(rfh2) I get the following data on the queue when testing a subscription through MQExplorer:-
| Quote: |
| 6865 6C6C 6F 'hello ' |
| Quote: |
5246 4820 0200 0000 6000 0000 1101 0000 'RFH ....`.......'
B804 0000 4D51 5354 5220 2020 0000 0000 '©...MQSTR ....'
B804 0000 3800 0000 3C70 7363 3E3C 436F '©...8...<psc><Co'
6D6D 616E 643E 5075 626C 6973 683C 2F43 'mmand>Publish</C'
6F6D 6D61 6E64 3E3C 546F 7069 633E 2F61 'ommand><Topic>/a'
6263 3C2F 546F 7069 633E 3C2F 7073 633E 'bc</Topic></psc>'
6865 6C6C 6F 'hello ' |
With broker I thought I'd have to build the RFH2 header with the Command=Publish and Topic=/abc in the psc folder. Following that, when it gets on the subscription queue it looks like:-
| Quote: |
5246 4820 0200 0000 4400 0000 2202 0000 'RFH ....D..."...'
B804 0000 4D51 5354 5220 2020 0000 0000 '©...MQSTR ....'
B804 0000 1C00 0000 3C6D 6364 3E3C 4D73 '©.......<mcd><Ms'
643E 4D51 5354 523C 2F4D 7364 3E3C 2F6D 'd>MQSTR</Msd></m'
6364 3E20 4845 4C4C 4F 'cd> HELLO ' |
| Quote: |
5246 4820 0200 0000 8000 0000 2202 0000 'RFH ....Ç..."...'
B804 0000 4D51 5354 5220 2020 0000 0000 '©...MQSTR ....'
B804 0000 3800 0000 3C70 7363 3E3C 436F '©...8...<psc><Co'
6D6D 616E 643E 5075 626C 6973 683C 2F43 'mmand>Publish</C'
6F6D 6D61 6E64 3E3C 546F 7069 633E 2F61 'ommand><Topic>/a'
6263 3C2F 546F 7069 633E 3C2F 7073 633E 'bc</Topic></psc>'
1C00 0000 3C6D 6364 3E3C 4D73 643E 4D51 '....<mcd><Msd>MQ'
5354 523C 2F4D 7364 3E3C 2F6D 6364 3E20 'STR</Msd></mcd> '
4845 4C4C 4F 'HELLO ' |
So psprop(none) stripped the publish subscribe compontents and left the rest of the RFH2 header....
Final attempt was not to build an RFH2 publish command in the broker and see if I could just set the topic in the Properties folder:-
| Code: |
SET OutputRoot = InputRoot;
SET OutputRoot.Properties.Topic = '/abc'; |
TIt published and the result is no RFH2 on the queue psprop(none).
So it can be done, even if it means zpat has to amend his subscription to say no RFH2. Thanks fjb_saper, mqjef and smd |
|
| Back to top |
|
|
| zpat |
| Posted: Thu May 22, 2014 5:57 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I always set PSPROP(NONE) on my admin subs - in fact I've set it on the default subscription object as well.
_________________
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 |
|
|
|
|
