Develop Reference

.net Workflows - created by a user or business analyst

We have an ordering system that is currently quite hard coded. We would like to make this flexible, and allow our Business Analyst to create workflows himself. The application will be installed for separate clients so there will be separate workflows for each client.
We are a bit uncertain about the correct technology here. One option may be WF but this seems to be directed more towards developer use.
We were thinking to create 'activities' and through a screen the business analyst can arrange these accordingly in a workflow. This information would be saved in some XML format and then we would load the info and execute the activities.
What is the correct technology here please? perhaps a third party tool or is WF ok?

I'm not sure I can give you the correct technology for your situation, but give you a few pointers if you want to go down the WF4 route. It will require investing some time in learning WF4 in general and some of the complex features of Re-hosting a Workflow. To put it simply Re-hosting the Workflow in an application will let you provide an environment where your BA can work that does not force him/her to work in Visual Studio.
Take some time and invest in learning Wf4 and Re-hosting:
http://msdn.microsoft.com/en-us/library/cc835242.aspx
http://blogs.msdn.com/b/asgisv/archive/2010/02/06/rehosting-the-workflow-designer-is-so-much-easier-in-net4-a-boon-for-the-isv-community.aspx

Dynamic Business Rules

I am creating an interface where users can build their own business rules out of domain specific objects at runtime, have those rules persisted in the database and then used by the application. Some of these are complex predicates and others require combinations of domain objects in what seems fairly complicated relations. So far I have looked into GoF, dynamics with eval, and CodeDom. Does anyone have suggestion on what should be used?

Actually, you can just develop your application with WF rules engine API without using WF. http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/08/09/WF-Rules-Engine-without-Workflow.aspx This will save you from a lot of work.

Kaizen, depending on the scope and kind of your dynamic rules you could eventually use a workflow engine, like MS WF to define the rules as workflow activities for example... in this way you isolate the logic and do not need a full rebuild of the application when you need to change anything in the workflow.
This might not be the best solution but could be an alternative...

Having spent a year building a rules engine and fighting on approaches I can tell you its not easy. Especially when you focus on what your goal is. If its to get users to write the rules for the system, you really need to focus hard on that area. Whats easy for a developer is perhaps much harder for most business users. We built a rules authoring platform in Excel that was compiled into C# and run dynamically ... problem was users found the spreadsheets and flow of logic too complicated and hired ASp.NET contractors to do build the rules.
BizTalk has an engine that I believe can be used for .NEt apps
http://www.microsoft.com/biztalk/en/us/business-rule-framework.aspx
Have fun!

How often do the rules change? Building a system that let's the business build (and version) their own rules is significantly more challenging than building a system that lets a programmer update the rules dynamically.
When a similar requirement came up in a past project, the business admitted that while yes, the rules will change; they won't change so often that it has to be them making the updates.
We ended up using IronPython for the dynamic parts and storing the code in the database and the system would pull up the appropriate rules on load. The rest of the app was written in C#. A win for us and for the business.

Real World Examples of WF and WPF Interaction

I'm looking for some good real-world examples of interaction between Windows Presentation Foundation and Workflow Foundation. Most of the WF tutorials I see demonstrate use within console applications. I'm more curious about applications that use a rich WPF interface and WF. Particularly if they allow user defined workflows (allow users to design and run their own workflows on the fly).

