|HomeShow ChangesEditPrintRecent ChangesSubscriptionsLost and FoundFind ReferencesRename
So you are going to add WF to your application, great but now you are faced with some decisions like:
See SequentialVersusStateWorkflows for the details. Next time I will write about where to leave all the information/data required by the workflow.
So the next question is how much to put in a single workflow. This is basically a question of creating bit catch all workflows versus smaller granular workflows.
My take on this is to create uses cases and turn each use case into a workflow. So let’s look at an example. A customer goes to a online shop, picks a few items, orders them and ask form them to be shipped. This is the basic use case but we can think of a number of additional use cases that may apply. For example:
Now all of these actions are valid variations of the basic sale but would it be smart to design them all into the same workflow? No certainly not! The workflow would become excessively large and complex with lots of actions that never execute during normal operations.
So I suggest you create a basic workflow consisting of a normal sales action. This consists of:
Now the payment and delivery are separated out of the main workflow. This way it becomes easier to support alternatives or reuse them in other places. For example if the customer returns a defective item we will have to ship him a new one. Shipping is no different but the whole process of handling defects is vastly different from selling the original item.
An alternative to spawning new workflows would be to modify the workflow at runtime adding the required steps. The main benefit would be that everything stays nice and contained in a single workflow making it easier to track but the drawback is that part of the workflow is designed in code removing the a major benefit of WF in that a picture is worth a thousand words.
Model your workflows after the real processes in your organization. If one process activates another take a good look if it is really part of the first process of more the result of it. Often it will turn out to be just a new resultant process that really should be a different depended workflow.
Sequential versus State workflows
23-11-2009 15:28:17 - -18.104.22.168
This wiki site is supposed to be a shared resource. As a shared resource everyone is encouraged to add new content or modify existing content!
Enjoy the WF wiki.
Click to read this topic
23-11-2009 15:31:34 - anonymous