Build the instance

We’ll see here the various available solutions to obtain running instance of the rule engine.

Java API

It is possible to use exposed public MRules APIs to build or modify an instance.

3 main steps are necessary:

  • Instanciation of Objects structure.
  • Compilation context instanciation and compilation.
  • Execution context instanciation and execution.

An already existing and compiled instance may be altered, in which case the changes made will only be taken into account after a new compilation.

The simple code below shows an example of an instance printing in console “Good Morning!” up to 12, “Good Afternoon!” until 20PM and then “Good night!”.

However, it is obvious that this method is very verbose. It has the main disadvantage of not being able to be modified without the intervention of a development team.

The use of the API may however be useful to create a GUI dedicated to the modification of an existing instance built by a Factory.


A Rule Engine Factory is a Java Class implementing the IRuleExecutionSetFactory interface. This interface defines the compilation parameters and methods for reading / writing.

In fact, the overall contract of a factory implementation is to manage both configuration reading (building the rule engine instance from a configuration) and writing (saving the configuration from the rule engine instance).

The factory will also perform the compilation phase when reading if it has enough information to do it :

  • A compilation context is provided to the factory, with necessary data filled (input / output data).
  • The ruleset can provide a context factory, which will allow to instantiate automatically required data.

The current version of MRules provides three implementations:

Light XML grammar

The Factory class is SimpleXMLFactory. It handles a simple grammar which does not take into account all the Addons or all the conditionning possibilities.

This syntax has the following principles:

  • Defining conditions / actions blocks (“rule”). For each of them :
  • Test one or more input bean property value (all operators are handled)
  • Set one or more output bean property.

Example :

However, this grammar might be quite enough in many cases.

Full XML grammar

The Factory class is RichXMLFactory. It allows usage of all Addons, including specific implementations. They must declare the configuration properties to save through the PersisantProperties et PersistantProperty annotations.

The root node declares the IMRuleExecutionSet to use and its configuration properties (Persistant Property). The “implem” attribute is requiered for each Addon declaration , providing its unique implementation ID.
Each attribute on nodes represents a configuration parameter for the declared Addon. Note the syntax “PROPERTY:#TIME”: it allows to avoid declaring a child node to declare a sub-addon, by providing as argument it’s default property value. Not all Addons declare a default property: they are described on the Addons Properties page. It’s also possible to chain Addons, for example: “NULLIFEMPTY:PROPERTY:myProperty.mySubProperty”.
Each child node also represent a configuration parameter for the parent Addon, which cannot be represented directly as an attribute.

The following example reproduces the demo using the Java API:

The following Java laucher may then be used:

Note that the above syntax might be much more compact in terms of XML representation, by setting sub-objects properties values directly in parents nodes. It is perfectly functional at reading but is not yet managed for writing:

To be noted, in this example, the factory performs the compilation, but a context has to be instantiated and provided by launcher. By specifying a Context Factory in the rule engine configuration, all data required for compilation will be automatically instantiated. The feature is very interesting if instances are meant to be centralized using the Builder (cf. Accessing the instances).

A little change in the XML configuration is enough to achieve this:

The following simplified Java laucher may then be used:

The complete grammar also allows to store  the generic properties of the rule set. These properties are accessible programmatically via the “setProperty” and “getProperty” methods. The syntax is very simple:

DSL Grammar

To be able to use this grammar and therefore the associated factory, you need the license for the Grammar Engine (“mrules-dsl”). You also need to import the “mrules-ext-dsl-bre” extension dependency .

The factory class is NativeLanguageFactory. It makes it easier to build a ruleset configured with the “Natural Language” grammar based on our grammar engine.

We invite you to consult the extension details page for more details on how to use the grammar and for more precise description of the syntax and editing tools.

The following example reproduces the demo by using this grammar:

The following Java laucher may then be used:


Another implementation can back up an instance using the Java binary serialization. The stream can optionally be encoded in Base 64.