I'm not sure what exactly you're looking for, but here are some links to information about actual real world applications using Workflow in desktop (WPF) applications in one way or another:
Sample Real World WF4 Integration
Infinity Workflow (there's a lot of info in the linked Word file)
Aderant Enterprise Workflow (also presented at PDC Windows Workflow Foundation Futures session)

Let me take the example of trying to make two workflows communicate with each other.
First you need to write a host. This is an extremely loaded proposition, because for two WF hosts to talk to each other, you will then also need to know WCF, and all mushy concepts of threading.
Then your WF will need to communicate with other WFs via the hosts. This makes sense because a WF doesn't keep running in memory for 3 months, when it is waiting for another WF to send an event. The WF sits in the database, and the communication occurs through the hosts.
Okay, even for simpler scenarios, for local in-process communication, you have the CallExternalMethod activity, and HandleExternalEvent activities. Even in this case, you have to talk via the host, because the WF might have been passivated to the database. So in order to do so, you have to remember to do 3 things, decorate your interface with the ExternalDataExchangeAttribute, eventargs needs to derive from ExternalDataEventArgs, and event args is serializable.
If you mess up in any of the items in #3, you get a very non-intuitive "InvalidOperationException". Sure the message says, "Service does not implement an interface with the ExternalDataExchange attribute", but it isn't until you look at the inner exception, that you really know what happened - i.e. you forgot to make it serializable. doh! But I did mark it as serializable. Actually, everything needs to be serializable, even the sender.
Then you have to connect the WF activities, via the proper interface names and method names you are using to communicate.
Finally, for even in-process WF communication, you have to remember to add your service to the ExternalDataExchangeService, and not the WF runtime. Otherwise, it will look like nobody is subscribing to the event. Not to mention, that this is one of those bug, that doesn't really throw an error. i.e. hard to track down!
So, in short, for the simplistic scenario of trying to make two workflows communicate, you need to have a good handle on the following:
*Writing windows apps (for the host),
*Threading,
*WCF,
*OOP Concepts,
*All concepts of serialization,
*Plenty of hooking up and non-intuitive details of WF itself,
*Ninja debugging skills.
Source:http://blah.winsmarts.com/2008-2-I've_been_here_before.aspx

The question is pretty vague but here is a possible awnser in this blog post I wrote. Basically I am rehosting the workflow designer to let end users change workflows as needed and let them run them right there and then. Of course you question could mean pretty much anything, like how to call a workflow service from a WPF form.

This is a sort of self promotion since the link is mine, but have a look.

Here is a sample project I did, which combines WF and WPF to simulate a ATM machine. The code works on some issues like handling the bookmarks, how to keep the workflow alive, and how to manipulate the UI from the workflow.
https://wpfwf.codeplex.com/

To Workflow or Not to Workflow?

I am responsible for a team of developers who will are about to start development of a light weight insurance claims system. The system involves a lot of manual tasks and business workflows and we are looking at using Windows Workflow (.NET 4.0).
An example of the business domain is as follows:
A policy holder calls the contact centre to lodge a claim. This “event” fires two sub tasks which are manually actioned in parallel and may take a lengthy time to complete;
Check customer for fraud – A manual process whereby an operator calls various credit companies to check and assess the potential of a fraudulent customer. From here the sub task can enter a number of sub-statuses (Check in progress, Failed Reference Check, Passed Reference Check, etc)
Send item to repairs centre – A manual process where the item for which the policy holder lodged the claim is sent the repairs centre to be fixed. From here the sub task can enter a number of sub-statuses (Awaiting Repair, In Progress, Repaired, Posted, etc).
The claim can only proceed once the status of each sub task has reached a predefined status (based on the business rules).
On the surface it seems that Workflow is indeed the best technology choice; however I do have a few concerns in using WF 4.0.
Skill set – Looking at the average developer skill set I do not see many developers who understand or know Workflow.
Maintainability – There seems to be little support within the community for WF 4.0 projects and this coupled with the lack of skill set raise concerns around maintainability.
Barrier to entry – I have a feeling that Windows Workflow has a steep learning curve and it’s not always that easy to pick up.
New product – As Workflow has been completely rewritten for .NET 4.0 I see the product as a first generation product and may not have the necessary stability.
Reputation – Previous versions of Workflow were not well received, considered difficult to develop with and resulted in poor business uptake.
So my question is should we use Windows Workflow (WF) 4.0 for this situation or is there an alternative technology (e.g., Simple State Machine, etc) or even a better workflow engine to use?

I have done several WF4 projects so lets see if I can add any useful info to the other answers.
From the description of your business problem it sounds like WF4 is a good match, so no problems there.
Regarding your concerns you are right. Basically WF4 is a new product and is lacking some important features and has some rough edges. There is a learning curve, you do have to do some things differently. The main point is long running and serialization, which is something the average developer is not used to and requires some thought to get right as I hear far too often that people have problems serializing an entities framework data context.
Most of the time using workflow services hosted in IIS/WAS is the best route when doing these long running type of workflows. That makes solving the versioning problem not to hard either, just have the first message return the workflow version and make that a part of each subsequent message. Next put the WCF router in between that routes the message to the correct endpoint based on the version. The basic is never to change an existing workflow, always create a new one.
So what is my advise to you?
Don't take a big gamble on a unknown, and for you unproven, piece of technology. Do a small, non critical, piece of the application using WF4. That way if it works you can expand on it but if it fails you can rip it out and replace it with more traditional .NET code. That way you get real experience with WF4 instead of having to base a decision on second hand information and you learn a new and powerful technology in the process. If possible take a course on WF4 as that will save you a lot of time in getting up to speed (shameless self plug here).
About the Simple State Machine. I have not used it but I was under the impression it was for short running, in memory, state machines. One of the main benefits of WF4 is the long running aspects.

I have come to this dilemma couple of times and I had chosen not to use Work Flow foundation. Some of considerations (similar to yours) were
Involved work flows were lot simpler (a combination of state machine and sequential actions) and doing it in WF seems to overkill for efforts involved.
Learning curve for developers to understand and to use WF effectively was considered high. Status transition table describing valid transitions and actions to be taken are used for additional flexibility and developers were comfortable with it, easily understanding the concept and purpose.
Chances of business process changes were slim and rudimentary changes were easily possible with help of transition table. A change in transition would mean a database script while change in actions would result in new release/patch. However, probability of such occurrence was deemed to be low.
Looking back after 13-14 months, I still think that decision of not using WF was correct. IMO, WF makes sense where there is strong likely hood that work flow can change and/or business rules can change. WF allows to isolate workflow in separate file and so making it configurable by users will be simpler.

We have been using WF 4.0 the last couple of months. I have to say it's challenging to think the Workflow way. However, I can tell you it's worth it. We knew very little when we started. We've bought a beginner and professional book for WF 4.0 that helped. I, myself, watched many videos online and followed PDC 2009 for their breaking news about WF 4.0 and how it's different from the previous somewhat sucky versions.
One major thing that we had to propose a solution for is the way we can deal with In/Our Arguments in a workflow without bounding our custom activities to certain data types and how to pass parameters between activities. I have come up with a good solution for that, and the workflow experience that we have so far is not bad at all. Actually, we have a workflow-intensive application that is getting bigger and bigger and I really cannot imagine myself solving it in a different environment. I love the visual effect that it has: it keeps me away from the details of if/else etc constructs and makes the business rules apparent in a way that doesn't make you forced to dive into lines of code to know what's going on or how to fix some bug.
By the way, the project that we worked on is very similar to what you described and it's a medium-sized project.
You can tell from my words that I like it and I do recommend it although is incorporates some risks as it's a new technology and you have to come up with some innovative ideas.
my 2 cents...

I did three projects in WF 3.5 and I have to say it is not easy. It force you to think in the whole new way especially when persistance is used. Updating the application which contains hundreds of incomplete persisted workflow is challenging. Single breaking change in serialization crashes them all. Introducing multiple versions of the same library to support new and old running workflows is common. It was challenging.
I haven't tryed WF 4.0 yet but based on experience from BizTalk and WF 3.5 I think it will be similar.
Anyway the best approach you can take is to do Proof-of-Concept. Take single WF from your requirments and try to implment it in WF 4.0. You will spend some time with it but you will prove if you are able to do that in WF 4.0 and if there are any visible benefits.
If you decide to use WF 4.0 I insist that you check possibility to run WF as WCF service hosted in Windows AppFabric. AppFabric provides some out of the box functionality for hosting WFs.

I think it does not really make sense today to talk about Workflow in WF4 as a technology choice for this kind of problem. What is really appropriate, as mentioned by Ladislav Mrnka above, is WCF WF Services hosted in AppFabric.
My experience with this is that it pays great dividends and is very enjoyable, but problems arise in the beginning because it is not properly appreciated that for many programmers this is a methodology shift more than a technology shift. On the other hand, generalists and those with a problem-solving mindset saw WCF WF AppFabric as a set of exciting opportunities. So if the mix of people on the project are fairly conservative C# devs attached to their daily set of OO and patterns, it will be hard to introduce. If the team is more innovative, then adoption will be much easier because the potential and new doorways multiply with each discovery.
Two main conceptual problems programmers had in moving to this technology was:
a) Message correlation and messaged exchange patterns
b) Workflows and unit testing
In standard systems in C# for example a workflow is rarely explicit and therefore rarely unit tested. The overall workflow is left for testing by acceptance scenarios or integration. Introduce an explicit WF as a software artifact and suddenly standard devs want to try and unit test it, which is usually not worth doing.
The message correlation aspect of it is a bit of mindset shift for those not familiar with message exchange patterns. Most devs have dealt with in process and remote calls, web service and SOAP, and usually focussed on one or two of those. To abstract above it all and work with a general message based system can be confusing at first.
On the positive side though, the end result is something that saves a lot of time and creates a lot of opportunities. One main thing is that the worfklow, if visually clear, is something that can be worked on by end user, developer and analyst together, eliminating unnecessary steps in the development lifecycle and focusing the parties on one artifact. Further, it discourages islands of functionality in dedicated apps, with dedicated glue layers, by encouraging a suite of business processes in WF per business domain. Further, with AppFabric, the plumbing for persistence, logging, and waking up scheduled activities is all done for you. WF4 performance is outstanding too.
My recommendation would be to find the most innovative or explorative team member do the initial scouting to discover the tricky parts, get the core functions working, and have that initial person be responsible for then compartmentalising the remaining work.

