Détail de la DSL du Moteur de Règles

Concepts généraux

La configuration du moteur de règles MRules peut, en version 1, passer par deux moyens :

  • L’utilisation des API Java.
  • Un fichier XML structuré.

Dans les deux cas, la création et l’édition de la configuration doit être faite par un intervenant technique. Ou alors une IHM de configuration doit être développée, permettant des modifications plus ou moins approfondie de la configuration.

Pour palier à cette limitation, un nouveau moyen a été créé. Il repose sur un autre des produits proposés par MRules : le moteur de grammaire. Une extension proposant une syntaxe de configuration proche du langage naturel a été développée.

Elle permettra au intervenant fonctionnel de pouvoir lire, comprendre et modifier la configuration des règles métier de leur domaine, sans besoin de support technique ou d’IHM dédiée.

Détails de la grammaire

La grammaire de configuration du moteur de règles est composée d’un ensemble de mots ou groupes de mots clés, appelés lexèmes. Mis bout à bout, ils composent un texte lisible et compréhensible, bien que différent de ce qu’il serait en langage « parlé ».

La grammaire est disponible nativement pour l’instant en langue anglaise. La version française sera disponible dans les prochaines versions.

Le détails de tous les lexèmes proposés et de leurs enchainements est disponible sur la documentation générée de la grammaire.

Étendre la grammaire

Prise en compte de développements spécifiques

Il est possible d’étendre la moteur de règles MRules en lui ajoutant des fonctions non proposés nativement (développement d’Addons).

Il est bien entendu possible d’étendre la grammaire pour prendre en compte vos développements spécifiques. En d’autre termes, l’ajout de lexèmes dédiés est prévu et passe par quelques étapes simples :

  • Créer le fichier « grammar/inc/mrules-natural-language-grammar-extensions.xml » accessible via le CLASSPATH de l’application utilisatrice. Ce fichier est automatiquement pris en compte si existant.
  • Configurer dans ce fichier les lexèmes supplémentaires à intégrer à la grammaire.

Traduction

Si vous avez besoin de proposer à vos utilisateurs la grammaire dans des langues différentes de celles nativement incluses, il est simple d’effectuer vous-mêmes vos traductions.

Il suffit de dupliquer le fichier « mrules-natural-language-grammar.xml » et ses inclusions et de nommer la copie « mrules-natural-language-grammar_XX.xml », XX étant la locale désirée. Modifier ensuite le contenu des fichiers dupliqués pour le traduire.

Les variantes localisées sont automatiquement prises en compte dès qu’elles sont disponibles dans le CLASSPATH.

Également, vous pourrez générer la documentation correspondant à votre traduction grâce à l’outillage.

La fabrique

L’extension fournit une classe de Fabrique (Factory) afin de faciliter la lecture de la configuration et la construction du ruleset.

Plus de détail sur la page dédiée à la construction de l’instance.

Outillage

Des outillages sont fournis avec le moteur de grammaire pour faciliter son utilisation.

L’éditeur Web

Il serait compliqué et rébarbatif de connaître par cœur tous les lexèmes. Ainsi, nous avons développés un composant Web d’édition de configuration du moteur de règles.

Ce composant est basé sur l’éditeur JavaScript ACE et est packagé sous la forme d’un Widget Vaadin.

Il permet une autocomplétion intuitive et une validation de la syntaxe lors de la frappe.

Le calcul de l’autocomplétion et de la validation est gérée par la librairie de moteur de grammaire. Seul le rendu est assuré par le composant Web. Il est aisé de mettre en place un éditeur sur des technologies différentes.

Le générateur de documentation

Vous pourrez générer la documentation de vos extensions à la grammaire le cas échéant.

L’éditeur Web permet également d’afficher la documentation de la grammaire en cours d’utilisation, générée à la volée.

Limitations connues

Bien que couvrant la majorité des fonctionnalités du moteur de règles, certaines limitations sont présentes lors de l’utilisation de la DSL.

Ces limitations s’amenuiseront au fur et à mesure des versions.

Nommage des opérations

L’affectation d’un nom à une action n’est pas possible, à l’exception du ruleset lui-même, des boucles « for » et des blocks.

Propriétés dynamiques

L’accesseur VPROPERTY permet d’accéder à une données dont le nom est construit dynamiquement, par concaténation de divers éléments.

Il n’est pas possible de spécifier les suffixe et préfixe comme dans le fichier XML structuré. Il peuvent cependant être considérés comme  des éléments à concaténer.

Encapsulation des opérations

Les opérations effectuées par le moteur de règles sont réparties en trois grandes familles :

  • Exécutables (positionnement d’une valeur, ajout dans une liste, …)
  • Conditions (valeur1 > valeur2)
  • Accès aux données (et transformations intermédiaires)

Il est fréquent d’encapsuler une opération pour qu’elle soit utilisée comme étant d’un type différent. Exemple :
« Positionner la condition (X >= 0) dans une variable ».

Il n’est pas possible actuellement dans 100% des cas de faire une double encapsulation dans une même opération. Il n’est par exemple pas possible d’écrire :
set :valeur1 and :valeur2 into :resultat

alors qu’il est possible d’écrire
if :valeur1 and :valeur2 then ...

Dans le premier cas, :valeur1 est un accès aux données devant être encapsulé en tant que condition. Puis la condition :valeur1 and :valeur2 doit également être encapsulée en tant qu’accès aux données. Ceci n’est pas techniquement possible pour le moment.

Il faut donc écrire
set :valeur1 == true and :valeur2 == true into :resultat

Fonctionnalités en attente d’implémentation

Certaines fonctionnalités n’ont pour l’instant pas été mise en place, car très spécifiques et peu utilisées. Elle seront couvertes à court terme.

  • Accesseurs non implémentés : CONDCOUNT et TERNARY .
  • Exécutable non implémenté : EXEC.
  • List Context Factory non implémenté.
  • Propriétés non modifiables des Accesseurs :
    • Property Accessor :
      • source
      • optimizeMultiRead
    • New :
      • argumentsTypes
  • Propriétés non modifiables des Executables :
    • Index :
      • stopAtFirstValidatedCondition
      • stopAtFirstValidatedDefaultCondition
  • Enfin, il n’est pas possible pour le moment d’ajouter des propriétés personnalisées au Rule Set, permettant par exemple d’ajouter un Optimizer personnalisé.