The first Decision Table based Rules Engine was written by AMS (American Management Systems) for the State of Texas in 2001. The goal was to build a proof of concept for the Texas TIERS project. Paul Snow was the architect and designer of this Rules Engine, and the goal was to prove that the Decision Tables produced by another vendor as a specification for TIERS could be executed directly.

The proof of concept was STARS, a self screener (no longer online) for users to self screen against 50 assistance programs in Texas. STARS implemented just under 90 decision tables, and was a success, winning awards for innovation and performance.

Deloitte & Touche won the contract to implement TIERS. Paul Snow worked as an Independent Consultant to Deloitte, and rebuilt and rewrote portions of the Rules Engine to support a more robust compiler technology (Flex and Cup) as well as better performance (handling 3000 or so decision tables).

The next Rules Engine implementation written again by Paul Snow was for AMS. This implementation supported the Ohio OFAST project. The Design of this Implementation included Rules Engine objects to provide access to Swing and AWT (Java libraries implementing UI objects). OFAST implemented 5 different programs for performing 5 different types of corporate audits. Each program was completely specified in XML using Decision Tables.

Decision Table based Rules Engines have been used by a number of states to automate policy since 2000. Deloitte has used this technology in the following deployments (See Eligibility Rules engine Eligibility Rules Engine, page 19 . [MMIS 2007]):

• Colorado CBMS
• California CalWIN
• Texas TIERS
• Michigan BRIDGES

With two of the Rules Engines tied up with Texas, and the third Rules Engine tied up with Ohio, Paul Snow wrote DTRules and built this open source project to house it. DTRules is in use by MAXIMUS and has been deployed to projects in New York and Pennsylvania.

DTRules incorporates many of the lessons learned in all of its previous applications. DTRules is far more consistent in implementation from the two Texas versions, and far smaller and lighter weight than the Ohio version. DTRules incorporates automated test support missing from all previous versions, as well as facilities to aid in the mapping of application data into and extracting information out of the Rules Engine.

DTRules is used by Maximus Inc. in a number of production systems, deployed in states like:

• New York
• Pennsylvania
• Colorado
• Louisiana

DTRules is also used by companies world wide, in domains such as commerce, business licensing, business processes, and accounting.

The Default compiler has ”very” simple error reporting. By simple, we mean somewhat cryptic.

The error reporting will only report one error per statement (i.e. context statement, or initial action statement, or condition statement, etc.). Once you fix an error on a statement, you may have another error that occurs after the error you fixed.

Example quote.message.channel error
When an error occurs, it is reported in a form like this:

Error:
Decision Table: Quote_Request
Filename: Quote_Manager_dt.xls

Source: quote.message.channel is equal to RETAIL
Error: java.lang.Exception: Error found at Line:Char =0:30 java.lang.Exception: java.lang.Error: Error: could not match input
Info: Old Postfix: None in XML
26 CONDITION condition
122 RENTITY quote.message

Here is what each line is telling you.

• ”’Decision Table”’ tells what decision table holds the error
• ”’Filename”’ gives the filename where that decision table is located (which helps when you have your decision tables in multiple files).
• ”’Source”’ details the actual statement in the decision table that has the error.
• ”’Error”’ should be something useful. In this case it isn’t, other than to give the character offset to the error.
• ”’Info”’ gives you the list of tokens parsed. ”’This is the most useful part of the error message.”’ Every list will lead with the section name of the table where the error was found.

In the example abouve, only two tokens were shown:

• CONDITION This was a condition statement that failed.
• RENTITY The next token parsed was an Entity (i.e. quote.message defines an Entity object)

At this point, either the syntax cannot lead with an Entity object, or an error occurs before another valid token can be found. In this particular case, the problem is the use of the “dot” syntax.

The “dot” syntax allows you to qualify a name to restrict its value to entities in the context with the given name. In this case, ”’message”’ must be defined by an entity named ”’quote”’. The user however goes on to try and use the dot syntax to go down another level. But while ”’quote.message”’ does define an entity, it isn’t an entity name. What is intended is to use the channel attribute of the quote.message entity. The fix in this case should be:

quote.message’s channel

Example Undefined Attribute

Here is another typical error, one where the attribute hasn’t been defined.

Error:
Decision Table: Quote_Request
Filename: Quote_dt.xls

Source: quote.code is equal to BANK
Error: java.lang.Exception: Error found at Line:Char =0:37 java.lang.Exception: Can’t recover from previous error(s)
Info: Old Postfix: None in XML
26 CONDITION condition
130 RSTRING quote.code
50 EQ is equal to
154 UNDEFINED BANK

In this case the last token BANK was undefined. What was intended was likely for BANK to be a constant defined in the EDD. Assuming code is some integer value, replacing BANK with its code number (like 8) would fix the problem. The better solution would be to define a read only constant in the EDD with the attribute BANK given a defaultvalue of 8.