views:

52

answers:

1

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.

+1  A: 

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.

Maurice
Thanks, Maurice, I'll look into your suggestions. However, just to play devil's advocate, why wouldn't the main workflow wait for the child workflow to complete? I have a code activity in the main WF that starts the child workflow instance, but I am using an AutoResetEvent to make the code activity block. Only until the child workflow completes (and sets the event in the WorkflowCompleted handler) does the main workflow continue. I am currently torn about error handling -- should I use try/catch, or FaultHandlers?
Dave
I guess I need to re-read this article: http://msdn.microsoft.com/en-us/magazine/dd419656.aspx
Dave
Maurice, after successfully implementing the workflow-within-a-workflow approach, I tried your suggestion. I was very excited to see how easy and logical it is to create a custom activity that you can just drop into other workflows. My only question now is, what's the mechanism for getting the parameters passed into the workflow into the custom activity? Since the activity is inside of the workflow, I'd expect it to somehow be able to access the workflow parameters, but haven't found the answer yet. **EDIT** ok, I poked around and just now saw them in the properties window in the designer!
Dave
Sorry again, I got too excited. The properties dialog doesn't seem to let me select or even enter variable names. And some are even grayed out...
Dave
I found this article that suggests that Dependency Properties in the workflow is the way to go -- you can bind the values in the custom activity to the DPs. http://msdn.microsoft.com/en-us/magazine/cc163504.aspx
Dave