David M. Richter's Blog

In that article I just want to depict what I found about Microsoft Workflow foundation in .NET 3.5. Its not comprehensive. But its an overview about the main entities in WF which were required by my application scenario.
In some article later on I will provide some small demonstration application. The article presumes that the reader has a certain knowledge of statemachines. Also its helpful to have had a quick glance at the Workflow Foundation in advance (just install it-it comes with VS2008 anyways, create a Statemachine, some Workflow, drop in some activities)

Now some theory about Microsoft Windows Workflow Foundation:

1. got the same work flow engine like MS BizTalk Server and SharePoint
   http://www.dotnetframework.de/lserver/artikeldetails.aspx?b=3773
2. Statemachines(SM) which can start sequential Workflows
3. Sequential Workflows(WF)
4. Activities of which the sequential workflow is build
5. Workflow/ Statemachine services to communicate 2 way to Workflows and Statemachines

Statemachine

The statemachine contains states.  The statemachine can only be in one state. The Initialisation of the state is itself a workflow in which the statemachine can do things. Just drop some StateInitialisationActivity into the State. Following you drag some other activities in the sequential Workflow (created by dragging the SateInitializationActivity on the State). As soon as the state initialisation is finished, the Statemachine is able to listen again. This is important since if some events are fired outside the Statemachine and the Statemachine is still initializing it cannot receive them. In every state the SM can listen to multiple events. The purpose of SM is not to incorporate actions. SM’s just depict some state in which some process is and what is possible logically in that state. If one wants to start methods and so on, its better to Invoke a Workflow which then later can call some activity.(see also section workflow services later )

Sequential Workflows

Sequential Workflows are also hosted in the WF engine. But they get only one WFEngine thread. (this can be a real thread or some virtual, the engine itself decides) They do not have states and therefore no state related activities.  The can only contain activities which have a sequential execution path.

Activities

Activities are representing just an encapsulated bit of code. They have properties and one can override for instance the Excecute method to do some other bytybyte calculations. Some can call some outside code, some are waiting for an event to occur and even some are depicting programming constructs as there is a If else construct.

All these 3, Activities, Statemachines and Workflows can be edited and created with the Visual Studio Designer for Workflows.

Workflow-Events

The Statemachine(or Workflow) only can listen to event of the type: 

public event EventHandler<System.Workflow.Activities.ExternalDataEventArgs> someEvent;

This type contains a receiver InstanceId. otherwise the WF Engine cannot dispatch the event, since it does not know about the destination. Normal events are not receivable by the Workflow engine. Communication to and from the Workflow to some external class can be done with CallExternalMethod Activity and HandleExternalEvent Activity.

Workflow Services

Some other way to communicate duplex  with the Statemachine is with services which implement some public interface decorated with the [DataExchange] attribute.  The pattern would be one Statemachine/Workflow : one service. Through this service the Workflow can trigger some work and wait for an event signaling “work is done”which then is raised later on from within the service. BTW: The Statemachine cannot directly call some method of the service(via activity), since it is then not able to receive the service’s event because the whole call is then synchronous. Therefore the SM has to invoke some Workflow (with InvokeWorkflow Activity) which itself calls the service method. By that the SM is immediately able to listen to events, after invoking some workflow.

As soon one has created a service with methods and events the wca.exe tool can be used on that interface. It creates then activities based on the method/event signature. These automatically produced activities can be used then later in the Workflow designer. the only thing to do, is to fill their properties.

Statemachine/Workflow Properties

One can extend the SM of the WF with properties to bring information into the WF. only programatically this is possible at the time of creation of the workflow. Otherwise one can set or link values to the properties with the Workflow Designer.

Pattern for startup of the Workflow environment

WorkflowRuntime workflowRuntime = new WorkflowRuntime();
// if I want to communicate with the Statemachine or Workflow I have to use some workflowServices
ExternalDataExchangeService eds = new ExternalDataExchangeService();// the general hoster
workflowRuntime.AddService(eds);
eds.AddService(new FactsheetSMService()); // now I add the actual service of the SM

// Create the workflow’s parameters collection
Dictionary<string, object> parameters = new Dictionary<string, object>();
parameters.Add(”ItemsToProcess”, queue); // set the ItemsToProcess Property of the Statemachine
//get the actual real instance of the statemachine
WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof(FactsheetSM), parameters);
FactSheetSMService es = workflowRuntime.GetService<FactSheetSMService>(); // retrieve the SMService
// fire the first event with the destination
es.OnRcpGetChangedSelected(new FactsheetSMServiceEventArgs(instance.instanceId));

now the SM is alive. One can even debug the SM or the workflows in the Workflow designer and see what is happening.

Conclusion

At the first glance the workflow foundation looks very promising.
Now If I would use WF I would hope:

• not anymore to care about the multithreading models, the workflow runtime would just take care of that
• get the process tracking out of the box
• get an easy adaptable tool to change the Workflow according to changed requirements with the workflow designer
• Better access to the state of some processing for the UI(with WF I would just display the state of the Statemachine or the current activity in the Sequential Workflow)
• ability to hibernate the process and proceed later.

All the entities used in Workflow Foundation are rather common sense for someone with IT background. So in some next article I will write my experiences with converting an existing app into Workflow application.

Some book on the matter which I can recommend: essential Windows Workflow Communication by Dharma shukla and Bob Schmidt ISBN 0-321-39983-8