In order to do an insurance claim system of any complexity that involves roles and "sub-tasks" you really need an BPM solution, not just workflow. Workflow Foundation 4.0 is slick but it really doesn't not come close to the functionalities of a BPM product.
BPM solutions, like Metastorm BPM, Global360, and K2.NET, provide human centric workflow, tasks, roles, and system integration that can model and streamline the business processes like your insurance claim system. Use ASP.NET to build the interface that integrates with the BPM workflow engine as their built in designers are usually limited and force you to use their custom built web control which usually are not as full featured as the ASP.NET web controls.

Go with the technology your team knows and feels comfortable with. Workflow Foundation is not a product that you can use straight away - it's rather a set of pieces you can embed in your application in order to build a workflow system. IMHO the workflow logic is the least important piece of technology, first of all you have to concentrate on the GUI because business owners will not see anything but the GUI. But if your system is a success then you have to be prepared for neverending change requests and new requirements so you have to implement your business logic so that it's easy to change and easy to divide into separate processes to suit different user needs (sometimes contradicting). BPM helps in this task because it allows you to have separate, multiple versions of business processes suiting various business needs. You don't need full fledged BPM engine for that but it's useful to code your business logic so that it can be versioned and divided into individual business processes - the worst thing to have is an unmantainable and intertangled blob of code that handles 'everything' and that no one can understand. There are many ideas for that - state machines, DSLs (domain specific languages), scripts etc - you decide what the implementation should be. But you should always think in terms of business processes and organize your logic accordingly so that it reflects these processes.
And be prepared for coexistence of many variants of business logic and data structures - this is the most difficult design task imho.

