2

这是我的场景。BizTalk 需要从共享/中央文档库传输文件。第一个 BizTalk 接收到带有库中此文档的引用/路径的传入消息。然后它只需要从这个库中读取它并发送它（可能通过不同的适配器）。这实质上是一个与 ClaimCheck EAI 模式相距不远的场景。

一些实现声明检查的方法已记录在案，特别是BizTalk ESB 工具包声明检查和 BizTalk 2009：处理超大消息，第 I 部分和第 II 部分。然而，这些实现确实假设发送管道可以立即读取已“签入”的流。</p>

这不是我的情况：文档在共享库中可用之前需要一些时间，我不能延迟最初收到的消息。这给我留下了两个选择：要么通过编排引入一些延迟，要么确保发送端口稍后会在文档不存在时重试。

（延迟只能通过编排引入，BizTalk 中没有基于时间的订阅。对吗？）

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

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

哦，对了……还有排队……但不幸的是，既不在本地也不在云端；）

好吧，我可能是在挑战极限……但只是出于好奇……</p>

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

4

2 回答 2

2

我对没有 Orch 怎么能做到这一点感到困惑。我能想到的唯一方法是：

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

基于编排的方法将遵循以下原则：

  • Orch 是由接收到库中“即将到来的”新文件的初始通知触发的。如果您的初始通知是请求响应（例如暴露的 Web 服务，您可以立即同步发出响应）
  • 另一个接收端口用于监视共享库中文件的可用性和检索，与原始通知消息相关（例如，通过文件名或其他键）
  • 一种在文档不可用时处理重试的机制，并且可能会导致最终超时，例如，如果文档从未进入共享库。
  • 成功后，发送端口将文档发送到下游

与在自定义适配器或管道代码中使用或类似方法相比，将延迟形状放置在 Orch 中将提供更大的可扩展性Thread.Sleep()，因为 BTS 仅计算 SQL 记录上的“唤醒”时间戳，然后可以使 orch 脱水，从而释放线程。

'文件还在吗？检查可以通过重试循环完成，每次检查失败后延迟，并行分支超时，例如一个小时左右。

于 2012-11-01T04:04:32.353 回答
0

轮询间隔可以在接收位置控制，所以我不明白 Biztalk 中没有基于时间的订阅是什么意思。您还有一个日程安排窗口。

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

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

于 2012-11-15T17:16:00.407 回答