Windows Workflow Foundation – Diasporic Element

Asynchronous Form Validation Using Windows Workflow

Just completed work on a Asp.Net validation framework using Windows Workflow for a client. The client maintains a host of medical related data collection applications and needed a unified framework for validations for them for the client and code behind. They wanted to write validation rules once and use them in multiple contexts: client side via Javascript and in code behind as plain C# web service calls. I designed and built for them a validation framework that consisted of

   1. asynchronous javascript validation using custom validators
   2. an XML web service that is called by javascript to execute validation rules that are expressed as workflow rules conditions (Business Rules Execution Service)
   3. ORM data mapping objects that workflow rule conditions are mapped to
   4. a business rules editor that leveraged the ruleset dialog editor to provide for editing rules.

The system is in the final test phases now. I am writing an article on it that I hope gets picked up by someone if not I will post here.

This approach works for several key scenarios:

1. Complex validations that are difficult to express in just javascript.
2. There is a need to store validation rules in the database
3. There is a need to use the same validation rules in multiple contexts: client side, code behind, web service, etc.

Performance considerations are not what you might think. A form with 50 elements and dozens of validation rules still takes about 200 ms round trip for the Business Rules service. Workflow rules conditions have execution times approaching those of plain C#. LinqToSQL mapping classes (what the rules conditions are bound to) have good hydration times from the db (100 ms or less for even large data mapped objects).

For inquiries or more specifics either look for my article when it is somewhere or email me.

MsBuild, CCNet, VS2008

If you ever want to get this all working. Please ignore all the blogs that try to indicate that somehow you can use a custom task library or maybe some feature of msbuild to do deployments. The best blog I have found on getting this all to work including deployment is here. Lets face it. Unless you have Team Foundation running, Microsoft wants you to jump through hoops to get continuous integration to work. Depend on CCNet and ignore having too much in MSBuild.

Creating Custom Activities can make you rich

After pulling out my hair to understand what it takes to make an activity without code-behind appear in the toolbar of Visual Studio 2008, I resigned myself to inevitability: ○ Unless you want to write your own XOML then you better use the code-behind format if you want to create a workflow. ○ Creating a custom activity is easy. Creating a custom activity that will have behavior and attributes like built in activities will take a little more time. ○ Most things you want to do in workflow can be accomplished using the default activities so don’t create your own custom activities if you don’t have to. ○ There is no such thing as truly dynamic properties in workflow. You will have to use any of the patterns for state (like State for example). I’ve finally been able to coble together a workable solution for a client that needed dynamic logic and dynamic variables. They also wanted to create the workflows graphically. The solution we proposed was to use custom activities that are arranged into a workflow using Visual Studio 2008. The clients would drop our custom activities onto a Sequential Workflow with code behind. They would then use the Rules Editor to define conditions that were a requirement of the Decision type activities. The client would then automatically create a XOML and a .rules file directly from inside Visual Studio 2008. The XOMl, .rules, and our activity library dll would be all that is required for another developer to create our workflow inside any Workflow container. This is powerful stuff because that is allowing custom logic and rules to be embedded into any system with

Windows Workflow for the rest of us

First off, get a good book. Workflow is too encompassing for you to pick up in a tutorial. Forget about learning it all in a weekend. Pick up a good book written by one of the original WF developers. My first choice was Essential Workflow by Shukla and Schmidt. More of a developer reference than anything else. There are other books for other users, but, you definitely need a book. Second, go ahead and move to Vista and Visual Studio 2008. Sure, you can do WF development in 2005 and XP, but, thats like desiging a Formula one race track when you have only driven Yugos: You can imagine what it feels like and if you have an excellent knowledge of race track design you can pull it off, but, for mere mortals its going to suck. Third, there is plenty of MS documentation on the MSDN site, but, you could just ignore all that and proceed to write some terrible implementations. Forth, the killer app for me of the moment is designing workflows using a Domain Specific Language. Fifth, profit.