帮助监控对象状态的自定义工作流程
我需要编写一个监视对象状态的工作流程。 （它可能需要等待数天或数小时才能改变状态）
我的对象具有以下状态（我们将其称为问题对象）：
1) Created
2) Unowned
3) Owned
4) UnAssigned
5) Assigned
6) In Progress
7) Signed Off
8) Closed
如果对象处于某种状态，我还需要对对象采取一些操作在规定的时间内（也不太确定如何实现这一点）。
对象的所有者/受让人可以随时更改（即从“进行中”变为“未拥有”），因此我猜测我需要使用状态机图。 如果我的想法不正确，请告诉我。
我的应用程序是用 c# .net 3.5 编写的。
我正在考虑使用一个名为 CreateIssue 的服务方法，它将票证插入数据库，然后开始工作流的实例（使用对象或对象的 id 作为参数）。 我不确定工作流程如何知道特定对象何时已更新，或者对象的状态是否已更改。我已经使用 Windows 工作流基础 3.5 制作了一些非常简单的“hello world”类型的应用程序，但尚未掌握如何实施此类内容。
任何有关这方面的指导都会非常有帮助。
提前致谢。
I need to write a workflow that monitors the status of an object. (It could wait for days or hours for a state to change)
I have the following states for the object (lets call it an Issue object):
1) Created
2) Unowned
3) Owned
4) UnAssigned
5) Assigned
6) In Progress
7) Signed Off
8) Closed
I would also need to take some action on an object if the object was within a certain state for a defined period (not really sure on how this can be accomplished either).
The object's owner/assignee can change at any point (i.e. Go from In Progress to UnOwned) so i am guessing that a state machine diagram is what i would need to use.
If my thinking is incorrect then please let me know.
My application is written in c# .net 3.5.
I was thinking about having a service method called CreateIssue that would insert the ticket into the db and then begin an instance of a workflow (with the object or an id of the object as parameters).
I wasn't sure of how the workflow would then know when a particular object has been updated, or if the object's state has changed. I've done some really simple "hello world" type of apps with windows workflow foundation 3.5 but have not yet grasped how to do go about implementing something like this.
Any direction on this will be extremely helpful.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
基本方法是创建一个 WorkflowService，定期检查数据库并在发送所需更改时将消息排入队列。 worklfow 活动告诉服务当它开始执行时正在等待什么以及它正在侦听的队列。收到所需消息后，活动将关闭。
The basic approach is to create a WorkflowService that regularly checks the database and enqueues a message one the required change was send. The worklfow activity tells the service what is is waiting for when it starts executing and the queue it is listening. The activity closes when the required message is received.
WF 中没有直接自动检测对象何时发生更改的机制，这给您提供了三种选择：
选项 1 和 2 依赖于轮询机制 - 在一种情况下在工作流程外部实现，而在其他情况下在工作流程内实现。选项 3 使用主题/观察者模式和事件来在发生更改时通知工作流。
使用 WF
EventDrivenActivity相对容易实现选项 3 - 请参阅此处的 MSDN 文档 或一点 关于它的维基文章在这里。从以下角度来看，此选项也是可取的：如果对象上存在一系列状态转换，则工作流会收到有关每个状态转换的通知 - 而轮询模型可能只选取最后一个（或轮询发生时发生的情况） 。如果您无权访问正在监视的对象的代码和/或无法更改对象的行为，则选项 1 和 2 有意义。在这些情况下，轮询几乎是您唯一的选择。
要在 1 和 2 之间进行选择，您需要确定有多少个同时工作流程可能全部等待状态更改。当工作流可以挂起并写入持久存储时，WF 可以很好地扩展；而当数百（或数千）个活动工作流必须同时在内存中处于活动状态时，WF 的扩展性较差。如果您只期望一些长时间运行的工作流等待发生此类受监视的更改，则可以继续实施选项 2（使用工作流延迟活动）。如果您期望有很多这样的工作流程，那么最好在单独的线程中执行监视并挂起工作流程，直到它们有事情要做。
如果您确实选择选项 2，请确保为工作流设计一个替代路径来中断（超时、通知、状态等），以避免留下活动的、孤立的工作流，这些工作流永远不会终止但会继续消耗资源。
There is no mechanism directly within WF to automatically detect when an object has changed - this leaves you with three choices:
Options 1 and 2 rely on a polling mechanism - in one case implemented outside of the workflow, and in the other cases implemented within it. Option 3 uses the Subject/Observer pattern with events to notify the workflow when a change occurs.
Option 3 is relatively easy to implement using WF
EventDrivenActivity- see the MSDN documentation here or a little wiki article about it here. This option is also desirable from the standpoint that if there are a sequence of state transitions on the object, the workflow is notified about each of them - whereas the polling model may only pick up the last (or whichever occured when the polling took place).Options 1 and 2 make sense if you don't have access to the code of the object you are monitoring and/or you cannot change the object's behavior. In these cases, polling is pretty much your only choice.
To choose between 1 and 2 you need to determine how many simultaneous workflows you will have that may be all waiting for state changes. WF scales well when workflows can be suspended and written out to a persistent store - it scales less well when many hundreds (or thousands) of active workflows must all be active in memory at once. If you only ever expect a few long-running workflows waiting for such monitored changes to occur, you could go ahead and implement option 2 (use the workflow delay activity). If you expect a lot of such workflows, you're better of performing the monitoring in a separate thread and suspending the workflows until there is something for them to do.
If you do go with option 2, make sure you design an alternative path for the workflow to break out (time out, notification, status, etc) to avoid leaving active, orphaned workflows that will never terminate but continue to consume resources.