Modelling a collection and item relationship
I'm looking to implement a state machine for a job system.
The lowest level item is a Job, but I would also like to have the ability to group jobs together i.e a batch of Jobs. Both a batch and a job would have states like Open, Assigned, Completed, Closed etc.
So you could have a Open batch with half of the Jobs completed one Closed and one assigned. Valid states for a batch would be dependent on all the Jobs in the batch i.e only closed when all Jobs are closed or completed. And a batch cant be closed if there are still assigned jobs for example.
I can see two approaches so far
1. One
workflow just for jobs and jobs are grouped by data i.e a batch ID and the state of the batch is interpreted.
2. Two
workflows a batch and a job a batch starts multiple job
workflows At this point I'm just looking for some general guidance about how to approach this problem. However if you want to go into details about how this should be approached don't hold back.
My sense is that you are looking at the state of your data and trying to derive process from that. What are the valid states that your process can be in? I would propose that the batch state is the closest thing to your process state. I would have a state machine workflow with each state representing the state of the batch. Then when events fire within that state, you would determine whether the state of the batch should be changed. Your job state is simply the data on the job item which you should be able to query out of your workflow if you need to.
Another idea would be to look at the batch having a state machine workflow and each job having it's own state machine workflow. As jobs changed state, you'd need to notify the batch workflow which could, again, determine if it should change state based on the state of all its children.
Hope this helps.
Matt
It seems to me that the state and process management that you need is at the job level. I'd suggest you might use tracking information from the job workflow instances to show the state for your batches. Aggregate the tracking information per batch to get the information you want. Check out the Tracking Service in Windows Workflow Foundation.
Check out the Workflow Monitor sample on this page for an overview of the Tracking Service.
Regards,
Paul
Hi Craig,
I would suggest that you create a state machine for the batch and a seperate state machine for each Job.
The reason why I am saying this is that, when we created the state machine workflow one of the patterns we wanted to implement is that of a group of autonomous state machine workflows working together. They can sync with each other by sending messages but they are essentially independent of each other i.e. they don't control the lifecycle of each other directly.
Now in your case the advantage of this approach is that the batch workflow can receive messages and create instances for each job. Once the job workflow is created it can work independently by receiving messages like assigned, completed etc. But in addition the job worklow can also receive messages like canceled, changed, re-assigned. In the meanwhile the Batch workflow is independently handling other application level messages like create a new job, it can even broadcast a message to all the job workflows if you want to cancel all jobs etc.
Another advantage is that when you want to track the workflows and ask specific questions like how many jobs are currently active, how many jobs are in a current state they can be answered easily because the Batch workflow can store the information on behalf of the jobs.
Let me know if you have more questions. This is a very crucial use of state machine workflows. In trying to verify the state machine workflows I have modeled similar patterns. For example a Stage/Gate process. Here each Stage in a process is a state machine, all the tasks within a stage are state machines on their own. Now the state machine for the stage may handle messages like "manually clear the stage eventhough some tasks are not complete" etc. While each task can receive messages are speficic to that task.
Thanks
Pravin Indurkar
