【问题标题】:Biztalk File Adapter DuplicationBiztalk 文件适配器复制
【发布时间】:2012-10-10 01:25:08
【问题描述】:

biztalk 2010 cu4,win2k8 服务器,无杀毒

我遇到了一个问题,即 biztalk 文件适配器间歇性地两次拾取完全相同的文件。这发生在 2 个不同应用程序中的 2 个不同接收位置的非远程或本地接收位置。

接收位置具有所有默认设置。我试过设置重命名文件勾选和取消勾选,但没有解决问题。文件掩码为 \H3OR*.txt。

作为副本之间“未解析的交换”的拾取时间永远不会超过 1 秒。 2 毫秒是常见的。查看重复项的未解析交换,上下文属性“receivedfilename”完全相同。重复的发生率大约是收到的 8 个文件中的 1 个。

接收位置确实具有 unc 路径的凭据,并且在处理完文件后会删除文件。

重新启动接收位置和 biztalk 主机都没有效果。

如果您需要更多信息,请告诉我。

谢谢。

【问题讨论】:

  • 您能否在事件日志中检查类似The FILE receive adapter cannot delete file XXX This file processed successfully. Please delete this file from the disk 的错误?但是,这通常只会在指定的重试间隔后复制批次。编辑:您是说您在不同的应用程序中指定了两次相同的接收位置?
  • 事件日志中没有任何内容。不,它们是完全不同的应用程序和位置。但两者都表现出相同的重复问题。
  • 底层存储也可能是问题所在。您是否有任何其他 BizTalk 接收位置指向同一文件服务器?您对这些流程有同样的问题吗?如果是 -> 您的文件服务器/共享可能是这里的问题。如果没有 -> 这与文件的来源有关。

标签: biztalk


【解决方案1】:

有时问题出在其他地方。您确定创建这些文件的上游进程首先没有复制它们,即快速连续发送相同的文件吗? 您可以通过创建另一个发送端口来测试这一点,该端口订阅这些文件但将它们写出到一个文件夹但将 %MessageID% 附加到 %SourceFileName%。 如果您有 2 个文件具有相同的 %SourceFileName% 但不同的 %MessageID% 且相隔 1 秒或更长时间,则证明问题出在上游。

【讨论】:

  • 我不这么认为。删除文件的过程已经运行多年,包括在实施 biztalk 之前。此问题仅在打开 biztalk 时才开始出现。我检查了最近的问题样本,消息 ID 不同。创建时间之间仍然存在几毫秒的差异。不幸的是,我现在已经放弃了这个问题,并使用编排来阻止重复文件。我会继续关注这个帖子,以防有人有有趣的想法。
  • 您能否检查一下您是否有不同的 最大并行度 设置?它应该是 1。请查看this
猜你喜欢
  • 2013-01-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-08-07
  • 2012-09-10
  • 1970-01-01
  • 2010-12-13
  • 2010-12-16
相关资源
最近更新 更多