Stephen Kaufman's WebLog : WF

AppFabric and BizTalk

skaufman — Tue, 24 Nov 2009 05:37:00 GMT

There have been lots of questions lately about AppFabric (code named Dublin). These questions have centered around why Microsoft needs another middle tier solution and will AppFabric replace BizTalk.

Lets take a look at these questions as well as two additional questions; What is AppFabric and why does Microsoft need another middle tier solution? First, AppFabric is a distributed application server. To answer the other questions, we need to go in a little more depth.

Before .NET was released, developers working with the Microsoft technologies used COM+ to host their middle tier objects. Back then, when we needed to scale out our object oriented and object based applications we created middle tier code libraries and ‘hosted’ them in COM+. The COM+ host provided instance management (just-in-time activation), role-based security, automated transaction management as well as better memory and processor management, distributed transactions and a number of other services.

When .NET was introduced, we moved away from COM components and also moved away from using COM+ as a hosting model. This left a vacuum that so far had gone unfilled.

In attempts to fill this vacuum, individual developers had to create their own hosts. These hosts typically were Windows Services. However, these services usually didn’t include multi threading, scale out capabilities, tracking, monitoring, etc. – the types of functionality that has been in BizTalk for years. As Microsoft looked at BizTalk, as well as the .NET Framework, it was determined that there are many great features in BizTalk that if a scaled down version was available it would address gaps in the framework. Thus AppFabric was born.

For .NET developers writing applications using WCF and WF, AppFabric will fill the middle tier hosting vacuum. AppFabric will provide the host and will provide scalability and support for building out your middle tier application components. It also will simplify deployment, configuration, management and scalability of composite applications. The goal of AppFabric is to provide a server infrastructure, on which business logic developed in WF can be executed and exposed via WCF endpoints, without the need to design, develop, and support the infrastructural code.

The next question I hear is will AppFabric replace BizTalk? The answer is very clearly no.

AppFabric should be used when your architecture calls for an application level code-first object based approach. This is the same approach that is used by WF and WCF programming models and is the one that can be hosted in AppFabric and the additional functionality that AppFabric provides. AppFabric will provide a number of management and scalability features through IIS and WAS to provide the server infrastructure without the need to write the plumbing as you did before. This is a different approach than that of the XML Schema first approach that is used in BizTalk.

Use BizTalk when your architecture calls for an enterprise level message based approach. Use BizTalk when you need to isolate disparate systems that need to be connected. In point-to-point integrations, changes made to the provider system can have a profound impact on the consuming application. BizTalk natively provides a hub-based integration model which eases this burden and allows organizations to provide business services that are isolated from the impact of changes made to the systems and processes on which these services are based. This is achieved through the use of separate schemas, and the associated ability to easily develop message transformation logic using BizTalk’s Mapper tool. Use BizTalk if you have business-to-business requirements and need to integrate using technologies such as EDI, SWIFT, RosettaNet, AS2 or HL7.

The reality is that businesses will utilize both of these technologies in their different application architectures. This is not an either or decision but instead a decision of where and when to use each.

Keep in mind, however, that many of the same terms are used to describe the functionality provided with both BizTalk and AppFabric. These terms are things like Content Based Routing, Correlation, long running transactions, etc. Although the terms are the same the implementation and functionality is different. With all decisions, make sure that you take a couple of minutes to look under the hood and ensure that you understand the differences.

Comparing the Workflow Rules Engine to the BizTalk Business Rules Engine

skaufman — Wed, 21 Mar 2007 07:18:00 GMT

Back in November I delivered a presentation to the Twin Cities BizTalk User Group titled 'Rule Engines: Workflow Rules vs. BizTalk Rules'.

Since then I have been working with the Rules Team in Redmond and with their input I have updated and added content to that presentation. Hopefully the presentation will help you when you get questions about how the Workflow Rules compare and relate to the BizTalk Rules Engine.

Using the WF rules to iterate over a collection

skaufman — Wed, 08 Nov 2006 23:59:00 GMT

I thought I understood how the WF Rules iterated over a collection. Isn't that always how it goes - you really prove it to yourself when you can explain it to someone else. Well, I started to explain how I thought it worked and this person started asking questions and I soon realized that I was no longer sure I understood it. After a bit of research and with my newly obtained understanding I tried to explain it again and it actually made sense.

So, I have decided to blog about this since I am sure that others will most likely need to do this and may even need to explain it to someone else.

