我们的客户端向我们发送了一个平面文件作为输入,然后在发送到目标系统之前将其接收并转换为XML文件。

平面文件由多行组成,每行均由LF或CRLF界定。

如何创建一个平面文件架构,以便BizTalk可以解释每条数据线,而不管该行是由LF(0x0A)还是CRLF(0x0d 0x0a)界定的行?

有帮助吗?

解决方案

问题解决了。这是其他人想知道的解决方案:

由于LF和CRLF都共享LF字符,因此我将行定界符设置为LF(0x0A)。这可以正确地提取完整记录(具有在CRLF为定界符时结束一个额外的CR字符的副作用)。

可以使用虚拟场来摆脱额外的CR角色,以吸收CR角色或使用地图。

请注意,由于LF和CRLF定界符分别具有不同的长度(分别为1和2个字符),因此我不得不对模式进行更多更改,以确保正确处理两者。

在我的情况下,分析的每个线路记录都包含8个位置字段,因此最终具有额外的CR字符,导致错误导致错误,因为BizTalk期望最后一个字段的一定长度,而不会考虑其他CR字符。解决方案是将第8个字段的长度(在我的情况下是填充字段)增加1。但是,为了仍然能够处理LF行定界器,请确保您设置 “允许提前终止” 标记为true。这样,如果最后一个字段是其分配长度的1个字符(如果不包括CR字符),则不会抛出任何错误。

其他提示

如果我误解了这个问题,请原谅我……听起来好像每行都是记录,但是有些行以LF而在CRLF中结束,您需要在同一级别上将两者都作为定界符?

我不知道用平面文件架构指定多个子界数字的一种方法,但是一种可能的解决方案可能是为接收管道的解码阶段编写自定义管道组件,以用LFS替换CRLFS,然后将LF用作平面文件架构上的定界符。

一种简单的方法是将LF设置为定界符,将CR设置为模式级别的填充字符。如果该模式在通过Visual Studio进行测试时工作,但是在管道中误解,则flip infix/postfix值。无需选择允许提前终止。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top