| Author |
Message
|
| MQSIGuy |
 Posted: Sun Feb 13, 2011 7:40 am Post subject: MRM TDS Behaviour |
 |
|
Novice
Joined: 26 Oct 2009
Posts: 20
|
Hi,
When building a complex structure in TDS message set I am receiving one of two errors.
I am creating a structure like this in a TDS MSET
<GROUP>
<GROUP1>
<ITEM1/>
<ITEM2/>
</GROUP1>
<GROUP2>
<GROUP3/>
<GROUP4>
<GROUP5/>
</GROUP4>
</GROUP2>
</GROUP>
Basically it is an XML structure with nested repeating groups down to the 4th level although each level can have multiple groups.
When I set the first group after the GROUP tag to min occurs '0' and max occurs '1' I get this error.
"MTI. Not all the buffer was used when reading message"
However when I set the occurs to min '1' and max '1' I get the following error.
"Missing markup following a complex child or group"
and the error is indicating its the first <GROUP> tag that's the issue. I have spent considerable time on this and I can't figure it out. I have checked on several occassions that the XML input matches the TDS message set which is why I don't understand the not all the buffer used error. I have also checked the error text with the markup error
"The parent of this child or group has a Data Element Separation of 'All Elements Delimited' or 'Variable Length Elements Delimited'. All complex children within a type or group with a Data Element Separation of 'All Elements Delimited' or 'Variable Length Elements Delimited' must be followed by some markup. That is a 'Repeating Element Delimiter', a 'Delimiter', a 'Group Terminator' or some markup from a higher level in the message model. "
and tried several solutions but can't make any progress after a long time spent on this.
Can anyone offer any insight to this error(s)> Any help would be greatly appreciated.... |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sun Feb 13, 2011 8:11 am Post subject: Re: MRM TDS Behaviour |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQSIGuy wrote: |
| Can anyone offer any insight to this error(s) |
If you can offer some insight into why you're trying to use a message set to parse an XML structure.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MQSIGuy |
| Posted: Sun Feb 13, 2011 8:46 am Post subject: Re: MRM TDS Behaviour |
|
|
Novice
Joined: 26 Oct 2009
Posts: 20
|
| Vitor wrote: |
| MQSIGuy wrote: |
| Can anyone offer any insight to this error(s) |
If you can offer some insight into why you're trying to use a message set to parse an XML structure. |
Well its not ideal but its because we have an unbounded input xml message. that has nested unbounded repeating groups to possible tens of thousands. Its parsed from XML to an output fixed length string but because the groups are unbounded at several levels CWF woudl not suffice.
The plan was to use TDS to map the input xml messages unbounded (as TDS gives) as well as accounting for some mandatory fixed length strings (again TDS offers this ) then use a simple LASTMOVE code snippet to parse the output message into a fixed length string which of course will be variable as is required and what CWF can't offer with this complexity.
No requirement for a CWF message set as the TDS has already done the validation. Simply parse into BLOB and output to application. This was the though behind it... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Feb 13, 2011 3:26 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Is the data actually contained within tags within angle brackets, in a format that is in fact consistent with the syntax of an XML document? If so, you should only be using the XMLNSC parser to manage it.
If it's an XML document, using anything other than an XML parser to parse it is at best poorly thought out.
I otherwise don't understand your explanation for what you are trying to do.
XMLNSC can fully validate the contents of a document, including the length of strings within tags. And you can construct a simplified TDS model for your fixed length output string - but it's not clear what the output message is supposed to consist of either, so you might not need TDS or you might again need to use XMLNSC. |
|
| Back to top |
|
|
| MQSIGuy |
| Posted: Mon Feb 14, 2011 11:49 pm Post subject: |
|
|
Novice
Joined: 26 Oct 2009
Posts: 20
|
| mqjeff wrote: |
Is the data actually contained within tags within angle brackets, in a format that is in fact consistent with the syntax of an XML document? If so, you should only be using the XMLNSC parser to manage it.
If it's an XML document, using anything other than an XML parser to parse it is at best poorly thought out.
I otherwise don't understand your explanation for what you are trying to do.
XMLNSC can fully validate the contents of a document, including the length of strings within tags. And you can construct a simplified TDS model for your fixed length output string - but it's not clear what the output message is supposed to consist of either, so you might not need TDS or you might again need to use XMLNSC. |
Hi,
Point noted about the XMLNSC and agreed but in this instance we can't use XMLNSC due to a few reasons that you'll have to take my word for that it simply isn't an option...
The message is XML input to fixed length string output. My thoughts were simply that we can't validate the output with a CWF message set because the length of the fixed length string is variable, that is sometimes it could be 100 bytes in length and then it could be 10k bytes in length.
That is why building a TDS model of the input XML allows it to be validated for mandatory fields and length of fields as dictated by the requirements. It would then be a case of parsing the TDA model into a fixed length string an outputting to the client.
Are you suggesting creating an MRM TDS set that validates the output rather than the input? I guess I hadn't considered this approach, although its probably obvious now its been suggested. In my time with the broker I have seen instances of TDS sets that validate XML input. I agree its not the norm but perhaps its because times have changed in terms of validation and how things are done within the broker? I'm not sure... |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Feb 15, 2011 1:56 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| in this instance we can't use XMLNSC due to a few reasons that you'll have to take my word for that it simply isn't an option... |
I assume that was intended to make us all curious. I cannot think of any good reason why a modern integration application should parse XML with anything other than an XML parser.
OK, I can. Because the upstream application is generating badly-formed XML data. In which case the correct decision is to fix the upstream application, or else stop calling it 'XML' and switch to a more compact non-XML format.
| Quote: |
| we can't validate the output with a CWF message set because the length of the fixed length string is variable |
This must be a new way to use the phrase 'fixed length'  . I must assume that the string length is encoded in the data, or else there is a delimiter indicating the end of the string.
| Quote: |
| Are you suggesting creating an MRM TDS set that validates the output rather than the input? |
If we are talking about validating the message tree, then it makes little difference either way unless the logical structure is simpler to validate at the output side. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Feb 15, 2011 3:55 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
set because the length of the fixed length string is variable
|
That is actually a lovely statement.
If this is the really the situation and it gets solved, I'm sure there is a Nobel Prize for Maths in it somewhere 
_________________
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 |
|
|
|
|
