Creating and Managing Business Rules with Code Effects

If you've been in the industry long enough, you know that managing a system that uses one of the conventional business rules engines is not really that easy. Evaluation of existing tested and approved rules against an organization's data is almost never a problem. Engines offer a variety of easy to understand and easy to use features when it comes to rule evaluation. It's rule management that causes so many headaches to business teams all over the world. Particularly, creation of new rules and modification of the existing/established ones.

Traditionally, the creation of business rules is accomplished in one of two ways:

  • Decision Tables. Rules are declared as text/CSV/XML/Excel files by business people who follow certain predefined formats, either public or proprietary. Such files are called decision tables. A single decision table usually defines one or more conditions and optional actions/value setters that make up a business ruleset. Each file is validated, compiled into native object(s), tested, and deployed by an IT team.
  • GUI. Business people create or modify rules by using a graphical UI, either provided by the engine or developed in-house. Such a UI often requires a working knowledge of scripting languages or consists of a series of predefined drop downs that can dynamically change their options depending on the current input. The IT team only sets everything up and maintains the system; the rule management itself can be administered by the business.

While other methods do exist, the above mentioned are the most common ones.

Decision tables have been around since the 60’s and haven’t changed much since then. Their fundamental problem is that business analysts cannot manage corporate rules without IT being heavily involved in the process. More often than not, a non-technical person cannot simply create a new table; first, (s)he must learn either some rule definition language or a cryptic format. In such systems, MS Excel © becomes the UI of choice, and it's not necessarily a great choice when it comes to business rules.

The GUI approach is the most appealing for organizations because it has the potential to almost entirely separate IT from the business, but it's very difficult to create a requirements-crunching system just by throwing a bunch of drop downs, labels and check boxes into fixed locations, no matter how complex the underlining logic is.

Code Effects component approaches the traditional business rules management from a completely different perspective. It provides an almost limitless GUI while delivering record-setting rule evaluation performance. There are no decision tables, no predefined UI controls; everything is XML-based, on the web, and compiled for speed. It’s easy to set up, and a pleasure to use.

As mentioned elsewhere in this documentation, Code Effects component is not a complete system. It doesn't include rule authorization logic, versioning control, or debugging capabilities. You can build those parts yourself if you need them. Code Effects component concentrates only on features that are essential for successful creation, validation, and evaluation of business rules.

Here is what needs to be done in order to use Code Effects in one of your products or as a stand-alone rule engine:

  • First, you must define the class(es) that Code Effects component can use as source objects. Chances are, your organization already uses such classes; they just need to be adapted to be consumable by Code Effects. This is an easy process in most cases.
  • Next, you need to decide which of your systems will host the rule evaluation. For example, it can be a Windows service, running 24/7 in the background somewhere on the corporate network. It could register a SOAP/WCF service and wait for instances of your source objects to arrive, evaluating each instance against one or more business rules. With Code Effects, it literally takes one assembly reference and several lines of code to evaluate a source object (or a multitude of source objects) against one or more business rules.
  • You also need to give your business analysts a way to create, edit, save, and delete rules. Code Effects component does not save or delete those rules for you. Instead, it gives you the rules’ XML documents and some related data every time the rule author clicks the Save, Delete, or Load button. It's up to you, the developer, how to handle that data. So, create a new web ASP.NET or MVC application or use any existing one and drop the Rule Editor in it. Define the rule saving, loading, and deleting logic to complete the application. That takes a relatively short amount of time, unless you enhance the app by adding rule security, debugging, and versioning features.

It's worth noting that Code Effects component is not trying to become an online IDE or a code editor of any kind. Our goal is very simple: to provide the best and easiest to use business rule editor for business people. Every new UI feature that we consider must make Code Effects easier to use for people who deal with business rules on a daily basis.

Post your support requests on Stackoverflow.com. You can also post your comments and product feedback using the form at the bottom of this page.
Comments: 0
Name (optional):
Comment (URLs are allowed and must start with http:// or https://; all tags will be encoded):
Remaining character count: