我对流程框架研究的一些观察是：
一旦接收到信号，@ Signign就会在决策器重放中开始执行 . @Signal方法在同一工作流程的所有未来重放中执行 . （一旦收到信号，在每次重播时，决策者执行@Signal） . @Asynchronus方法不应该是长时间运行的任务，因为只有在所有@Asynch方法完成执行后，decider才会安排Activity Tasks .
我的观察是否正确？如果是：那么如果在同一工作流程中我想要一个信号，执行某项任务然后停止执行以备将来重放 . 例如暂停信号：用户可能多次暂停和恢复工作流程 .
另一个问题是：流如何处理以下类型的案例：决策者超时，同时有两个事件：取消工作流和活动完成 . decider如何确定它们是相关的，如果取消了，那么不要响应ActivityComplatedEvent .
1 回答
它有助于不考虑重放方面的工作流行为 . 重放只是恢复工作流状态的一种机制 . 但是当编写工作流逻辑时，除了确定性的要求之外，它并不是真正可见的，并且工作流代码是异步的和非阻塞的 . 所以在设计工作流逻辑时永远不要考虑重放 . 写它，因为它是一个本地执行的异步程序 .
因此，当重放不是某种方式时，@ Signal只是一个回调方法，每个接收到的信号执行一次 . 因此，如果您从@Signal方法调用某个操作，那么它将执行一次 .
至于第二个问题，它取决于收到取消和活动完成的顺序 . 如果首先取消，则首先将取消发送到工作流程，这可能导致取消活动 . 取消实际上是阻止等待活动取消 . 完成活动（这是下一个活动）将取消阻止取消 . 如果完成时间为秒，则活动完成，随后的任何内容将被下一个事件取消 . 在大多数情况下，结果与收到活动完成完全相同，但之后的所有逻辑都被取消 .