At the heart of every enterprise software is its business logic, the code that parses the inputs and creates the appropriate outputs. This is how we turn the steps of a business process into code, adding logic to each step of a workflow. This way we only have to write the necessary code and we can avoid complexity.
Not all business logic is immutable. Certain processes, especially those that are critical to a company’s finances, are often governed by external rules and regulations that can change at short notice. For example, you might calculate sales tax as part of an e-commerce service when government policies dictate a sudden change in the rate or how those rates are applied.
This could suddenly require you to pull resources from other projects to rapidly develop new modules so that you’re ready to go as soon as new regulations come into effect. Development resources don’t come cheap, so what’s needed is a way to outsource those rules and regulations so you don’t need to change your code, just the rules it uses.
The answer is old: the rules engine. Here, input values are tested and simple rules are applied, returning a result that indicates which rules were triggered. Complex aspects of business logic can remain in their own modules and services; all that needs to change is the rules engine configuration. So, for example, if a service needs to be called if a transaction is greater than $50, and the rules change to set that limit to $45, you just need to edit and update the rule that calls the service and passes the transaction to this.
Overview of the Microsoft Rules Engine
Microsoft has developed a relatively easy to use tool open source rules engine library for .NET applications, available as a NuGet package or from GitHub. Designed to provide rules abstraction from your code, rules are stored outside of your application in JSON format with rules written using Familiar lambda expression syntax from .NET. An active community and regular updates make it a useful tool and worth considering.
With its rules outside of your code, you can change the rules at any time by simply uploading a new rules file and restarting your application. You can choose an appropriate store for your rules, with the best option for the platform you are running on, for example, using MySQL on a web server, Filesystem on a PC, or an Azure Blob Storage account for a Azure app. Service request.
After you add the rules engine library to your code, the engine parses the rules and input messages, returns the results to your application, and allows processing to continue based on the status provided by the engine. The library itself sits outside of your code, working as a referenced NuGet package with a wrapper to handle getting and caching rules, as well as driving the rest of your application from the results of the assessments rules.
Creating Rules for the Rules Engine
Getting started with the .NET rules engine is relatively simple. You will first need to figure out how to separate your application’s rules, and then how to describe them in lambda expressions. There are options to create your own custom rules using public classes that can be referenced from a lambda expression, an approach that gets around the limitations associated with lambda expressions that can only use namespaced methods .NET system.
You can find a JSON schema for the rules in the project’s GitHub repository. This is a comprehensive schema, but in practice you’ll probably only need a relatively basic structure for your rules. Start by giving your rules workflow a name, then follow it with a nested list of rules. Each rule needs a name, an event that is triggered on success, an error message and type, and a rule expression defined as a lambda expression.
Your rule expression must be defined in terms of entries in the rule engine. Each input is an object and the lambda function evaluates the various values associated with the input. Each value must be given a test, the tests being part of a logical expression which, when evaluated as true, will trigger the rule’s success event. It’s a good idea to list all the rules you want to use in advance, along with the conditions that must be met to trigger the rule. This way, you can confirm that the rules you’ve defined address your application’s use case in a way that makes them understandable to stakeholders.
To use the rules engine, first use a constructor to instantiate the library, loading the workflow rules in JSON format. Once it’s up and running, getting results from the rules engine consists of calling it with a workflow name and current inputs, getting the OnSuccess or OnFail events, and using them in your application. A wiki offers Detailed Instructions to learn how to use the library.
Create your own rules editor
A useful tool to help establish rules comes in the form of a Blazor UI library which can modify new rules and export them in a suitable format for your applications. You can build it into your own code so you can keep your rule development inside your firewall, or there’s a quickstart in the form of a progressive web application based on WebAssembly that developers can install on their own devices to create schema-compliant rules.
The PWA rules editor works in two modes. First, a workflow-driven view constructs rules using lambda expressions. The second option defines Input RuleParameters, which can give custom names to rules. At the same time, you can use locale settings in a rule to break it up into easier to understand items with their own names which can then be combined into a single rule. For example, one local parameter can be associated with an expression indicating whether a specific input is a specific value, with another for a different input. The results associated with each local setting can then be combined into a logic statement to determine whether or not the complete rule fires.
By separating rules from code and using a web editor to create new rules, we can create a tool that allows business analysts to modify rules without requiring developer intervention. This approach can save time and resources. It’s not quite about launching your own Power Platform-like tools, as you limit the inputs and rules that can be changed, operating with far more constraints than the more free-form Power Platform. Even so, giving users some element of control in areas where changes are expected ensures that those changes are made in a timely manner and that developers don’t need to switch tasks on the fly.
Using a rules engine like this can simplify application workflow, outsource your business logic, and enable rapid updates that other development methods and tools can prevent. Microsoft’s open-source approach to .NET library development lets you go into code and make changes that meet your business needs, while letting you take advantage of performance improvements and new features community-oriented.
Copyright © 2022 IDG Communications, Inc.