Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Our client sends us a flat file as input, which we then take and convert to an XML file before sending to the destination system.
The flat file consists of multiple lines, each line is delimited by LF or CRLF.
How do I create a Flat File Schema so that BizTalk can interpret each line of data regardless of whether the line was delimited by LF (0x0A) or CRLF (0x0D 0x0A)?
Problem solved. Here is the solution in case anyone else is wondering:
Since LF and CRLF both share the LF character, I set the line delimiter as LF (0x0A). This works correctly for extracting the full records (with the side effect of having one extra CR character at the end when CRLF is the delimiter).
One can get rid of the extra CR character using a dummy field to absorb the CR character or by using a map.
Notice that since the LF and CRLF delimiters have different lengths (1 and 2 characters respectively), I had to do a couple more changes to the schema to ensure that both are handled correctly.
In my scenario, each line record that was parsed contains 8 positional fields, so having an extra CR character at the end resulted in an error due to Biztalk expecting a certain length for the last field that does not account for the additional CR character. The solution is to increase the length of the 8th field (which is a Filler field in my case) by 1. However, in order to still be able to handle the LF line delimiters, make sure you set the ‘Allow Early Termination’ flag to TRUE. This way no errors are thrown if the last field is 1 character short of its assigned length (if the CR character was not included).