使用Throw形状推迟Biztalk中的消息是否是一种很好的做法？

Question

在编排过程中的某个时刻，需要在一段时间后重新发送交易。 是否可以使用Throw shape来使交易失败，所以它会在Port retrial
中过一段时间后重试，或者最好使用Loop/Wait形状来实现这一点？

你还没有真正明白为什么（使用情况下）消息需要重新发送 。

客户端要求我们重新向Web服务发送事务，以防Web服务返回“成功失败”错误。

Answer 1

你还没有真正澄清为什么（用例）的消息需要重新发送，但在任何情况下，我会用Throw控制通过编排流程。

在一个错误的情况

如果您需要重新发送邮件，因为它未能达到，则第一站是到configure the send port to do retries，用合适的延迟间隔（并注意备份传输选项，以及）。通常不需要使用编排循环进行手动重试。 - 这里的例外包括下游服务接受消息并发出定制的可重试'NACK'状态 - 例如错误指示死锁或超时 - 然后需要检查，然后可能需要延迟+循环方案。

发送给多个消费者

如果需要发送相同的消息到另一个目标（延迟后）作为业务流程的正常流程的一部分，那么我会建议使用parallel actions shape在流量发散的点，然后在发送到第二个目的地之前，在第二个航段上使用延迟形状。如果消息可以同时发送到多个目的地，我会考虑使用Send Port Groups来执行此操作。

消息发生器/触发/调度程序

如果该业务流程的目的是要在定义的时间间隔发布多个消息（例如触发消息），则发布，延迟，和环（和例如递减的计数器）编排会很好地工作。

Answer 2

有与处理Web服务的例外在这篇博客文章涉及一个很好的方案概要： http://blog.codit.eu/post/2012/01/13/Best-Practices-for-consuming-Web-Services-from-within-BizTalk-Server.aspx

为了实现重试，您可以配置发送端口自动重试，或把环状带错误处理程序中的延迟。