General concept

The configuration of the MRules Business Rule Engine can, in version 1, be achived by two ways:

• Using Java APIs.
• Using a structured XML file.

In both cases, creating and editing the configuration must be done by a technical person. Or a configuration GUI must be developed, allowing more or less superficial modifications of the configuration.

To overcome this limitation, a new way has been created. It is based on another of the products offered by MRules: the Grammar Engine. An extension proposing a configuration syntax close to natural language has been developed.

It will enable functional stakeholders to read, understand and modify the configuration of business rules in their domain, without the need for technical support or dedicated GUI.

Grammar details

The rule engine’s configuration grammar consists in a set of keywords or groups of keywords, called lexemes. Put together, they compose a readable and understandable text, although different from what it would be in “spoken” language.

For the moment, the grammar is available natively in the English language. The French version will be available in future versions.

The detail of all proposed lexemes and of how they are chained is available on the generated grammar documentation.

Extend grammar

Taking into account specific developments

It is possible to extend the MRules Business Rule Engine by adding functions not proposed natively (Addon development).

It is of course possible to extend the grammar to take into account your specific developments. In other words, the possibility to add dedicated lexemes is provided and goes through a few simple steps:

• Create the file grammar/inc/mrules-natural-language-grammar-extensions.xml” accessible via the CLASSPATH of the application. This file is automatically taken into account if it exists.
• Configure in this file additional lexemes to be included in the grammar.

Translation

If your users need the grammar in other languages than those which are natively included, it’s easy to do your own translations.

Just duplicate the file “mrules-natural-language-grammar.xml” and its inclusions and name the copy “mrules-natural-language-grammar_XX.xml”, where XX is the desired locale. Then modify the content of the duplicate files to translate it.

Localized variants are automatically taken into account as soon as they are available in the CLASSPATH.

Also, you will be able to generate the documentation corresponding to your translation with the dedicated tool.

Tools

Tools are provided with the grammar engine to facilitate its use.

The Web Editor

It would be complicated to remember all the lexemes. So, we developed a rule engine configuration editor Web component.

This component is based on the ACE JavaScript Editor and is packaged as a Vaadin Widget.

It allows intuitive autocompletion and validation of syntax when typing.

The calculation of autocompletion and validation is handled by the grammar engine library. Only rendering is provided by the web component. It is easy to set up an editor based on different technologies.

The documentation generator

You can generate the documentation of your extensions to the grammar if necessary.

The web editor also allows you to view the documentation of the grammar in use, generated on the fly.

Known limitations

Although covering most of the rule engine’s features, there are some limitations when using DSL.

These limitations will be handled by future versions of the product.

Naming operations

The assignment of a name to an action is not possible, with the exception of the ruleset itself, “for” loops and blocks.

Dynamic properties

The VPROPERTY accessor provides access to data for which the name is dynamically built by concatenating various elements.

It is not possible to specify the suffix and prefix as in the structured XML file. However, they can be considered as elements to be concatenated.

Wrapping operations

The operations performed by the rules engine are divided into three main families:

• Executables (settinga value, adding to a list, …)
• Conditions (value1 > value2)
• Data access (and intermediate transformations)

It is common to encapsulate an operation to use it as a different type. Example:
“Set the condition (X> = 0) in a variable”.

It is not currently possible in 100% of cases to encapsulate twice in the same operation. For example, it is not possible to write:
set :value1 and :value2 into :result

while it is possible to write:
if :value1 and :value2 then ...

In the first case, value1 is a data access which as to be encapsulated as a condition. Then the condition :value1 and :value2 must also be encapsulated as a data access. This is not technically possible at the moment.

So you have to write:
set :value1 == true and :value2 == true into :result

Features awaiting implementation

Some features have not been implemented yet, because they are very specific and rarely used. They will be covered soon.

• Not implemented Accessors: CONDCOUNT et TERNARY .
• Not implemented Executable: EXEC.
• List Context Factory is not implemented .
• Unmodifiable Accessors properties:
  • Property :
    • source
    • optimizeMultiRead
  • New :
    • argumentsTypes
• Unmodifiable Executables properties:
  • Index :
    • stopAtFirstValidatedCondition
    • stopAtFirstValidatedDefaultCondition