During my research I found the MSDN article titled Introduction to the Windows Workflow Foundation Rules Engine which had a little blurb towards the bottom titled Collection Processing which I found to be a good start. I also found Matt Winkle's blog entry which had an example that he put on the Workflow Community Site. It was this example that really solidified it for me.

he had created 4 rules

Rule 1: Initialize with a priority of 2

IF
1==1
THEN
this.enumerator = this.OrderItems.GetEnumerator()

Rule 2: IterateOverItems with a priority of 1

IF
    this.enumerator.MoveNext()
THEN
    this.currentItem = (RulesWithCollectionSample.OrderItem)this.enumerator.Current
    System.Console.WriteLine("Assignednumerator" + this.currentItem.Price)
ELSE
    System.Cosole.WriteLine("we are all done")

Rule 3: IndividualItem with a priority of 0

IF
    this.CurrentItem != null
THEN
    this.Total = this.Total + this.CurrentItem.Price * this.CurrentItem.Quantity
    System.Console.WriteLine("Running Total: " + this.Total.ToString())
ELSE
    System.Console.WriteLine("current item is null")

Rule 4: Finished with a priority of -1

IF
    this.CurrentItem == this.CurrentItem
THEN
    System.Console.WriteLine("Finished True")
    Update("this/enumerator")
ELSE
    System.Console.WriteLine("Finished False")
    Update("this/enumerator")

In addition to these rules you also have to decorate your class with three additional properties.

First, create an enumerator property that is of type System.Collections.Generic.IEnumerator<T> or System.Collections.IEnumerator

Second, create an items collection to contain your collection of items which can be of type List<T> or anything that supports IEnumerator

Third, create a property to hold the current item

After looking at the rules and the properties I was ready to watch it run.

Rule 1 ran first, as it should since it has the highest priority and has a condition that always returns true. This rule populates the enumerator property backing store. Then the rules engine looks for the rule with next highest priority, which is Rule 2. This rule calls MoveNext on the enumerator and if it is able to move then true is returned and the THEN part of the rule runs which passes the current collection item to this.currentItem. If MoveNext return false then the text "we are all done" will be written to the Output Window which is the last item output after all of the items in the collection has been iterated over.

If the MoveNext method in Rule 2 returned true, then the rules engine again looks for the next rule with the highest priority, which is now Rule 3. Rule 3 checks to see if there is a Current Item and if so does some work (in this case updates the total). If the Current Item is null then we will get the text "current item is null" written to the Output Window. However, this line is never encountered when the rules run.

Finally the fourth rule is run, the condition can really be anything but it needs to be evaluated each time, which updates the engine telling it that we want to update the enumerator and force forward chaining behavior. By doing this we are saying that the engine should look for any rules that have conditions that are reliant on the enumerator. In this case, Rule 2 matches this and the engine loops to Rule 2 and continues to run through the rules based on priority from there. This will then set off a loop in the rules engine moving from Rule 4 back to Rule 2, then Rule 3 and Rule 4 until the MoveNext function in Rule 2 returns false (indicating it has no more items in the collection) and the ELSE portion of the rule runs. At this point the rules are finished processing and the control is returned back to the calling application.

Hopefully this helps explain what is required to iterate over a collection as well as what is happening during the iteration process.

Tracking Rules Execution in Windows Workflow

skaufman — Fri, 15 Sep 2006 19:36:00 GMT

In my previous blog entry on Tracking and the TrackingExtract functionality I talked about the ability to track the rules that fired. As part of this functionality I needed to capture the rules that fired as well as to capture an XML representation of the object state (this is where the TrackingExtract functionality came in) to the database so that reporting systems could look at the data. When I first started researching to find out if this functionality existed I came across a great tracking sample on Moustafa Ahmed's blog. This sample shows how you can use the standard tracking infrastructure to track the rules.

Unfortunately, the standard tracking functionality didn't do exactly what I was looking for. First, the data is written to the UserEvent table in the UserData_Blob field and shows up as 0x0001000000FFFFFFFF01000000000000000C020000005D53797374656D2E576F726B66......., which, represented the serialized object, but was somewhat unreadable. Next, I would need to deserialize this data and cast it to a RuleActionTrackingEvent type in order to work with it for reporting. And lastly, I wanted to store additional data that was not part of the UserEvent table.

