In the absence of K2 being an available choice (consider expenses, resources, environment, support and maintenance that goes with selecting technologies and frameworks), Windows Workflow Foundation (WF) is becoming a viable option.
Not for everyone, but for those that understand Workflow, C# and need to interact with SharePoint in some way or another, it can be a nice option to have available.
Things to take in to consideration with WF is: what can I use for a User Interface if there is any Human to System interaction; how much do I need to know about the plumbing; how much do I need to know about SharePoint (if this is part of the solution)...
SharePoint 2010, InfoPath 2010 & WF seem to make a nice combination in the latest edition of the Microsoft tool sets. WF hasn't made in major leaps and bounds. People used to Visual Studio add-on WspBuilder and the like, will be happy to hear that this type of project set up is now out of the box.
A lot of the plumbing that was once a tedious affair in Feature.xml file, is now handled for you for the most part... not quite completely but with little effort, it all sings and dances together quite nicely.
Debugging through Visual Studio 2010 has also been taken in to account such that all one needs to do is hit F5 and the solution is deployed and awaiting an event to be triggered. For those that worked on previous incarnations of WF, this is quite amazing stuff. No more attaching the debugger manually after a painful deploy, or having to write batch files to automate the process.
InfoPath 2010 integration is a little painful still as the solution doesn't understand the .xsn extension still. But this can be manually associated with a little massaging.
Key to this is getting the Elements.xml (or workflow.xml depending on your preference for naming the elements manifest) to point to the right file path. In the new project structure, everything appears in a folder, which means you need to ensure that the .xsn files are in that folder correctly.
I used to try and avoid solutions that had MOSS 2007, InfoPath 2007 and WF as its technologies of choice like a dog trying to avoid worm tablets! However, these new solutions have had spared some thought for the lowly developer and tried to make our lives a little.
Whilst this still remains a very code dependant technology, and really Microsoft haven't put much effort in upgrading the framework (alot of it still using Framework 3.5), at least the deployment part has been simplified.
Not really fair to make a comparison between whether to use WF or K2, as a developer K2 is hands down the better tool (and is built on top of WF therefore providing you with everything WF would give you), in the absence of a choice, there's no need to be scared of WF.
Reading properties in the workflow of the Metadata columns from a SharePoint List or Library, creating user tasks to approve or reject tasks, notifications, workflow history etc are all things that are, with a little bit of configuration and programming, quite simple to establish. With the simplified way to debug these days, finding and correcting bugs in your code is also less painful than it once was.
I wouldn't say I am looking forward to more WF projects in the future, but I am definitely less apprehensive about it.
My recommendation would be to give it a go, create a simple approval workflow and check it out for yourself. If you have SharePoint 2010 and InfoPath 2010 as well, have a go at all three together and see how the experience compares.
Happy programming.
Not for everyone, but for those that understand Workflow, C# and need to interact with SharePoint in some way or another, it can be a nice option to have available.
Things to take in to consideration with WF is: what can I use for a User Interface if there is any Human to System interaction; how much do I need to know about the plumbing; how much do I need to know about SharePoint (if this is part of the solution)...
SharePoint 2010, InfoPath 2010 & WF seem to make a nice combination in the latest edition of the Microsoft tool sets. WF hasn't made in major leaps and bounds. People used to Visual Studio add-on WspBuilder and the like, will be happy to hear that this type of project set up is now out of the box.
A lot of the plumbing that was once a tedious affair in Feature.xml file, is now handled for you for the most part... not quite completely but with little effort, it all sings and dances together quite nicely.
Debugging through Visual Studio 2010 has also been taken in to account such that all one needs to do is hit F5 and the solution is deployed and awaiting an event to be triggered. For those that worked on previous incarnations of WF, this is quite amazing stuff. No more attaching the debugger manually after a painful deploy, or having to write batch files to automate the process.
InfoPath 2010 integration is a little painful still as the solution doesn't understand the .xsn extension still. But this can be manually associated with a little massaging.
Key to this is getting the Elements.xml (or workflow.xml depending on your preference for naming the elements manifest) to point to the right file path. In the new project structure, everything appears in a folder, which means you need to ensure that the .xsn files are in that folder correctly.
I used to try and avoid solutions that had MOSS 2007, InfoPath 2007 and WF as its technologies of choice like a dog trying to avoid worm tablets! However, these new solutions have had spared some thought for the lowly developer and tried to make our lives a little.
Whilst this still remains a very code dependant technology, and really Microsoft haven't put much effort in upgrading the framework (alot of it still using Framework 3.5), at least the deployment part has been simplified.
Not really fair to make a comparison between whether to use WF or K2, as a developer K2 is hands down the better tool (and is built on top of WF therefore providing you with everything WF would give you), in the absence of a choice, there's no need to be scared of WF.
Reading properties in the workflow of the Metadata columns from a SharePoint List or Library, creating user tasks to approve or reject tasks, notifications, workflow history etc are all things that are, with a little bit of configuration and programming, quite simple to establish. With the simplified way to debug these days, finding and correcting bugs in your code is also less painful than it once was.
I wouldn't say I am looking forward to more WF projects in the future, but I am definitely less apprehensive about it.
My recommendation would be to give it a go, create a simple approval workflow and check it out for yourself. If you have SharePoint 2010 and InfoPath 2010 as well, have a go at all three together and see how the experience compares.
Happy programming.
