What Was I Thinking?

Follies & Foils of .NET Development
posts - 95 , comments - 352 , trackbacks - 0

Faulting Handling for Dynamic Workflows - Part 1.

"There is no joy in Mudville - the mighty Casey has struck out."

I've been spending some time lately reviewing and bolstering my old WF Execution code.  Part of this refactoring included a revamped approach at Exception handling.  With so many different kinds of activities, implementing a "standard" fault handler is proving more challenging than I had originally thought.   Managing exceptions in base workflow activities is one thing, but handling exceptions in custom business activities is quite another.

Unfortunately, I haven't found a way to activity bind dynamically added properties in windows workflow.  As a result, I've developed a custom activity generator that I can point to an exe or dll and have it selectively generate custom activities from exposed public methods .  The generated activities support dynamic, strongly typed parameters for the method's input, output and return values.  There are also a handful of helpful "converter" activities that will convert objects from one type to another, storing the results in strongly typed generated fields.    This approach has a nice side benefit of being able to generate unit tests and ensure coverage of my business activities without relying on workflow execution-- but I digress.  The generated activities have no intrinsic  error handling of their own, but rather bubble up the thrown exceptions up the activity hierarchy to the workflow.

Left unhandled, an exception in a custom activity will fault the workflow, terminating workflow execution and tear down and unload the workflow from the runtime.  Sometimes terminating workflow execution is the proper response, but not usually.  All my workflows are dynamic.  They are all XAML activated workflows with a root activity that points to my compiled base workflow.  My goal was to implement a root level fault handling routine in my base workflow (a compiled workflow), that would act as a "safety net" for all the dynamic workflows that it hosts.

I implemented a basic fault handler via the workflow designer and ran my first unit test.  The workflow failed validation. In fact, every workflow was now failing validation.  Digging into the error stack I discovered the cause:

"Can not add activity in a CompositeActivity which has built in children." 

So there's evidently a design decision that was made that states "if the composite activity has children, it cannot be modified at runtime."  The composite activity its referring to is the base workflow itself.  The children activities is actually the fault handler activity (it gets added like another activity to the workflow's children collection).  This means I cannot support any activities (even fault handlers) in my base workflow.

For now, I've removed the fault handling code (at least my workflows pass validation and execute again).

My next idea is to change the root activity in my xaml workflows from the concrete class to a dynamic class, or possibly write something to set the internal CanModifyActivities flag during workflow load...

Got a thought?  I'd love to hear from you.

Print | posted on Friday, February 1, 2008 3:36 AM | Filed Under [ Windows Workflow Foundation ]


No comments posted yet.
Post A Comment

Powered by: