0

我有一个平面文件架构，它解析一个包含多行的文件，我在句子“请求信息 [CR] [LF]”之后制作了分隔符以获取所需的数据。

当我尝试使用文件（.txt）测试项目时，它可以正常工作。但是当我尝试通过电子邮件中的 POP 数据进行测试时

我收到了这个错误：

由于以下错误，接收管道“InqueryCardDemo.EmailParserPipleline, InqueryCardDemo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0​​522d81e74b224f”中组件“Flat file disassembler”的输出消息被暂停：查找时发现意外数据： 'Request Information\r\n' 当前正在解析的定义是 Root。发生错误的流偏移量为0。发生错误的行号为1。发生错误的列为0。。挂起消息的序号为 1。

<xs:element name="Root">`   
  <xs:annotation>` 
    <xs:appinfo>`
        <b:recordInfo structure="delimited" child_delimiter_type="hex" child_delimiter="0x52 0x65 0x71 0x75 0x65 0x73 0x74 0x20 0x49 0x6E 0x66 0x6F 0x72 0x6D 0x61 0x74 0x69 0x6F 0x6E 0xD 0xA" child_order="infix" sequence_number="1" preserve_delimiter_for_empty_data="true" suppress_trailing_delimiters="false" />
     </xs:appinfo>
4

2 回答 2

1

我建议更换 PassThru 管道的 EmailParserPipeline 并连接发送端口以将消息转储到文件位置（在消息未键入时过滤接收端口名称）。然后，检查文件 - 它看起来像预期的那样吗？尝试使用十六进制编辑器并检查出现在“请求信息”之前的任何字节顺序标记。这可能会帮助您诊断问题所在；我并不是说这是一个解决方案。

我怀疑 POP 适配器在您正在寻找的令牌之前在消息的开头添加了一些内容。一旦您确定了它是什么，您可以：更新您的平面文件架构以使用这些令牌，或者在平面文件反汇编程序之前添加一个自定义管道组件来操作传入的消息，使其符合架构。

如果消息的编码不是 utf-8，则需要使用字节顺序标记 (BOM) 告诉 BizTalk 它是什么编码。另请参阅此 MSDN 问题以获取更多信息：http: //blogs.msdn.com/b/atinag/archive/2009/03/18/utf-encoded-message-failing-in-biztalk-2006.aspx

于 2013-09-17T07:39:51.050 回答
0

检查从 BizTalk 2006R2 的 HAT 或 BizTalk 管理控制台（如果 BizTalk 2009 或更高版本）收到的消息。您可能会发现它是一个必须接受的 Multipart 消息，然后从中获取您想要的部分，并通过 Orcherstration 中的 Pipeline 运行它以进行分解。

POP3 适配器

POP3 接收适配器从指定 POP3 服务器上的指定邮箱检索电子邮件。默认情况下，POP3 接收适配器将 MIME 处理应用于它下载的电子邮件，并将这些消息作为多部分 BizTalk 消息提交给 BizTalk Server。POP3 接收适配器可以接收和处理以下格式的电子邮件：纯文本 * MIME 编码 * MIME 加密 * MIME 编码和签名 * MIME 加密和签名

在我的工作中，由于安全问题，我们避免使用 POP 适配器，我们更喜欢在 BizTalk 服务器上运行一个 SMTP 服务来转发电子邮件，并将其配置为将它们写入我们然后选择的 .eml 文件通过 MIME 管道启动和处理并遍历所有附件。

于 2013-10-12T07:08:48.967 回答