Hosting Workflows

The code to host the WorkflowRuntime in a process will vary based on the application itself.

For a Windows Forms application or a Windows Service, it is typical to construct the runtime at the start of the application and store this in a property of the main application class.

In response to some input in the application (such as the user clicking a button on the user interface), you might then construct an instance of a workflow and execute this instance locally. The workflow may well need to communicate with the user - so for example, you might define an external service that prompts the user for confirmation before posting an order to a back-end server.

When hosting workflows within ASP.NET, you would not normally prompt the user with a message box but instead navigate to a different page on the site that requested the confirmation and then present a confirmation page. When hosting the runtime within ASP.NET, it is typical to override the Application_Start event and construct an instance of the workflow runtime there so that it is accessible within all other parts of the site. You can store the runtime instance in a static property, but it is more usual to store this in application state and provide an accessor method that will retrieve the workflow runtime from application state so that it can be used elsewhere in the application.

In either scenario - Windows Forms or ASP.NET, you will construct an instance of the workflow runtime and add services to it as shown below.

  WorkflowRuntime workflowRuntime = new WorkflowRuntime(); workflowRuntime.AddService(     new SqlWorkflowPersistenceService(conn, true, new TimeSpan(1,0,0),                                       new TimeSpan(0,10,0))); // Execute a workflow here... 

To execute a workflow, you need to create an instance of that workflow using the CreateInstance method of the runtime. There are a number of overrides of this method that can be used to construct an instance of a code based workflow or a workflow defined in XML.

Up to this point in the chapter, you have considered workflows as .NET classes - and indeed that is one representation of a workflow. You can, however, define a workflow using XML, and the runtime will construct an in-memory representation of the workflow and then execute it when you call the Start method of the WorkflowInstance.

Within Visual Studio, you can create an XML-based workflow by choosing the Sequential Workflow (with code separation) or the State Machine Workflow (with code separation) items from the Add New Item dialog. This will create an XML file with the extension .xoml and load it into the Designer.

When you add activities to the Designer, these activities are persisted into the XML, and the structure of elements defines the parent/child relationships between the activities. The XML below shows a simple sequential workflow that contains an IfElseAcvtivity and two code activities, one on each branch of the IfElseActivity.

  <SequentialWorkflowActivity x: x:Name="Workflow1"   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow">   <IfElseActivity x:Name="ifElseActivity1">     <IfElseBranchActivity x:Name="ifElseBranchActivity1">       <IfElseBranchActivity.Condition>         <CodeCondition Condition="Test" />       </IfElseBranchActivity.Condition>       <CodeActivity x:Name="codeActivity1" ExecuteCode="DoSomething" />     </IfElseBranchActivity>     <IfElseBranchActivity x:Name="ifElseBranchActivity2">       <CodeActivity x:Name="codeActivity2" ExecuteCode="DoSomethingElse" />     </IfElseBranchActivity>   </IfElseActivity> </SequentialWorkflowActivity> 

The properties defined on the activities are persisted into the XML as attributes, and each activity is persisted as an element. As you can see from the XML, the structure defines the relationship between parent activities (such as the SequentialWorkflowActivity and the IfElseActivity), and the child activities.

Executing an XML based workflow is no different from executing a code-based workflow - you simply use an override of the CreateWorkflow method that takes an XmlReader instance, and then start that instance by calling the Start method.

One benefit of using XML-based workflows over code-based workflows is that you can then easily store the workflow definition within a database. You can load up this XML at runtime and execute the workflow, and very easily make changes to the workflow definition without having to recompile any code.

Changing a workflow at runtime is also supported whether the workflow is defined in XML or code - you construct a WorkflowChanges object, which contains all of the new activities to be added to the workflow, and then call the ApplyWorkflowChanges method defined on the WorkflowInstance class to persist these changes. This is exceptionally useful, as business needs often change and, for example, you might want to apply changes to an insurance policy workflow so that you send an e-mail to the customer a month prior to the renewal date to let them know that their policy is due for renewal. Changes are made on an instance by instance basis, so if you had 100 policy workflows in the system, you would need to make these changes to each individual workflow.