Building a Dynamic Business Rules Engine

Building a Dynamic Business Rules Engine

In this article, we discuss dynamic business rules in software development and a few approaches that can be employed to achieve this.

 

What do we mean by dynamic business rules?

In most software solutions, business rules are often statically coded into the system in languages such as C#.  These rules might live in Windows Services, Web Services or Web APIs.  The business rules will have been captured by an analyst at one point and documented in a user story or functional specification for a developer to ingest and build code from.

If a requirement changes, the analyst typically will document this, pass the change request over to the developer for him to then build.  This often involves lifting the hood on the existing codebase, making the changes and then going through a test and release cycle.  

Bonus Download: Building a Dynamic Business Rules Engine Guide

Dynamic business

Dynamic business rules allow the end user to make changes to the way their software behaves – without developer intervention.

There are many benefits of building a Dynamic Business Rule Engine Click To Tweet

Why?

The benefits of implementing dynamic business rules are obvious. Some of the reasons mentioned for implementing them are:

  • Regularly changing requirements
  • The business needs visibility into business rules execution
  • Users want to be able to modify their application’s behavior without developer intervention

From a software vendor’s perspective, implementing dynamic business rules can free up developers to work on more interesting tasks or save the business money if specific features can simply be configured from a user interface.

Dynamic business rules can free up developers to work on more interesting tasks Click To Tweet

Options

Depending on how much configuration management is required, you have a few options:

  • Implement configuration tables that enable / disable specific branches of code in your application based on values held in your configuration tables.

  • Off the shelf solution.

  • Build your own dynamic rules engine – an extension of #1 but with much more dynamic code.

Bonus Download: Building a Dynamic Business Rules Engine Guide

 

Configuration Tables

You can use configuration tables if the business rules you need to amend 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 some element of dynamic business rules.

Or maybe another set of examples are the descriptions of page headers, images or text on buttons in your web application.  Settings such as these can be stored in configuration tables and administered by power users on a client site.

What sort of data should be in the configuration table?

You can keep this generic, yet simple and have a database table with a similar definition:

Column

Description

Data Type

SettingKey

The unique key, e.g. WelcomeMessage

String

SettingDesc

Human readable description for the admin user, e.g. This is the login message the user sees

String

SettingCategory

This can be used to group settings per functional area, e.g. LoginSettings

String


Then at runtime, you can load these settings via some kind of helper class.

 

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 allowing you to build workflows in Visual Studio.

You can easily model process flows and develop business rules through the designer canvas that ships out of the box.  

You can re-host the Workflow Designer in a standalone WPF application for business analysts to use on their machines.  The designer canvas offers a drag and drop user experience which is hard to beat.

One thing worth mentioning is 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 around this, though.  You can speak to our team too as our engineers are experts and building applications using WPF !

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!

Other commercial products are:

 

Roll Your Own Rules Engine

This is where things get interesting, but it 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:

YARE allows you to do things like this:

Expression Trees

With Expression Trees, you can manipulate objects, properties, and methods at run-time. You can form dynamic, in-memory branches of code and execute them.  

Taking it a step further, you can load external assemblies via reflection into your application and write a web interface that allows you to construct rules around the objects contained in these assemblies.

For example, consider the following, you have an assembly that contains a Person object with properties such as Name, Age, Address, ZIP Code.  

The person object also contains another object Notification.

With the web interface that leverages expression trees, you can write code to the effect:

If Person.ZIPCode = 73301 Then [GenerateAndSendEmailToAustin]

Where:

  • Person = Object
  • Zip Code = Property
  • GenerateAndSendEmailToAustin = method invoked at runtime when the precondition is evaluated successfully.  i.e. the person zip code being processed = 73301.  

 

The key point here is that the actual method in the assembly is being selected by the user from a rule admin / web interface, and the rule definition is being persisted in a database and subsequently loaded and executed at run-time later.

 

Amending rules and change management

End users 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).

It’s a good idea to split your business rules into two camps:

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

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

Bonus Download: Building a Dynamic Business Rules Engine Guide

 

Summary

In this article, we’ve introduced dynamic business rules, and why they can be beneficial for both the end user and software vendor. Here at Growth Acceleration Partners, our expert team of engineers can help you deliver such solutions, and have expertise in Analytics, Mobile, Cloud development and QA.  

We recognize that finding cost effective and quality software engineers can be a problem.  Whilst some offshore models look attractive on paper, issues regarding timezone and culture can hinder project delivery.  GAP are based in Austin, TX and by using software development centers in nearby Costa Rica and Colombia, we can mitigate such risks.  No more late night calls or email boomerang.  

Why not give us a call today and see how Growth Acceleration Partners can help you?