| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Wildcard element processing fails in MRM |
« View previous topic :: View next topic » |
| Author |
Message
|
| cjr8020 |
 Posted: Tue Jun 23, 2009 3:10 pm Post subject: Wildcard element processing fails in MRM |
 |
|
Newbie
Joined: 25 Sep 2006
Posts: 8
|
MQSI 6.0.0.8
I have a message envelope defined in an XSD. It has a body element defined in a manner that is nearly identical to soap-envelop 1.2:
Body->sequence->any wildcard ##any
When I create a message definition, I see the following:
Body->{Local complex Type}(min:1, max:1)->Wildcard Element (min:1, max:-1)
Sort of what I expected (I suppose "Local complex Type" acts as a "sequence" would)..
I also see a warning:
| Quote: |
Wildcard Element has min/max occurs set to something other than 1. This is only supported on a broker running at version 6.0 or above. Brokers running below this level will ignore the min/max occurs value.
|
Ok, I have 6.0.0.8, so I should be fine. However, the behaviour I observe is exactly as if the wildcard max value is being ignored. That is, I can successfully produce a single complex element in the Body, however, when I attempt to produce a second one of the same or different type, I get
| Quote: |
(0x03000000):Number = 5339
(0x03000000):Text = 'move to next sibling failed.'
|
The exception is thrown not in the Compute node where the output message is being produced, but during parsing prior to MQOutput node.
Any ideas would be appreciated. |
|
| Back to top |
|
 |
| kimbert |
| Posted: Wed Jun 24, 2009 12:55 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
Ok, I have 6.0.0.8, so I should be fine. However, the behaviour I observe is exactly as if the wildcard max value is being ignored. That is, I can successfully produce a single complex element in the Body, however, when I attempt to produce a second one of the same or different type, I get
| Code: |
(0x03000000):Number = 5339
(0x03000000):Text = 'move to next sibling failed.' |
|
Two things:
- That is just the summary line of the message. You should look in the Windows event viewer. If not on Windows, you should take a user trace, or look up the full text of the message online.
- I don't understand what the problem is ( probably my fault ). The parser is throwing an exception when you include two bodies. But you seem to be saying that it is 'ignoring' the maxOccurs value on the wildcard?
| Quote: |
The exception is thrown not in the Compute node where the output message is being produced, but during parsing prior to MQOutput node.
|
Good. Take a user trace, and read it carefully. By default, message broker uses 'on demand parsing' which means that the parser only parses what the message flow needs. In this case, it may be delaying some of the parsing of the input message until it needs to construct the output message. |
|
| Back to top |
|
|
| cjr8020 |
| Posted: Wed Jun 24, 2009 10:34 am Post subject: |
|
|
Newbie
Joined: 25 Sep 2006
Posts: 8
|
Let me try to describe the problem a little better. The idea was to use an element wildcard as a child of "Body" to allow any element in any namespace to be used in its place. Actually, a sequence is used as an immediate child of Body to allow for "one or many" cardinality of the "any" element:
| Quote: |
...
<xsd:element name="Body" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
...
|
When I attempt to produce an output message containing one object, say "Person", no problem:
| Quote: |
<?xml version="1.0"?>
<NS1:Envelope xmlns:NS1="envelope" xmlns:NS2="Person" xmlns:NS3="Org" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="1.0.0">
...
<NS1:Body>
<NS2:Person>
...
</NS2:Person>
</NS1:Body>
</NS1:Envelope>
|
However, as soon as I attempt to add another object to the body, e.g
| Quote: |
<?xml version="1.0"?>
<NS1:Envelope xmlns:NS1="/NS/envelope" xmlns:NS2="/NS/Person" xmlns:NS3="/NS/Org" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version="1.0.0">
...
<NS1:Body>
<NS2:Person>
...
</NS2:Person>
<NS3:Org>
...
</NS3:Org>
</NS1:Body>
</NS1:Envelope>
|
I get an exception. I took a User Trace and it was not very helpful:
| Quote: |
ParserException BIP5339E: Mismatch between message tree and logical definition. While writing the message, the message tree did not match the logical structure of the message. The problem was encountered while attempting to write element ''/NS/Org:Org'' in message set ''TestService (AIG1VO0002001)''.
This problem is usually caused by a badly-structured input message. It can also be caused by a badly-structured output message tree. Check that the structure of the input message matches the logical structure of the message. ....
|
So, it appears that the MRM model does not allow Org to appear in the Body. However, Org is certainly defined in the message set. Individually, I can put either Person or Org in the Body, but not both. This is why I'm questioning whether or not the parser is interpreting min/max correctly. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jun 24, 2009 2:57 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Right. That's a lot clearer now.
The MRM parser does not claim to be a 100% accurate implementation of the W3C schema spec. I suspect ( based on previous experience ) that this is an example of non-compliance.
You *could* raise a PMR but it would probably be easier to find another solution. I would try one of
- switch off validation in the output node ( if not strictly required )
- move up to v6.1 and use XMLNSC
- change the model to use an embedded message instead of a wildcard. |
|
| Back to top |
|
|
| cjr8020 |
| Posted: Wed Jun 24, 2009 3:47 pm Post subject: |
|
|
Newbie
Joined: 25 Sep 2006
Posts: 8
|
Kimbert, appreciate your recommendations. Evaluating which route to go.
Just tested switching off validation in the output node, unfortunately, that did not prevent the parse exception - so same outcome - input message rolled back..
Tested this as on v6.1. Exact same behaviour - the 6.1 MRM parser hasn't gotten this particular update ...
On a different note, even if the wildcard cardinality worked as it should, there would be another issue - when I configure message domain as MRM in the input node, I specify the message set that contains all of the message definitions (Envelope, Person, Org), but then I have to select one and only one message type. I've selected "Envelope" which results in everything being self-defined that isn't defined in Envelope. Generally, this isn't good..
I guess I have one last question (which has probably been answered many times). Unless one absolutely has to have validation, is there any reason why you would use MRM in 6.0 or beyond?
Thanks again for your responses. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 24, 2009 10:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| cjr8020 wrote: |
Tested this as on v6.1. Exact same behaviour - the 6.1 MRM parser hasn't gotten this particular update ...
|
No, but as kimbert said, v6.1 does have XMLNSC.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 24, 2009 10:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| cjr8020 wrote: |
| Unless one absolutely has to have validation, is there any reason why you would use MRM in 6.0 or beyond? |
Even if you do have validation, the reasons are limited. Speaking personally, I use XMLNSC for everything that isn't a CWF or other specialised message (e.g. MIME)
Other opinions here are equally valid of course.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jun 25, 2009 12:17 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I'm not surprised that v6.1 MRM XML suffers from the same problem - that's why I recommended XMLNSC.
There is no good reason for using MRM XML in v6.1 and beyond, even if you do need validation. All new message flows which process XML should use XMLNSC, unless the guidance in the product docs suggests that XMLNS is more suitable ( that will be unusual ). |
|
| 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
|
|
|
|
