Windows Workflow and validation

Requirement

I need to provide a means to perform validation on a booking system. This validation needs to act as a type of service. It will initially be simple, but will change as usage patterns emerge in the system that we wish to deal with and validate against. The validation process will be the same for every booking, but the process itself may change each week or month depending on the business. ie. We need an easy way to update the validation periodically. Eventually the fluidity will subside but initially it could be quite high.

Solution

I have written a proof of concept that uses windows workflow which I think is going to work out nicely. I define a workflow that performs the validation in a separate assembly. The workflow uses a base class that contains a property which holds the meta data upon which to validate the booking against. This will act as a common point to provide the data upon which to validate.

The validation is created using the workflow designer and is serialized as XOML (Workflow specific XAML) and saved to a database (just a simple string). The assembly is shipped with the system. The validation API loads the current XOML definition from the database and instantiates a workflow from it (de-serializes the XOML), then populates the meta data properties so the workflow can do its thing. We kick off the activity and get a notification about success or failure (and appropriate reason if failure).

When I need to change the validation, I define a new one using the workflow designer (same assembly or a new one...doesn't matter), serialize it and store it in the DB (using a really basic utility app. new validation is now used when the next booking is performed.

 

I'll post some code when I get a nicer API around it going and the code a lot neater. Right now it is very dirty and just proves the technical concept. Now I can move forward with a neater solution to encapsulate this within our current solution.

Just thought I'd share for comment. Works well in the POC. Actual implementation may be different....

10 Comments

  • Hi

    Are you familiar with the Validation Application Block? Maybe you can create a custom activity that performs validation according to configuration or attributes...

    Guy Burstein

  • Yeah I am familiar but the validations will require ever more complex rules that I didn't want to necessarily have to write code. Using the workflow designer is so much nicer. Sure I can use attributes, but the validation process is going to get reasonably complex. Also, the serialisation aspects are so easy that it makes it very simple to switch in and out validation rules.
    Finally, I didn't want a dependency on EntLib jus for validation. Mind you, this is being used within a Web Client Software Factory project, which comes pre-packaged with Entlib dependencies. I have removed all thoe too. Not a big fan of EntLib just for a few simple aspects. it would have to really warrant all that extra overhead for me.
    Thanks for the sggestion though.

  • I think one of the really cool things about this is that your validation logic can easily be versioned in the DB - it's just a string. This way you can apply historical business records to old records and what not pretty easily ...

    Cool. :)

  • Thanks Tatham. I can see some good potential from this. I'll keep posting as I progress.

  • Hi Udi,

    Yes an interface to act as the contract for the API is exactly how I see this working, but that is in fact the easy bit and its very similar to the strategy pattern, but the things I wanted to address in this implementation is 1. Ease of creating new validations (I dont really want to have to manually code it all) 2. Flexibility within the validation itself (I want to be able to do almost anything) 3. being able to easily implement them without re-deploy of full codebase, just the new bits and 4. as a final advantage the versioning aspect that tatham mentions.

    The design is pretty standard I think and not that difficult for a singular validation path. Interface abstraction is a common design point and no different whether workflow or not. The validation itself can take many forms so it needs to be quite flexible and the redeploy of that validation needs to be easy because of its fluidity. The workflow solution meets all those really nicely. So the design is standard and relatively straightforward, but the issue is all about the implementation and how it fits the design requirements (ie. fexibility, deployment, ease of use, versioning).

    I have done dynamic validation scenarios before using provider type models whih are usually driven through the config file or similar, and often require some tricky implementation mechanics to get the dynamic invocation how you want it, but often can require app restarts (yes you can make it happen without restarts) but the workflow solution makes this quite easy.

    BTW, there was something wrong with the link you provided so I could not have a look at it.

  • Hi Glav,

    I am looking for a solution very similar to yours. Can you please share the POC? It would be great help.

  • Any Updates on the Source code for the POC?

  • PaulF - email me offlist at glav AT aspalliance DOT com and I'll send something to you.

  • How did this implementation work out with windows workflow foundation. I've stayed away from it (use ShareVis/SharePoint instead, which has build-in workflow rules validation). Seems like the core strategy had some promise, but a fair bit of coding to follow. I also wonder how the whole implementation rolled out with user interaction and data access/reporting.

  • Hi spsworkflow. The implementation worked well. The ability to roll in a different validation assembly easily proved quite useful and powerful. Note that, its probably not the way workflow was intended to be used (mostly the dynamic loading factor), but hey, it suited my purposes well. Its currently in prod in 2 different deployment, with more to come, and potentially being sold overseas.

Comments have been disabled for this content.