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
Rehosting the Workflow Designer is quite simple and straightforward to do, as I have shown in a previous post. The demo project that I have open-sourced on github is a good place to start.
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.
Workflow Types
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
Overview of the WF technology:
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
Workflow Manager
Workflow Manager is a very heavy component of Workflow Foundation and a core layer of Sharepoint.
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.
Persistency
A key feature for long running workflows, Persistency is available out of the box in WF, as long as you decide to use the available Data Stores, WorkflowIdentity and persistency activities.
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 and 4.8.x
- mostly bug fixes; e.g. see .net 4.8 WF release notes
.Net 5 (core)
- WF will not be part of it
- CoreWF is an open-source effort to port Workflow to .Net Core
* Reference Links
- Windows Workflow Foundation and .Net Core
- 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):
Hello There,
Very cool to see your post come up when I was searching this topic!
Is the UiPath SDK supported anymore? I click the link on the homepage and it goes no where. I can’t find much information about it. Seems like there is an effort to hide it now. I think writing complex logic using UIPath Studio would result in a bloated mess. Writing even a simple loop with a few assign statements is comically bloated.
Appreciate your effort for making such useful blogs and helping the community.
Thank you,
Neha
Appreciate your effort for making such useful blogs and helping the community. It really had me stumped. Thanks for the explanation
Hi Andrei,
Thanks for this great post and nice to see that WF is not dead as stated in various places! We still use it actively and have achieved really cool things with it, not to mention that I truly enjoy its flexibility thought I wish MS would invest more in terms of improving it. It’s been a long time since something new has been added.
Anyway, I’m currently facing a problem (ScheduledAction not being triggered) and I’m not sure this is the place to post it and posting it on StackOverflow doesn’t seem to be very helpful these days when it comes down to WF.
May I post it here or do you have an email I can send you detail to? I’d love to get some feedback on whether or not this can be achieved. So far, everything I’ve read is not looking good but I’m hoping that you might have a work-around for it or maybe let me know that I’m going about it the wrong way.
Hi Andrei,
thanks for your summary about Workflow Foundation 4.x, I really enjoyed your experience reading throught the post and I am happy we’re not alone! 🙂 Please read my blog posts to see what we’ve done.
We’re still actively developing our BPM solution on top of it and we’re quite happy about advanced features such as peristence, compensation, versioning, tracking, extensibility and so on…
However we’re being asked many and many times to provide a web experience for the designer which seems to be a really big deal. I am not thinking about clik-onceing the application through. I am thinking about a full-fledged HTML5 state-of-the-art designer.
I am unsure about what MS wants to do about that but maybe they will be providing on something on the .NET Core platform about that in the future extending the great project UIPath’s folks started to work on.
Considering that designing a complex process is not an everyday task for anyone, this is not a major showstopper for now, … but since WPF sounds to be “deprecated” in the next years I am trying to find the best way to resolve this issue.
What’s your opinion about that?
Thank you
Hi Adriano,
I am glad that you found the article useful – I’ve seen on your blog that you did quite a lot of WF work yourself. I have added a few ideas regarding Workflow Foundation and .Net Core in a new article at https://andreioros.com/blog/windows-workflow-foundation-net-core/
For your particular business case:
– I would gradually migrate the runtime to CoreWF – for BPM you probably don’t have very complex activities tightly coupled with Windows dependencies
– the current rehosted designer is unlikely to resurface in .net core any time soon (at least not with .net core 3x)
– at the moment, the focus of the UiPath sponsored open-source CoreWF project is on the runtime / WF engine, but in the future the scope could be extended to also include a WF web designer – see https://github.com/UiPath/corewf/issues/58#issuecomment-516088754
Hello Andrei,
We have a very big WWF implementation and till date it was hosted on AppFabric Server 1.1 in Windows Server 2008 R2. As we know that both AppFabric 1.1 and Windows Server 2008 R2 has reached it’s life term and we are looking to migrate to Windows Server 2019. What could be our best bet for hosting WF services?
Please advise.
AppFabric Server 1.1 extended support ends on 4/12/2022.. meanwhile you could look into Redis on Windows for an on-premises deployment, or at Azure Cache for Redis for a cloud one. Also, ScaleOut StateServer looks very interesting.
Thanks Andrei,
Regards,