Sitting in a session at mix and they have confirmed that CRM 4.0 will use Windows Workflow Foundation to manage workflow.

So late last week Microsoft published the Windows Workflow Foundation Web Workflow Approvals Starter Kit or WFWWASK

This is the culmination of a lot of hard work by the Dunedin office of Intergen who put together this sample for the .NET 3 team @ Microsoft in Redmond.

It's a great demonstration of how you can use WF to achieve a multiuser task management and assignment system. It uses roles to determine the routing of tasks.

If WF interests you I encurage you to go and grab this sample kit to have a play. Feel free to post comments in here if you have any questions.... I must get the rest of our Dunedin team blogging!

Some discussion came up recently on a mailing list I'm on about how difficult it is to get dataexchange working with WF. Here is my reply

Windows Workflow can be a bit of a pain to debug some days. In particular there are often scenarios where an exception gets swallowed somehwere in the runtime and you go off and spend 20 hours barking up the wrong tree.

Someone had one of these issues using some of the sample code from one of my MSDN articles today.

http://forums.microsoft.com/MSDN/AddPost.aspx?PostID=575571&SiteID=1&ReturnUrl=

A hot tip is to turn on some of the debug tracing in the runtime- easy to do. Just bigg the following into your config file.

<system.diagnostics>
    <switches>
      <add name="WorkflowTraceToDefault" value="1" />
      <add name="Host" value="All" />
      <add name="Runtime" value="All" />     
      <add name="Activity" value="All" />
    </switches>
  </system.diagnostics>

We've done quite a bit of Workflow stuff for Microsoft recently.

This morning two bits of stuff that we've worked on are featured on the front page of
MSDN.

There's a Virtual Lab- which is basically some hands on labs that we've been working on running in a Virtual Machine and also my article on Simple Human Workflow.

Neath huh!?!

Windows Communication Foundation and Windows Workflow Foundation now have Go Live licenses.

Beta 2 of WF was released to the public today and it's got some great changes.

Make sure that you head to http://www.windowsworkflow.net/ to pick it up.

Make sure that you also grab the Hands on Labs from here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=5DF74E3B-FB51-4A94-A11D-DFF70288A8BB&displaylang=en

These give worked examples of almost all the key functionality in Windows Workflow Foundation. The team @ Kognition have spent the last month or so re-working and re-building these labs for Beta2.

My favourite of the labs is #10. We provide a fully worked example showing how to

1. Host the WF Designer in your own application
2. Set properties on your workflow activites at design time- including showing you how easy it is to do activity binding in your own designer.
3. Save and compile the workflows
4. Run the workflow

So the WWF tools for VS.NET 2005 have some 'issues' that can rear their head as strange build errors.

The symptom is that your solution, which has no syntax errors at all, sometimes fails to build and just spouts random bollocks.

What seems to be happening is some wierd caching of types by the designer- reason being is that the designer has to build your custom activities at design time so that you get a nice design experience.

So here are a few tips if you are seeing wierd build errors.

#1. If you are closing VS.NET and/or your solution, make sure that all designer and code documents are closed.

#2. If it's behaving strangely have a crack and building some of the key projects (communication service interfaces, services and activities) individually.

3#. If none of that works, close all your documents, close VS.NET, reopen and rebuild the solution as soon as you re-open.

THey have just shown the WWF designer pulled up into IE to dynamically edit the Indigo workflow they've just built...... and you can also edit currently running workflows.

This is just SOOOOO cool....

Imagine how good this could be for mobile routing solutions.... you can login 1/2 way through the transaction and reconfigure a running workflow to handle and exception case.

This is probably the coolest WWF demo that I've seen so far.

THey showed a workflow hanging on a delay activity and they dropped in some new activities after it stright from the web browser.

Sitting in a Don Box session at the moment looking at some future stuff for how WWF and WCF will talk together.

Very cool concepts- theability to simply have a workflow be an Indigo service but they really tightly integrated the two.... which is great.

For example if you have a correlated receive and send pair or activities in your workflow when exported as an Indigo service they will be matched up as a Send/Receive pair..... This also means that we can model contracts more richly than just single pairs- we can model contracts as conversations- i.e. we know the order in which our workflow expects to recieve messages.

Looks great. One thing that I'm interested in is just how much hosting support they're going to give us for Indigo Workflows. I'm pretty sure that IIS is going to be an out of the box supported hosting mechanism (hosting session is next).... will be interesting to see what sort of higher end support services we get OOB... things like persistence services and so forth to enable long running work flows.

One of the fundamental things you'll need to get your head around when you start playing with workflows is how to go about getting stuff out of, but more importantly into your executing workflow. Here's my 30 second synopsis......

1. Your workflow runs inside a runtime engine.
2. All of your communications from the outside world will come to you via services provided by your host. In addition, in many cases your communications with the outside world will be sent by way of services provided by your host.

This is basically the provider pattern in action and it's an important concept to grasp... here's an example of why.

Say you build a workflow that manages registrations for your user group events via email. The logic is obviously going to be pretty simple, receive registration emails, send confirmations etc.... Your workflow declarativly defines the logic of what should happen in the sequence. Your workflow contains EventSink activities e.g. ReceiveEmail that allow your eworkflow to receive inbound mail. Try, as much as you can, to think of these EventSink activities in their abstract form. That is, your activity represents a mechanism by which your workflow receives an email but, as far as is possible, doesn't mandate or specify too much concrete implementation as to how that is delivered. The actual mechanics of how it does this will often depend on where your workflow might be running- e.g. You would probably receive the email in a different way depending on whether you are running your workflow in Outlook or on a server hosted in IIS. If we want to be able to use exactly the same Workflow definition, with exactly the same Activities then we need some sort of indirection mechanism to seperate the logical concept of ReceiveEmail with the actual concrete implementation of how we do it.

So let me give you an example. You have an activity that represents receiving an email. This is an abstract concept. You then create a workflow definition (in code or XOML/XAML) that uses this activity. You then host this workflow in a couple of different hosts. When you set up each of the hosts you can construct a different service type to service you ReceiveEmail activity depending on where you are running the host. When it is running, your activity is going to ask the runtime to provide it with a service that implements a certain known .NET Interface type. Thus you could have two different services that use two different email receipt mechanism, one for a desktop host and one for a server host. Through this mechanism you achieve the indirection that enables us to use the same delcarative business logic definition (the workflow) in a number of differnt contexts which may have markedly different requirements.

All About WWF
SO Windows Workflow Foundation shipped today. We've been kicking it around for a bit now.

WWF is going to be the worflow engine for windows. It basically allows you to declarativly stitch together application logic into worflows. Not only does it support your typical 'Biztalk style' sequential workflow types but it also allows you to build state machine type workflows. You can either write them in code or.... wait for it..... you can declare them in XAML (though it's called XOML in the current drop). What this means is you could potentially stictch together a whole application out of components in just XML. Avalon would form the UI and WWF could be used to provide a state based execution engine. Slap a nice GUI UI around it and you've got a high productivity app builder that any old BA can use.

I'm going to post a bit over the next few days about some of the things that I've learnt around WWF thus far and some of the cool ideas that I've got for WWF.

I'll post some screen shots tonight once I'm back on my dev machine.