So, I needed to augment the standard functionality with my functionality. I started by creating two new tables that would live in the tracking database. The first was the RulesTrackingData table and the second was the UserTrackingData table. They were defined as

CREATE TABLE [dbo].[RulesTrackingData](
    [id] [bigint] IDENTITY(1,1) NOT NULL,
    [ComputerName] [varchar](25) NOT NULL,
    [ActivityType] [varchar](50) NOT NULL,
    [InstanceID] [varchar](40) NOT NULL,
    [EventDateTime] [varchar](50) NOT NULL,
    [PolicyName] [varchar](50) NOT NULL,
    [RuleName] [varchar](40) NOT NULL,
    [ConditionResult] [varchar](10) NOT NULL,
    [TrackingRecord] [varchar](500) NOT NULL
)

and

CREATE TABLE [dbo].[UserTrackingData](
    [id] [bigint] IDENTITY(1,1) NOT NULL,
    [ComputerName] [varchar](25) NOT NULL,
    [ActivityType] [varchar](50) NOT NULL,
    [InstanceID] [varchar](40) NOT NULL,
    [EventDateTime] [varchar](50) NOT NULL,
    [TrackingRecord] [varchar](500) NOT NULL
)

The RulesTrackingData table will hold the tracking data for each rules that runs while the UserTrackingData will hold the state of the object after all of the rules have run.

After the database had been setup it was time to work on the code. I created a custom tracking service for the Workflow Runtime. As part of my RuleTrackingService I created a RuleTrackingChannel class which inherited from TrackingChannel and a RuleTrackingService class which inherited from TrackingService. To find out more about the RuleTrackingService take a look at my previous blog entry on Tracking and the TrackingExtract functionality. Right now we are just going to focus on the RuleTrackingChannel class since this is where we get to grab the tracking data and write it the way we want to the database.

So the code looked like this:

public class RuleTrackingChannel : TrackingChannel

