Help with Custom Workflow that monitors an objects state

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 t开发者_运维技巧his 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.

---

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.

---

There is no mechanism directly within WF to automatically detect when an object has changed - this leaves you with three choices:

1. Suspend the workflow, and use external code to resume it when the external object changes state.
2. Within the workflow add a Delay activity within a While structure that periodically examines the object being monitored for changes.
3. Publish an event on the object that fires when the state of the object changes.

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.