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
13
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? 
A few weeks ago we launched a new feature for one of our internal applications that leveraged Workflow Foundation extensively. When working through a new technology you will always find curve balls along the way. I like to call these shiny pennies and rusty washers. For example, something may seem like a shiny penny when you first see it in a demo. After much consideration of weighing the features vs the learning curve of the new technology you decide to use it a production environment. Once something goes into production the game changes. This is the point where you are going to be held accountable by the business or your client for the technology you chose to use. This is the point where you have to go deep with the new technology because you have to support it once the “copy to production” button is pressed. It is during this phase you find some of those shiny pennies are actually rusty washers. 
You will always find rusty washers when you work through a new technology. There are even some recent examples of this I ran across in blog posts. For example 