I'm in a situation where I have to use 4.0 as .NET 4.5 isn't accredited for use in our prod environment yet. I had major pain understanding generally how to get long running workflows going to suit our business need but eventually found an elegant solution. It's not something which just anyone coming later to support can just pick up with ease because there's so much to think about, but I do believe in WF as a tool for managing workflow states.
One big thing I take issue with WF 4.0 though is Maurice's comment:
The basic is never to change an existing workflow, always create a new one
That's great if you just want a new version, but what if you have 50,000 persisted workflows and realise at some point that there's a bug in the workflow? You need to be able to update the xamlx and still be coupled to the existing instances. I've tried ungzipping the various metadata columns in the SQL Server instances table to find something that ties the instance to the workflow definition without any luck.
I did write a synchronisation application for importing data from an old system into our new WF 4.0 driven one. We basically load the data into the system, then run the process which goes about automatically calling into the workflow steps and calling validation methods, essentially mocking user interaction. This only really worked well with us due to the architecture we implemented for access to the workflow service host. It's great as a one off, where after running you can go through and do checks to ensure consistency of the data migration process, but having to use this approach for potentially hundreds of thousands of cases once a system is live isn't really an approach that instills confidence and over burdens the process of integration simple bug fixes.
My recommendation is that you avoid WF 4.0 altogether and just go straight to 4.5 if you're environment supports it. The Dynamic Updates and Side by Side Versioning it provides caters for bug fixing and WF versioning all out of the box. I've still yet to investigate exactly how as 4.5 still isn't accredited for use by our client, but eagerly awaiting this opportunity.
What I'm desperately hoping for is that our client doesn't request changes to policy (and therefore workflow adjustments) and that the current workflows hold up without any bugs. The latter being a vain and empty hope as bugs always pop up.
I really can't understand what was going through the WF dev team's heads to release a system where out of the box you can't fix bugs easily. They should have developed a technique for re-binding an instance to new xamlx.

Is the PnP WPF/Silverlight Composite Application Guidance appropriate for role-based UI composition?

I'm developing a line-of-business application using WPF, possibly multitargeting SL as well. One of the requirements is that UIs be composed based on user roles/rights. For example, if the user is a salesperson, she shouldn't see any of the accounting components. If the user is an accounting clerk, that user will see some accounting components and a subset of sales components. If the user is an accounting dept manager, she will see all accounting modules, and a larger subset of sales modules, and so on.
I know that the Composite Application Library supports module-loading and UI composition (obviously), but I want to be sure that it has the flexibility to support this feature before I invest a big chunk of time in spiking it.
I'm not asking whether role-based UI composition is "baked-in" to the library (I assume that it isn't), but only whether it is a good fit for this model -- that I can intercept or configure the module loading and UI composition logic without any severe code contortions.
Thank you.

The Composite Application Guidance actually is a very good option for this. By being able to easily assign content to regions, you can swap out your content by roles in a very flexible manner.
I personally think combining Prism with MEF makes this type of situation easier, though, since MEF allows for easier dynamic extensibility for roles.
I'd recommend listening to Glenn Block's chats on Prism, Unity, and MEF.