Caspar Fall describes his company's experience in developing a low-cost solution in a .NET architecture with an open-source rule engine. A major requirement was a user-friendly interface, often lacking in low-cost and open-source rule engines. The selected engine, NxBRE, meets this requirement with a GUI based on Microsoft Visio -- John Hall

Applying an Open-source Business Rule Engine to Questionnaire Response Validation

C. J. Fall

ELCA, Avenue de la Harpe 22-24, CH-1001 Lausanne, Switzerland, www.elca.ch

Abstract

Commercial rule engines provide users with a wide variety of functions for managing and executing business rules, but their licenses can prove expensive, particularly for small projects. Alternatively, open-source rule engines with graphical user interfaces are now available to fulfil similar requirements. We report on a real-life experience of applying a free rule engine in a commercial environment. The case study centres on the validation of complex online questionnaires. Business rules serve advantageously to indicate to end users completing a multi-page questionnaire where their answers contain unexpected values or where conflicting responses have been provided. For questionnaire providers, the rules serve to test the plausibility of the responses provided in comparison to historical or average values. For this task, we have employed NxBRE, a free and lightweight rule engine, and report on its advantages, limitations, and performance.

Introduction

Until recently, business rule engines came in two flavours: systems of academic origin: small tools designed originally for research purposes and costly commercial solutions designed for large-scale production. While undeniably powerful, the academic rule engines, such as CLIPS [1] or Jess [2] required rule authors to learn a custom syntax and/or rule-authoring language, making programming skills necessary to update rules. Solutions of commercial origin typically provide better graphical user interfaces (GUIs), for authoring decision tables, decision trees, or managing versions of business rules, but can come with a high license cost. However, some free or low-cost rule engines now provide graphical user interfaces to author business rules. This development significantly enhances the ease for business managers to update rules and makes the integration of a rule engine interesting even in low-budget projects, thus significantly broadening the application domain of rule engines.

ELCA was recently mandated by the Health Section of the Swiss Federal Statistics Office to develop a solution designed for managing online annual questionnaires, where a number of rules are employed to validate the responses provided by over a thousand end users. The rules check that the end users have filled in all the mandatory questions, that there are no contradictions between their responses to various questions, and that the numerical values provided are plausible when compared to values provided the previous year, for example. We decided to implement a rule engine to handle such tests since our customer wanted to be able to add rules autonomously.

In this paper, we discuss the criteria used to select the rule engine, explain the architecture of the solution developed, evaluate the chosen engine based on our project experiences, and conclude.

Tool selection

Table 1 shows the list of low-cost forward-chaining rule engines that were initially considered. All these products are under continuous active development. They differ in their licensing mode, availability of support, and application programming interface (API). OpenRules and DROOLS both support the JSR-94 standard [6] and allow decision tables to be authored in standard spreadsheets. DROOLS also provides a comprehensive XML format for authoring rules and is the only system in our list to use the RETE algorithm for rule execution [7] . Our choice of rule engine was constrained by a number of factors: a limited budget, a need for a user-friendly interface, and an imposed Microsoft .NET architecture. In the .NET world, NxBRE is the only open-source rule engine with a graphical user interface. The only other open-source .NET rule engine we are aware of is the Simple Rule Engine [8] , a recently released product that has yet to reach maturity and that does not have a GUI. Given this information, NxBRE was selected for our needs.

---

Product	License	Support	API	Graphical user interface	Architecture
NxBRE [3]	Free LGPL	Via SourceForge	Custom	Microsoft Visio 2003	.NET
OpenRules [4]	Free GPL	Commercially available	JSR-94	Excel or OpenOffice	Java
DROOLS [5]	Custom open-source	Commercially available	JSR-94	Excel or OpenOffice	Java

---

Table 1: Selected list of low-cost forward-chaining rule engines with graphical user interfaces

Solution developed

