My blog stats show trending topics around searches for “wf4 rule engine” and “wf rule engine” and “wf rules” among other variations. If those topics are leading people to this blog, then I might as well address the topic directly.
What Is WF?
For those who don’t know what the queries above mean – it means that people are searching for the rule engine feature (named Windows Workflow Foundation Rules Engine aka “WF Rules”) in Microsoft’s Windows Workflow Foundation (aka WF). The feature originally shipped with .NET 3.0, and I have written previously about the feature set especially as it compares to Microsoft’s other rules offering.
Changes To WF
With .NET 4.0, the Workflow Foundation is introducing a new workflow model (more details here) – so we now talk about the workflow model in .NET 3.0/3.5 as “WF3” and the new workflow model in .NET 4.0 as “WF4”. However, as mentioned at that link, all of WF3 is still available in .NET 4.0. (Note: the assemblies ship in the ‘Extended’ .NET 4.0 install and not the ‘Client’ .NET 4.0 install.)
Rules Integrated With WF4
WF4 does not include a new forward chaining rules engine that is closely integrated with the WF4 activity model (that does not preclude one being made available in the future). Again, to be very clear, the existing WF Rules features are still available in .NET 4.0 and may be used within WF4. Put another way, there is still a forward chaining rules engine in .NET – it has not gone away. A direct statement from Microsoft on the topic can be seen on the .NET Endpoint blog as follows:
“Two other major WF 4 activities that were discussed at PDC, a new state machine activity and a new forward chaining ruleset activity, will not be available with the VS2010 beta 1 release – and we will cover each of these topics in greater depth in the next month. At this point, a new forward chaining rules engine won’t be ready for the .NET 4 timeframe, and will probably see a CTP release post-VS2010 to gather feedback and to allow customers the opportunity to evaluate the direction we are considering. It’s important to note that we are working to ensure integration with the WF 3 rules engine will be possible in a number of ways, though; one example of integration back to the WF 3 rules engine is the SDK sample activity I mentioned above.”
WF3 -> WF4 Migration
There is also now some rules-specific migration guidance published here as part of some overall WF3->WF4 migration guidance. See also the WF Migration Kit CTP 1 that I posted about previously. Questions about using the WF3 rules with WF4 should most likely be addressed via the forums.
Tell Microsoft What Rules Features You Would Like To See For .NET
Finally, if you have interest in rules on the .NET platform and are willing to provide feedback to Microsoft – I encourage you to do so. In fact, it would be great if you could be as concrete as possible about your feature needs. The inclusion of a feature often depends on customer feedback. Here are some examples of feedback that you could provide to Microsoft:
- If using the existing WF Rules feature with WF4 via the Interop activity satisfies your technical needs and why or why not.
- If you would like to see WF Rules more fully integrated with the WF4 programming model, or not.
- If you use or would like to use rules in applications apart from WF.
- Specific feature feedback about WF and/or MS BRE.
- If your needs skew more towards the runtime rule engine or BRMS tools.
Specific feature requests for the future should be provided through Connect (detailed instructions for providing feedback about WF4 through Connect).
Also, if you are interested in discussing your rules scenarios and requirements in more detail with someone from Microsoft, you can contact me via the contact form on this blog, or email me at my firstname.lastname at my employer’s domain.com.
Hi Karl,
My problem is that i am not able to decide whether i require forward chaining or will sequential rules will be fine for me.
I am in process of designing an application for which i am thinking of whether to wf 4.0 or wf3.5.
Problem arises from the fact that wf4.0 does not support forward chaining.
My problem is that i am not sure whether my requirements require forward chaining or not.I read articles about difference between forward chaining and sequential rules but couldn’t understand.
It would be of great help for me if you can help me by giving some examples of sequential and forward chaining rules and how these affect the final outcome(action) of ruleset(if ruleset exists in wf4.0??).
Thanks in advance
Cheers
rajiv
Rajiv –
Thanks for your comment.
As my posting describes, the WF Rules features introduced in 3.0 are available in both 3.5 and 4.0, so you can leverage them from WF4 if so desired.
Again, the current WF Rules features are not integrated with WF4. That may or may not be an issue for you, depending on your architecture. Things to consider: will the rules be used in a stateless or stateful manner? Will the rules reason to a decision, or will they need to schedule workflow actions?
As for forward chaining or sequential, you need to look at your rule requirements and consider if you have rules that will need to execute more than once or cannot be explicitly ordered. Try putting your rules in an order and see if the logic will work correctly.
Keep in mind that sequential rules will often execute correctly under forward chaining (although potentially slower), but forward chaining rules will generally not execute correctly in a sequential mode..
You may also find that some of your rules will work sequentially and that other rules may require forward chaining. It is OK to execute some rules in one mode and other rules in a different mode.
I do get this question on a regular basis and will consider it for a future blog posting.
You mentioned”if you have rules that will need to execute more than once or cannot be explicitly ordered”
i don’t have any rules which are required to be executed more than once or not need to be explicitly ordered.
I am needing a rule engine based workflow application in which
1) Rules inside a ruleset can inherently other rules explicitly
2) One rule can cancel previous rules explicitly which are waiting for user action
3)Two rules with different actions can be fired simultaneously and action will be taken on both as a result of a ruleset execution.
4) During execution of a flowchart workflow, at stage 1 suppose Rule A gets fired and action takes place based on that rule, then workflow moves to stage 2 and then it comes to stage 1 again and now again Rule A condition gets satisfied, then RuleA will not be fired as Rule A has already been fired once in that workflow.
As the ruleset size is huge, i am thinking of moving it to seperate file from workflow.
Please suggest the possible technology and solution
Cheers
Rajiv –
It sounds like you need an opportunity to discuss your business problem in more detail.
In particular, some clarification would be useful around your requirements for inheritance, cancellation and simultaneous firing. I’ll warn you up front that most rule engines (not just Microsoft’s) fire rules in a single-threaded manner one at a time.
Let’s take this offline to email. I will try to either help you myself or find you a contact who can help you.
Thanks.