Dynamic Business Rules

Introduction

In almost every project I’ve worked on, at some point a requirement surfaces that talks about “configurable business rules”.  The benefits to a project are obvious and some of the reasons cited are:

• Dealing with regularly changing business logic or rules
• The business needs visibility into business logic execution
• Users wish modify business logic without a developer 

The purpose of this post is to give you options and ideas to think about in terms of rolling out your own business rule engine.

Options

Depending on how much configuration management is needed you have a few.

1. Implement configuration tables that enable / disable specific branches of code in your application based on values held in your configuration tables.
2. Off the shelf solution.
3. Build your own dynamic rules engine – an extension of #1 but with much more dynamic code.

I’ve applied all of the above to different projects and here is what I’ve found.

Configuration Tables

Minimal effort.  Suitable if the configuration changes you need to deal with are simple.  For example, you have an application that extracts X number of records from the database for each query.  The value for X could be defined in the admin section of your application and fetched at run-time thereby giving you an element of configuration management.

Off the shelf

You’ll need to do your homework and see what’s out there.  Integration with your existing product stack, training, licensing costs or technical support all need to be considered.

Workflow Foundation integrates easily with your .NET web applications.  Easy to build workflows in Visual Studio and is what I’ve used in the past.

You can easily model process flows and develop business rules through the designer canvas that ships out the box.  You can re-host the Workflow Designer in a stand alone WPF application for business analysts to use on their machines.  The designer canvas offers a rich drag and drop user experience which is hard to beat.

One thing worth mentioning that when you re-host the Workflow Designer in a WPF application you’ll lose IntelliSense support.  ActiPro have a product which helps you get round that though.  Speak to them nicely enough and they may give you a demo application too (they sent me a copy).

Naturally you need to import your domain specific objects and dlls into the designer to use them and whoever updates the workflows must know their way around the object graph and problem domain.  You’d need to do this with other off-the-shelf products too.

With the advent of .NET Core it’s not clear if Microsoft are going to port Workflow Foundation which is a slight concern.  The community are pushing for it though which can read more about here.

I’ll probably publish some other blog posts regarding Workflow Foundation as I used it quite a bit in the past so have been through the pain figuring out what all the moving parts are!

Other commercial products are:

• InRule
• Workflow Engine.NET

Roll Your Own Rules Engine

This is where things get interesting but involves substantial effort.  With Expression Trees you can “write code that writes code”.  Rules can be built in run-time using configuration data stored in your database and evaluated.

There are quite a few examples of this on the web.  Check out the following implementations:

• Yet Another Rules Engine (YARE)
• Expression Trees and Dynamic Business Rules

YARE allows you to do things like this:

        [TestMethod]
        public void EvaluatorDecimalWithParams()
        {
            Pricing p = new Pricing()
            {
                Cost = 100
            };
            var compiledRule = RuleBase.CompileDecimalEvaluatorWithParameter("5-1*3+1/2+Cost");
            var result = compiledRule(p);

            decimal expected = 102.5M;
            Assert.AreEqual(expected, result);
        }

I took this concept a step further and built a prototype application based on Expression Trees that allows you to load an assembly with associated objects, properties and methods into the database.

From the front end you can then pick and choose from a grid to construct simplistic rules such as:

If [Person].[Age] < 18 Then [SetMinorToTrue]

Where:

• [Person] = Object
• [Age] = Property
• [SetMinorToTrue] = method to invoke at runtime when this rule is evaluated successfully.  i.e. the person age of object being processed is less than 18.This is an actual method in my imported assembly which gets loaded via the rule definition and executed.  Parameters are passed to the method via the calling objects properties and the database record is updated.

Amending rules and change management

In my experience end users very rarely want to modify the business rules daily in their application.  A business rules engine should be used by administrators, business analysts and technical support staff.

A change management process should be adopted when new iterations of business rules have been developed to mitigate any risks of breaking your application.  You don’t want to update a process or business rule that take immediate effect in your production environment (unless it’ a hot-fix).

With this in mind, it’s a good idea to split your business rules into two camps:

1. Rules that can be updated by users
2. Rules that should not be updated by users.  i.e. core product rules

Make these decisions as build your product and get feedback from the user community.

Finally

In this post I’ve discussed a few solutions you can use if you need to implement dynamic business rules in your application.  We’ve talked about managing change and who this functionality should be targeted at.

Have you used anything else?

What has your experience been?

Let me know your thoughts.