RSS

Windows Workflow Foundation Episode 3

15 Dec

Welcome to part 3 of Windows Workflow Foundation 4 for K2 developers. In part 1 I outlined the differences between how you should approach K2 and WF4, and in part 2 I spoke about the different designer options you have and mentioned a few best practices. There is 1 more topic I need to discuss before we can start building our workflow engine, and that is the topic of workflow persistance.

As I mentioned, WF4 is not a service – it’s baked into your application, so when your application thread stops running, so does your workflow. If we’re going to be turning this into a service then we’re going to need a way of maintaining workflow state. We’ll be doing this by serialising our workflows and persisting them in a database.

Step 1 – Creating the SQL Store

Microsoft have made this simple for us by providing us with the store to use. Assuming you have .Net 4 installed on your machine you should be able to navigate to [C:\Windows\Microsoft.NET\Framework\v4.0.30319\SQL\en] and you’ll see a bunch of SQL scripts. 2 of these are important to us:

  • SqlWorkflowInstanceStoreSchema.sql – This script will provide you with the schema you need to persist your workflow
  • SqlWorkflowInstanceStoreLogic.sql – This adds the logic to the schema

Start by creating a new database called WorkflowInstanceStore, then execute the above scripts against the database. That’s it – you’re done.

Step 2 – Set your workflows up to automatically persist

What we want to accomplish here is to get your workflows to automatically persist whenever the workflow is idle, such as when it’s waiting for a user to do something. We will also need a way of referencing this workflow again at a later stage (so you’ll need to save the workflow ID) and you’ll also need to be able to tell the workflow which activity you’re wanting to resume, and for this you need a Bookmark (a bookmark is just a string). I’ll show you how to get your workflow to automatically persist itself to the database by creating an activity which listens for the idle event. Here’s what you will do (we will implement this later – this is just pseudocode to get the idea across)

  1. Create a code activity which inherits from NativeActivity and call it WaitForSomething
  2. Add this method in:
  3. protected override bool CanInduceIdle
    {
       get { return true; }
    }
  4. Create a new workflow and somewhere in the workflow you should add your WaitForSomething activity. Now when you start your workflow, you’ll do it this way:
  5. WorkflowApplication wfApp = new WorkflowApplication(MyWorkflowDefinition);
    SqlWorkflowInstanceStore store = new SqlWorkflowInstanceStore(connectionString);
    wfApp.InstanceStore = store;
    wfApp.PersistableIdle = delegate(WorkflowApplicationIdleEventArgs e)
    {
       // Instruct the runtime to persist and unload the workflow.
       return PersistableIdleAction.Unload;
    };

I’ll stop here and recap what we’ve done. Firstly, we created an activity which raises a PersistableIdle event. Then we added this activity to a workflow and created a delegate to handle the PersistableIdle event. The event returns Unload’ which tells WF4 to unload the process from memory and persist it to the sql store referenced by the connection string we provided.

Right – I think I’ll stop there because if we go any further without doing some examples we’re going to get lost. In the next post we will start building our project and I’ll include the project for you to download so you can follow along.

As always, please send any and all questions my way.

 
Leave a comment

Posted by on December 15, 2011 in Windows Workflow Foundation

 

Leave a Reply

Your email address will not be published. Required fields are marked *