| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Problem in parsing MRM repeating segments |
« View previous topic :: View next topic » |
| Author |
Message
|
| yshakraj |
 Posted: Fri Aug 10, 2012 11:48 am Post subject: Problem in parsing MRM repeating segments |
 |
|
Voyager
Joined: 14 Sep 2011
Posts: 91
|
Hi All,
Need help in parsing the message for the below strusture.
Only one record is being parsed, second,third ans so on records are not being parse.
| Code: |
INPUT_MAIN (CompType DES:ALD, GI:001 ,GT:<CR><LF>,DE:<CR><LF>) (1,1) ----complex type
SEG_001 (FL)(1,1)
elenemt1
elenemt2
TYPE_001 (CompType DES:ALD, GI=002 ,GT=<CR><LF>,DE=<CR><LF>)(0,-1) ----complex type
SEG_002 (FL)(1,1)
elenemt1
elenemt2
sequence (DES : TFL, length of tag=3) (0,1)
SEG_003 (FL, TAGName=003)(0,1)
elenemt1
elenemt2
sequence (DES : TFL length of tag=3) (0,1)
SEG_004 (FL, TAGName=004)(0,1)
elenemt1
elenemt2
TYPE_002 (CompType DES:ALD, GI=005 ,GT=<CR><LF>,DE=<CR><LF>)(0,-1) ----complex type
SEG_005 (FL)(1,1)
elenemt1
elenemt2
sequence (DES : TFL, length of tag=3)(0,-1)
SEG_006 (FL, TAGName=006)(1,1)
elenemt1
elenemt2
sequence (DES : TFL length of tag=3) (0,-1)
SEG_007 (FL, TAGName=007)(1,1)
elenemt1
elenemt2
sequence (DES : TFL,length of tag=3) (0,-1)
SEG_008 (FL, TAGName=CCC)(1,1)
elenemt1
element2
sequence (DES : TFL length of tag=3) (0,-1)
SEG_009 (FL, TAGName=CCC)(0,1)
elenemt1
elenemt2
Input data looks like:-
001aaaaaaa
002bbbbbb
003cccccc
004dddddd
005eeeeee
006ffffff
007gggggg
008hhhhhh
009iiiiii
002xxxxxx
003xxxxxx
004xxxxxx
005xxxxxx
006xxxxxx
007xxxxxx
008xxxxxx
009xxxxxx
xxxxxx
psuedo code for the MRM message set
main(1,1)
seg001 (1,1)
TYPE_001 (0,-1)
seg002 (1,1)
seg003 (0,-1)
seg004 (0,-1)
TYPE_002 (0,-1)
seg005(1,1)
seg006(0,-1)
seg007(0,-1)
seg008(0,-1)
seg009(0,-1)
|
Message is parsing for only one record set of 0002
second record set is not parsing 0002xxxxxx
Please giude me on the issue.
Regards:
Yshakraj |
|
| Back to top |
|
 |
| yshakraj |
| Posted: Fri Aug 10, 2012 12:59 pm Post subject: |
|
|
Voyager
Joined: 14 Sep 2011
Posts: 91
|
I am getting the below error:-
| Code: |
ParserException
File:CHARACTER:F:\build\S000_P\src\MTI\MTIforBroker\MtiImbParser2\MtiImbFIHandler.cpp
Line:INTEGER:1004
Function:CHARACTER:MtiImbFIHandler::endMessageContent
Type:CHARACTER:
Name:CHARACTER:
Label:CHARACTER:
Catalog:CHARACTER:BIPv610
Severity:INTEGER:3
Number:INTEGER:5288
Text:CHARACTER:MTI. Not all the buffer was used when reading message
Insert
Type:INTEGER:2
Text:CHARACTER:1051
Insert
Type:INTEGER:2
Text:CHARACTER:73574
|
Please giude me.
Thanks,
Yshakraj |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 10, 2012 1:00 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
What does it say when it fails to parse?
You may also need to remove the Group Terminator somewhere and allow a higher level Repeating Element Delimiter to consume it instead. |
|
| Back to top |
|
|
| yshakraj |
| Posted: Fri Aug 10, 2012 1:29 pm Post subject: Problem in parsing MRM repeating segments |
|
|
Voyager
Joined: 14 Sep 2011
Posts: 91
|
Hi Mqjeff,
As suggested, i remove the inner complex type group terminator, still it shoe the post error
| Code: |
"Text:CHARACTER:MTI. Not all the buffer was used when reading message
|
no luck. Any other suggestion.
Regards:-
Yshakraj |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 10, 2012 3:03 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'd remove the GT from the outermost type, not the innermost type.
You don't want the outermost type to end until there's no data left. The group terminator says "I'm done now".
I would likewise remove it from TYPE_001, and make sure it's set on TYPE_002.
Then I'd set the Repeating Element Delimiter on INPUT_MAIN. This should instruct the model that the second <CR><LF> after 009iiiiii is the termination of one repeating instance of TYPE_001, rather than the terminator of any of the outer groups. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 10, 2012 3:09 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Oh, and then, I'd take a User Trace of the flow during execution and find out where it's failing to parse. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Aug 21, 2012 12:29 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Tip: You will *never* succeed in modelling a complex TDS message without the help of a debug-level user trace.
Reason: The error reported by the parser is hardly ever related to the real problem. This is not the fault of the MRM parser - the message model often allows the parser to 'stay on it's feet' for quite a long time after the parsing has gone wrong. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 21, 2012 12:31 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kimbert wrote: |
| Tip: You will *never* succeed in modelling a complex TDS message without the help of a debug-level user trace. |
Spare the occasionally lucky guess that goes undiscovered until midnight on saturday during month end during the busy season. |
|
| 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
|
|
|
|
