| Author |
Message
|
| BLOB |
 Posted: Sat Sep 01, 2012 9:56 pm Post subject: MRM EOL missing |
 |
|
Newbie
Joined: 01 Sep 2012
Posts: 3
|
Hi,
I am fairly newish to MRM but I have created a message set that when parsing the incoming message it parses correctly but when writing out to the same message set in the same flow (simple in-out flow) misses the last EOL character, is this a feature or have I got my message set wrong
Incoming message parsed (I have put in the EOL characters to show)
| Code: |
00000200000152100212<CR><LF>
0011111100230015001000<CR><LF>
0022222200200016501100<CR><LF>
0033333300030018001200<CR><LF>
0044444400200019501300<CR><LF>
0055555500100030002000<CR><LF>
0066666600040022501500<CR><LF>
|
Outgoing message:
| Code: |
00000200000152100212<CR><LF>
0011111100230015001000<CR><LF>
0022222200200016501100<CR><LF>
0033333300030018001200<CR><LF>
0044444400200019501300<CR><LF>
0055555500100030002000<CR><LF>
0066666600040022501500
|
The parser doesnt complain about the right and all completes but when the message is viewed via rfhutil or an editor (ultraedit or notepad) the last EOL is missing, but my app further down the line requires there be one for each line.
Thanks in advance |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Sun Sep 02, 2012 5:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
How did you choose to tell the message model to include the CRLF?
That is, exactly which property of exactly which structure in your message model includes it.
I can't tell you which is missing until you tell me where you put it.
Also, there are several different ways this can be done, so without knowing how you started, I can't tell you the right way to finish. |
|
| Back to top |
|
|
| BLOB |
| Posted: Mon Sep 03, 2012 1:05 am Post subject: |
|
|
Newbie
Joined: 01 Sep 2012
Posts: 3
|
mqjeff - thanks for the prompt reply especially over a weekend and it would have been more useful with some additional information...sorry
As it happens with a bit of perserverance yesterday I realised my mistake and all is working fine now
Thanks though |
|
| Back to top |
|
|
| McueMart |
| Posted: Mon Sep 03, 2012 1:38 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Traditionally, when replying with a post saying 'I worked out what my issue is' , its nice to explain your solution to help anyone else in future who runs across your post. Just a heads up  |
|
| Back to top |
|
|
| MrSmith |
| Posted: Mon Sep 03, 2012 5:58 am Post subject: |
|
|
Master
Joined: 20 Mar 2008
Posts: 215
|
can you provide a structure of the example
_________________
-------- *
“Outside of a dog, a book is man's best friend. Inside of a dog it's too dark to read.” |
|
| Back to top |
|
|
| BLOB |
| Posted: Mon Sep 03, 2012 6:02 am Post subject: |
|
|
Newbie
Joined: 01 Sep 2012
Posts: 3
|
| McueMart wrote: |
| Traditionally, when replying with a post saying 'I worked out what my issue is' , its nice to explain your solution to help anyone else in future who runs across your post. Just a heads up |
Sorry - the result was that I had a type with local element that was based on a secondary type and had got both type levels as AED whereas the top level type should have been that with its associated repeater but the one underneath should have been fixed.
I didnt post a relpy with explanation because it was my point of view of the way it would parse that was flawed not a product anomoly. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Sep 03, 2012 6:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| BLOB wrote: |
| McueMart wrote: |
| Traditionally, when replying with a post saying 'I worked out what my issue is' , its nice to explain your solution to help anyone else in future who runs across your post. Just a heads up |
Sorry - the result was that I had a type with local element that was based on a secondary type and had got both type levels as AED whereas the top level type should have been that with its associated repeater but the one underneath should have been fixed.
I didnt post a relpy with explanation because it was my point of view of the way it would parse that was flawed not a product anomoly. |
So, to translate... You had an inner type that was set to All Elements Delimited instead of Fixed Width. You resolved your lack of an end of line character by changing the inner type to be Fixed Width, and leaving the outer type at All Elements Delimited?
I'm not sure how that would have made the change, given that the EOL character needs to be a delimiter or a group terminator. But I'll take your word that it resolved the issue, and hope that six months from now it makes sense to someone having a similar problem. |
|
| Back to top |
|
|
|
|
