Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

FlatFilePipeline Error. The remaining stream has unrecognizable da

761 views
Skip to first unread message

KK

unread,
Dec 10, 2007, 12:28:00 AM12/10/07
to
Hey Guys,

I have positional EDI Flat file in the below, each row has positional fields
ending wit 0x0A(LF).

My FF's Root node propertiies are:-

- <xs:element name="VsEDI855Flat">
- <xs:annotation>
- <xs:appinfo>
<b:recordInfo structure="delimited"
preserve_delimiter_for_empty_data="true" suppress_trailing_delimiters="false"
sequence_number="1" child_delimiter_type="hex" child_delimiter="0x0A"
child_order="default" />
</xs:appinfo>
</xs:annotation>

Error i'm getting is thies..
There was a failure executing the receive pipeline:
"EDDirect.VsEDI855FlatFileDisassembler, EDDirectSchemas, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=9b8871d5833801a1" Source: "Flat file
disassembler" Receive Port: "S855ReceivePort" URI:
"\\server\outFolder$\data\received\*.txt" Reason: The remaining stream has
unrecognizable data.

Thanks for any help/comments. I appreciate people taking time out to read m
problem & suggest ways to handle it. Truly.

--

KK

unread,
Dec 11, 2007, 4:03:00 PM12/11/07
to
After a lot of test/trials I realized that the PO had a Trailing CR at the
End of File.
If i remove that CR manually and reprocess it; Pipeline accepts it happily.

Now how can i remove that CR at the end of the file.

I tried following:-

1. I set Use requirement on last Padded Field = Optional.
2. Suppress Trailing Delimiters = Yes on the root node of the schema.

Still it couldn't remove or ignore CR at the EOF.

Can anyone suggest any other way to avoid CR during read in the FlatFile
DIsassembler Pipeline??

--
Biztalk Beginner


Jan Eliasen

unread,
Dec 11, 2007, 4:58:22 PM12/11/07
to
On Tue, 11 Dec 2007 13:03:00 -0800, KK <K...@discussions.microsoft.com>
wrote:

>Can anyone suggest any other way to avoid CR during read in the FlatFile
>DIsassembler Pipeline??

Add a record to the end of the schema with an optional element inside.

--
eliasen, representing himself and not the company he works for.

Private blog: http://blog.eliasen.dk

Private email: j...@eliasen.dk

KK

unread,
Dec 12, 2007, 10:33:01 AM12/12/07
to
How do i do that??
Do you mean create/add a Child record at the end of the schema??

I thought i already did that... this is the last element of my schema. is
this exactly what you are saying??


<xs:attribute name="Pad16" type="xs:string" use="optional">


- <xs:annotation>
- <xs:appinfo>

<b:fieldInfo sequence_number="6" justification="left" pos_length="252" />
</xs:appinfo>
</xs:annotation>
</xs:attribute>
--
Biztalk Beginner

SadguruSainath

unread,
Jan 3, 2008, 9:33:08 AM1/3/08
to
I know it is very late on this thread but just to help anyone else newly
getting into this error; here are few tips to trace and fix the issue.
1) If your problem is with extra CRLF at the end of the message, many
already given the answer here or else where. The best way is to add a
separate dummy “Trailer Schema” to the “Receive pipeline” as suggested at
http://www.biztalkgurus.com/forums/p/3833/7416.aspx.
2) Otherwise:
a. If you have the message and the schema on hand, use FFDasm.exe to see
where the issue is by incrementally submitting the message segment wise to
FFDasm. Once the problem segment is identified check properties like the “Tag
Identifier” of message segment to see if that is matching with your
corresponding schema element. Most likely it is the schema mismatch issue in
that segment. There could be a mismatch of Tag Identifier or missing
element(s) or “positional length” etc field properties. Validate the data
found in the message at the problem segment with the schema properties to see
where the problem is and fix the schema accordingly.
b. If you have a generated schema by a tool and are receiving the message on
the wire from another system (like SAP Adapter generated IDoc schema and the
IDoc arriving from SAP into your orchestration), first try to capture the
whole message without applying the generated schema (if there is no other way
to see the message at this point). May be you can use a schema with one
string element to catch the entire message and then write it to a file. Once
you can see the message, take a look at the “Tag Identifier” property of each
element in the schema against the Tag Identifiers that are found in your
message. If your message is huge you can take the help of FFDasm.exe as in
the previous case to identify the problem segment.

For instance in my case, the ORDERS01.xsd schema generated by "mySAP
Business Suite Schema Generation Wizard" has a child record “E1EDP19” with
“Tag Identifier” set to “E2EDP19001” where as the ORDERS01 IDoc that is being
sent by SAP has the segment marked with “E2EDP19002”. When the “Flat file
disassembler” got to this segment, it failed, as it could not recognize the
tag E2EDP19002 that is not declared in the schema. Result - the exception
‘There was a failure executing the receive pipeline: …. Source: "Flat file
disassembler" … Reason: The remaining stream has unrecognizable data.’ By
simply modifying the “Tag Identifier” property value to “E2EDP19002” in the
generated schema, the error vanished.

Adding the dummy Trailer Schema to the Receive pipeline would swallow the
rest of the message from the problem tag. This may not be helpful in cases
where there is some useful data being sent in the problem part of the
message. Again if your problem is only with the extra CRLF that is getting
into the message and there is no issue with the schema then adding the dummy
Trailer schema is really helpful as suggested at
http://www.biztalkgurus.com/forums/p/3833/7416.aspx.


0 new messages