我有一种情况，主要编排负责处理一组消息。这些消息属于一组客户，编排将在消息进入时读取这些消息，并且对于它找到的每个新客户 ID，它将启动一个新的编排，负责处理特定客户的消息。我必须在消息进入时保留它们的顺序，因此新创建的编排应该处理它拥有的消息并等待来自主编排的其他消息。
尝试了不同的方法来解决这个问题，但未能成功实施。 我想听听您对如何做到这一点的意见。
谢谢。
【问题讨论】：
标签： biztalk orchestration ordered-delivery
听起来你想要的是一组嵌套的车队。虽然有可能让它发挥作用，但它会……嗯，受伤了。特别是，我首先担心的是维护：对流程进行任何更改都会让人头疼，而且更糟糕的是，部署会非常非常糟糕。
就个人而言，我真的会尝试找到一种替代方法来实现这一点，并尽可能避免使用车队，但这在很大程度上取决于您的具体情况。
几个问题，如果你不介意的话：
您的订购要求是什么？例如，您是否只需要对单个传入批次或跨批次的每个客户进行订购处理？如果是后者，您能否在没有主编排的情况下只为每个客户强制执行一个 convoy'd 实例？仍然不是很好，但可能会简化很多。
您对订购有哪些失败要求？它应该完全停止处理吗？保存消息并继续？重试呢？
是否完全根据消息的到达时间进行排序？消息中是否有任何内容可用于在内部强制订购，而不是纯粹依赖到达时间？
处理各个消息的作用是什么？排序要求是否只是为了确保在处理特定消息时满足某些先决条件（例如，消息表示某些需要先处理父级的树结构）。
【讨论】：
我认为您不需要主编排来启动子编排。我假设您不是在谈论实现护航模式的主编排。所以，如果是这样的话，我可能会这样做。
有一个简短的示例here 介绍了如何实现单例编排。此示例向您展示如何设置只存在一次的编排。发送给它的所有消息将按接收顺序排列并一次处理一个。您的示例不同之处在于您希望通过客户 ID 完成此操作。这很简单。提升入站消息中的客户 ID 并将其添加到相关类型。现在，每个客户只会有一个编排实例。
单例的问题是这样的。您必须在某个时候杀死它们，否则它们将永远作为脱水的编排而存在。所以，你需要让他们结束。如果给定客户的最后一条消息可以通过某种方式向编排发出信号，表明它是时候通过属性等死去，那么您可以执行此操作。如果这是不可能的，那么您需要设置一个计时器。如果在 x 秒内没有收到任何消息，则终止 orch。这一切都很容易做到，但它可以引入僵尸。当该客户的另一条消息进来时，当该编排正在关闭时，就会出现僵尸。这通常可以通过调整等待时间来解决。无论如何，它会导致偶尔的僵尸。
来自他领域的注释。我们已经这样做了，这确实不是一个很好的长期解决方案。我们正在接收客户信息更新，我们必须确保订单处理。我们采用了这种单例方法，它在僵尸问题和例外问题方面存在问题。如果 Singleton 编排抛出异常，它将阻止对该客户的所有未来消息的处理。所以 - 处理每一个可能的异常。真正的解决方案是让远端系统检查更新消息中的时间戳，并丢弃比上次更新更早的时间戳。我们想走这条路，但接收系统不想做这些额外的工作。
【讨论】：