|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MRM - Fixed length Records, Delimited with Space problem |
« View previous topic :: View next topic » |
Author |
Message
|
Tonedef |
Posted: Mon May 21, 2007 2:39 am Post subject: MRM - Fixed length Records, Delimited with Space problem |
|
|
Apprentice
Joined: 05 Feb 2007 Posts: 44
|
Trying to model a Fixed Length record that contain spaces as a delimited and spaces as a padding character,
Can anyone advise the best way to do this,
I am trying All elements delimited but it doesn't like the spaces !
File looks something like
TAG1<sp>DATA1<sp>DATA2<sp>DATA3<sp> <sp>DATA7<CRLF> |
|
Back to top |
|
 |
vk |
Posted: Mon May 21, 2007 8:17 am Post subject: |
|
|
Partisan
Joined: 20 Sep 2005 Posts: 302 Location: Houston
|
Hi Tonedef,
What do you mean by Fixed Length record? Should the elements DATA1, DATA2 etc have a fixed length padded with spaces?
Also, is this the only record type in the file or can there be more records? TAG2, TAG3 etc?
If it is just a single record which repeats, you can try the following design -
Message of Type Type1 (All Elements Delimited, Delimiter "<CR><LF>")
--------Element Record of Type Type2 (All Elements Delimited, Delimiter "SPACE", Select Observe Element Length property)
----------------TAG1 STRING (Specify Length)
----------------DATA1 STRING (Specify Length)
----------------DATA2 STRING (Specify Length)
----------------DATA7 STRING (Specify Length)
Regards,
VK. |
|
Back to top |
|
 |
Tonedef |
Posted: Mon May 21, 2007 10:20 am Post subject: |
|
|
Apprentice
Joined: 05 Feb 2007 Posts: 44
|
sorry didn't explain very well,
The records are fixed length,
they start with a TAG,
each field has a space as a seperator
each field is mandatory and must be padded with spaces.
there are multiple records type
there are multiple data type inc decimal
there are repeating groups
TAG1 STRING INGEGER INTEGER STRING DECIMAL STRING<CR><LF>
TAG2 STRING INGEGER INTEGER STRING DECIMAL STRING<CR><LF>
TAG3 STRING INGEGER INTEGER STRING DECIMAL STRING<CR><LF>
TAG3 STRING INGEGER INTEGER STRING DECIMAL STRING<CR><LF>
TAG4 STRING INGEGER INTEGER STRING DECIMAL STRING<CR><LF>
TAG2 STRING INGEGER INTEGER STRING DECIMAL STRING<CR><LF>
TAG3 STRING INGEGER INTEGER STRING DECIMAL STRING<CR><LF>
TAG3 STRING INGEGER INTEGER STRING DECIMAL STRING<CR><LF>
TAG4 STRING INGEGER INTEGER STRING DECIMAL STRING<CR><LF>
TAG5 STRING INGEGER INTEGER STRING DECIMAL STRING<CR><LF> |
|
Back to top |
|
 |
vk |
Posted: Mon May 21, 2007 11:46 am Post subject: |
|
|
Partisan
Joined: 20 Sep 2005 Posts: 302 Location: Houston
|
Try the following design. I hope the records will come in the same order - TAG1, TAG2, TAG3, TAG4, TAG5.
Quote: |
Message of Type Type1 (Use Data Pattern)
--------Element MsgRepeat of Type Type1 (All Elements Delimited, Delimiter "<CR><LF>")
----------------Element Record1 of Type Type3 (Tagged Delimited, Delimiter "SPACE", Tag "TAG1", Tag Data Separator "SPACE")
------------------------STRING1 STRING (Specify Length)
------------------------INTEGER1 INTEGER (Specify Length)
------------------------INTEGER2 INTEGER (Specify Length)
------------------------STRING2 STRING (Specify Length)
------------------------DECIMAL1 DECIMAL (Specify Length)
------------------------STRING3 STRING (Specify Length)
----------------Element Record2 of Type Type4 (Tagged Delimited, Delimiter "SPACE", Tag "TAG2", Tag Data Separator "SPACE")
------------------------Define as above |
Define the pattern for the message as required. The pattern for eacvh record should be like ((TAG1).{RecordLength - Tag length}). Also specify minOccurs and maxOccurs for records as required. <CR><LF> can be given in data pattern as "/r/n"
Regards,
VK. |
|
Back to top |
|
 |
kimbert |
Posted: Mon May 21, 2007 3:22 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
vk is on the right lines. A couple of comments, though:
Code: |
Element MsgRepeat of Type Type1 (All Elements Delimited, Delimiter "<CR><LF>") |
Type 1 should be Tagged Delimited. Type 3 should be All Elements Delimited ( or Variable Length Elements Delimited, see below for why ).
Quote: |
I hope the records will come in the same order - TAG1, TAG2, TAG3, TAG4, TAG5. |
That's easy to solve. Instead of making Type1 a sequence, make it a repeating choice ( i.e. Composition = Choice, maxOccurs=-1 ). Then the sequence of the fields will not matter.
Quote: |
Define the pattern for the message as required. |
Data pattern is ignored unless you set Data Element Separation to 'Use Data Pattern'. In your suggested model, it will have no effect at all.
Tonedef: Your message format is a little unusual. Normally, fields are either fixed-length or delimited. Yours are both. You can solve this in two ways:
- If the field is a string, just include the delimiter in the length of the field. If you don't want the extra space character included in the message tree, set the padding character to <SPACE> ( it probably will be anyway ).
- If the field is a decimal, the trailing space cannot be included in the length ( you will get data conversion errors ). So change the Data Element Separation to 'Variable Length Elements Delimited' and add a fixed-length field called 'Delimiter' with length 1. |
|
Back to top |
|
 |
vk |
Posted: Mon May 21, 2007 6:40 pm Post subject: |
|
|
Partisan
Joined: 20 Sep 2005 Posts: 302 Location: Houston
|
Thanks Kimbert,
I made a mistake when putting that structure. Element MsgRepeat should be of Type2 (Tagged Delimited, Tag Data Separator "SPACE" and Delimiter "<CR><LF>"
Element Record1, Record2 etc should be of a type which is (All Elements Delimited and Delimiter as "SPACE")
In the design which I mentioned, the message type is Use Data Pattern. So the data pattern specified will take effect. Whereever there are more than 2 levels to be defined in the message (Message having multiple records and the entire structure repeats), I have always defined the outermost type as Use Data Pattern and specify a pattern which will help the parser to parse inner repeating structures. This has worked for me in many interfaces which are in Production now.
I am not sure of any other way to define the outermost type.
The 2 methods which you suggested will work. As you said, the first option wont be feasible if the padding character for INTEGER and DECIMAL fields is zero. The second option will work, but it will be very tedious to create so many additional elements just for the delimiters.
Regards,
VK. |
|
Back to top |
|
 |
kimbert |
Posted: Wed May 23, 2007 7:45 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
Whereever there are more than 2 levels to be defined in the message (Message having multiple records and the entire structure repeats), I have always defined the outermost type as Use Data Pattern |
If it works for you, that's OK - but it is not necessary, and it will impact performance.
Use Data Pattern is intended for scenarios where the other Data Element Separation settings are not sufficient. No criticism intended - just making sure that the facts are clear. |
|
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
|
|
|
|