Part 2: Leveraging Workflow Foundation – Invest in Your Workflow Infrastructure
Posted by Keith Elder | Posted in .Net, Web Services, Workflow Foundation | Posted on 28-05-2007
In Part 1 of Leveraging Workflow Foundation we discussed how Workflow Foundation is just an API. Since APIs don’t provide business value out of the box, it is important engineers exploring Workflow Foundation for the first time approach it in the same manner they would any API: write once, run everywhere. In other words, instead of building out the workflow components for one application, look at it from the 10,000 feet view. This is of course going to take more time than one might originally think so be sure to allow for this in development time. We’ll look at the basics engineers starting with Workflow Foundation will need to think about to invest in their workflow infrastructure. Who knows, we may even find some rusty washers and shinny pennies along the way.
Think about workflow from a central service for your business not just within one application. Think about workflow outside of the box. Think about reusability. Think about a central rules engine.
While this will not be a comprehensive guide on how to build out one’s infrastructure with Workflow Foundation, I do want to point out several entry points everyone should consider. The idea is to invest time in Workflow Foundation just as one might in invest other areas of .Net like Asp.Net for example. I use Asp.Net as an example because most engineers that build Asp.Net web sites have some type of reusable framework they can apply to other web sites they build. If the same principal is applied to Workflow Foundation and done correctly, it could pay off huge dividends for a business.
The Big Picture From a 10,000 Feet View
We understand we need to invest in our workflow infrastructure. What are the things we need to spend our time on to make Workflow Foundation more reusable across our teams? Let’s first look at our goal. Our goal is to build out a core workflow infrastructure that can be reused among various projects, teams, and applications.
Now that our goal is set, here are the things we need to focus on to make this a reality:
- Provide a central location where workflows can be stored.
- Provide a central location where rules can be stored.
- Provide a central service where workflows can be invoked.
- Provide a central service and API where rulesets can be manipulated and invoked against workflows or instances of any object.
- Provide a custom user interface to easily create, modify, update, track and manage existing workflows and rules. Also this should have the ability to deploy workflows and rules to different environments (test, beta, prod).
As we see there is A LOT that needs to be done to build out a reusable infrastructure. Let’s start with the first two items above since these are relatively easy to accomplish. The reason I used the words “easy to accomplish” is because workflows and rules associated with workflows can be expressed in XML. Once we persist our workflow to XML, which is called XOML, it becomes trivial to store the XOML in a database. Rules associated with workflows are already created in XML and this makes it easy to store these. The harder one to deal with is the workflow though. More on that later.
When we create our database structures to store workflows and rules XML it is important we do not build our tables in a way where rules are always tied to a workflow. In other words don’t build a single table. Workflows and rules should be stored separately and by doing so gives us some nice reusability with the rules engine as we’ll see later on. Remember we are trying to create not only a reusable workflow infrastructure but a reusable rules engine as well. Now that we understand workflows and rules can be stored in a database let’s look at how this will be accomplished.
Storing XOML Workflows in the Database
As mentioned earlier we can express our workflows in XML. At the time of this writing Visual Studio supports two types of workflows. A code behind workflow and a XOML workflow. It is the XOML workflow type that we are interested in. Since the XOML workflow is essentially XML, we can easily store it into a database.
To persist workflows we need to first create our workflows as XOML based workflows. With a little bit of code we could persist the XOML into a database. The next question is how do we instantiate workflows from XOML. The answer is easy but it is a matter of knowing where to look. To create an instance of a XOML workflow we have to dig a little deeper into the APIs but not too far. The method we are going to look at is CreateWorkflow(). CreateWorkflow() has six overrides and it is the sixth override that provides us the entry point we need not only for workflows but also to pass in rules our workflow would use. Here is the syntax of it:
public WorkflowInstance CreateWorkflow (
XmlReader workflowDefinitionReader,
XmlReader rulesReader,
Dictionary<string,Object> namedArgumentValues
)
The reason this override method in particular is interesting is it allows us to pass in all the arguments we need to kickoff our workflow including our XOML, our rules and any parameters the workflow needs.
When you first add a workflow object to your solution, but sure to select the one that is XOML based, here is a screen shot from Visual Studio.
Assuming an interface is built to manipulate workflows outside of Visual Studio, using the XOML based workflow will allow us to adjust the workflows in real time without having to recompile assemblies and redeploy them (assuming the code behind doesn’t need modified). Be sure to download the workflow samples available as it contains examples of how to rune workflows with XOML. The main thing missing from Visual Studio though are tools to assist in running and deploying XOML based workflow definitions so plan on devoting a lot of time to this area as the documentation and tools available are slim. Keep your eye on the prize though!
Just for the record, here is a sample hello world XOML workflow to give you an idea what the XOML looks like:
<SequentialWorkflowActivity x:Class=“WorkflowLibrary1.Workflow2“ x:Name=“Workflow2“ xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml“ xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/workflow“>
<CodeActivity x:Name=“codeActivity1“ ExecuteCode=“codeActivity1_ExecuteCode“ />
<CodeActivity x:Name=“codeActivity2“ ExecuteCode=“codeActivity2_ExecuteCode“ />
</SequentialWorkflowActivity>
The first code activity prints “Hello” and the second prints “World”. Since we’ve expressed this in XML we could easily manipulate the workflow to print “World” then “Hello” simply by moving the codeActivity2 above codeActivity1. We could do this without needing to redeploy any code.
The hard part of this is tying the ability to persist XOML workflows with the big picture item number five. Storing our XOML in a database doesn’t necessarily make us agile from a business standpoint, it is the interface the end users (business analyst or other engineers) interact with and the central workflow services we expose that is going to make us more agile. This is where the majority of your time is going to be spent. There is good news in that there are numerous samples floating around on the Internet to give you a better idea. Be sure to checkout the samples here. You are also going to have to devote a fair amount of time to the ComponentModel to create the desired UI experience to load a workflow from XOML, alter it, and then persist it back.
As we discussed in part 1 there are rusty washers and this is one of them. While we can off load workflows to the database we will find there aren’t many tools to assist us in doing so and the art of doing this will seem kludgy and an after thought at best. I personally spent several hours trying to get workflows to reliably load from the file system and couldn’t. I’m sure it was something simple I wasn’t doing but the whole process was very inelegant. Hopefully the Workflow Team will beef up their tool offerings in the next version of Visual Studio to make this more trivial. Because of the lack of time to devote to this our team decided we would revisit it at a later date when we had more time.
Storing Workflow Rules in the Database
We’ve looked at storing workflows so let’s move onto storing rules in the database. The rules engine aspect of Workflow Foundation turned out to be a shiny penny and one that isn’t talked about much. #2 and #4 of our big picture items is off loading rules to the database and then creating a central service where rules can be invoked.
When we add a “policy” activity to a workflow we can associate one or more rules to it. Once a rule is defined we can also re-use it within the workflow. That’s great, but what if we want to reuse the same rules again in a different workflow? This is one reason why we want to off load these rules into a separate location. When rules are created within Visual Studio by default they are stored in a hidden file called .rules. The nice thing about the rules is they are already written in XML. Here is a screen shot so you can see how this appears from Visual Studio.
This is also where the second parameter of CreateWorkflow() override number six comes into play. We can easily offload the rules we’ve created into another database table or set of tables and then pass those into the workflow at runtime. Not only can we leverage the built in rule APIs within Workflow Foundation for workflows we can also utilize this for validating instances of objects that could then be used across multiple applications. During my exploration, once this light bulb went on I realized that I could really save my team a lot of time. I started down the path of building out a tool that could not only serve the purpose of storing rules for workflows but also a tool that could be called via a service from any application. I call the tool “Orbb”.
Orbb – Object Rules Business Builder
According to our goals as outlined above, we knew we wanted to store rules in a database and then expose functionality via a service. To make ourselves more agile we need an interface to manipulate these rules. During my exploration of the rules engine that ships with Workflow Foundation it became apparent that rules can be run against ANY INSTANCE OF ANY OBJECT. This is powerful because it means we aren’t tied to XML like Biztalk for example. For example we could have a Winform instance that needs to have rules performed against it, or maybe an Asp.Net web page, or may a simple business entity like a purchase order. As long as it is an “instance” we can leverage the rules engine that ships with Workflow Foundation.
Once this light bulb went off, a few hours later I had a database, WCF service and a user interface to build, manage and centrally store rules for a variety of applications. Orbb was then born. Today Orbb is just a proof of concept but the value it could provide is unquestionable. It is in a very infant stage right now and may never see the light of day but it is far enough along I can share a screen shot with you here. Here is a screen shot:
The idea is fairly simple. An application is created within Orbb and then permissions are setup (who can edit / change rules for each application) along with the various environments you need to test your rules (test, beta, prod). Those that are granted access can then use Orbb to manage not just one application but multiple applications. Imagine one central service where rules could be stored, validated and retrieved.
For example, imagine you have a smart client where users can create a new helpdesk ticket. The business informs you that users aren’t entering enough information in the “what is wrong” textbox and they want you to force them to enter at least 150 characters. Instead of having to add this rule to your code by hand and re-push it, you could simply launch Orbb, select the form and add the new rule to the form. Then copy the new ruleset to your test, beta and prod environments without having to redeploy your application.
This type of flexibility could also be applied to workflows whereby rules change. Being able to adjust your workflow rules without having to redeploy is definitely worth an investment. One of the things that came out of Orbb as I worked through it was a generic class that takes any Object and retrieves the rules from a database and then validates the object using the rules. You could utilize this in a service, Winforms, Asp.Net pages, business objects and more. I have provided a copy of this below in the “Validating Any Object with Workflow Rules Engine” section.
Conclusion
As you can see there is quite a bit of work that can be done to leverage Workflow Foundation and your mileage will vary in regards to your time / benefit ratio. In the end it will pay in huge dividends if an investment is done up front, not as an after thought. In part 3 of Leveraging Workflow Foundation we’ll look at hosting the workflow runtime. Will we find any rusty washers? Stay tuned!
Validating Any Object With Workflow Rules Engine
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Practices.EnterpriseLibrary.Data;
using System.Data.Common;
using System.IO;
using System.Xml;
using System.Workflow.Activities.Rules;
using System.Workflow.ComponentModel.Serialization;
using System.Workflow.ComponentModel.Compiler;
namespace Orbb.BusinesLayer
{
/// <summary>
/// This is a generic class that will take any object and process rules
/// against that object that are defined in a database.
/// </summary>
public class ObjectValidation
{
private object entity;
/// <summary>
/// The object that needs to be validated.
/// </summary>
public object Entity
{
get { return entity; }
set { entity = value; }
}
private string ruleSetName;
/// <summary>
/// Name of the RuleSet that is in the database we need
/// to use.
/// </summary>
public string RuleSetName
{
get { return ruleSetName; }
set { ruleSetName = value; }
}
private System.Workflow.Activities.Rules.RuleSet ruleSet;
/// <summary>
/// Deserialized RuleSet object which contains all the rules.
/// </summary>
public System.Workflow.Activities.Rules.RuleSet RuleSet
{
get { return ruleSet; }
set { ruleSet = value; }
}
private RuleValidation ruleValidation;
public RuleValidation RuleValidation
{
get { return ruleValidation; }
set { ruleValidation = value; }
}
private WorkflowMarkupSerializer serializer = new WorkflowMarkupSerializer();
/// <summary>
/// Provides the extensible Application Markup Language (XAML) serialization services
/// to workflow at design time.
/// </summary>
public WorkflowMarkupSerializer Serializer
{
get { return serializer; }
set { serializer = value; }
}
private System.Workflow.Activities.Rules.RuleExecution ruleExecution;
/// <summary>
/// Stores state information while executing RuleCondition or RuleAction classes.
/// </summary>
public System.Workflow.Activities.Rules.RuleExecution RuleExecution
{
get { return ruleExecution; }
set { ruleExecution = value; }
}
public ObjectValidation(Object entity, string ruleSetName)
{
this.Entity = entity;
this.RuleSetName = ruleSetName;
// Get the rule from the database
this.GetRuleFromDatabase();
}
/// <summary>
/// Gets the rule from the database as specified.
/// </summary>
private void GetRuleFromDatabase()
{
Database db = DatabaseFactory.CreateDatabase(“OrbbConnectionString”);
using (DbCommand cmd = db.GetSqlStringCommand(“select RuleSet from Rules where Name=@Name”))
{
db.AddInParameter(cmd, “Name”, System.Data.DbType.String, this.RuleSetName);
string ruleSet = (string)db.ExecuteScalar(cmd);
this.DeserializeRuleSet(ruleSet);
}
this.ValidateRuleSet();
}
/// <summary>
/// Deserializes a ruleset from the database into a RuleSet object.
/// </summary>
/// <param name=”ruleSetXmlDefinition”></param>
private void DeserializeRuleSet(string ruleSetXmlDefinition)
{
if (!String.IsNullOrEmpty(ruleSetXmlDefinition))
{
StringReader stringReader = new StringReader(ruleSetXmlDefinition);
XmlTextReader reader = new XmlTextReader(stringReader);
this.RuleSet = Serializer.Deserialize(reader) as RuleSet;
}
}
/// <summary>
/// Executes the rule set on the given entity.
/// </summary>
public bool ExecuteRule()
{
if (null != ruleExecution)
{
try
{
ruleSet.Execute(ruleExecution);
}
catch
{
throw;
}
return true;
}
else
{
return false;
}
}
/// <summary>
/// Validates that the entity being processed contains the properties
/// defined in the ruleset.
/// </summary>
private void ValidateRuleSet()
{
ruleValidation = new RuleValidation(this.entity.GetType(), null);
if ((null != ruleValidation) && (!ruleSet.Validate(ruleValidation)))
{
string errors = “”;
foreach (ValidationError validationError in ruleValidation.Errors)
{
errors = errors + validationError.ErrorText + “\n”;
}
throw new Exception(errors);
}
else
{
ruleExecution = new RuleExecution(ruleValidation, this.entity);
}
}
}
}
Like this article? 
At SplendidCRM, we are using XAML-only workflows and we store the workflows in the database. We actually went one step further by writing our own persistence and tracking providers. We have yet to take advantage of the rules engine, but we may some day do that as well.
@Alpesh
That’s not that hard, you read the xoml contents into a string variable and then write a SQL query to insert it into a database table.
I want a code for Store a .xoml file in Database.
Please help me
The XOML is just your execution path. Your code for that activity is pulled from wherever the instance of your app is running from. Thus, it will be loaded from the /bin or, you could load it from the GAC if you need to keep track of different versions, or you could store your DLL in a database that is versioned with your XOML and then load it from there (which is what vendors like K2 do).
-Keith
Thanks for sharing Keith. Although I have a question. In your example you have two CodeActivities with associated events. Even when it’s simple to store the XOML in a database, how do i store the “code behind” ? I mean, the code for “codeActivity1_ExecuteCode” is not saved in the XOML file…
Thanks for the example. I was banging my head against the RuleExecution constructor. I kept thinking it was an error with the ITypeProvider argument, which I was loath to try and implement on my own. Turned out it was the RuleValidation object that needed instantiating.
Thanks a lot.
But its still not working, dont know why!
the changes made are just not getting saved!
You would do something like this (just reverse the DeSerialization() ):
One of my friends, Mel, has a sample of this on his blog here. He’s taken this concept after several of our conversations and implemented it.
http://melgrubb.spaces.live.com/blog/cns!A44BB98A805C8996!182.entry?wa=wsignin1.0
i’ve a similar windows form application where i am calling this rules set editor in dialog box. i want to edit & create new rules using this & also save this to database.
i am successful in retrieving the ruleset from database & displaying it in rule set editor. but i am not able to save changes made to this rule set using editor.
how to save to SQL database?
Thanks. It helps me so much. Can I have these code files?.
Thanks Nadine, glad you liked the practical approach.
This is great stuff! You’ve gone deeper into the practical aspects of using WF than anybody else I’ve seen so far.
Thanks for sharing what you’ve learned thus far.
You’ve been kicked (a good thing) – Trackback from DotNetKicks.com