| Author |
Message
|
| crossland |
 Posted: Wed Oct 15, 2008 7:39 am Post subject: MRM does not parse when RFH2 is set |
 |
|
Master
Joined: 26 Jun 2001
Posts: 248
|
When I set MQRFH2 fields in one flow, a subsequent flow is failing to parse its incoming MRM message, producing a BLOB.
If I remove the following code to set the RFH2 fields, the MRM parser correctly parses the message:
SET OutputRoot.MQRFH2.(MQRFH2.Field) Version = 2;
SET OutputRoot.MQRFH2.(MQRFH2.Field) Format = MQFMT_STRING;
SET OutputRoot.MQRFH2.(MQRFH2.Field) NameValueCCSID = InputRoot.Properties.CodedCharSetID;
SET OutputRoot.MQRFH2.(MQRFH2.Field).usr.fname = value;
Prior to setting the RFH2 fields, I am issuing SET OutputRoot.MQMD.Format = MQFMT_RF_HEADER_2.
Looking at the message that is generated, it looks as if the RFH2 values and MQMD value have all been set.
Has anyone seen something in the RFH2 that could stop the MRM parser from working?
Thanks for any help. |
|
| Back to top |
|
 |
| fschofer |
| Posted: Wed Oct 15, 2008 7:50 am Post subject: |
|
|
Knight
Joined: 02 Jul 2001
Posts: 524
Location: Mainz, Germany
|
Hi,
is the MQRFH2 mcd folder filled after the first flow ?
Greetings
Frank |
|
| Back to top |
|
|
| paranoid221 |
| Posted: Wed Oct 15, 2008 11:21 am Post subject: |
|
|
Centurion
Joined: 03 Apr 2006
Posts: 101
Location: USA
|
fschoefer is right.
I did have this problem before and this is what I did.
SET OutputRoot.MQRFH2.mcd.Msd = 'MRM'
The Msd describes the message service domain for the consumers of this message.
This has worked for me.
Try this and you should be fine. I Guess 
_________________
LIFE is a series of complex calculations, somewhere multiplied by ZERO. |
|
| Back to top |
|
|
| crossland |
| Posted: Thu Oct 16, 2008 1:53 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
Thanks for the pointer, paranoid221.
Using the debugger, WMB appears to reset OutputRoot.MQRFH2.mcd.Msd when you leave the Compute node if the message is a BLOB.
However, inserting a ResetContentDescriptor node (with all the MRM fields set) into the first flow, before the MQOutput node, did the trick.
In a way, this is far from ideal as it suggests that WMB would struggle to MRM parse a message that has a RFH2 header, unless the first application is aware of the Message Set details. |
|
| Back to top |
|
|
| paranoid221 |
| Posted: Thu Oct 16, 2008 9:01 pm Post subject: |
|
|
Centurion
Joined: 03 Apr 2006
Posts: 101
Location: USA
|
In your first flow, you can set the Msd property of the RFH2 header to MRM in a compute node right before your MQOutput node. I'm failing to see a reason why you'd need to include an RCD. MRM is a supported and allowed/valid value for Msd. If however the consumer of your message is a JMS app, the Msd needs to be jms_text and this is where you'd typically use the RCD node to force the Msd to be jms_text.
On a side note, in the compute node before the MQOutput node in your first flow if you haven't set the Msd property, broker defaults it to <none> and this would mean that the message will be treated as an opaque BLOB. This is what I'm suspecting to be happening in your case.
There could be one more reason why you are seeing the Msd to be reset.
The documentation says the following:
| Quote: |
The <Set> element is needed when <Msd> is mrm, xmlnsc, or idoc; the <Type> element is needed when <Msd> is mrm; the <Fmt> element is needed when <Msd> is mrm or idoc.
|
So when you set mcd.Msd to MRM, make sure you set the following:
mcd.Set=Message set that you are using
mcd.Type = Your Message Type
mcd.Fmt = The message format that you are using
Give it a try. It should work and you can buy some performance by getting rid of the RCD node.
Not sure if I made any sense to you with the above description but pardon me if I misinterpreted your solution and/or requirements.
_________________
LIFE is a series of complex calculations, somewhere multiplied by ZERO. |
|
| Back to top |
|
|
| crossland |
| Posted: Fri Oct 17, 2008 12:22 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
Going through with the debugger, I saw the Msd, Set, Type and Fmt fields of the mcd all being set. Then, on leaving the Compute node, the Msd field was reset. This may be due to the format of the message being a blob.
To get round this, I was able to set the Msd field in the RCD node and allow the other mcd fields to be set in the Compute node.
Ideally, I would prefer not to have to use a RCD node and just set the values in the Compute node. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Oct 17, 2008 1:19 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
|
| Back to top |
|
|
| crossland |
| Posted: Fri Oct 17, 2008 1:48 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
Thanks for the pointer, Kimbert - my previous searches somehow managed to miss that link.
It would be nice to be able to specify in the second flow that the MRM parser should be applied against an incoming BLOB which contains a RFH2 header. This could be done by providing an 'override RFH2 mcd' option on the MQInput node Parsing properties.
Otherwise the first flow has to be aware of the message set used by the second flow, forcing tight coupling of services.
Maybe in a future release? |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Oct 17, 2008 1:10 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I see your point. I'm not convinced that your 'override RFH2 mcd' option is the best solution because a very common use of the RFH2 mcd is to deliberately override the input node properties. Providing an option to reverse that order of precedence would create confusion.
If I were in your position, I would probably use the environment variable to revert to the old behaviour. |
|
| Back to top |
|
|
|
|
