事件处理范围活动中的延迟活动 - Windows 工作流共享点
我正在尝试创建以下场景：
- 将任务分配给用户以完成
- 任务，并为经理创建任务，以在必要时重新分配用户任务（不要问，他们希望这样）
- 需要发送电子邮件提醒当任务接近截止日期时发送
因此，我想到使用 EventHandlingScope 来实现这一点：
- 我正在监听 eventhandlingscope 活动的主分支上的任务更改，
- 监听事件驱动分支中的重新分配任务更改 - 如果重新分配任务被激活，将第一个任务重新分配给另一个事件驱动分支中指定的用户，
- 使用延迟活动并定期检查用户分配的任务是否接近截止日期并发送电子邮件提醒
所以，我认为 eventhandlingscope 对此很有好处，而且主要是，除了 DelayActivity 的问题。
如果我将延迟活动放在事件处理程序分支之一中，它会触发一次，但不会多次。 而如果我在那里放置一个 onTaskChange 活动，那么每当有人更改该任务时它就会触发。
那么，这是预期的行为吗？为什么 DelayActivity 不循环？ 我怎样才能以不同的方式做到这一点？我的想法是使用 CAG，但这看起来有点复杂...
更新：CAG 的问题是整个事情都会阻塞，直到延迟活动触发，即使 onChange 事件触发。这是有道理的，但使用起来有点棘手。
更新2：我重新措辞了文本以使其更清晰
I am trying to create a following scenario:
- a task gets assigned to the user to complete
- a task get created for the manager to reassign the user task if necessary (don't ask, they wanted it this way)
- an email reminder neeeds to be sent when the task is nearing a due date
So, I thought of using EventHandlingScope for this:
- I am listening for a task change on the main branch of eventhandlingscope activity,
- listening to reassign task change in event driven branch - and if reassign task gets activated, reassign the first task to the user specified
- in another event driven branch use a delay activity and check periodically if user assigned task is nearing a due date and send an email reminder
So, I though eventhandlingscope would be good for this, and it mostly is, except for the problem with the DelayActivity.
If I put a delay activity in one of the Event Handlers branches it fires once, but not more.
Whereas if I put an onTaskChange activity there it fires everytime somebody changes that task.
So, is this the expected behaviour? Why doesn't DelayActivity loop?
How could I do this differently? My thought is with a CAG, but this looks a bit more complex...
Update: the problem with CAG is that the whole thing blocks until delay activity fires, even if the onChange event fired. This makes sense, but makes it a bit trickier to use.
Update2: I've reworded the text to make it hopefully clearer
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
解决方案
解决此问题的基本活动安排是包含
ListenActivity的WhileActivity。监听活动有 3 个
EventDrivenActivity分支。第一个是“用户任务已完成”分支，第二个是“经理更改了分配的用户”分支，第三个包含DelayActivity，后跟您的电子邮件逻辑。在侦听活动中，任何分支都可以完成侦听活动，并且当它们完成侦听活动时，侦听活动中的其他活动将被取消。
您需要确保“用户任务完成”序列设置一些可由 while 循环测试的值，以便当用户完成任务时 while 循环退出。
当“用户任务已完成”分支以外的分支负责完成
ListenActivity工作流时，将循环回ListenActivity并重新执行所有 3 个事件驱动的活动，包括包含DelayActivity的一个。请注意，这与 EventHandlingScope 方法略有不同，因为“监听用户任务已完成”将被取消并重新执行，而使用 EventHandlingScope 则不会发生这种情况。在我看来，这是一种更好的安排，因为这意味着当前选择在 Listen 活动开始时执行任务的用户保证在结束时保持不变（因为如果更改，则整个活动将被丢弃并启动新的活动） ）。
为什么 Delay 在 EventHandlingScope 中只触发一次
实际上，您设置的是一个正在侦听两个事件的范围。一个是您的经理更改分配的用户事件，另一个是“计时器触发事件”。
现在，按照文档中描述的方式，听起来好像涉及一些循环，就好像这些活动之一完成后它们就会重新启动。然而它并不完全是这样，它实际上只是继续监听原始事件，并且如果另一个此类事件被触发，它将重新运行内容。
在
DelayActivity的情况下，正在侦听一些内部“计时器触发事件”。当第一次输入延迟时，将设置超时，以便计时器将在适当的时间触发，然后侦听该事件。一旦它触发，作用域就会返回监听“计时器触发事件”，但是，不会重新运行设置超时的初始代码，因此不会出现其他“计时器触发事件”。The Solution
The fundemental activity arrangement that solves this problem is a
WhileActivitycontaining aListenActivity.The listen activity is given 3
EventDrivenActivitybranches. On the first is your "User Task Completed" branch, the second is the "Manager Changed the assigned user" branch and the third contains aDelayActivityfollowed by your emailing logic.In a listen activity any of the branches can complete the Listen activity and when they do the other activities in the Listen activity will be canceled.
You will need to ensure the the "User Task Completed" sequence sets some value that can be tested by the while loop such that the while loop exits when a user completes a task.
When a branch other than the "User Task Completed" branch is responsible for completing the the
ListenActivityworkflow will loop back to theListenActivityand re-execute all 3 event driven activities including the one containing theDelayActivity.Note that this is slightly different from the EventHandlingScope approach because the "listen for user task completed" will get canceled and re-executed whereas with the EventHandlingScope that wouldn't happen. IMO this a better arrangement since it means that the user that was currently selected to do the task at the start of the Listen activity is guaranteed to be unchanged at the end (because if it is changed the whole activity is discarded and a new one started).
Why the Delay only fired once in the EventHandlingScope
Effectively what you had set up is a scope that is listening for two events. One was your managers change assigned user event, the other was a "timer fired event".
Now the way its described in the documentation it sounds like some loop is involved as if once one of these activities completes they are restarted. However its not quite like that, it actually just continues to listen for the original event and will re-run the contents if another such event is fired.
In the case of the
DelayActivitythere is some internal "timer fired event" that is being listened to. When the Delay is first entered the timeout is setup so that the timer will fire at the appropriate time, it then listens for that event. Once it has fired the scope returns to listening to a "timer fired event", however, there is no re-running of the initial code that setup the timeout hence no other "timer fired event" is forth coming.我知道您不想听到这个，但您最好创建一个工作流程来代替处理程序，因为工作流程旨在更好地处理时间维度，因为它们是“长时间运行”的。事件处理程序的作用范围更大，是由某个时刻的事件触发它们，然后它们完成一个操作。不仅如此，从您编写的内容来看，如果要求如此简单，您可以创建一个 SharePoint Designer 工作流，这样您甚至不必打开 Visual Studio。
另外，不确定您是否知道这一点，但 SharePoint 任务确实会发送电子邮件，这些任务会在任务迟到时发送每日提醒，以便您可以使用开箱即用的功能来解决延迟活动。
最后，如果您在调试模式下运行并且已硬编码您的任务 ID，则每个调试会话只能运行一个任务，否则当具有相同 ID 的另一个项目添加到 SharePoint 时，您的事件处理程序将停止。这可能可以解释为什么您的延迟活动被阻止。
I know you don't want to hear this but you would be better off creating a workflow in place of the handler as workflows are designed to handle the time dimension much better as they are "long running". Event handlers are more scoped for a moment-in-time event triggers them and then they complete an action. Not only that, but judging from what you write, if the requirements are that simple you can create a SharePoint Designer Workflow so you wouldn't even have to crach open Visual Studio.
Also, not sure if you know this but SharePoint tasks do send out emails, these tasks will send out daily reminders when the task is late so you might be able to address your delay activity using out-of-the-box functionality.
Finally, if you are running in debug mode and you have hard-coded your taskid, you can only run one task per debug session otherwise your Event Handler will stop when another item with the same ID is added to SharePoint. This might explain why your delay activity is blocked.