BizTalk 平面文件架构 - 如何接受 LF 或 CRLF 作为行分隔符
我们的客户向我们发送一个平面文件作为输入，然后我们将其转换为 XML 文件，然后发送到目标系统。
平面文件由多行组成，每行由 LF 或 CRLF 分隔。
如何创建平面文件架构，以便 BizTalk 可以解释每一行数据，无论该行是由 LF (0x0A) 还是 CRLF (0x0D 0x0A) 分隔？
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)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
问题解决了。如果其他人想知道，这里是解决方案：
由于 LF 和 CRLF 都共享 LF 字符，因此我将行分隔符设置为 LF (0x0A)。这可以正确提取完整记录（当 CRLF 为分隔符时，其副作用是在末尾有一个额外的 CR 字符）。
可以使用虚拟字段吸收 CR 字符或使用映射来消除多余的 CR 字符。
请注意，由于 LF 和 CRLF 分隔符具有不同的长度（分别为 1 和 2 个字符），因此我必须对架构进行更多更改，以确保两者都得到正确处理。
在我的场景中，解析的每行记录都包含 8 个位置字段，因此末尾有一个额外的 CR 字符会导致错误，因为 Biztalk 期望最后一个字段具有一定的长度，而该字段不考虑额外的 CR 字符。解决方案是将第 8 个字段（在我的例子中是填充字段）的长度增加 1。但是，为了仍然能够处理 LF 行分隔符，请确保设置 'Allow Early终止' 标志为 TRUE。这样，如果最后一个字段比指定长度短 1 个字符（如果不包含 CR 字符），则不会引发错误。
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).
如果我误解了这个问题，请原谅我......听起来好像每一行都是一条记录，但有些行以 LF 结尾，其他行以 CRLF 结尾，并且您需要将两者作为同一级别的分隔符？
我不知道一种方法可以单独使用平面文件模式指定多个子分隔符，但一种可能的解决方案可能是为接收管道的解码阶段编写一个自定义管道组件，以用 LF 替换 CRLF，然后使用 LF 作为平面文件模式的分隔符。
Forgive me if I misunderstand the question... it sounds as if each line is a record, but some lines end in LF and others in CRLF, and you need to have both as a delimiter at the same level?
I don't know of a way to specify more than one child delimiter with the flat file schema by itself, but one possible solution could be to write a custom pipeline component for the decode stage of your receive pipeline to replace the CRLFs with LFs, then use LF as the delimiter on the flat file schema.
一种简单的方法是在模式级别将 LF 设置为分隔符，将 CR 设置为填充字符。如果架构在通过 Visual Studio 测试时有效，但在管道中出错，请翻转 Infix/Postfix 值。无需选择允许提前终止。
A simple approach is to set LF as the delimiter and CR as the padding character at the schema level. In case the schema works when testing via Visual Studio but errs out in the pipeline, flip Infix/Postfix values. No need to select Allow Early Termination.