|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Which message model type to choose? |
« View previous topic :: View next topic » |
Author |
Message
|
Wim |
Posted: Fri Mar 21, 2008 2:32 am Post subject: Which message model type to choose? |
|
|
Newbie
Joined: 25 Oct 2006 Posts: 9 Location: BE, EU
|
Hi,
The message I'm trying to model in toolkit V6.0.2 is physically one long string of characters (no delimiters or separators) and it is structured as follows:
- Field1 is 5 characters long and acts as a length code for Field2
- Field2 is "a record".
These 2 fields are repeated until the end of the stream.
The 'record'-part is identified by the first 2 characters of the record (i.e. record-type).
I can have 16 different types of record; they are described in a COBOL copybook. All but one are optional and they can repeat.
One record has a structure "OCCURS 0 TO 30 DEPENDING ON (previously-defined-field)" in it. This structure appears at the end of the record, but the record appears somewhere in the middle of the stream.
I modeled the message in TDS as a sequence of 2 elements:
- A local element (length field)
- A complex type (choice)
The complex type of composition "choice" has TDS DES="Tagged Fixed Length". The choice is resolved by the 2 character record-type as a tag.
This works fine until I encounter the record with the repeating structure in it.
The parser insists on creating 30 structures even if the previously-defined-field has a value of say "02". The result is that the remaining records are "eaten up" and eventually I get a parser exception.
I hoped that somehow the length field would restrict the number of characters that are passed to the choice, and therefor stop creating structures when it runs out of "record", but this does not seem to be the case
So, is there a way to indicate the number of repeats for this structure? In TDS I only see "Repeating Element Delimiter" ... but the message doesn't have delimiters. All the other stuff is about "length".
In the CWF properties I found Repeat References so I figured that maybe a CWF model could parse the message.
After a lot of reading in the docs and in the forums, it became clear that a choice in CWF was not possible because the records I have are not the same length. So I decided to convert everything to a multipart message in CWF. I treated every record as a separate message, with the value of the record-type interpreted as MessageIdentity in combination with the Message Alias for the selection (instead of choice). But now I'm stuck with the length field in front of each record. I cannot seem to indicate that the parser should interpret this field as being the length of the record that follows...
If all the above is correct, I have 4 options to model my message:
1. CWF with choice
2. CWF with multipart message
3. TDS with choice
4. TDS with multipart message
1: doesn't work because the record lengths are different
2: doesn't work because I cannot interpret the length field
3: doesn't work because of the structure that repeats n times based on a previous field
4: haven't tried yet but I guess it wouldn't work for the same reason as 3.
Any ideas to get me out of this mess would be greatly appreciated.
-=Wim=- |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Mar 21, 2008 3:27 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
If everything else fails you could always try parsing it record by record using CWF...
Did not understand your need to interpret the length field for CWF multipart message.
Change your message to include the length field as it is part of each row...
so your row definition would be
length field
cobol structure...
I am sure this can be modeled in CWF so the message type identifier is the second field instead of the first....
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Wim |
Posted: Fri Mar 21, 2008 4:38 am Post subject: |
|
|
Newbie
Joined: 25 Oct 2006 Posts: 9 Location: BE, EU
|
Quote: |
Did not understand your need to interpret the length field for CWF multipart message. |
The length field is necessary to know where the "record" ends, because the same record type can have different lengths due to optional fields at the end of the record.
I thought the parser would first chop the message into records by using the length field and then try to "recognise" the records by matching the record-type with the Message Aliases. How would the parser otherwise know where the records end?
-=Wim=- |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Mar 21, 2008 12:32 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Wim wrote: |
Quote: |
Did not understand your need to interpret the length field for CWF multipart message. |
The length field is necessary to know where the "record" ends, because the same record type can have different lengths due to optional fields at the end of the record.
I thought the parser would first chop the message into records by using the length field and then try to "recognise" the records by matching the record-type with the Message Aliases. How would the parser otherwise know where the records end?
-=Wim=- |
Seem to remember something about the optional fields having to be at the end of the message/record. But the MRM parser should know which fields are optional...
Anyway you could parse it in ESQL by reading the right number of bytes and doing a create parse with the right message info.... _________________ MQ & Broker admin |
|
Back to top |
|
 |
kimbert |
Posted: Fri Mar 21, 2008 3:08 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
I do understand the problem you are facing.
I think your best hope is to try the Tagged Encoded Length style in TDS. I know for a fact that it limits the content of an element to the length specified. The only question is whether you can set 'Tag Length' to zero and still have things work properly. Worth a try, at least.
If you were on V6.1, you might have been able to use the new 'Repeat Reference' support in TDS to model to 'OCCURS 0 to 30 DEPENDING ON'. That would avoid the need to know the entire length of the structure in advance ( for that structure only ). If there are other records among your 16 which still require the length to be known then this would only be a partial solution. |
|
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
|
|
|
|