Windows Workflow Rules From Outside A Workflow, And Other Conference Demos

Had a great time presenting at the SOA and Business Process Conference and wanted to share some of the code bits that I demonstrated during my Developing and Maintaining Business Rule Solutions session.

One thing I demonstrated was the ability to build business rules in Windows Workflow and execute those rules from either within the workflow, or completely stand-alone. The rules themselves are fairly simple ...

So I can execute those rules by kicking off the workflow, you can find lots of examples of that. On the other hand I haven't seen a whole lot of code showing how to execute these rules outside the workflow confines. In this code snippet below, I make use of the .rules file that gets created when you build rules in WF.

//load up a rule set from file; file name abbreviated here
XmlReader xreader = XmlReader.Create(@"C:\...\LoanWorkflow.rules");

//class that allows us to load up the rules from XML
WorkflowMarkupSerializer serialize = new WorkflowMarkupSerializer();

//inflate a RuleDefinitions object from the XML in the file
RuleDefinitions r = (RuleDefinitions)serialize.Deserialize(xreader);

xreader.Close();

//set values on the loan application member variable
loanApp.ApplicantAge = Convert.ToInt32(txtAge.Text);
loanApp.LoanPurpose = txtPurpose.Text;

//create new instance of RuleEngine class; new in the RC build
RuleEngine engine = new RuleEngine(r.RuleSets[0], typeof(WorkflowCaller));

//execute
engine.Execute(this);
MessageBox.Show("Rule Result: Loan Applicant Qualified? " + LoanApp.IsApplicantQualified.ToString());

Neat stuff. I passed in my actual Windows Form object which had a member variable of the same name as what the rule expected. You can download all the code for this sample here.

Another demonstration I built showed how to build your own BizTalk Business Rules Engine TrackingInterceptor. Why in the world would you do this? Any rules that get executed by an orchestration can be set up to track all the execution details (facts asserted, conditions evaluated, rules that fired, etc). But, what if you call that rule outside of BizTalk? By default, nothing gets tracked. So, I inherited the IRuleSetTrackingInterceptor interface and wrote the data I wanted to a simple custom database. I also added an input parameter to the tracking interceptor's constructor requiring the rule caller to identify themselves. This way, I'm recording who is using a particular ruleset. Finally, I built an interesting little ASP.NET site which shows the basics of each executed policy, and if you choose, you can view all the gory details of the execution cycle.

You can grab the database script, BizTalk project (which holds the schema) tracking interceptor, WinForm app that calls the rule, and the working ASP.NET site here. You'll probably have to fiddle around to make it work, and I make no promises that any best practices were remotely used. Another option (instead of the custom database) was mentioned to me by my new buddy Mark who suggested using the BAM API from within the Tracking Interceptor and stuffing this into (related) activities. Nice idea.

I also demonstrated the usage of my Rules Authorization Manager tool which can be downloaded from here.

One of the things I enjoyed demonstrating the most at the conference was RuleBurst which nicely integrates with the BizTalk Business Rules Engine. My next post will contain a short review of that product.

Thanks to the surprising number of folks who attended the session and I hope you enjoyed yourself.

Technorati Tags: BizTalk, Technorati Tags: Windows Workflow, Technorati Tags: Business Rules