| Author |
Message
|
| n1ghtrain |
 Posted: Wed Jun 08, 2011 12:18 am Post subject: EDIFACT - Non standard Group Terminator |
 |
|
Apprentice
Joined: 23 Mar 2006
Posts: 48
Location: Bangalore
|
I was customising the EDIFACT sample for a requirement.
The input message that I am trying to parse has group terminator as <FS> instead of <SUB>.
My question is how do i change Group terminator (at message set level or at group level) to <FS>. I tried changing it to <U+001c> or <FS> but it seems to have no effect. Can this be achieved in any other way..?!! Also tried adding <FS> to reserved characters and removing <EDIFACT_GROUP_TERM> from there. No Luck. Am i missing something.?
When i convert all occurrences of <FS> to <SUB> in my input message, I am able to parse the message successfully. But i hate to use this work around.
Last edited by n1ghtrain on Wed Jun 08, 2011 1:17 am; edited 1 time in total |
|
| Back to top |
|
 |
| n1ghtrain |
| Posted: Wed Jun 08, 2011 12:23 am Post subject: |
|
|
Apprentice
Joined: 23 Mar 2006
Posts: 48
Location: Bangalore
|
Broker, toolkit Version : 7.0.0.1
The problem is similar to the one mentioned here.
http://www.mqseries.net/phpBB/viewtopic.php?p=55697&sid=10b6142f4cf69ba9e9fa5e2e949d1b22
The requirement is just to parse one type of non-standard EDIFACT message. So as of now, there is no plan to get the WTX and pack. As for the "predefined message set solution for EDIFACT from IBM" i believe that the non-standard group terminator should be a problem there too.!?
ServiceStringAdvice UNA is not supplied
Any thoughts? |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jun 08, 2011 1:26 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
|
| Back to top |
|
|
| n1ghtrain |
| Posted: Wed Jun 08, 2011 1:59 am Post subject: |
|
|
Apprentice
Joined: 23 Mar 2006
Posts: 48
Location: Bangalore
|
Kimbert.,
Messaging Standard is set to EDIFACT. Delimiters are specified using the mnemonics e.g:- <FS>
EDIFACT Service string is not present. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jun 08, 2011 2:43 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
So you have a message with non-standard delimiters, and the sender is not using the facility that was specifically designed by EDIFACT for dealing with that situation. 
In that case, go through the message definition file and replace whatever TDS mnemonic you are using to represent <SUB> with the one that you are using to represent <FS>. |
|
| Back to top |
|
|
| n1ghtrain |
| Posted: Wed Jun 08, 2011 3:58 am Post subject: |
|
|
Apprentice
Joined: 23 Mar 2006
Posts: 48
Location: Bangalore
|
Well.. i was trying to do that..
Right now, when i specify <FS> as group terminator and pass data with <FS> in it data is not parsing.. However if i replace <FS> in data with <SUB> it parses fine. Flows are set to do no conversion, sending with 437,reading at 437.
Could it be cos of Code Page ?
http://www-01.ibm.com/support/docview.wss?uid=swg21194736
The article says file separator character must be consistent with the CodedCharSetId. ?? |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jun 08, 2011 4:52 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Right now, when i specify <FS> as group terminator and pass data with <FS> in it data is not parsing |
Oh, that's unfortunate. I expect something is wrong somewhere. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 08, 2011 4:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kimbert wrote: |
| Quote: |
| Right now, when i specify <FS> as group terminator and pass data with <FS> in it data is not parsing |
Oh, that's unfortunate. I expect something is wrong somewhere. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| n1ghtrain |
| Posted: Thu Jun 09, 2011 12:59 am Post subject: |
|
|
Apprentice
Joined: 23 Mar 2006
Posts: 48
Location: Bangalore
|
Vitor, Very Helpful 
To me it looks like parser behaviour is not as expected. I was looking for a second opinion before raising a PMR.
============================================
Data with <FS> in data. (As specified in Message Set). BLOB shows X'1C' at Byte 50. Here is User Trace
2011-06-08 18:08:32.793300 7408 UserTrace BIP5612I: ''UNH<GS>'', ending at byte '4', was matched as the tag for ''/SBRRES/UNH''.
2011-06-08 18:08:32.794628 7408 UserTrace BIP5607I: While scanning for the end of a field, the end of the bit stream was encountered at byte '2982'.
Data with <FS> occurance substituted with <SUB>.. BLOB shows X'1A' at Byte 50. Here is User Trace
2011-06-09 10:36:08.514081 7408 UserTrace BIP5612I: ''UNH<GS>'', ending at byte '4', was matched as the tag for ''/SBRRES/UNH''.
2011-06-09 10:36:08.514131 7408 UserTrace BIP5609I: ''<FS>'' has been matched as a delimiter for ''/SBRRES'' at byte '50'.
============================================ |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jun 09, 2011 1:09 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
n1ghtrain: Now that you have provided some information about the parsing failure, it's a little easier to provide help
I agree that those two traces look funny. There may be a defect in the product - but I can't check it out right now. Meanwhile, you might like to try using <EDIFACT_GROUP_TERM> instead of <FS>. But make sure that the Messaging Standard is set to 'EDIFACT' in the message set properties, otherwise it won't have any effect. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 09, 2011 4:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Vitor wrote: |
| kimbert wrote: |
| Quote: |
| Right now, when i specify <FS> as group terminator and pass data with <FS> in it data is not parsing |
Oh, that's unfortunate. I expect something is wrong somewhere. |
|
| n1ghtrain wrote: |
| Vitor, Very Helpful |
I was responsing to the comment of kimbert, which as long time readers will know replaced his oft-repeated (and valuable) sermon on the value of the complete error message and a user trace in diagnosing a problem. Especially when you're trying to convey your problem to a bunch of strangers on the Internet. The simple comment "is not parsing" really doesn't provide anything helpful.
I was pleasantly surprised and amused he could be so dry. And was the most relevant thing I could add to the discussion in the lack of any facts to comment on.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 09, 2011 4:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| I was pleasantly surprised and amused he could be so dry. |
He must have been on his second glass of orange juice for the evening.
By the time he's deep in his cups on his *third* glass of orange juice, he's positively wacky. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 09, 2011 4:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Vitor wrote: |
| I was pleasantly surprised and amused he could be so dry. |
He must have been on his second glass of orange juice for the evening.
By the time he's deep in his cups on his *third* glass of orange juice, he's positively wacky. |
That I should live to witness such a thing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
