| Author |
Message
|
| jamesyu |
 Posted: Wed Sep 01, 2010 12:27 am Post subject: How to Set MessageType for Parsing? |
 |
|
Acolyte
Joined: 31 Jan 2007
Posts: 70
|
Hi All,
I have a message set project with multiple different broker schemas created, and in each broker schema, I have multiple message definition files associated with multiple messages in each message definition file.
Say one of those broker schemas is a.b.c.d. The message is called MyMessage created in the message definition file with the format of XML or TDS, etc. in this schema.
Normally I specify the message type in the Properties folder something like:
SET OutputRoot.Properties.MessageSet = 'MyMessageSet';
SET OutputRoot.Properties.MessageType = 'MyMessage';
SET OutputRoot.Properties.MessageFormat = 'XML1';
In this case, should I set the message type like this:
SET OutputRoot.Properties.MessageType = '{http://b.a/c/d/}:MyMessage';
Because in the trace file, I saw this:
(0x03000000:NameValue):MessageType = '{http://b.a/c/d/}:MyMessage' (CHARACTER)
Can anyone let me know what this "http" URI comes from? I checked the information centre, and didn't see the usage of this.
Thanks,
James |
|
| Back to top |
|
 |
| kimbert |
| Posted: Wed Sep 01, 2010 1:18 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
There is no need to supply the namespace when specifying the message type.
You *can* do so, but it is not required. |
|
| Back to top |
|
|
| jamesyu |
| Posted: Wed Sep 01, 2010 3:43 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2007
Posts: 70
|
| kimbert wrote: |
There is no need to supply the namespace when specifying the message type.
You *can* do so, but it is not required. |
I need to do this. Where to get the dcoument about the convention? if the full name is a.b.c.d.MyMessage, does it always convert it to {http://b.a/c/d/}:MyMessage?
The real reason I need to do this is in my message flow, I have a RCD node.
Like I described, my messaget set was automacally created by importing multiple WSDL files (ie. multiple broker schemas were generated). I use RCD to validate the web service response "immediately" after the SOAPREquest node. In RCD, I pick up XMLNSC as domain, and the message set. But the message type & message format are not editable in RCD (not sure why?), which is
causing the problem from RCD somehow the message type was pointing to the SOAP message definition like below:
A schema validation error has occurred while parsing the XML document:5032:2:1:76:Unexpected root tag.
Element ""SOAP_Domain_Msg"" is not a global element.:/Root/XMLNSC:"
So somehow, the XMLNC parser didn't find "MyMessage" from the message set, instead, it finds the "SOAP_Domain_Msg" autumatically generated by broker to parse the SOAP response.
I plan to explicitily set up the message type in my code to force RCD to use the right message to parse the SOAP response message. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Sep 01, 2010 7:15 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I can't work out whether a.b.c.d is the target namespace of one of your message definition files, or a path from a global element down to a local element. Please can you clarify that.
| Quote: |
| I plan to explicitily set up the message type in my code to force RCD to use the right message to parse the SOAP response message. |
XMLNSC does not use the MessageType and MessageFormats fields - that's why they are not editable when XMLNSC is set as the domain.
Note : XMLNSC does not use the message set properties defined in the XML1 physical format - it converts the mxsd files in the message set into raw xsds, and it validates strictly and accurately against those xsds. The XML1 physical format is only used by the MRM XML parser ( but please don't use MRM XML in a new message flow ).
| Quote: |
A schema validation error has occurred while parsing the XML document:5032:2:1:76:Unexpected root tag.
Element ""SOAP_Domain_Msg"" is not a global element.:/Root/XMLNSC:" |
That error message is probably telling the truth. If SOAP_Domain_Msg is not declared as a global element in one of your mxsd files then it cannot be used as the root tag in your XML document. Is there an element with name 'SOAP_Domain_Msg' somewhere in your message set? |
|
| Back to top |
|
|
| jamesyu |
| Posted: Wed Sep 01, 2010 7:48 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2007
Posts: 70
|
a.b.c.d is the broker schema, under this schema, the message difination file was created with a message named "MyMessage" defined.
If you are fimiliar with generating message set from WSDL, then you can see a soap.mxsd gets created in the defualt broker schema, and the SOAP_Domain_Msg is there. It is a global element.
The thing is, somehow RCD always pick up this message to validate the real SOAP response message... Not sure how this soap.mxsd works with other messages generated by WSDL... |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Sep 01, 2010 3:15 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| The thing is, somehow RCD always pick up this message to validate the real SOAP response message |
Not true. It is not the RCD node that makes the decision. The XMLNSC does what any other XML parser would do - it looks at the root tag and then looks in the available schemas for a global element with that namespace and name. So if this is true...
| Quote: |
| a soap.mxsd gets created in the defualt broker schema, and the SOAP_Domain_Msg is there. It is a global element. |
...then either
a) the message set does not contain that schema, or
b) the name/namespace of the root tag in the input message does not match that element declaration
If I were in your position I would open up the BAR file using a zip tool ( you can rename it to have extension .zip if that helps ), extract the <messsageSetName>.xsdzip ( again, change the extension if you need to ) and look at its contents. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 01, 2010 6:15 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
 Please don't open up the bar file unless you know exactly what you're doing.
If you're failing to match the SOAP message, then the most likely cause is indeed an issue with a namespace.
The usual suspects in this case are either a) sending a SOAP 1.2 message to a flow expecting a SOAP 1.1 message (or vice versa) or b) ending a namespace with an improper use of "/". I.e. either ending it with a "/" in the message when the XSD doesn't have one at the end, or vice versa.
The FIRST step in these cases is to go back and look at the WSDL or the message definition in the Toolkit and compare. And NOT to go mucking about in BAR files.
and the NEXT step after THAT is to take a user trace at debug level, and see exactly what the XMLNSC parser is doing.
I understand that the engineers who wrote the XMLNSC parser took some steps to ensure that it would provide lots of helpful information about namespaces and element and attribute parsing during a user trace.
Or do I have that wrong, kimbert? |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Sep 02, 2010 1:02 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Please don't open up the bar file unless you know exactly what you're doing. |
Modifying its contents would be dangerous. Unzipping it for the purposes of diagnosing a problem is not particularly dangerous.
| Quote: |
If you're failing to match the SOAP message, then the most likely cause is indeed an issue with a namespace.
The usual suspects in this case are either a) sending a SOAP 1.2 message to a flow expecting a SOAP 1.1 message (or vice versa) or b) ending a namespace with an improper use of "/". I.e. either ending it with a "/" in the message when the XSD doesn't have one at the end, or vice versa.
The FIRST step in these cases is to go back and look at the WSDL or the message definition in the Toolkit and compare. And NOT to go mucking about in BAR files. |
I agree - although my convictions on the matter are evidently not quite as strong as yours 
| Quote: |
| I understand that the engineers who wrote the XMLNSC parser took some steps to ensure that it would provide lots of helpful information about namespaces and element and attribute parsing during a user trace. |
The parsing of individual tags and attributes is not logged in the user trace by the XMLNSC parser. Perhaps you were thinking of the TDS parser, which does log its parsing activity in user trace? |
|
| Back to top |
|
|
|
|
