I am currently using sequential workflows in Windows WF, but need to break up the process because I now have multiple workflows that need to share a piece of functionality. I believe there’s a way to create custom code activities in WF that would basically accomplish this, but my plan is to eventually ditch WF in favor of Stateless; therefore, I don’t want to spend the time right now learning how to code custom activities.
The only thing I can think of is to create a new WF project that contains all of the “shared” behaviors, and then launch them from within the workflows that need them. I’m working on this now to see how it goes, but can anyone tell me if this is just a Bad Idea?
EDIT — one “problem” I see right now is that I use a singleton for the WF runtime, as I have experienced massive memory leaks before, even when I dispose of the WF RT properly. I track all WF instances in the initial caller of the workflow, so in order to handle the events properly, I’d have to pass this List of WF instances into the workflow so it can add the WF that I’m launching internally. Seems a bit messy to me, although I can certainly still try it this way. I track the WF instances because I’m trying to use this to enable Pause / Abort / Resume functionality. When the user clicks the respective button in the GUI, it loops over all WF instances and calls the matching method.
Your main problem with splitting a workflow into separate parts is that they are completely disconnected. That is the main workflow doesn’t wait for the child workflows to finish. This can be done but takes some doing.
Another think to keep in mind is error handling. When a child workflow faults the main workflow is not aware of this, quite different behavior from adding child activities.
If you need to reuse logic you can also create composite activities using the designer. This is very similar to developing workflows and you can reuse these activities on multiple workflows as needed.