我遇到过这样一种情况,即主编排负责处理一组消息。这些消息属于一组客户,编排将在消息进入时读取这些消息,并且对于它找到的每个新客户id,它将启动一个新的编排,负责处理特定客户的消息。我必须在消息传入时保持消息的顺序,因此新创建的编排应该处理它拥有的消息,并等待来自主编排的其他消息。
尝试了不同的方法来解决这个问题,但没有成功地实现它。我想听听你对如何做到这一点的意见。
谢谢。
发布于 2010-07-07 21:07:29
听起来你想要的是一组嵌套的车队。虽然它可能会让它工作,但它将...嗯,受伤了。特别是,我的第一个担忧是维护:对流程的任何更改都将是令人头疼的事情,更糟糕的是,部署将非常非常糟糕。
就我个人而言,我真的会尝试找到一种替代方法来实现这一点,如果可能的话,避免车队,但这在很大程度上取决于您的特定场景。
如果你不介意的话,有几个问题:
发布于 2010-07-08 01:25:47
我认为您不需要主编排来启动子编排。我假设您不是在谈论实现护航模式的主编排。所以,如果是这样的话,我可能会这么做。
这里有一个关于如何实现单例编排的简短示例here。此示例向您展示如何设置一个仅存在一次的业务流程。所有发送给它的消息将按接收顺序排列,并一次处理一条。您的示例的不同之处在于您希望通过客户ID完成此操作,这非常简单。提升入站消息中的客户ID,并将其添加到关联类型。现在,每个客户只有一个编排实例。
单例的问题是这样的。你必须在某个时候杀死他们,否则他们将永远作为脱水的管弦乐队而存在。所以,你需要让他们结束。如果给定客户的最后一条消息有一种方法向编排发出信号,表明是时候通过属性或诸如此类的方式来终止编排,那么您可以这样做。如果这是不可能的,那么你需要设置一个计时器。如果在x秒内没有收到消息,则终止orch。这一切都很容易做到,但它可以引入僵尸。当该编排正在关闭的过程中,当该客户的另一条消息传入时,就会出现僵尸。这通常可以通过the等待时间来解决。不管怎样,它会导致偶尔的僵尸。
田野里的一张纸条。我们已经做到了这一点,这真的不是一个很好的长期解决方案。我们正在接收客户信息更新,我们必须确保有序处理。我们做了这种单例方法,它已经从僵尸问题和exeption问题中产生了问题。如果单例编排抛出异常,它将阻塞对该客户的所有未来消息的处理。所以-处理每一个可能的异常。真正的解决方案应该是让远端系统检查更新消息中的时间戳,并丢弃比上次更新旧的时间戳。我们想走这条路,但接收系统不想做这些额外的工作。
https://stackoverflow.com/questions/3186368
复制相似问题