Tutoriel

Introduction

Dans ce tutoriel, nous allons voir comment mettre en œuvre le moteur de règles MRules, en passant par les différentes étapes nécessaires :

  • Définition du besoin
  • Conception du modèle objet
  • Configuration du moteur. Nous allons ici établir la configuration pour les deux grammaires XML
    • Simple
    • Complète
  • Utilisation du moteur dans un environnement multi thread
    • Écriture du code permettant de lire la configuration et exécuter les règles
    • Écriture de code de test permettant de générer des cas métier et de simuler l’environnement multi-thread.

Cas métier

L’objet de ce tutorial étant de présenter l’utilisation, nous allons étudier un cas dont la configuration est relativement simple.

A l’inscription sur un site Web, l’utilisateur reçoit un cadeau de bienvenue. Le cadeau est différent selon les caractéristiques de l’utilisateur. Les critères et le cadeau évoluent régulièrement, le moteur de règles sera donc responsable de lire les caractéristiques pertinentes et de définir le cadeau attribué.

Les caractéristiques d’un utilisateur sont :

  • Sa date de naissance, de laquelle est déduite son age
  • Son sexe
  • Sa ville

Les règles sont :

  • Un homme de moins de 25 ans reçoit un t-shirt
  • Une femme de moins de 30 ans reçoit un maillot de bain
  • Un utilisateur de plus de 60 ans reçoit un coffret foie gras
  • Les autres utilisateurs reçoivent une bouteille de vin

Modèle objet

Le modèle objet est ici simpliste. Un seul Bean Java contiendra les éléments d’entrée / sortie.

Configuration des règles

La configuration de la grammaire XML simple est la suivante :

La configuration de la grammaire XML complète est la suivante :

Test en environnement multi thread

Préparation

Tout d’abord, nous allons créer deux classes utilitaires permettant de simuler l’environnement et de créer des cas de test.
Le Rules Runner est une classe abstraite permettant d’exécuter le moteur de règles sur une liste d’Objets. Ses implémentations contiendront le code dédié à invoquer MRules. Qu’elles soient ensuite appelées par un Batch, une Servlet ou comme ici un TU ne change pas leur finalité.

Le RuleTestThread est un Thread qui va créer les cas de test, exécuter le moteur de règles via une implémentation de AbstractRulesRunner et tester les résultats. Si une exception est levée elle sera stockée. Cette classe va permettre d’émuler un environnement concurrent.

Implémentation

Nous allons ici implémenter le code qui permettra de lire la configuration et d’exécuter le moteur. Trois implémentation possible du Rules Runner sont présentées et comparées.

L’objectif principal de ce tutorial est de clarifier l’utilisation cible du Rule Set :

  • L’instance du Rule Set peut (et devrait) être unique et centralisée. Elle est dans ce cas partagé entre tous les Thread. Les phases de relecture de la configuration et de compilation ne doivent se faire qu’en cas de modification de la configuration.
  • Le Contexte d’Exécution est dédié à une exécution et ne peut pas être centralisé ni partagé entre les processus concurrent. Chaque Thread n’instantie cependant qu’un et un seul contexte, car en son sein les exécution ne sont pas simultanées et concurrentes.

 

La première implémentation présentée permet de lire la configuration de type grammaire complète, en utilisant l’utilitaire centralisé MRulesBuilder. Des paramètres doivent être transmis à l’utilitaire, qui va se charger de construire une et une seule fois l’instance, même s’il y a une concurrence d’appel.

Ces paramètres sont ceux que l’on retrouve pour la déclaration d’une ressource JNDI ou pour l’injection CDI.

L’avantage de ce code, même s’il est légèrement plus verbeux, est que si le fichier de configuration est modifié, il sera automatiquement rechargé grâce au paramètre « checkhash ».

 

La deuxième implémentation présenté permet également de lire la grammaire complète, mais sans passer par le builder.

Une champ statique est déclaré et valué à l’initialisation de la classe. Cette technique garantit, de par les spécifications de la JVM, que la construction du moteur (donc la phase coûteuse de compilation) ne sera effectuée qu’une seule fois.

 

La dernière implémentation présentée permet de lire la grammaire simple, selon la même technique de champ statique.

Since the version 1.4.0 of MRules, the simple grammar allows to specify the context factory to use. Until 1.3.0, a compilation context had to be provided to the factory.

Depuis la version 1.4.0 de MRules, la grammaire simple permet de préciser la fabrique de contexte à utiliser. Jusqu’en version 1.3.0, un contexte de compilation devait obligatoirement être fourni à la fabrique.

Lancement

Le lancement se fait par un test JUnit standard, qui va créer un 100 Thread par Rules Runner (donc 300 en tout) et les exécuter.

On voit parfaitement bien dans les logs que seules 3 compilations sont effectuées, pour chaque Runner.

 

Le téléchargement du projet de test complet sera bientôt disponible.