This post will introduce the first part of a starter kit for doing Page Flows in ASP.NET with Windows Workflow. The first Release Candidate for Workflow is now out as part of the June .NET 3.0 CTP. If you are already working with the Beta's you will need to update your SQL Persistence and Tracking databases with the new scripts.
I have put in a request to CodePlex to host the starter kit. I will add an update to this blog once it is approved.
The first thing the starter kit contains is the necessary configuration to get a PageFlow project started. As I started learning workflow I discovered that there are several things required for using it from an application.
Hosting the Runtime
Windows Workflow does not offer any out of the box servers or special applications to take advantage of it. It is entirely up to developers to host the Workflow runtime inside of an application. This could be a Windows service, a .NET web service, a Windows application or an ASP.NET application. The only requirement is that host can work with the .NET 3.0 Workflow assemblies. In our case we will focus on hosting inside of ASP.NET.
The runtime only needs to be created once per application in order to host multiple workflows. The blogs and examples I have found so far recommend creating the runtime in the global.asax.cs file. I have chosen in the starter kit to instead use an httpModule. By using a module it is easier to add Workflows to existing applications without having to cut and paste code.
All that is needed is to create an instance of WorkflowRuntime and then shove it into an application variable that we can access later in our ASP.NET pages. We will use this variable in a PageFlowManager control so that direct interaction with the runtime is not even necessary from our applications.
WorkflowRuntime workflowRuntime = new WorkflowRuntime("WorkflowRuntime");
context.Application["WorkflowRuntime"] = workflowRuntime;
workflowRuntime.StartRuntime();
There are 2 important additional items to note in the code above. When creating the runtime the constructor takes a configSectionName as string. That string matches the workflow configuration element name in the web.config. I find that consistently naming it keeps it simple and easy to manage. The code would have to be changed if you named it something different. The second thing is that StartRuntime is called. This allows the runtime to read the configuration and initialize all of the services that you have added via the configuration itself.
Configuration
Lets take a look as what is in the basic configuration.
First we define a config section for the WorkflowRuntime. Note that the name matches the name passed to the constructor when creating the runtime.
<configuration>
<configSections>
<section name="WorkflowRuntime" type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</configSections>
We add a reference to the httpModule that initializes the runtime for us.
<system.web>
<httpModules>
<add name="AspNetPageFlow" type="AspNetPageFlow.WorkflowRuntimeModule, AspNetPageFlow"/>
</httpModules>
<system.web>
Finally we configure the runtime with the typical services we need for most workflows. Note that the root element of the section matches the name given when creating the configuration section above. The services added via configuration are automatically loaded by the runtime when it starts. Services can also be added via code, but for the common ones it makes sense to me to just put them in config.
<WorkflowRuntime Name="WorkflowServiceContainer">
<CommonParameters>
<add name="ConnectionString" value="Data Source=.\SQLEXPRESS;database=WFServices;Integrated Security=True;"/>
</CommonParameters>
<Services>
<add type="System.Workflow.Runtime.Hosting.ManualWorkflowSchedulerService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" UnloadOnIdle="false"/>
<add type="System.Workflow.Runtime.Tracking.SqlTrackingService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" UseDefaultProfile="true" IsTransactional="false" ProfileChangeCheckInterval="60000" PartitionOnCompletion="false"/>
<add type="System.Workflow.Activities.ExternalDataExchangeService, System.Workflow.Activities, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</Services>
</WorkflowRuntime>
</configuration>
The CommonParameters section is nice because it allows us to share configuration for elements that have the same configuration. In our case we are sharing a database for Workflow tracking and persistence. You will find the SQL scripts at C:\windows\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\EN for the latest release anyhow.
The other services we have added here are the ManualWorkflowSchedulerService and the ExternalDataExchangeService. The ManualWorkflowSchedulerService was created specifically for ASP.NET. It requires us to do a little more management because we have to explicitly run the workflow when we need it. This will be a non-issue once we add the PageFlowManager to our pages, but nevertheless it is required. What this service does is it allows the runtime to borrow the current thread from ASP.NET itself. That is important to understand as it will have affect on security and page postbacks. A separate thread is automatically managed by the runtime for delay activities, but otherwise ASP.NET hosted workflows run in the same thread as the hosting application.
Just today I read that the ExternalDataExchangeService should be unique for each workflow instance. I need to do a little more research on this one and I may amend this post if that is indeed true. This service is used for communication between the host and the workflow. We will use it with a simple data pipe service in order to simplify sending objects back and forth between the host and the workflow. Of course the complexties involded will be wrapped up into the PageFlowManager and some workflow activities to make our jobs much easier.
In a future post I will examine the PageFlowManager and how it keeps the pages and the workflow in sync driving navigation and abstracting the management of the runtime from the application developer.