Introduction
In a previous post I touched on Workflow Foundation (WF). I used it in the past to give power users the option of amending business rules in their applications without the need a developer.
Whilst investigating WF and trawling the web for examples, it seemed that not many people were using it “in the wild”.
With the advent of .NET Core, progress in terms of porting it to this new .NET platform has been slow.
That aside, it’s worth sharing my experience should you be thinking of using WF in your project.
Why use it?
In essence, it gives you the ability to model process flows using a visual designer that’s more akin to how humans think about such things. It looks good and the drag and drop interface is simple to use.
Using the designer, you select Activities from the Toolbox and drop them onto the designer canvas then snap them together to form end to end processes.
As you create your workflow you supply Conditions and Expressions to these Activities to form the business rules that your need. If you need to make a change to a particular rule, simply select the Activity in the designer and amend the relevant property. It doesn’t require much coding knowledge.
What can I build?
You can build 3 types of Workflow:
- Sequential
- Flowchart
- State Machine
More on these types in another blog post but know that regardless of the type, you still use Activities whether they be out of the box (Primitive) or Custom Activities, i.e. custom .NET code that inherits from the class CodeActivity.
How do I pass data in and out of my workflow?
When implementing a Workflow Service, you define a number of Data Contracts that describe the data it sends and receives. These are messages that represent the objects your application deals with.
The workflow service also exposes metadata (in the form of WSDL) in order to describe the operations of the service that you can invoke.
Web Application Integration
The workflows I had to build were going to be integrated with a service oriented application that implemented WCF. Workflow for Services was perfect for this as it offered seamless integration between Workflow and WCF.
The Workflow Services get exposed as WCF Endpoints that can be consumed by client applications or in my case, the ASP.NET web application. When you’ve built a Workflow Service, you generate the WCF proxy and the respective method will be created in your proxy class for clients to consume.
A benefit I found to using this was where there were user stories with defined inputs/outputs and complex data calculations. Team A could focus on UI elements, navigation, building components, and Team B (Workflow) could build back end data services that were responsible for crunching numbers and perform rule based calculations and returning outputs. These tasks could be done in parallel saving time.
Team A need to integrate the Workflow Service call at one point and that requires Team B advising which properties need to be passed into the Workflow Service to fetch the desired output.
Finally
This post was intended to give a brief overview of some initial concepts you’ll need to understand in order to implement Workflow Foundation in your application. In a future post I’ll talk through some of the specific types.
Have you used WF in any of your applications?
Leave a Reply