The elements of our solution are shown in Figure 1. The questionnaire provider — in this case the Swiss Federal Statistics Office — is responsible for writing the rules applied to questionnaire responses in a standard Visio file. The file is saved as a standard Visio VDX file, which can then be deployed in the productive system. The steps performed by the system to apply the rules to the contents of a questionnaire are as follows: The rule engine reads and parses the Visio file in advance, extracting rules and pre-defined facts (1). End users are provided with a web-based electronic questionnaire (2), which contains several pages of questions. Users fill in the questionnaire and submit their responses page by page (3). The core system stores their answers in a database (4) and submits the data to the NxBRE inference engine (5). The results of these tests (6) are stored in the database (7) and displayed to the end users (8), who can then adjust their responses in the questionnaire if necessary.

Figure 1: Elements and principles of the questionnaire response validation system

As shown in Figure 2, the system consists of a traditional client-server three-tier architecture. End users, the questionnaire provider and questionnaire reviewers access the documents through a standard browser connected to a web server via encrypted communications. Questionnaire reviewers are responsible for checking the results of the plausibility tests on the end users' responses. Various business modules handle the questionnaire contents, import and export data, and generate PDF versions of the questionnaires, for example. A database stores all the data provided.

The business modules call two external elements: the rule engine and an anonymizer module, which serves to uniquely identify individuals mentioned in the questionnaire without their names explicitly appearing to the questionnaire reviewers. Two versions of the system have been developed: a server-based solution, which runs on Microsoft Internet Information Services (IIS) and which interfaces with an Oracle back-end, and a stand-alone version distributed on a CD-ROM, which runs with a free Microsoft Cassini web server and which uses a Microsoft Access file as a database.

Figure 2: Architecture of the solution

Rules to validate the questionnaire contents are written in Visio files using a set of template elements distributed with NxBRE. These templates correspond to various operations, such as selecting, counting, defining and modifying facts in the working memory. Logical operators are also provided. The templates are linked together using standard Visio connectors to form rules.

A typical complex rule in Visio is shown in Figure 3. Various blue boxes serve to select the questionnaire field names and test their contents. They thus correspond to the "IF…" part of a rule. In this example, the rule tests if field A23 is equal to 2 and if at least one of three fields is greater than zero. The tests on the three fields (E3.03 to E3.05) are combined with a logical OR operation. An additional blue box selects a message to display to the user (MessageA1) if the other criteria are verified. The messages are stored in three languages (German, French, and Italian) directly in the Visio file, as predefined facts, to allow the questionnaire provider to update them with ease. The red box at the bottom of Figure 3 corresponds to the "THEN…" part of the rule. It defines which field of the questionnaire is primarily concerned (here, A23) and sets the message to be displayed to the user, together with a predefined error level (major or minor alert).

Figure 3: Typical questionnaire validation rule authored in Visio. Elements with a brown shaded background are comments that are not part of the rule definition.

NxBRE evaluation

NxBRE is a rule engine with a unique Visio user interface. At first sight, the rules in Visio will probably appear unfamiliar to seasoned business rule practitioners. The rule engine thus requires a minimum amount of training not only to specify the solution in terms of data binding and rule organization, but also to learn how to read and update the rules. We found, however, that the documentation and the numerous examples distributed with the source code were of sufficient quality to make for an adequate learning curve. The NxBRE authors were also quick to respond to queries submitted in their SourceForge forum.

A particularly useful feature of NxBRE is the availability of the so-called inference engine console, a standalone Windows application that allows rule authors to load and test a Visio rule file. In our application, we include in the Visio rule file a set of dummy questionnaire responses as predefined facts for NxBRE. The console can read these test values and apply the validation rules to them. The productive application is of course configured to ignore the test data in the Visio file. In conformity with the business rules approach, the console has made it possible to easily develop and test the rules separately from the rest of the application. Indeed, the rules were authored locally while the rest of the application was developed in a separate location. The rule files were largely completed before the main code was available.

In our solution, all the rules for a given questionnaire are stored in a single Visio file. The rules are organised in the Visio file in a series of tabs, which are equivalent to rule packages. The rules for a given page of the questionnaire can be grouped in a corresponding tab in the Visio file. NxBRE then allows the system to selectively apply only the rules in that tab when the corresponding page contents is submitted to the rule engine. This avoids applying rules that would not be verified due to lack of input data. Although not used in this project, NxBRE supports rule priority, rule preconditions, and mutual exclusions if the rule execution order needs to be fine-tuned.

