| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MRM Validation Design for XML |
« View previous topic :: View next topic » |
| Author |
Message
|
| DAS |
 Posted: Sun Feb 26, 2006 3:20 am Post subject: MRM Validation Design for XML |
 |
|
Apprentice
Joined: 15 Aug 2005
Posts: 30
|
| Code: |
| Broker version: Websphere Business Integration Message Broker v5 CSD 6 |
I have noticed some very strange validation behaviour. I have created a very simple message-flow (MQInput->MQOutput) with MRM validation on the MQInput node (Content and Value, Exception, Complete).
The message-set I used has three MRM definitions in it (message A,B,C). For the Message Type field in the MQInput node I used 'A'.
The message format I used is XML, so all messages are modelled based on XSD's.
Now I assumed that this MQInput node would only accept the message 'A', so messages B and C should not be accepted and neither would a message for which no MRM definition exists in the message-set.
To my enjoyment (as I wanted to create a simple validation flow, that will only let messages pass for which a MRM definitions exists in the message-set and obviously, they should be conform the appropriate MRM definition (valid)) I saw the following:
Valid messages A,B and C did get validated properly, although the Message Type was set to 'A'. Afterwards I also tried to validate message D and I did get a parser exception, that message A was expected, but message D was given.
Now I found this prettyg strange, but what I found even more strange was the following:
When I leave the Message Type empty in the MQInput node the above validation process works the same, BUT with one big difference: message D does get through the validation process!!
I have seen posts where people said, that 'by design' the MRM parser does not do anything with the Message Type field for XML messages. It simply takes the root-tag of the XML message and treats that as the Message Type.
Now this would be true when I could fill in anything that I like in the Message Type field and I would get the same validation behaviour, but....imho....the MRM validation process for XML messages does not work 'as designed' or the design decisions made are (lightly said) strange.
NOTE: I can even stress this out further by saying that in my opinion, the Message Type field is used as a flag for XML messages in the MRM domain to let the parser know, whether you want messages with an unknown root-tag to get through the validation process. I can even harden this statement, because I entered bogus information in this field. I entered 'This IBM product is very strange' in the Message Type field and you know what?? Messages A,B and C were accepted, but message D wasn't (the exact exception: The message identifier in the bitstream ('D') differs from the expected message identifier ('This IBM product is very strange')).
Everybody will agree with me.....strange.......VERY strange 
I am very pleased with my findings though, as I can create a validation flow that suits my needs now.
I do wonder though, could a IBM guy tell me in clear words how this MRM validation process works for XML messages, based on the Message settings used in the MQInput node? Even you guys must admit that this behaviour is strange and if you tell me that it works by design....I am intrigued by the way you handle node properties differently in each case 
Thanks in advance! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Sun Feb 26, 2006 4:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The fields on the MQInput node are only default values. If a message comes in that can't be identified, then and only then will they be used.
If a message comes in with an MQRFH2 that includes MessageSet, MessageType, and etc properties, then the Broker will use those.
There's nothing strange about this. It's just that you don't know how it works.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| DAS |
| Posted: Sun Feb 26, 2006 9:01 am Post subject: |
|
|
Apprentice
Joined: 15 Aug 2005
Posts: 30
|
Aha....thanks Jeff and indeed I don't understand how it works, that's why I was posting this 
Thanks for your very short, though clear answer. I fully understand it now! |
|
| Back to top |
|
|
| DAS |
| Posted: Sun Feb 26, 2006 12:22 pm Post subject: |
|
|
Apprentice
Joined: 15 Aug 2005
Posts: 30
|
This thing still puzzles me though. Every message I put onto the queue does not contain a RFH2 header, so I guess all of my messages aren't recognized and therefore the Message properties on the MQInput node are used right?
If that is true, then this still doesn't explain why I see different validation behaviour when tinkering with the Message Type field of the MQInput node.
Now let's assume that the broker recognizes message A, B and C without a RFH2 header, then my logical question would be: where does it get the information from? I assume that the broker traverses the message-set entered as the Message Set property and looks if it can find a message with the same name as the root-tag of the message. But what does it do with the Message Type field then? Does an empty Message Type field mean that each and every XML message will be accepted?
Could you please tell me how this process works in steps, as I still don't get it. It would make it understandable for me, if I knew that no matter what I would be entering in the Message Type field, the same behaviour would be noticed, but that's not the case.
Maybe you don't understand my question, so I write it down in short:
XML messages A,B and C are valid messages, for which a message definition is available in the message-set entered as the Message Set property for the MQInput node.
XML message D is a valid XML message, for which NO message definition exists. Messages are put onto the queue without an RFH2 header.
Results when putting message A,B,C and D onto the input queue:
Message Type empty --> Message A,B,C and D get through
Message Type filled with some content (doesn't matter what) --> Message A,B and C get through, D doesn't
Is it logical that the unrecognized message D is only flagged as invalid when the Message Type field is filled with some bogus data? If so....I don't get it  |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Feb 26, 2006 2:23 pm Post subject: Message Sets & Different messages |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Thtere is a mechanism in the message set called CHOICE
If the XCD is written correctly, then the message set can interpret different messages quite easily.
The message set can handle these via the choice mechanism.
In my experince it is easier to set all these options in the XSD and importing it all cleanly rather than developing it all in the message set designer. IMHO it is a lot easier, quicker and more reliable.
Normally, the Choice mechanism is used then there is some commonality between the messages. Usually, a message header or something similar.
For example
MsgA = Message Header + Choice A
MsgB = Message Header + Choice B
IN the XML world, this is just a different set of tags after the header.
eg
<Message_Body>
<Sales_Record>
or
<Message_Body>
<Stock_Record?
and so on.
_________________
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 |
|
|
| DAS |
| Posted: Sun Feb 26, 2006 10:42 pm Post subject: |
|
|
Apprentice
Joined: 15 Aug 2005
Posts: 30
|
Thank you for this tip smdavies99. Though, I know that mechanism, but I don't want to convert all my XSD's in one huge XSD's (or import them using the XSD import feature).
I just want to understand the validation process of XML messages modelled in the MRM domain.
In other words, my question phrased in the previous post still stands |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Feb 27, 2006 4:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In the case of XML, if the root tag can be matched with a message in the default message set, then that message will be used.
Also, XML is in general self-defining, so if the broker can identify that the message is XML then it will be parsed as XML without the use of a message definition.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| DAS |
| Posted: Mon Feb 27, 2006 11:18 am Post subject: |
|
|
Apprentice
Joined: 15 Aug 2005
Posts: 30
|
Well, I sort of understand it now. I still don't understand though, why message D gets through when the Message Type is empty. I guess this is normal behaviour.
If someone would ask you though, that he wants non-modelled XML messages not getting through the validation process, would you tell him to enter some content in the Message Type field? Really, am I the only one who finds this strange? If you can tell me that an empty Message Type field means 'accept any XML that is well-formed', I would be satisfied |
|
| 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
|
|
|
|
