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.
application 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 ASPNET, 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 here:
To execute a workflow, you need to create an instance of that workflow using the Create lnstance 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 Workflow lnstance.
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 following XML shows a simple sequential workflow that contains an If Else Acvtivity end two code activities, one on each branch of the If Else Activity:
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 Sequential Workflow Activity and the If Else Activity) 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 Create Workflow method that takes an XML Reader 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 you can 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 Workflow Changes object, which contains all of the new activities to be added to the workflow, and then call the Apply Workflow Changes method defined on the Workflow lnstance class to persist these changes. This is exceptionally useful, because business needs often change and, for example, you might want to apply changes to an insurance policy workflow so that you send an email to the customers a month prior to the renewal date to let them know 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.
The Workflow Designer
To complete this chapter, we’ve left the best until last. The Workflow Designer that you use to design workflows isn’t tied to Visual Studio you can re host this Designer within your own application as necessary.
This means that you could deliver a system containing workflows and permit end users to customize the system without requiring them to have a copy of Visual Studio. Hosting the Designer is, however, fairly complex, and we could devote several chapters to this one topic, but we are out of space. A number of examples of rehosting are available on the Web- we recommend reading the MSDN article on hosting the Designer available at http://msdn2.microsoft . com/en-usllibrary/aa480213. aspx for more
The traditional way of allowing users to customize a system is by defining an interface and then allowing the customer to implement this interface to extend processing as required.
With Windows Workflow that extension becomes a whole lot more graphical, because you can present users with a blank workflow as a template and provide a toolbox that contains custom activities that are appropriate for your application. They can then author their workflows and add in your activities or custom activities they have written themselves.