- This topic has 9 replies, 1 voice, and was last updated 9 years, 2 months ago by
.
-
Posts
-
-
[quote:dec8bb7863]Note I am not using Covast. When I use the Base EDI Adapter to pick up this instance it fails in the translation from EDI to XML phase. I keep getting the error from HAT [/quote:dec8bb7863]
Note – you ARE using Covast. The base adaptor IS Covast with less schemas. I suspect 996 is not a schema they include with the base adaptor and therefore is not recognized as a loaded type by Covast.
You might investigate the full version Covast.
-
it looks to me u r sending 4050 version, schema is 3020 version u r using, check u r GS08=003020
GS*CG*043073964*6082744330*20051220*0604*50006*X*003020
Nar-
-
[quote:b7db937423=\”Anonymous\”]it looks to me u r sending 4050 version, schema is 3020 version u r using, check u r GS08=003020
GS*CG*043073964*6082744330*20051220*0604*50006*X*003020
Nar-[/quote:b7db937423]
Nar – it’s defaulting to 4050 because it doesn;t recognize his version; here is from the KB article:
[quote:b7db937423]When an interchange is received that has a higher version of the control segments than the 4050 version (for example, when the version that is indicated in the ISA segment is higher than \”00405\”), the system will try to parse it with the highest version (for example, 4050).[/quote:b7db937423]
Another note – the author is referring to the parsing of the flat EDI file as \”translation\”; the correct terminology would be
parsing – conversion from Flat EDI to XML
translation – mapping from one document format to another
serialization – conversion from the XML output of translation back to the flat version of the EDI.His document is failing parsing because the subsystem is not recognizing the version, thus it doesn’t have the cues necessary to be able to parse the file.
In BT2002, there was a Syntax setup where you would give the thing a number range of where to look for the version in the GS and this type of problem would occur if you didn’t have that number range set correctly. There was also a checkbox for using regular expression parsing to find the version; I don’t know that all this carried forward into 2004. I suspect they may have made the regex method standard and unchangable because it byte location method caused confusion and issues in 2002.
-
What base schema are you using?
That error you are getting is probably some \”invalid\” (for the subsystem) filed on the header of the file!
-
I have an EDI file Document [b:eeaeb83786]996 [/b:eeaeb83786]for Format version [b:eeaeb83786]3020[/b:eeaeb83786] (which is not supported by the BASE EDI Adapter out of the box):
[code:1:eeaeb83786]ISA*00* *00* *01*043073964 *12*6082744330 *20051220*0604*U*00302*000003522*0*P*$
GS*CG*043073964*6082744330**0604*50006*X*003020
ST*996*500060001
BGF*855*OQ*96243
K3*7997100
SE*4*500060001
GE*1*50006
IEA*1*000003522[/code:1:eeaeb83786]Note I am not using Covast. When I use the Base EDI Adapter to pick up this instance it fails in the translation from EDI to XML phase. I keep getting the error from HAT – Error(30) [b:eeaeb83786]Translation failed[/b:eeaeb83786].
[code:1:eeaeb83786]Error encountered: ERROR (30), interchangenr 10012 :
The document does not contain a required element. Contact the sender.source format: [5 00405 ,X12-4050]
source document: [(unknown)]
source segment: [data#0,def#1,tag=ISA ,name=Interchange Control Header]
source element: [def#1,elm#1,comp#0,tag=9001,name=Authorization information qualifier], (msgnr:0 segnr:0)(line:1 pos:0 filepos:3)Error encountered: ERROR (30), interchangenr 10012 :
The document does not contain a required element. Contact the sender.source format: [5 00405 ,X12-4050]
source document: [(unknown)]
source segment: [data#0,def#1,tag=ISA ,name=Interchange Control Header]
source element: [def#3,elm#3,comp#0,tag=9003,name=Security information qualifier], (msgnr:0 segnr:0)(line:1 pos:0 filepos:3)[/code:1:eeaeb83786]And so on – note only the elm# and the name keeps updated to reflect all 16 expected segments of the ISA interchange header. But as you can see from the sample the ISA interchange header is all there. Also note the Format version is 4050 and not the 3020 as it should be. And yes I have followed all the points in KB article
[url]http://support.microsoft.com/kb/840113/en-us[/url]. (Set \”Accept all unlisted documents\” to \”Yes\” in the Receive Location configuration)This error is obviously happening during the translation phase – when the EDI document is being translated into an XML Message. Any ideas? There seems to be no help ANYWHERE on this.
-
The GS05 missing date solved this. Now I have another error –
Error encountered: ERROR (46), interchangenr 10056 :
[b:dcdeeeb321]The source document in this mapping is not recognized[/b:dcdeeeb321]. Check the mapping. (msgnr:1 segnr:1)(line:0 pos:178 filepos:178)source format: [5 00405 ] source document: [996 0030202 X ]
source format: [5 00405 ] source document: [996 0030202-
[quote:60a1e046af=\”myPFerreira\”]What base schema are you using?[/quote:60a1e046af]
I am using a 996 Schema I created with the ISA, GS, GE and IEA taken from a 850 – then I added the BGF and the K3 (just 2 segments) – all I need is 2 elements of data from it. All of which validates in Biztalk
But the point is the [b:60a1e046af]translation fails before it reaches a Pipeline [/b:60a1e046af]so it does not even get the chance to be mapped to any schema. The translation phase happens before the mapping to a schema\” phase and I confimed this with a test with the understood 850-4010 (by undeploying the orchestrations then dropping the 850 instance) which showed a status of \”Accepted by Biztalk\” status in HAT (although I get the \”unsubscribed message\” subsequently as it cannot find a subscriber).
[quote:60a1e046af=\”myPFerreira\”]That error you are getting is probably some \”invalid\” (for the subsystem) filed on the header of the file![/quote:60a1e046af]
You could be right – I sawyour posting on EDI how got an unlisted schema to work. Can you spot what is wrong – here is the 996 again
[code:1:60a1e046af]ISA*00* *00* *01*043073964 *12*6082744330 *051220*0604*U*00200*000003522*0*P*$
GS*CG*043073964*6082744330*20051220*0604*50006*X*003020
ST*996*500060001
BGF*855*OQ*96243
K3*7997100
SE*4*500060001
GE*1*50006
IEA*1*000003522[/code:1:60a1e046af]-
[quote:2f6fabc8e8=\”Anonymous\”][quote:2f6fabc8e8]Note I am not using Covast. When I use the Base EDI Adapter to pick up this instance it fails in the translation from EDI to XML phase. I keep getting the error from HAT [/quote:2f6fabc8e8]
Note – you ARE using Covast. The base adaptor IS Covast with less schemas. I suspect 996 is not a schema they include with the base adaptor and therefore is not recognized as a loaded type by Covast.
You might investigate the full version Covast.[/quote:2f6fabc8e8]
The funny thing this was working with BTS 2002. I know Microsoft made things stricter with BTS 2004 but as I said the translation phase fails before it even reaches the schema.
[quote:2f6fabc8e8=\”Anonymous\”]You might investigate the full version Covast.[/quote:2f6fabc8e8]
We can’t – the client does not have or does not want Covast.
-
[quote:87120d8d89=\”Anonymous\”]
Nar – it’s defaulting to 4050 because it doesn;t recognize his version; here is from the KB article:
[/quote:87120d8d89]The cues (00200- meaning highest compatibility; and 00302) is plenty enough to figure out a version and parse it. The instance would even validate in a 4050 but it doesnt.
[quote:87120d8d89=\”Anonymous\”]
Another note – the author is referring to the parsing of the flat EDI file as \”translation\”; the correct terminology would be
parsing – conversion from Flat EDI to XML
translation – mapping from one document format to another
serialization – conversion from the XML output of translation back to the flat version of the EDI. [/quote:87120d8d89]I used the term \”translation\” because HAT uses this term for all such messages. Please understand there is NO MAPPING happening at the translation phase – its just trying to determine from the headers and envelope if this is a valid EDI and the version numbers etc. (so yes its better called ‘parsing’)
[quote:87120d8d89=\”Anonymous\”]
His document is failing parsing because the subsystem is not recognizing the version, thus it doesn’t have the cues necessary to be able to parse the file. [/quote:87120d8d89]From the cues (00200- meaning highest compatibility; and 00302) there is no reason not to figure out a version and parse it.
We never found the real reason, it was posted on Microsoft internal Biztalk discussion – no one volunteered an answer. Most likely the (fringe) 996 is not even documented in the Base EDI Adapter.
-
This issue was posted on Microsoft internal Biztalk discussion – no one volunteered an answer. Most likely the (fringe) 996 is not even documented in the Base EDI Adapter.
I have resolved this using the Flat File route – treating the EDI message as a flat file message. Using the (dream of a tool) Flat File Schema Wizard in BTS2006, I was easily able to generate the FF schema from an instance – then massaged the schema a bit and did the mapping. All very smooth. Lesson learned – when faced with such situations, instead of trying to mess around with the lightweight Base EDI Adapter, use the Flat File Route.
In R2 of BTS2006 they are releasing 7000 EDI schemas out of the box as an acknowledgement that the Base EDI Adapter is a lightweight joke for serious EDI.
-
-
-
-
-
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.