NxBRE is well designed to compare string, Boolean, or numerical fields to predefined values, as performed for example in Figure 3, where we test three fields for positive values. Comparing two variables in a rule file, for example to test if one is greater than the other, requires a slightly more complicated syntax in Visio than might be expected, but the solution is adequate. The latest version of NxBRE also supports arbitrary C# expressions in the Visio file, which for example allow mathematical expressions to be included, in order to sum two variables, say. While powerful, the processing of rule files including C# expressions is sometimes much slower than those without such code. In Figure 4, we display the execution times of NxBRE version 2.3, on a Pentium IV 1.6GHz computer, as a function of the number of rules (with one initial fact) and as a function of the initial facts relevant to the rules (with 10 rules). We consider various rule scenarios:

1. A daisy chain of rules A implies B, B implies C, C implies D, etc…;
2. A set of independent rules A implies B, A implies C, A implies D, etc…; and
3. The first call to NxBRE for a set of rules like case 2, but with each rule containing a C# mathematical expression

The execution times in Figure 4 include only the processing within the rule engine and do not include time to bind the data or retrieve anything from the rule engine or database. The performance tests were executed within the console distributed with NxBRE, with dummy rules and data unrelated to our project.

Cases 1 and 2 represent two extremes in terms of rule dependence. As expected, a set of independent rules always runs faster than a daisy chain. Both cases scale as the square of the number of rules and are linear in the number of initial facts. Execution times are under a second for around 170 independent rules with one initial fact or 10 rules with 500 relevant initial facts..

When the rule file contains C# expressions, the first time the rule engine is called, the rules are compiled and the execution time is extremely slow (case 3 in Figure 4). The compilation overhead depends on the number of rules with C# expressions but not on the number of facts. NxBRE provides a mechanism for cloning the rule engine for subsequent calls, and in this case the processing of rules with C# expressions is as fast as those without them, i.e. nearly equivalent to case 2 (not shown in Figure 4).

NxBRE also provide a binding mechanism for abstracting C# expressions necessary for defining rules out of the Visio file. In this way, rules can call necessary mathematical expressions defined outside the rule file in the main program. This also avoids a lengthy first run but is more complicated to set up and less practical for rule managers. Since there were no significant performance or high-volume requirements in our application, we chose to include a few selected mathematical expressions directly in our rule files. As seen in Figure 4, this is practical up to a few tens of rules with C# expressions.

Figure 4: NxBRE execution times for various rule scenarios as a function of the number of rules for a fixed number of facts (A), and as a function of the number of initial facts relevant to the rules for a fixed number of rules (B). Black diamonds correspond to a daisy chain of rules, white diamonds to a set of independent rules, and white triangles to the first execution time of a set of independent rules including mathematical C# expressions.

Conclusions

If you are considering a .NET project and are looking for a rule engine, NxBRE is a worthwhile alternative to commercial products. It is well adapted to projects with no significant performance requirements. The Visio graphical user interface may at first seem surprising, but in combination with the NxBRE console, and after a necessary training phase, it allows rule authors to quickly update and test new rule files. In the course of our project, we identified two small bugs in the latest releases of NxBRE. The rule-engine developers fixed both issues extremely rapidly. Overall, we estimate that NxBRE is now a stable product for industrial applications. Our integration of NxBRE in a client-server commercial environment was performed without difficulty, to the full satisfaction of the Swiss Federal Statistics Office, for which the solution was developed.

References

[1] CLIPS: A Tool for Building Expert Systems, www.ghg.net/clips/CLIPS.html

[2] JESS: Java Expert System Shell, herzberg.ca.sandia.gov/jess

[3] NxBRE: .NET Business Rule Engine, www.agilepartner.net/oss/nxbre

[4] OpenRules, openrules.com

[5] DROOLS, drools.org

[6] JSR 94: Java Rule Engine API, www.jcp.org/en/jsr/detail?id=94

[7] RETE: A fast algorithm for the many pattern/many object pattern match problem, Charles L. Forgy, Artificial Intelligence 19 (1) 17-37, September 1982

[8] SRE (Simple Rule Engine), sourceforge.net/projects/sdsre

 
 

# # #