| At my last project I was asked to develop a workflow that was quite complex. Now I have my fair experience of building workflow's using SharePoint Designer and custom workflow activities but I didn’t have any experience in building workflow's in VS. First thing to decide was whether to use a sequential or a state machine workflow. I decided to go for a state machine workflow so let me explain why I opted for that type of workflow and let me begin by briefly describe what the workflow is supposed to do : - Automatically create sites
- Handle the user registration process
- If it’s the first user then do ‘code A’
- If it’s the second user .. eleventh user then do ‘code B’, etc
- If the first user didn’t respond within 2 months than do ‘code C’
- Automatically modify sites if there are an X number of users who have registered, after a X period of time modify the site again
So to me, this looked like a state machine. The first state is ‘creating the site’ , second state is ‘user registers’ and the final state is ‘modifying the site’. As always I googled for some (simple) tutorials who lead me the way and I started off with a console state machine workflow and within minutes I had a nice little workflow running :) I decided to put this little workflow into our SharePoint environment which meant that the console workflow was running in an ASP.NET environment. This is where I got my first struggle with the Workflow Foundation. I wasn’t aware of the fact that the workflow was having it’s own scheduler and was running asynchronously. In order to run the workflow synchronously with the ASP.NET process you have to define the ManualWorkflowScheduler. The following articles pointed me in the right direction : So after tackling that, the next ‘problem’ was facing me. I was very keen on using the persistency and tracking functionality since that gave the end-user/administrator the ability to quickly see in which state the workflow was running and what has happened in the past. Unfortunately this meant that the workflow could not be modified while running. Since the workflow could run for over a couple of months and having the requirement that a couple of variables could be changed (like the period of waiting or how many users are required) this was not an option. This was also not an option because when the workflow would wait for a couple of days it meant that an user could not register because the instance was waiting. So I had to drop that functionality and I had to modify the workflow so every time ‘something’ happened in the system which would fire the workflow, the workflow would create a new instance. Here are some articles which describe a bit more what I’m talking about : So after a whole lot of iterations the workflow actually got more and more sequential.. And instead of a ‘site’ lifecycle it became an ‘user per site’ lifecycle. My lessons learned are the following : - There is a huge difference between console applications and ASP.NET application that utilitize the workflow foundation.
- Spend more time in defining the workflow and make good choices between state machine and sequential. An process workflow that is defined in the functional phase could be very different in the technical phase
- Make a choice in having one instance or several instances of a workflow in terms of ‘waiting’ workflow’s. Next to that, running instances can not be versioned. So if you have long running workflows (eg. the lifecycle of a SharePoint site) and you want to make some changes to the workflow you simply cannot.
|