如何强制暂停当前消息并在以后从自定义BizTalk ** send **管道组件中重试？

Question

这是我的情景。 BizTalk需要从共享/中央文档库传输文件。第一个BizTalk接收传入消息，其中包含库中此文档的引用/路径。然后它只需要从这个库中读出它并发送它（可能通过不同的适配器）。这实际上是一个与ClaimCheck EAI模式不太遥远的场景。

已经记录了一些实现索赔检查的方法，显而易见BizTalk ESB Toolkit Claim Check和BizTalk 2009：处理极大邮件，第一部分和第二部分。 Part II。然而，这些实现确实假设发送管道可以立即读取已经“签入”的流。

这不是我的情况：文档在共享库中可用之前需要一些时间，并且无法延迟收到的初始消息。这给我留下了两个选择：要么通过编排引入一些延迟，要么确保发送端口稍后将重试，如果文档还没有。

（延迟只能通过业务流程引入，BizTalk中没有基于时间的订阅。对吧？）

由于这是一个仅消息流，我想我可以跳过编排。我已经看到了如何使用管道“在仅消息解决方案中使用自定义重试逻辑”的方法，但我需要的不仅是控制重试行为（由适配器执行）的方法，而且还是从管道内强制执行它...

到目前为止，我所做的每一次尝试最终都是一条暂停的消息，即使发送适配器已经重试配置也不会自动重试...如果这确实可行，那么我应该在哪里/我应该做什么？

哦对了......而且有排队......但遗憾的是，无论是在场所还是在云端;）

好的，我可能正在推动极限......但出于好奇......

非常感谢您的帮助和建议！

Answer 1

我很困惑如何在没有Orch的情况下完成这项工作。我能想到的唯一方法就是：

• 初始消息的接收端口只是“吃掉”消息， 例如使用Null适配器将这些消息订阅到虚拟发送端口， 完全无视他们。
• 您使用接收端口监控共享文档库，查找是否有？任何新的？那里的文件。
• 任何找到的文件都由发送端口订阅并发送到下游。

基于业务流程的方法将遵循：

• Orch是通过收到“即将发布的”新文件的初始通知来触发的。如果您的初始通知是请求响应（例如，公开的Web服务，您可以立即并同步发出响应）
• 另一个 receive 端口用于监控共享库中文件的可用性和检索，与原始通知消息相关联（例如，通过文件名或其他密钥）
• 如果文档不可用则处理重试的机制，并且可能是最终超时，例如，如果文档永远不会进入共享库。
• 成功时，发送端口然后向下游发送文件

将延迟形状放置在Orch中将提供比例如在自定义适配器或管道代码中使用Thread.Sleep()或类似的，因为BTS只计算广告标记SQL记录上的'唤醒'时间戳，然后可以使orch脱水，从而释放线程。

那是'那里的文件吗？'可以使用重试循环进行检查，在每次失败检查后延迟，使用具有超时的并行分支，例如一个小时左右。

Answer 2

轮询间隔可以在接收位置控制，所以我不明白你的意思是Biztalk中没有基于订阅的订阅。您还有一个计划窗口。

引入延迟的一种方法是将该初始消息发送到内部Web服务，该服务将在指定的时间间隔后将消息回发到Biztalk。

还有环回适配器，它只是将消息发回消息框。可以修改这一点以增加延迟。