我知道对很多人来说这似乎很明显，但我的客户使用的模式我并不是很方便。
案例是，他们的客户通过nservicebus向第三方系统发送存款或取款。第三方系统需要处理该交易，但交易完成可能需要数天甚至数周。
今天的解决方案是创建一个saga，它首先发送一条消息，将事务交给第三方系统。完成后，传奇的下一步是检查完成更新。如果交易未完成，则会发送请求超时，就像等待一样。当达到超时时，再次执行相同的检查并发送新的请求超时......等等。这个已经是一个永恒的循环。它还能做的是用相同的SagaTimeout完全填充ServiceInsight。
我一直在研究单反相机，但它看起来很缺乏。我只需要对特定消息进行多次重试，而不是针对所有消息。
要添加，第三方系统无法发送已完成交易的事件，这意味着我们需要轮询完成更新。
另一方面，我认为更好的解决方案是保存交易的状态，将交易发送给第三方并完成此特定的传奇。然后有一个使用时间间隔检查完成更新的传奇。
以这种方式使用sagatimeouts是一种常见的模式吗？并且，只有检查完成更新的传奇/处理程序是否是更好的解决方案？
答案 0 :(得分：3)
据我所知，你是按照它应该做的方式做的。当然，你可以开始一个单独的传奇来处理超时，但我认为没有任何理由这样做。
由于您不知道交易/流程何时在第三方系统上完成，因此对最终用户来说对时间不敏感，因此您不需要经常请求超时。您甚至可以计算传奇数据中的超时次数，并增加下次超时的时间跨度，从而最大限度地减少超时次数。您还可以检查传奇已经运行了多长时间，并警告某人（您或客户等），如果第三方系统花了太长时间来完成交易。这是NSB传奇真正闪耀的地方，它在处理这些情况时非常灵活。
当然不要将SLR用于此类事情，它只是在发生间歇性错误时重试处理程序。
答案 1 :(得分：0)
IMO听起来像你的传奇混淆了技术问题（轮询外部服务，等待事情发生）与域关注（想要在事情发生时得到通知）。
我的经验是，您通常可以从将技术内容与技术内容隔离开来获益，在这种情况下，它可能意味着您应该将轮询放在某个地方的集成服务中，然后当事情发生时会发出适当的事件
这样，saga可能会在整个过程中超时（例如，检查过程是否在四周内完成，或者您认为在任何人之前必须花费的最长时间）并且只是订阅{{来自集成服务的1}}事件。