我正在尝试创建以下方案：
所以，我想到了使用EventHandlingScope：
所以，虽然eventhandlingscope会对此有好处，但主要是，除了DelayActivity的问题。
如果我在其中一个事件处理程序分支中放入延迟活动，则会触发一次，但不会更多。 然而，如果我在那里放置onTaskChange活动，那么每当有人改变该任务时它就会触发。
那么，这是预期的行为吗？为什么DelayActivity不循环？ 我怎么能这样做？我的想法是用CAG，但这看起来有点复杂......
更新：CAG的问题是整个事情都会阻塞，直到延迟活动触发，即使onChange事件被触发。这是有道理的，但使用起来有点棘手。
Update2：我已经对文本进行了重写，以使其更加清晰
答案 0 :(得分：5)
解决方案
解决此问题的基本活动安排是包含WhileActivity的{{1}}。
听取活动有3 ListenActivity个分支。第一个是“用户任务已完成”分支，第二个是“管理员更改分配的用户”分支，第三个分支包含EventDrivenActivity，后跟您的电子邮件逻辑。
在监听活动中，任何分支都可以完成Listen活动，当他们这样做时，Listen活动中的其他活动将被取消。
您需要确保“用户任务已完成”序列设置一些可由while循环测试的值，以便在用户完成任务时退出while循环。
当“User Task Completed”分支以外的分支负责完成DelayActivity工作流时，将循环回ListenActivity并重新执行所有3个事件驱动的活动，包括包含ListenActivity。
请注意，这与EventHandlingScope方法略有不同，因为“侦听用户任务已完成”将被取消并重新执行，而使用不会发生的EventHandlingScope。 IMO这是一个更好的安排，因为这意味着当前选择在Listen活动开始时执行任务的用户在结束时保证不变（因为如果它被更改，则整个活动被丢弃并且新的活动开始）。
为什么延迟只在EventHandlingScope中触发一次
有效地，您所设置的是一个正在侦听两个事件的范围。一个是您的经理更改分配的用户事件，另一个是“计时器触发事件”。
现在它在文档中描述的方式听起来像一些循环，就好像一旦这些活动之一完成它们就会重新启动。然而它不是那样的，它实际上只是继续监听原始事件，如果另一个这样的事件被触发，它将重新运行内容。
在DelayActivity的情况下，正在收听一些内部“计时器触发事件”。首次进入延迟时，会设置超时，以便定时器在适当的时间触发，然后监听该事件。一旦它被触发，范围返回到监听“定时器触发事件”，但是，没有重新运行设置超时的初始代码，因此没有其他“定时器触发事件”即将到来。
答案 1 :(得分：0)
我知道你不想听到这个，但你最好创建一个工作流代替处理程序，因为工作流设计用于处理时间维度，因为它们“长时间运行”。事件处理程序更具范围，可以触发它们，然后完成一个操作。不仅如此，从您编写的内容来看，如果要求非常简单，您可以创建一个SharePoint Designer工作流程，这样您甚至不必打开Visual Studio。
此外，不确定您是否知道这一点，但SharePoint任务会发送电子邮件，这些任务会在任务延迟时发出每日提醒，以便您可以使用开箱即用的功能解决延迟活动问题
最后，如果您在调试模式下运行并且您已经对您的taskid进行了硬编码，则每个调试会话只能运行一个任务，否则当具有相同ID的另一个项目添加到SharePoint时，您的事件处理程序将停止。这可能解释了您的延迟活动被阻止的原因。