Windows Workflow Foundation is a mature technology from the .Net Framework (full) which empowers developers to build enterprise grade workflow based products and solutions. It is easy to get started with, if offers a lot of features out of the box and it powers some of Microsoft’s key projects (Sharepoint, Azure Powershell Workflow Runbooks).
Windows Workflow Foundation and .Net Core
The porting of Workflow Foundation to .Net Core was one of the most discussed issues on the .net corefx github repository (160 comments), but Microsoft still decided against going forward with the project for the moment; it is possible that in the future, if more companies adopt Nano servers, the business case will get stronger and the decision will be revised.
However the WF Runtime and ETW tracking provider were ported unofficially at the CoreWF github repository by the PM leading the WF development at Microsoft, Dustin Metzgar, making the project a community effort. In its current state, it is far from replacing the full featured WF, but it is a solid starting point.
CoreWF enables new workflow foundation scenarios on Unix / Linux and it remains the only viable cross platform WF alternative after the Mono Olive WF effort was stopped.
The Future of Workflow Foundation
The main focus of the WF development today is on the Workflow Manager. The next .Net version will also include some accessibility items for the WF Designer.
As far as support goes, Windows Workflow Foundation is not going anywhere, Microsoft has a lot of vested interest in it:
- the WF technology is at the core of SharePoint 2016 for which Microsoft offers extended support until August 2026
- WF is also used in Azure Powershell Workflow Runbooks
- TFS 2010-2013 used WF for XAML builds (for automation purposes)
As Microsoft invests a lot of resources & innovation in the direction of .Net Core, it is important to emphasize that the classic full .Net Framework (and implicitly WF) is not going anywhere, it is continuously being developed and supported.
Business Cases – Who Uses Workflow Foundation ?
Windows Workflow Foundation is a .NET technology for defining, designing, hosting & running processes as Workflows. A few WF samples are available from Microsoft on the WF documentation page; examples from the doc: Document Approval, Hiring Process, Corporate Purchase.
Besides Microsoft (SharePoint), there are many companies in the industry that have successfully integrated WF at the core of their products. A few examples:
- Flowster Studio – focused on IT operations, processes automation
- UIpath – robotic process automation
- Insurance technology
Workflow Foundation Rehosted Designer
The WF designer offers a lot of features out of the box and on top of that it is easy to extend; that is why many companies have integrated it in their products and solutions.
There are 3 workflow types and you can use them according to your business case / process logic requirements; they can also be used together if needed, in a mixed mode (WF / Activities grouping is possible):
- Sequential Workflow (simple, linear logic)
- Flowchart Workflow (very intuitive, flow chart diagram logic)
- State Machine Workflow (powerful, state transitions, events, triggers)
Workflow Building – Authorship
Workflows can be created visually, programmatically and via powershell scripting:
The serialization is done with Xaml and it makes Workflows very flexible:
At the same time, the strong WF dependency on Xaml is one of the main impediments for porting Workflow Foundation to .Net Core.
Workflow Foundation Activities and Activity Libraries
WF offers out of the box a Built-In Activity Libraries (Control flow, state machine, flowchart, messaging, collection and error handling, powershell, etc) – see the Rehosted Workflow Designer example project for how to load and use them.
The number and type of use-cases which can be addressed with Workflows can be greatly extended with the help of Custom Activities: you can develop your own libraries and wrap existing APIs from 3rd party vendors for integration with WF workflows.
Windows Workflow Foundation Architecture
Runtime and Hosting
There are 3 options for hosting & running workflows, each suitable for a different use-case:
WorkflowInvoker (doc & samples)
- great for simple scenarios and short lived workflows
- doesn’t provide hosting, bookmarks, instance control, persistence
WorkflowApplication (doc & samples)
- single WF instance (loading / unloading WFs possible), good choice for long running workflows
- provides hosting, bookmarks, instance control, persistence
WorkflowServices (doc & samples)
- multiple instances, good for service oriented solutions
- provides hosting (WorkflowServiceHost), service messaging, bookmarks, instance control, persistence
It can be adopted in custom solutions, just like the Rehosted Workflow Designer, and it offers a lot of value out of the box: REST Endpoint & Client API, Multi-tenancy (Scopes) & Scaling, Management (DB Stores), Tracking and Monitoring, Instance Management, Fully Declarative Authoring.
However, the deployment is not lite (might not be a major issue for Saas, but it is when deploying with custom installers) and it enforces on the solution its implementation of versioning, instances, data stores.
Custom Tracking Participant
Workflow Foundation offers a high level of transparency regarding both the process logic and its execution. Custom Tracking Participants are easy to implement and adapt to your specific use-case. The Track method is called whenever the workflow emits a TrackingRecord containing WF execution data (logs, insights).
The standard EtwTrackingParticipant model is a good starting point for implementing workflow tracking.
Besides enabling new scenarios, the feature also helps with resources scaling vertically when you have a workflow as a service model and you execute many workflows in parallel on the same server / vm: the WF state will be removed from memory until a next step / trigger restores it from the persistency data store and resumes its execution.
The Evolution of Workflow Foundation
WF was introduced in 2006 with .Net Framework version 3.0 and Visual Studio offered support for it. It was also integrated with BizTalk Server 2006 R2 via BAM Interceptors and Extensions (btsSend, btsReceive).
Afterwards, from as early as 2007, the development of WF was mostly aligned with the Microsoft Sharepoint roadmap:
Workflow Foundation 4 was a major milestone for the technology: it was a major redesign / fork which departed from the old WF3:
- limited compatibility between the versions is available via Interop activity
- the transition process to WF4 is documented in a migration guide
However, the WF4 effort was considered necessary and justified because of the very big performance improvements.
Workflow Foundation 4 timeline
.Net Framework 4.0
- Re-Architecture of Core Model, Runtime, Hosting, Integration, Tooling
- Great Performance improvements
- Designer rehosting made easier
- Limited Compatibility with WF 3x (Interop)
.Net Framework 4.5
- Designer improvements: Usability (designing, navigation), Annotations (activities, vars, args), C# expressions support
- New Activities
- State Machine
- Workflow Services
- Versioning (Workflow Identity, Dynamic Update)
.Net Framework 4.6.x
- C# expressions and IntelliSense in the Re-hosted WF Designer
- Transactions improvements
- small update – resume timeout interval for non-protocol bookmarks
.Net Framework 4.7.x
- mostly bug fixes
* Reference Links
- Windows Workflow Foundation
- WF runtime ported to work on .NET Core
- Rehosting the Workflow Designer
- WF 4 Code Samples download
- Powershell Workflows & Azure Automation
- What’s new in WF 4.5
- A Developer’s Introduction to WWF
- Workflow Manager
- My Windows Workflow Foundation Demystified presentation at CodeCamp Timisoara (available on slideshare and also embedded below):