2

我正在尝试创建以下场景：

  • 任务被分配给用户完成
  • 为经理创建一个任务，以便在必要时重新分配用户任务（不要问，他们想要这样）
  • 当任务接近截止日期时，需要发送电子邮件提醒

所以，我想到了为此使用 EventHandlingScope：

  • 我正在监听 eventhandlingscope 活动主分支上的任务更改，
  • 监听事件驱动分支中的重新分配任务更改 - 如果重新分配任务被激活，则将第一个任务重新分配给指定的用户
  • 在另一个事件驱动的分支中，使用延迟活动并定期检查用户分配的任务是否接近截止日期并发送电子邮件提醒

所以，我认为 eventhandlingscope 会对此有好处，而且大多数情况下都是这样，除了 DelayActivity 的问题。

如果我在其中一个事件处理程序分支中放置一个延迟活动，它会触发一次，但不会更多。而如果我在那里放置一个 onTaskChange 活动，它会在每次有人更改该任务时触发。

那么，这是预期的行为吗？为什么 DelayActivity 不循环？我怎么能以不同的方式做到这一点？我的想法是使用 CAG，但这看起来有点复杂......

更新：CAG 的问题是整个事情都会阻塞，直到延迟活动触发，即使 onChange 事件触发。这是有道理的，但使用起来有点棘手。

Update2：我已经改写了文本以使其更清晰

4

2 回答 2

5

解决方案

解决这个问题的基本活动安排是WhileActivity包含一个ListenActivity.

听活动有 3 个EventDrivenActivity分支。第一个是您的“用户任务已完成”分支，第二个是“经理更改了分配的用户”分支，第三个包含DelayActivity您的电子邮件逻辑。

在侦听活动中，任何分支都可以完成侦听活动，当它们完成侦听活动时，将取消侦听活动中的其他活动。

您将需要确保“用户任务已完成”序列设置了一些可由 while 循环测试的值，以便在用户完成任务时退出 while 循环。

当“用户任务已完成”分支以外的分支负责完成工作流时，ListenActivity工作流将循环返回ListenActivity并重新执行所有 3 个事件驱动的活动，包括包含DelayActivity.

请注意，这与 EventHandlingScope 方法略有不同，因为“监听用户任务已完成”将被取消并重新执行，而 EventHandlingScope 则不会发生。IMO 这是一个更好的安排，因为这意味着当前选择在 Listen 活动开始时执行任务的用户保证在结束时保持不变（因为如果它被更改，整个活动将被丢弃并开始一个新的活动）。

为什么延迟只在 EventHandlingScope 中触发一次

实际上，您设置的是一个侦听两个事件的范围。一个是您的经理更改分配的用户事件，另一个是“计时器触发事件​​”。

现在它在文档中描述的方式听起来像是涉及一些循环，好像一旦这些活动之一完成它们就会重新启动。然而它并不完全那样，它实际上只是继续监听原始事件，如果另一个这样的事件被触发，它将重新运行内容。

在这种情况下，DelayActivity有一些内部“定时器触发事件​​”正在被监听。当第一次进入延迟时，设置超时，以便计时器将在适当的时间触发，然后它会侦听该事件。但是，一旦触发，范围就会返回侦听“计时器触发事件​​”，但不会重新运行设置超时的初始代码，因此不会出现其他“计时器触发事件​​”。

于 2009-12-06T21:40:38.397 回答
0

我知道您不想听到这个，但您最好创建一个工作流来代替处理程序，因为工作流旨在更好地处理时间维度，因为它们是“长时间运行的”。事件处理程序更适用于即时事件触发它们，然后它们完成一个动作。不仅如此，而且从您编写的内容来看，如果要求如此简单，您可以创建一个 SharePoint Designer 工作流，这样您甚至不必打开 Visual Studio。

此外，不确定您是否知道这一点，但 SharePoint 任务确实会发送电子邮件，这些任务会在任务迟到时发送每日提醒，以便您可以使用开箱即用的功能解决延迟活动。

最后，如果您在调试模式下运行并且您对 taskid 进行了硬编码，则每个调试会话只能运行一个任务，否则当具有相同 ID 的另一个项目添加到 SharePoint 时，您的事件处理程序将停止。这可以解释为什么您的延迟活动被阻止。

于 2009-12-02T17:14:50.343 回答