Microsoft BizTalk Server
A family of Microsoft server products that support large-scale implementation management of enterprise application integration processes.
371 questions
Getting error at receive location - The Messaging Engine encountered an error during the processing of one or more inbound messages but error messgae changes after resuming
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(262.40000000000003, 43%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EYJ%3C/text%3E%3C/svg%3E)
Yamina Jabeen
61
Reputation points
In BizTalk 2020, receive location is having two flat file disassembler which is processing two different type of schema and orchestration is involved for processing the input file.
issue is the same input files is working in Biztalk 2013 R2 enviroment and its not wrking in Biztalk 2020.
what can be the troubleshooting step to resolve this issue.186413-test1.txt
@David Downing @Colin Dijkgraaf @Biztalk Admin @Biztalk Developer
{count} votes
-
Yamina Jabeen 61 Reputation points
2022-03-24T10:30:00.153+00:00 and after resuming the file the error message changed to
There was a failure executing the receive pipeline: "E0FG004_OCR_fra_Prematch.Pipelines.ReceivePipeline_E0FG004_OCR, E0FG004_OCR_fra_Prematch, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8bcf7ce3a0f7a654" Source: "Flat file disassembler" Receive Port: "Receive_E0FG004_OCR_Fra_Prematch" URI: "\filebiz_preprod.nobos000.bos\FTPArea\In\E0FG004_OCRinnbetalinger*.*" Reason: The remaining stream has unrecognizable data.
-
Yamina Jabeen 61 Reputation points
2022-03-24T10:30:22.847+00:00 and after resuming the file the error message changed to
There was a failure executing the receive pipeline: "E0FG004_OCR_fra_Prematch.Pipelines.ReceivePipeline_E0FG004_OCR, E0FG004_OCR_fra_Prematch, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8bcf7ce3a0f7a654" Source: "Flat file disassembler" Receive Port: "Receive_E0FG004_OCR_Fra_Prematch" URI: "\filebiz_preprod.nobos000.bos\FTPArea\In\E0FG004_OCRinnbetalinger*.*" Reason: The remaining stream has unrecognizable data.
-
David Downing 706 Reputation points2022-03-24T16:16:01.29+00:00 Did you recreate the schemas or migrate them to BTS 2020? Can you run Validate Instance on both BTS 2020 and BTS 2013 R2 and attach the resulting XML files? This is from Visual Studio in case you're not familiar with it.
I'm guessing the 186413-test1.txt is the offending flatfile, correct?
There's also a development utility that can run the flatfile disassembler from a command line, it's called FFDasm.exe. It's been 15 years since I worked on the BizTalk flatfile components for Microsoft so I don't remember all the details of the utility, but there should be adequate help using /? or running without parameters.
-
David Downing 706 Reputation points
2022-03-24T16:52:20.03+00:00 Looking at the flatfile; I'm guessing the following is a header document:
NY000010000080800800012000001590000000000000000000000000000000000000000000000000
and this is your trailer document:
NY000089000007800000163000000002295854876210322000000000000000000000000000000000
If you are using Header and Trailer documents to disassemble sub-documents; make sure you specify them in the flat file disassembler component.
Looking at the trailer, the <CR><LF> is postfix.
-
Yamina Jabeen 61 Reputation points
2022-03-25T06:00:38.713+00:00 We have migrated the schema to BTS 2020 from BT 2013 R2.
I will Validate the instance in BT 2020 and 2013 and attached the output file below:
186790-e0fg004-ocr-prematch-output-2013.xml186821-e0fg004-ocr-prematch-output-2020.xml
the input file attached before is the file for which we got the error in BT 2020 but the same is successfully processed in BT 2013 R2 and i have also attached the schemas for which this instance is getting validated and in the receive pipeline we have added flat file disassembler in which we have mentioned this schema under 186794-e0fg004-ocr-prematch.xmldocument schema
-
Yamina Jabeen 61 Reputation points
2022-03-25T06:46:38.19+00:00 yes these are the header and the trailer of the schema but we are not using any header and trailer document to disassemble sub document . we are only using document schema in flat file disassembler.
do we need to specify them separately in flat file disassembler component. what difference does it will make?
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(208, 99%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDD%3C/text%3E%3C/svg%3E)
David Downing 21 Reputation points2022-03-25T16:48:39.813+00:00 Are you disassembling the flat file into multiple documents or generating a single XML document?
Using Header/Trailer allows the disassembler to correctly parse the document... first it parses the header, then parses the document until a match is not made, then finally parses the trailer. Each of the document parses generates a new message in BizTalk.
If you are generating a single document, the header and trailer don't matter.
-
David Downing 21 Reputation points
2022-03-25T16:49:24.837+00:00 The error you're getting indicates the parser is not able to match the document stream with the parse table generated from the schema.
If I remember correctly (which may not be the case given the length of time), the FFDasm.exe may indicate the position in the stream where the error occurs. If not, there is another utility called Pipeline.exe that runs the pipeline from the command window.
One thing to note; the sample document you sent has <CR><LF> at the end, which means your document has a postfix <CR><LF> at the root record. If you are using infix at the root, the stream will not be completely consumed and there will be a remaining <CR><LF> in the stream. I believe the FF disassembler requires the stream to be completely consumed.
Several other things to look at:
- The parser behaves better when records have a tag... header -> 'NY00001', document -> 'NY09002', 'NY09133', trailer-> 'NY00008' (or something like that). If possible, include tags in the records.
- There is a setting related to lookahead depth, make sure it's set to infinite lookahead. Can't remember if it's on the schema or the disassembler.
-
Yamina Jabeen 61 Reputation points
2022-03-29T06:52:32.557+00:00 yeah i think we can make these changes and see but first thing which is coming in my mind the same schemas is working in Biztalk 2013 prod but why it failing with this error in Biztalk 2020 even though the all the artifcats has been compared and its same
for what differnce its failing?
@David Downing @Colin Dijkgraaf @Microsoft BizTalk Consultant @Prins, Andre @BizTalk
-
David Downing 706 Reputation points
2022-03-29T16:09:39.943+00:00 Because I no longer work on the BizTalk development team, I can't say what changes have been made to the Flat File Components. If you are able to determine the offset of the failure using either FFDasm.exe or Pipeline.exe that will at least provide a clue of what's going on.
I don't currently use BizTalk, but I can take a look at the document using a hex editor at the failing offset and may be able to determine the issue.
-
David Downing 706 Reputation points
2022-03-30T02:50:00.497+00:00 I took a quick look at your schema and there's one thing you can try; change the root record element E0FG004 order from default to postfix.
-
Yamina Jabeen 61 Reputation points
2022-03-30T07:56:32.15+00:00 ok let me try that.. let me try that
-
Yamina Jabeen 61 Reputation points
2022-04-04T09:16:19.92+00:00 i changed some property at schema level and now its able to parse the input data, i updated the parser optimization as complexity and allow early temination as Yes.
and it worked
Sign in to comment
Sign in to answer