| Author |
Message
|
| Esa |
 Posted: Mon Feb 06, 2012 5:56 am Post subject: MQRFH2Header node |
 |
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Has anybody ever requested or thought about an MQRFH2Header node? I think that would be a nice one and it shouldn't be too difficult to implement. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Feb 06, 2012 6:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
No, it's a completely unnecessary thing.
At least, once broker supports Message Properties correctly and directly.
MQRFH2 is obsolete with version 7, and everyone should stop thinking about messages as if they had an MQRFH2 on them. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 06, 2012 6:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Also, the MQHeader node should already cover this, and if it doesn't, a Mapping node should. |
|
| Back to top |
|
|
| Esa |
| Posted: Mon Feb 06, 2012 6:18 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| mqjeff wrote: |
| At least, once broker supports Message Properties correctly and directly.. |
Somehow I get the impression that it's not the case yet...
| mqjeff wrote: |
| MQRFH2 is obsolete with version 7, and everyone should stop thinking about messages as if they had an MQRFH2 on them. |
Unfortunately some obsolete applications are still sending messages that have an RFH2 header.
| mqjeff wrote: |
| Also, the MQHeader node should already cover this |
It should, shouldn't it?
| mqjeff wrote: |
| No, it's a completely unnecessary thing. |
From pattern development point of view it's not. I would very much like to see the concern of transforming message payload separated from the concern of modifying the headers. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Feb 06, 2012 6:43 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
No, it's a completely unnecessary thing.
At least, once broker supports Message Properties correctly and directly.
MQRFH2 is obsolete with version 7, and everyone should stop thinking about messages as if they had an MQRFH2 on them. |
And what about MQ's famed compatibility with older versions? Are you trying to tell us that has all gone down the plughole?
There are quite a few systems I know of that can't be upgraded due to other version incompatibility issues. eg, an old version of Biztalk that won't run with WMQ 7 and that the biztalk apps can't be upgraded as the supplier went bust without leaving the source code in escrow.
_________________
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 |
|
|
| mqjeff |
| Posted: Mon Feb 06, 2012 6:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Esa wrote: |
| mqjeff wrote: |
| At least, once broker supports Message Properties correctly and directly.. |
Somehow I get the impression that it's not the case yet... |
Broker v7 and v8.0.0.0 still populate and read from Root.MQRFH2. That's not quite the same thing as supporting message properties directly.
| Esa wrote: |
| mqjeff wrote: |
| MQRFH2 is obsolete with version 7, and everyone should stop thinking about messages as if they had an MQRFH2 on them. |
Unfortunately some obsolete applications are still sending messages that have an RFH2 header. |
If they are talking to a MQ v7 queue manager, those MQRFH2 headers will have been turned into message properties.
Broker will then read those message properties and populate them into Root.MQRFH2.
This doesn't mean that there's an MQRFH2 header in the mix anywhere.
| Esa wrote: |
| mqjeff wrote: |
| Also, the MQHeader node should already cover this |
It should, shouldn't it? |
I'm surprised to hear you suggest that it doesn't, but I've never seen significant reason to use an MQHeader node, so.
And, thirdly, again, the Mapping Node should handle this if MQHeader doesn't.
| Esa wrote: |
| mqjeff wrote: |
| No, it's a completely unnecessary thing. |
From pattern development point of view it's not. I would very much like to see the concern of transforming message payload separated from the concern of modifying the headers. |
From a pattern development point of view, you can create two separate mapping nodes, one that maps the message payload and one that manages the message properties.
Then, among other things, you can promote or make UDPs the relevant header properties in a way that is more obviously separated from the message payload properties.
Again, however, given that MQ itself considers the MQRFh2 header to be an obsolete notion in all newer levels of MQ, you should consider it extremely unlikely that the Broker team will spend any time developing anything to further support them. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 06, 2012 6:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Esa wrote: |
| Somehow I get the impression that it's not the case yet... |
That day is in the foreseeable future.
| Esa wrote: |
| mqjeff wrote: |
| MQRFH2 is obsolete with version 7, and everyone should stop thinking about messages as if they had an MQRFH2 on them. |
Unfortunately some obsolete applications are still sending messages that have an RFH2 header. |
So what we really need is seamless compatibility at the queue manager level where an RFH2 == Message Properties.
| Esa wrote: |
| From pattern development point of view it's not. I would very much like to see the concern of transforming message payload separated from the concern of modifying the headers. |
Forced to disagree slightly there. The RFH2 is not a technical header like the MQMD & the CICS header. There's often a lot of business data in that usr folder which is very often a key input to the transformation process. So it's hard to strictly segrigate the processing of that header from the processing of the message.
I take your point in terms of developing a pattern.
IMHO an RFH2Header node might have been useful 5 years ago. Now the RFH2 itself is in it's golden years I'd prefer development effort inside WMB focused on other matters.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Esa |
| Posted: Mon Feb 06, 2012 7:04 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Vitor wrote: |
| IMHO an RFH2Header node might have been useful 5 years ago. Now the RFH2 itself is in it's golden years I'd prefer development effort inside WMB focused on other matters. |
I agree very much. RFH2 shold be allowed to retire and rest in peace in the heaven of headers.
| mqjeff wrote: |
| Again, however, given that MQ itself considers the MQRFh2 header to be an obsolete notion in all newer levels of MQ, you should consider it extremely unlikely that the Broker team will spend any time developing anything to further support them. |
Indeed, they should be doing their best to support message properties. It would be very valuable to many customers. But perhaps nobody has requested it? |
|
| Back to top |
|
|
| inMo |
| Posted: Mon Feb 06, 2012 10:25 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
I'm curious to see if I've understood correctly that:
1. MQRFH2 will be supported going forward. At a minimum to ensure backwards compatability.
2. Message properties are the prefered path forward (I say prefered as I don't see any other applicable statement given point 1. Will something prevent someone from leveraging an MQRFH2 header?) |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 06, 2012 11:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| inMo wrote: |
I'm curious to see if I've understood correctly that:
1. MQRFH2 will be supported going forward. At a minimum to ensure backwards compatability. |
When you construct a message in your application that contains an MQRFH2, and you then write that message to a queue hosted on an MQ V7 queue manager, to the best of my knowledge, the message on the queue does not have an MQRFH2 header on it.
It has message properties that represent the same data.
| inMo wrote: |
| 2. Message properties are the prefered path forward (I say prefered as I don't see any other applicable statement given point 1. Will something prevent someone from leveraging an MQRFH2 header?) |
Message properties is the default path forward for putting context information on a message that is not part of the message body.
When an MQ v6 queue manager sends a message over a channel with an MQRFH2 header on it, MQ v7 will convert all of that data into message properties, unless the channel is specifically constructed to prevent it.
When an MQ v6 application publishes a message using MQRFH2 structures talking to an MQ v7 pub/sub broker, the MQRFH2 header is converted to message properties.
At least, as I understand things from the documentation...   |
|
| Back to top |
|
|
| Esa |
| Posted: Mon Feb 06, 2012 11:56 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Funny enough, I have always thought exactly the other way around. That message properties is just a new API for accessing the data stored in an RFH2 header. The documentation is a bit unclear about this. The MQ 7 course materials, from where my knowledge mostly comes from, are even more unclear. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 06, 2012 12:08 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Esa wrote: |
| Funny enough, I have always thought exactly the other way around. That message properties is just a new API for accessing the data stored in an RFH2 header. The documentation is a bit unclear about this. The MQ 7 course materials, from where my knowledge mostly comes from, are even more unclear. |
And yet, if you use amqsbcg, what do you see?
Message properties are not stored in an MQRFH2. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 06, 2012 12:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Esa wrote: |
| Funny enough, I have always thought exactly the other way around. That message properties is just a new API for accessing the data stored in an RFH2 header. The documentation is a bit unclear about this. The MQ 7 course materials, from where my knowledge mostly comes from, are even more unclear. |
Well I look at it as a dual way to represent the same data.
If the propctrl is compatibility mode or RFH2 you will see an RFH header on the message.
If the propctrl is neither of those nor none you get V7 properties.
Using the JMS classes the access to the properties makes no difference whether RFH2 or V7 style...
Maybe that helps alleviate somewhat the fog of that confusion... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 06, 2012 12:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
[quote="Esa" ]That message properties is just a new API for accessing the data stored in an RFH2 header.[/quote]
[quote="Esa" ] The documentation is a bit unclear about this.[/quote]
Hardly. The WMQv7 InfoCenter says here:
| Quote: |
| Use message properties to allow an application to select messages to process, or to retrieve information about a message without accessing MQMD or MQRFH2 headers |
(Bold added for emphasis)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| inMo |
| Posted: Mon Feb 06, 2012 12:39 pm Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
I'm looking at a message that I know uses an MQRFH2 header. It is sitting on a v7 queue manager's queue. The message format is marked as MQHRF2. The message has StrucId of RFH and Version 2. The RFH structure contains a <usr> folder, an <mcd> folder and a <mqps> folder.
I'm gather the details through MQMON, but can also see the StrucId RFH through MQ Explorer.
This message, at least to me, seems to be in the physical RFH2 structure while sitting on the queue. Thoughts/Comments?
---
Adding after seeing I missed a few posts while writing:
Property Control is set to 'Compatibility'
Last edited by inMo on Mon Feb 06, 2012 12:47 pm; edited 1 time in total |
|
| Back to top |
|
|
|
|