{
............

public RuleTrackingChannel(........)
{
}
//This is what it all comes down to!
protected override void Send(TrackingRecord record)
{

    if (record is UserTrackingRecord)

{
DetermineTrackingRecordType((UserTrackingRecord)record);
}

}

private void DetermineTrackingRecordType(UserTrackingRecord userTrackingRecord)
{

    if (userTrackingRecord.UserData is RuleActionTrackingEvent)

{
WriteRuleTrackingRecord((RuleActionTrackingEvent)userTrackingRecord.UserData, userTrackingRecord);
}

    else

{
WriteUserTrackingRecord(userTrackingRecord);
}

}

// This method writes a record to the database for each rule that fires. This record represents the data before the rule fired.
private void WriteRuleTrackingRecord(RuleActionTrackingEvent ruleActionTrackingEvent, UserTrackingRecord userTrackingRecord)
{

string PropXml = string.Empty;
if (this._trackedProperties != null)

{
PropXml = CreateXmlFragment(userTrackingRecord, "RuleTrackingSnapshot");
}

//At some point we might want to change this to a stored proc
SqlCommand command = new SqlCommand();
command.Connection = new SqlConnection(_connectionString);
command.Connection.Open();
SqlDataAdapter adapter = new SqlDataAdapter();
StringBuilder commandString = new StringBuilder();

commandString.Append ("INSERT INTO TrackingStore..RulesTrackingData ");
commandString.Append("(ComputerName, ActivityType, InstanceID, EventDateTime, PolicyName, RuleName, ConditionResult, TrackingRecord)");
commandString.Append(String.Format("VALUES ('{0}','{1}','{2}','{3}','{4}','{5}','{6}','{7}')", System.Environment.MachineName, userTrackingRecord.ActivityType.FullName.ToString(), this._instanceID ,System.DateTime.Now, userTrackingRecord.QualifiedName.ToString(), ruleActionTrackingEvent.RuleName.ToString(), ruleActionTrackingEvent.ConditionResult.ToString(), PropXml));

command.CommandText = commandString.ToString();
command.ExecuteNonQuery();
command.Connection.Close();
}

private string CreateXmlFragment(UserTrackingRecord userTrackingRecord, string rootNodeName)
{

XmlDocument doc = new XmlDocument();
XmlDocumentFragment doctype;
doctype = doc.CreateDocumentFragment();
doc.AppendChild(doctype);
doc.AppendChild(doc.CreateElement(rootNodeName));
XmlNode root = doc.DocumentElement;

for(int i = 0; i < userTrackingRecord.Body.Count; i++)
{

XmlElement elem = doc.CreateElement(userTrackingRecord.Body[i].FieldName.ToString());
elem.InnerText = userTrackingRecord.Body[i].Data.ToString();
root.AppendChild(elem);

}

    return doc.InnerXml;

}

In the Send method I make sure that I am only grabbing UserTrackingRecord objects and then I check to determine if I have a RuleActionTrackingEvent object. If so then I am ready to start writing to the RulesTrackingData table. In the WriteRuleTrackingRecord method I create the XML snapshot of the object state and then create my SQL insert statement. Once the Send method is called I can start to grab data from the RuleActionTrackingEvent object and the UserTrackingRecord object to fill in the table with the data we need. I have included the computer name as one of the fields since the rules run on the client side I need to make sure that I can determine where the rules ran. Since this is a snapshot of code, I have left out some other functionality and did not take time to refactor the code for this example and could have consolidated it a bit. Anyways, once this code runs and data is written into the RuleTrackingData table it will look like the following (I will let you compare the fields with the table structure above (I put a : as a field separator to make it easier to read)):

4 : WFTEST : System.Workflow.Activities.PolicyActivity : 4091dc04-43fe-4dde-8b80-ba837c9cc9a0 : 8/30/2006 7:03:37 AM : simpleDiscountPolicy : ResidentialDiscountRule : True : <RuleTrackingSnapshot><orderValue>600</orderValue><discount>2</discount></RuleTrackingSnapshot>

As you look at all of the data written to the database you should pay close attention to the ConditionResult field (which gets populated from ruleActionTrackingEvent.ConditionResult) . This will show 'true' for each rule in which the predicates match and the condition is executed. This column will show 'false' for a rule where the predicates do not match and the else condition was executed. For a rules in which the predicates do not match and there is no else condition then a record will not be written to the database table. In addition, the data that is available to track contains the state of the object before the rules execute and therefore the database contains the before snapshot. When many rules run it becomes quite easy to select the rules and look to see what rules had what affect. The problem is that we also needed to have a snapshot of the object after all of the rules ran. In the code able there is a call to a method that I didn't include called WriteUserTrackingRecord. This method is very similar to the WriteRuleTrackingRecord method but only contains enough data to join to the data in the RulesTrackingData table and to contain an XML representation of the end state. What makes this different is that in order to get this final state I needed to place a Code Activity after my Policy Activity. In the Code Activity I included the following line of code:

this.TrackData("WholeObject", crr);

where crr is the object that I passed into the rules engine.

The TrackData takes the object and passes it as a UserTrackingRecord which when I receive it I call the WriteUserTrackingRecord method. Since I am taking this snapshot after the policy runs I will get one of these database entries whereas I will get as many database entries as the number of rules that run in the RulesTrackingData table.

WF Custom Activities and the ToolboxBitmap attribute

skaufman — Wed, 30 Aug 2006 19:42:00 GMT

Ok, so this isn't just limited to Windows Workflow. It is relevant to any piece of code that will end up on the Visual Studio toolbox.

I am building a number of custom activities and I got tired of seeing the standard cog graphic in the toolbar for each one. Within seconds all of my project tasks were put on hold and changing that image was placed to the top of my priority list. Little did I know that it would be 1 1/2 hours later before I could set my gaze on all of those 16x16 pixel graphic images.

Why did it take so long? Well, it turns out that the code behind the ToolboxBitmap attribute code attempts to dynamically create a path to point to the embedded resource file. There are times when the path created does not point to a valid location.

So when I first started down this path I followed the typical route. This typical path is to add a graphic as a resource of the assembly with the graphic marked as an embedded resource on the property page. Then add the ToolboxBitmap attribute to your class providing the type of the object and the location for the graphic. Compile and add your item to the toolbar and you should see the entry along with your graphic image.

As I was researching this I found that there are two things that can mess this process up. The first is to make sure that you know the fully qualified path of graphic, including if the graphic is in a folder in the solution and second is around the namespace of the assembly.

If the default namespace has been changed from the original settings you will need to add that to the beginning of the string along with the the folder tree scheme. Therefore, if I have my graphic image in a folder called Resources and my default namespace is BlogActivity then my resource address is BlogActivity.Resources.MyGraphic.png. A problem occurs if we change the default namespace. Lets say that I change it to BlogActivityTest. This change would have my resource address as BlogActivityTest.Resources.MyGraphic.png. This in an of itself is not a bad thing but in order for the ToolboxBitmap attribute to find the graphic the attribute code needs to find them in the context of their own namespace. There are two attribute constructors that are relevant to this (there are three constructors but the third loads the graphic from a location on the file system and that is not what we want). These two constructors are:

TooboxBitMap(typeof(<control>), "<assembly>.<resource>")

ToolboxBitMap(typeof(<control>))

The second constructor is interesting if you name the graphic the same name as the control. If they are the same then the attribute code will match the graphic with the resource automatically.

It is the first constructor that led me in circles. As it turns out there is a little bug in the GetImageFromResource method. If you have a namespace that is different from the assembly name (as I am sure happens in most scenarios) then the GetImageFromResource ends up putting the assembly name in front of the resource address. In my example, my resource address would look something like BlogActivity.BlogActivity.Resources.MyGraphic.png and this location does not exist.

Now that I understood what was happening I wanted to see what my Visual Studio project thought the address was. Place the code below in the constructor of your object. The output of this code will show you the full path to your embedded resource that the runtime will use. This output should match the string you are using for the second parameter. This is only to loop through all of the embedded resource for debugging and is not meant to remain in your code.

public BlogItem()

{

InitializeComponent();

//Remove this code after debugging

string[] rn = this.GetType().Assembly.GetManifestResourceNames();

foreach (string s in rn)

{

System.Diagnostics.Trace.WriteLine(s);

}

After verifying and testing this path and things still don't work then follow these steps. We need to tinker with the internal dynamic path creation mechanism.

First, create an internal class that is outside of the root namespace. This class can be called whatever you want (in my example I called it EmbeddedResourceFinder)

Next, use this class name in the ToolboxBitmap attribute instead of your control name

Lastly, change the resource location argument to match "<default namespace>.<resourcename>" in order to locate the resource.

The code will look like this:

using System.Workflow.Activities;

//this internal class is needed to fool the ToolboxBitMap attribute so that it can actually build the

//assembly/namespace string correctly for it to find the resource.

internal class EmbeddedResourceFinder

{

}

namespace BlogItem.Workflow.Activities

{

[ToolboxBitmap(typeof(EmbeddedResourceFinder), "BlogActivity.MyGraphic.png")]

[Designer(typeof(PerformanceMonitorDesigner))]

[ActivityValidator(typeof(PerformanceMonitorValidator))]

public partial class BlogActivity : SequenceActivity

{

..........

Now that you are using the empty class and modified attribute you will find that the next time you add your control to the toolbox you will see your picture.

Windows Workflow Tracking and the TrackingExtract functionality

skaufman — Tue, 22 Aug 2006 19:33:00 GMT

New Page 1

I was writing a custom tracking service for the Windows Workflow engine for my client that will be used to track the rules that fired. One of the things that I wanted to do was to track the values of the properties that my rules would touch. I would then create an xml document which would be stored in a row in my tracking database.

The challenge was to find a way to get the internal tracking functionality to grab these property values. In addition, I only wanted the properties that I was interested in and not every property on the class. I found that the tracking infrastructure provides this functionality in the WorkFlowDataExtract class.

I did a search using my favorite search engine to see if there was anything documented on this subject. I was surprised at the lack of information on this functionality. There was one post on the WF Forums, which is a great resource and I highly recommend looking at these posts for information, but, unfortunately, it didn't expand on this class. Therefore, this seemed like the perfect opportunity for a blog entry.

First, lets look at what the class does. There are actually two classes that provide TrackingExtract functionality. They are the WorkflowDataTrackingExtract class and the ActivityDataTrackingExtract class. These classes take the name of a property or field that should be extracted from the root activity of the workflow and sent to the tracking service when a tracking point is matched.

The difference between these two classes is that the ActivityDataTrackingExtract class is bound directly to a specific activity whereas the WorkflowDataTrackingExtract can be assigned anywhere across the workflow. Remember though that these classes are 'bound' to the tracking point and can be used in either the Extracts properties of either the UserTrackPoint or ActivityTrackPoint classes.

The data that is extracted is placed in either the ActivityTrackingRecord or the UserTrackingRecord.

Use the Member method to specify the field or property to extract. You can also associate additional information with the extracted data by using the Annotations functionality.

So, I wanted to accept a list of properties that were important to the workflow developer, in this case I used the List<string> generic type, which was passed in when instantiating the RulesTrackingService. This list gets created in the program.cs file in the Main method as listed in the following code:

static void Main()

{

WorkflowRuntime workflowRuntime = new WorkflowRuntime();

string connectionString = "Initial Catalog=TrackingStore;Data Source=localhost; Integrated Security=SSPI;";

List<string> trackedProperties = new List<string>();

trackedProperties.Add("orderValue");

trackedProperties.Add("discount");

workflowRuntime.AddService(new RulesTrackingService(connectionString,trackedProperties));

...............

}

Once the RulesTrackingService gets instantiated there are two interesting pieces of code. The first is the GetTrackingChannel method. This returns a RuleTrackingChannel object (which inherited TrackingChannel) which is where you will provide the code to operate on the tracking data. In my case, I took the object data and serialized it into XML so that I could place it in a row in the database. The second is the the GetProfile method. Within this method, I have a foreach loop where I cycle through the List<> and for each entry I create a new WorkflowDataTrackingExtract object passing the property on the constructor and then add the extract object to the userTrackPoint.Extracts collection as shown in the code below.

public class RulesTrackingService : TrackingService

{

...........

public RulesTrackingService(string connectionString, List<string> TrackedProperties)

{

this._connectionString = connectionString;

trackedProperties = TrackedProperties;

}

protected override TrackingChannel GetTrackingChannel(TrackingParameters parameters)

{

    if (trackedProperties != null)

    {

        return new RuleTrackingChannel(parameters, this._connectionString, trackedProperties);

    }

    else

    {

        return new RuleTrackingChannel(parameters, this._connectionString);

    }

}

private static TrackingProfile GetProfile()

{

TrackingProfile profile = new TrackingProfile();

profile.Version = new Version("1.0.0");

UserTrackPoint userTrackPoint = new UserTrackPoint();

UserTrackingLocation userLocation = new UserTrackingLocation();

..........

userTrackPoint.MatchingLocations.Add(userLocation);

foreach (string trackedProp in trackedProperties)

{

WorkflowDataTrackingExtract wkflowExtract = new WorkflowDataTrackingExtract(trackedProp);

userTrackPoint.Extracts.Add(wkflowExtract);

}

profile.UserTrackPoints.Add(userTrackPoint);

return profile;

}

The data that is returned from the tracking point for each of the tracked properties represents the data before the rule runs. This was great for the 'before' snapshot but I also needed to see the 'after' snapshot. For this functionality, I added a Code activity onto my workflow after the Policy activity. In this activity I pass the object (in this case it is crr) that the rules operate on to the TrackData property which creates a UserTrackingRecord as shown in the code below.

private void codeActivity1_ExecuteCode(object sender, EventArgs e)

{

this.TrackData("WholeObject", crr);

}

Earlier I talked about the TrackingChannel functionality. In this class I check to see if the tracking object is my custom type or if it is a base UserTrackingRecord (which is what the .TrackData creates). If it is the UserTrackingRecord I again serialize and place this in a different table in my database. I place it in a different table since there will be one of these for each policy whereas there will be many records for the rules tracking records. I place keys on the tables so that they can be related and selected at a later time to actually investigate what occurred in the rules processing.

I now have a tracking service that tracks each rule that fires, including the before shapshot, as well an entry for the data after all of the rules have fired on the object.

Programmatically Create Windows Workflow Rules

skaufman — Mon, 15 May 2006 20:45:00 GMT

I am currently working with a client that is evaluating the Windows Workflow Rules Engine. One of their requirements is that they need to be able to create the rules programmatically through their own application. First we looked at the ability to host the Windows Workflow rules dialog boxes in our application. We can accomplish this through the RuleSetDialog object and the RuleConditionDialog object. Second we looked at how we could create our own UI and programmatically create the rules through an API. Based on the requirement of the application they have decided to use their own UI. So, the search began on how we were going to create these rules.

The Workflow Rules Engine API works through the CodeDom system. This makes a lot of sense since we are using code to create code - which is exactly what CodeDom was designed for.

I have used a sample fictitious rule that represents the type of rule that will be created through the UI. The rule we need to create (and the one used in the example below) is a rule that checks the model and year of a car along with the gas mileage and assigns a surcharge, if necessary.

In looking at the code below I have set up private variables to hold our data. This could have easily been a separate object (and will be in real life). Once I have my variables I need to setup the CodeDom objects which will reference the variables that I will be using in my rules.

The CodeDom objects that are supported in the rules object model are:

CodeThisReferenceExpression
CodeArrayIndexerExpression
CodeAssignStatement
CodeBinaryOperatorExpression
CodeCastExpression
CodeDirectionExpression
CodeExpressionStatement
CodeFieldReferenceExpression
CodeIndexerExpression
CodeMethodInvokeExpression
CodeMethodReferenceExpression
CodePrimitiveExpression
CodePropertyReferenceExpression
CodeTypeReference
CodeTypeReferenceExpression

Next, I start the rule creation code. I create a RuleSet object which I will add Rule objects to. After I create the Rule object then I create the conditions which will be added to the rule using the Rule.Condition property(handing it a RuleExpressCondition object). After that I will add the action using the Rule.ThenAction.Add Method (handing it a RuleStatementAction object). I can also add the Else action using the Rule.ElseActions.Add method. Before I can add the condition I need to create the code to represent the predicate parts that will be added to the condition. In the code this can be seen starting with the code to create the predicate for GasMileage. I create a CodeBinaryOperatorExpression object and then using the Left, Operator and Right properties to assembly the predicate. I continue this for each of the predicates I will need for this rule (in this case there are 3). I have shown in the code how to compare against an integer (with the GasMileage predicate), against a string (with the ModelYear predicate) as well as against an Enum type (with the CarCategory predicate). These predicates also show how to use the CodeBinaryOperatorType object with both the .ValueEquality and .LessThan operators. An interesting find is that there is no inequality operator. To find inequality you need to create the syntax as (CarCategory == "Sports") == false.

Once I have created the predicates that represent each of the parts of my rule I then need to join the predicates and create the condition which will be passed to a RuleExpressionCondition object. As seen in the code below I take the first two predicates; the ruleGasMileageTest object and using a BooleanAnd operator join to the ruleCarCategoryTest object. If I only had two predicates I would be done and could add the condition object to the rule (carChargeRule). Since I had three predicates I need to take the condition object created from the joining of the first two predicates and join them to the third predicate (ruleModelYearTest) to create the final condition (ruleCondition2) which will be added to the rule.

At this point we have the 'if' portion of the rule complete. We now need to create the 'then' portion. This is accomplished using the Rule.ThenAction.Add method as seen at the bottom of the code.

After you have looked at the code make sure to look at the image of the locals window which follows the code. This screen shot shows the rules code that all of this CodeDom code created.

public class ......

{

//Object Items

private string CarName = "Jaguar";

private string CarModel = "XK SLE";

private string ModelYear = "2009";

private CarCategory carCategory = CarCategory.SportsCar;

private int GasMileage = 12;

private double SurchargeRate = 0;

private void BuildRuleSet()

{

RuleSet surchargeRuleSet = new RuleSet("SurchargeRuleSet");

// Define property and activity reference expressions through CodeDom functionality

CodeThisReferenceExpression thisRef = new CodeThisReferenceExpression();

CodeFieldReferenceExpression CarNameRef = new CodeFieldReferenceExpression(thisRef, "CarName");

CodeFieldReferenceExpression CarCategoryRef = new CodeFieldReferenceExpression(thisRef, "carCategory");

CodeTypeReferenceExpression CategoryEnumRef = new CodeTypeReferenceExpression(typeof(CarCategory));

CodeFieldReferenceExpression ModelYearRef = new CodeFieldReferenceExpression(thisRef, "ModelYear");

CodeFieldReferenceExpression SurchargeRef = new CodeFieldReferenceExpression(thisRef, "SurchargeRate");

CodeFieldReferenceExpression GasMileageRef = new CodeFieldReferenceExpression(thisRef, "GasMileage");

// IF GasMileage < 15 AND CarCategory = Sports AND ModelYear = 2009

// THEN Surcharge = $500

Rule carChargeRule = new Rule("CarChargeRule");

surchargeRuleSet.Rules.Add(carChargeRule);

// define first predicate: GasMileage < 15

CodeBinaryOperatorExpression ruleGasMileageTest = new CodeBinaryOperatorExpression();

ruleGasMileageTest.Left = GasMileageRef;

ruleGasMileageTest.Operator = CodeBinaryOperatorType.LessThan;

ruleGasMileageTest.Right = new CodePrimitiveExpression(15);

// define second predicate: CarCategory = Sports

CodeBinaryOperatorExpression ruleCarCategoryTest = new CodeBinaryOperatorExpression();

ruleCarCategoryTest.Left = CarCategoryRef;

ruleCarCategoryTest.Operator = CodeBinaryOperatorType.ValueEquality;

ruleCarCategoryTest.Right = new CodeFieldReferenceExpression(CategoryEnumRef, "SportsCar");

// define third predicate: ModelYear = 2009

CodeBinaryOperatorExpression ruleModelYearTest = new CodeBinaryOperatorExpression();

ruleModelYearTest.Left = ModelYearRef;

ruleModelYearTest.Operator = CodeBinaryOperatorType.ValueEquality;

ruleModelYearTest.Right = new CodePrimitiveExpression("2009");

// join the first two predicates into a single condition

CodeBinaryOperatorExpression ruleCondition = new CodeBinaryOperatorExpression();

ruleCondition.Left = ruleGasMileageTest;

ruleCondition.Operator = CodeBinaryOperatorType.BooleanAnd;

ruleCondition.Right = ruleCarCategoryTest;

// join the third predicate into the condition

CodeBinaryOperatorExpression ruleCondition2 = new CodeBinaryOperatorExpression();

ruleCondition2.Left = ruleCondition;

ruleCondition2.Operator = CodeBinaryOperatorType.BooleanAnd;

ruleCondition2.Right = ruleModelYearTest;

carChargeRule.Condition = new RuleExpressionCondition(ruleCondition2);

// add the action: Surcharge = 500

CodeAssignStatement ruleSurchargeAction = new CodeAssignStatement(SurchargeRef, new CodePrimitiveExpression(500));

carChargeRule.ThenActions.Add(new RuleStatementAction(ruleSurchargeAction));

// Add the ruleset

RuleDefinitions ruleDef = new RuleDefinitions();

ruleDef.RuleSets.Add(surchargeRuleSet);

// Set the RuleDefinitions on the workflow

this.SetValue(RuleDefinitions.RuleDefinitionsProperty, ruleDef);

}

public enum CarCategory

{

SportsCar = 0,

Sedan = 1,

SUV = 2,

.......

}

BizTalk and Windows Workflow

skaufman — Tue, 22 Nov 2005 21:35:00 GMT

It always comes down to choices. The biggest part of choosing is knowing what you gain and what you give up with each alternative. Whenever I start talking about Windows Workflow I am always asked many questions. Typically the first question that is asked is "does this mean that BizTalk is going away?" followed by "well, then when do I use each one".

That is what I want to discuss in this blog entry.

First, BizTalk is not going away.

I want to put a definition around BizTalk to make it easier to compare to Windows Workflow. BizTalk Server is an enterprise level workflow and message processing environment. This environment is tried and tested (extremely rigorously over the last many years). BizTalk also includes many adapters to connect to a variety of back end system. Out of the box, BizTalk provides scalability, manageability, tracking, logging & administration tools.

Windows Workflow is an SDK for creating workflow based applications. The tools are there to build a host and to render a graphical workflow environment. Scalability is possible with Windows Workflow but it is up to the developer to create a truly scalable solution. In addition, there are administrative functions through runtime and tracking visibility but there is not an out of the box administration tool as this is also up to the host developer to create.

The message that I tell people is to use BizTalk when you want to target users/clients that want to span multiple applications whereas Windows Workflow would be used when you want to target users/clients that want workflow within an application.

Now after saying that I know the next question you would ask and it is "Are you saying that Windows Workflow doesn't scale?". The answer is certainly yes, Windows Workflow scales. Windows Workflow scales based on your implementation. This is similar to what you would expect when scaling any application built using the .NET framework. Windows Workflow does not come pre-built as a server application ready to scale as does BizTalk but if you develop the appropriate host and put in place the appropriate development effort then it will certainly scale.

It has been stated that in the future Windows Workflow will be the core workflow engine in all of the Microsoft products that offer workflow. This means that future versions of BizTalk will be built on top of and extend Windows Workflow. This also means that products like SharePoint will also offer workflow based on top of Windows Workflow.

So, to summarize, Windows Workflow is great for workflow within an application whereas BizTalk is great for workflow across applications and this is precisely why BizTalk shines in Enterprise Application Integration scenarios.