1. Introduction The goal of this Technology Letter is to provide an overview of how to work with Windows Workflow Foundation 4.0. It has two sections: First, there is an introduction that describes what the Workflow Foundation actually is. This is followed by an example illustrating how a service of this type is configured. This Technology Letter is intended primarily for developers and architects.
2. What is WF?
The Windows Workflow Foundation (WF) is part of the .NET framework. It provides developers with a declarative programming language that allows simplified description of complex procedures. The primary focus is on WHAT rather than HOW: In the case of an algorithm, for example, we care about what it computes instead of how it is done. This simplifies the user's life by making it possible to focus on the logical program flow while avoiding excessive technical details. A graphical programming environment provides support, presenting the logical flow with symbols instead of code.
WF was shipped for the first time with version 3.0 of the .NET framework. However, it was poorly received since the product was very complicated to understand and use. The latest version has been completely rewritten to simplify the programming and to improve the productivity and performance. Backwards compatibility is guaranteed so that previously developed programs can still be used with the newer version 4.0.
WF is a framework for creating computer-based workflows that normally contain user interactions. The workflows can be made persistent (e.g. as an XML file or using a database) and restarted and resumed at a later stage. Tracking also makes it possible to track a workflow and determine its current status.
For programming purposes, the following component types (known as Activities in WF4) are included: loops, conditions, assignments, sequences, method and service calls, parallelisation, persistence, collections, delay, transactions, error handling and interoperability.
Important changes vs. WF3
As has already been mentioned, WF4 has been completely rewritten and is very different from the previous version.
The revised Workflow Designer is now based on the Windows Presentation Foundation (WPF) and the workflows created with it are saved in EXtensible Application Markup Language (XAML). A new feature is the ability to define variables for the persistence or modification of a status or parameter for input and output, i.e. for communication with the host (see section on hosting configuration).
WCF was already supported in WF3, but WF4 has added "activities" to simplify connection of WCF services. As a new feature, the developer can also differentiate between typed and untyped service contracts. Untyped service contracts offer the benefit of better performance since no serialisation is required.
The class library in WF4 was extended to include a new activity type that makes it possible to define a workflow also using a FlowChart. A FlowChart can be embedded in sequences like any other activity in order to modify the flow there based on the status of variables and parameters. The following figure shows an example of how a FlowChart workflow of this type might look:
Data connection and data flow
Unlike WF3, in WF4 the data connection is no longer controlled via a DependencyProperty since this entailed serious performance losses when reading or setting a property and was intended more for flexible connection to a user interface. Besides better performance, the goal was to obtain a clear distinction between data that are passed to the activity and data that are needed within an activity for processing.
WF4 has an activity that allows parallel execution within the workflow. As a result, processing that lasts longer because it needs a response from a server, for example, no longer blocks the workflow scheduler.
Execution always requires a host on which the workflow runtime runs and the developed workflows are executed. The host is responsible for the persistence of a workflow, e.g. if it executes over several days or is interrupted.
However, server applications are not the only potential hosts. Depending on the purpose, a local application (e.g. Windows Forms or WPF) can also be used for hosting.
There are basically three ways of executing workflows:
- The WorkflowInvoker, which calls and processes the workflow like a method (synchronous).
- The WorkflowApplication, which executes a single instance of a specific workflow. This means that the calling application does not pause during processing of the workflow (asynchronous).
- The WorkflowServiceHost, which executes the workflow as a WCF service and is designed for service-based operation.
Custom Activity Library: User-created activities
Base Activity Library: The predefined components
In WF, every component is an activity, while the workflow itself is also an activity and contains a number of activities. Activities are described in XAML, or the code that is generated by the designer is saved as XAML.
Certain activities that are provided by the framework (e.g. WriteLine) can be executed with additional logic, but currently only VB expressions are supported.
The Runtime Engine is responsible for executing workflows. If a workflow must pause, the Runtime Engine saves the current status of the workflow and then reactivates it after a certain time interval or in case it receives another message. Predefined states are available such as "started", "stopped" and "faulty". However, the user can also define additional states and record them. The Runtime Engine is the external communications interface for the workflows.
4. Creation of workflows
In order to offer a workflow as a service, a connection service must be started in addition to the actual workflow service since otherwise no other computer will be able to use the service. As mentioned above, the Windows Communication Foundation (WCF) is available for this task. In the previous versions, it was necessary to deal with the connection specifications and service interfaces oneself, while in the current version they can be directly generated from the designer. However, in order to be able to better understand the underlying technology, we will now examine the WCF configuration and the workflow call.
A simple function that inserts a document into a database if the document signature is correct will be used as an example.
For the WCF part, a new project of the type WCF Service Application is created. Then, it is necessary to define what will actually be offered as a service. For this purpose, a ServiceContract is defined with the methods that can be invoked later. They are marked with the OperationContract attribute.
Test class to verify the RSA hash:
For the actual workflow, a project of the type Activity Library is created. This library type is more or less like a normal Class Library. However, instead of writing the logic in the usual manner into a .cs or .vb file, a graphical editor is used with an XAML file.
Now, we can begin using the designer to define our workflow. The individual elements are inserted into the workflow by way of Drag&Drop :
In the XAML file, there is then the following declaration :
Here, Activity defines the workflow with the x:Class attribute (reminder: workflows in WF4 are treated as activities) and the Sequence element that we inserted.
The InvokeMethod activity is used to invoke a method in an external class. It is then passed the class type as well as the method name and the parameter list (in the Properties). For storage in the database, there is the Persist activity, which must also be configured using the Properties. The Assign activity can be used to assign values to variables and parameters.
It is still necessary to define parameters so that data (e.g. the document) can be passed to the whole workflow and results can be received. This is also handled using the designer. A name, a type and a direction (In, Out, InOut) must be specified.
The WCF service instance must now implement the defined interface and call the appropriate workflow. It starts the workflow using a method that is defined in System.Activities. Accordingly, this library must be contained in the reference list for the WCF project.
The results from the workflow are returned via a dictionary of the type IDictionary[string,object]. The key is the parameter name that was previously defined in the workflow's parameter list. In our example, it is the argResult which contains the operation status.
In order to start the workflow as an application, the WorkflowApplication class is instantiated with the reference to the Workflow and then called with the Run method.
The new project type WCF Workflow Service Application can be used to create a WF/WCF combined solution. It independently generates the ServiceContracts in the background based on the method names that are used in the ReceiveAndSendReply activity.
This example clearly illustrates the extent to which WF4 has been simplified compared to the previous version: The programmer is now spared the entire programming effort required for communication between the two services (WF/WCF) and can concentrate on the business logic. In addition, the logic programming is handled to a great extent using the graphical part of the designer (as mentioned in the introduction), so that even developers without extensive knowledge of C# or VB can create their own workflows within a short time.
There are still many WF4-related topics that were not discussed or only touched upon very briefly such as tracking, interaction with databases, creation of one's own activities, etc. However, these topics are beyond the scope of this article, and the interested reader should consult other sources.
6. Resources / Bibliography
- MSDN documentation: http://msdn.microsoft.com/de-de/library/dd489441.aspx
- Webcast "Einführung in die Windows Workflow Foundation 4.0" [in German: "Introduction to Windows Workflow Foundation 4.0"]: http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=1032487426
- Bruce Bukovics: Pro WF: Windows Workflow in .NET 4.0, ISBN 1430227214
- Image source for figure on workflow configuration: http://msdn.microsoft.com/en-us/library/dd489465.aspx