views:

985

answers:

2

There is a pretty strong need for us to design some workflows around various processes. The problem is none of us actually know any workflow technology yet, and finding good data to compare the available options has been tedious and not entirely fruitful.

So I figured I'd ask you guys.

The main technologies we are looking at are Windows Workflow Foundation and eDocs Workflow. What other options are there? Sharepoint 2007 has workflow functionality too, right? Is that just based on WF?

What are the pros and cons of the various technologies? How do they compare?

EDIT: Also, one feature the administrative types like with eDocs Workflow is that it provides a method for them to edit it themselves. I believe Sharepoint '07 does as well. Is there some other way to allow that with a straight WWF implementation?

A: 

It is possible to 'rehost' the WF designer (the one from Visual Studio) in your own application, so that users can author workflows. There are a number of code examples on the web, the most important one from MS itself: http://msdn.microsoft.com/en-us/library/aa480213.aspx).

At some point, when evaluating WF, I implemented a demo application that did this and added some features and found that although it works, not everybody can understand and use the more difficult activities (like the policy activity) that require understanding of how the rules engine works.

Bernie
+2  A: 

Sharepoint and WF more like complementary technologies, designed as two different workflow authoring tools in the same ecosystem. There's a Sharepoint workflow designer, and a WF (Windows Workflow Foundation) workflow designer.

The Sharepoint designer is meant to be an Office-like workflow editing experience, easier to get started with, geared for non-technical types, and generates all the web forms automatically.

The 'WF' workflow designer on the other hand is actually a component of Visual Studio (by default - as Bernie says you can rehost it), and designed to allow programmers to be able to fully customize workflow, and integrate it with any other code/systems desired. Building and deploying sharepoint sites this way is still possible, through the use of 'Sharepoint Activities', but more complex.

If you take the former route, you can hopefully let the administrative types do their own basic customizations (up to the limits of that environment) without causing total chaos.

Hrm... we're running Sharepoint 2007 in our Rochester office... if I had the manager guy who's bugging me about this develop the workflow in sharepoint, is there a way to grab what's generated and plug it into VS for me to work with after? Or is it permanently tied to sharepoint?
Telos