La gestion des règles métiers et Drools

Écrit par Nadir Si Mohammed

Un peu de contexte

J’ai travaillé sur un logiciel destiné aux assureurs où la partie métier était assez présente dans mon code. Pour implémenter la partie gestion des règles métiers comme la proposition des produits selon les profils et la tarification, je suis passé par plusieurs ateliers métiers. Je n’apportais rien à cette partie du projet autant que développeur, tous ce que je faisais c’était de retranscrire des règles en français en langage technique.

Comme nombreux développeurs, avec l’équipe R&D nous avons cherché une solution robuste et flexible pour optimiser la partie de gestion des règles métiers.

Le besoin est de fournir un outil aux experts pour exprimer leurs expertises en langage simple et accessible sans passer par des ressources techniques et d’injecter ces règles dans le système. Drools se distingue comme une solution fiable et peut répondre aux besoins cités ci-dessus, donc il peut très bien endosser ce rôle crucial.

Dans cet article, je ne vais pas faire un tutoriel de comment intégrer l’outil (pom .xml, des classes java et des fichiers .drl) vu qu’internet ne manque pas de tutoriels à ce sujet mais plutôt aborder la question du pourquoi.

Drools

Drools ou Jboss Rules est un système d’exploitation multiplateforme développé en java (les normes JSR) par Jboss sous une licence Apache.

Drools est une solution du système de gestion des règles métier (Business Rules Management Solution) utilisant un raisonnement déductif en se basant sur des prémisses définies par l’utilisateur. Il fournit un moteur de règles qui traite la data ou données en entrée (Facts) et produit des résultats à la suite du traitement des règles et de la data.

Il fournit un moteur de règles métier (BRE), une application web de création et de gestion de règles (Drools Workbench), un support d’exécution complet pour les modèles DMN (Decision Model and Notation) au niveau de conformité 3 et un plugin Eclipse IDE pour le développement du cœur de la solution.

Decision Model and Notation (DMN) est une norme de l’OMG qui fournit une notation commune et visuelle facilement compréhensible par tous les utilisateurs.

Drools est né en tant que moteur de règles, mais en suivant la vision de devenir une plateforme unique pour la modélisation d’entreprise, il a réalisé qu’il ne pouvait atteindre cet objectif qu’en s’appuyant sur 3 techniques complémentaires de modélisation d’entreprise :

Gestion des règles d’entreprise (Drools Expert)
Gestion des processus métier (Drools Flow)
Traitement des événements complexes (Drools Fusion)

Les bases de Drools

Faits (FACTS): représentent les données qui servent d’entrée aux règles, les objets sur lesquels les règles sont appliquées sont appelés “faits”. Il peut s’agir d’un simple POJO Java ou d’un objet complexe. Objet Java est synonyme de faits dans Drools.
Mémoire de travail (Working Memory): stockage des faits, où ils sont utilisés pour la mise en correspondance et peuvent être modifiés, insérés et supprimés.
Règle (Rule): représente une règle unique qui associe les faits aux actions correspondantes. Elle peut être écrite en langage de règles Drools dans les fichiers .drl ou sous forme de table de décision dans une feuille de calcul Excel. Base de connaissance (Knowledge Base): représente la connaissance dans l’écosystème Drools, elle contient les informations sur les ressources où les règles sont trouvées, et crée également la session de connaissance.
Session de connaissances (Knowledge session): elle contient toutes les ressources nécessaires au déclenchement des règles, tous les faits sont insérés dans la session, puis les règles correspondantes sont déclenchées. elle est le composant central dans lequel les règles sont déclenchées. La session de connaissances est créée à partir de la base de connaissances. Pour déclencher les règles, des faits sont insérés dans la session et lorsqu’une condition d’une règle particulière est remplie, la règle suivante est déclenchée. Il existe deux types de sessions :
- Session de connaissance sans état(Stateless KnowledgeSession) :cette session ne suivra pas les changements dans les faits pendant que les règles sont déclenchées. En d’autres termes, une fois que nous avons inséré tous les faits dans la session et déclenché toutes les règles, les règles ne peuvent pas être déclenchées sur les faits mis à jour. En d’autres termes, une fois que nous avons inséré tous les faits dans la session et déclenché toutes les règles, les règles ne peuvent pas être déclenchées sur les faits mis à jour.
- Session de connaissance avec état (Stateful Knowledge Session) : Dans une session de connaissance avec état, une fois que tous les faits sont insérés et que les règles sont déclenchées, une règle met à jour le fait et, après la mise à jour du fait, une autre règle peut également être déclenchée car le fait est toujours dans la session. Comme un site web avec une session et un panier.
Module (Module): contient plusieurs bases de connaissances avec différentes sessions. Agenda : C’est un concept logique. L’agenda est l’endroit logique où les règles attendent d’être appliquées.

Comment ça fonctionne ?

Les règles sont chargées dans Rule Base, qui sont disponibles à tout moment et les faits sont affirmés dans la mémoire de travail où ils peuvent ensuite être modifiés ou rétractés.
Le processus de mise en correspondance des faits nouveaux ou existant avec les règles de production est appelé correspondance de modèles et est effectué par le moteur de règles.
L’agenda permet de gérer l’ordre d’exécution des règles conflictuelles à l’aide d’une stratégie de résolution des conflits.
Enfin nous avons les résultats.

Langage de règles (.drl)

Une règle Drools est construite d’une construction de type “WHEN” et “THEN”, la section “WHEN” exprime la condition à vérifier et la section “THEN” énumère les actions si la condition est remplie. Le dictionnaire du langage (la syntaxe du .drl) est constitué de :

package : c’est le nom du package semblable à l’instruction import de Java, le fichier de règles est situé à l’intérieur de ce package
import : semblable à l’instruction import de Java.
global : permet de définir une variable de niveau global pour une session.
dialecte : un dialecte spécifie la syntaxe employée dans les expressions de la section condition ou de la section action. Par défaut, le dialecte est Java. Drools supporte également le dialecte mvel ; il s’agit d’un langage d’expression pour les applications basées sur Java. Il prend en charge l’accès aux champs et aux méthodes/objectifs.
rule : définit un bloc de règles avec un nom de règle
when : spécifie une condition de la règle.
then : ce bloc exécute l’action lorsque les conditions du bloc when sont remplies.
end : fin de la règle

Comment exprimer une règle métier ?

Une règle nous permet de définir ce qu’il faut faire (déclarative) et non comment le faire (impérative).

Prenons un exemple en java, pour comparer le style impératif et déclaratif

Impérative vs Déclarative — Comparaison de l’impérative et le déclarative

Sinon il existe une autre manière pour décrire les règles métiers via un fichier excel. Il faut toujours respecter la syntaxe mais au lieu d’écrire dans un fichier .drl on va faire une table de décision dans un fichier excel.

Une table de décision permet de définir des règles dans une feuille de calcul Excel préformatée. Ce qui est plus simple à comprendre pour une personne non technique ou faire évoluer et exprimer la logique sous ce format.

Les points positifs et négatifs ?

J’ai eu l’occasion d’utiliser Drools dans un logiciel destiné aux assureurs. Nous avons utilisé Drools pour gérer la partie tarification du logiciel donc on a mis en disposition des experts du métier un fichier excel préformater pour définir leurs règles de tarification. Après 4 ans d’expérience, je peux faire le bilan aujourd’hui.

Les points positifs :

La centralisation de la logique d’entreprise permet d’introduire des changements rapidement et à moindre coût. Il comble également le fossé entre les équipes commerciales et techniques en permettant de rédiger les règles dans un format facile et compréhensible même pour des personnes non techniques.
L’isolation de la partie clé de la logique métier Avec DMN, les analystes commerciaux peuvent définir les exigences de décision initiales et formaliser ensuite des modèles de décision plus détaillés, les développeurs techniques peuvent automatiser les décisions dans n’importe quel processus avec une sémantique d’exécution portable permettant ainsi de comprendre pourquoi une décision a été prise à un moment donné (plus l’audit et la traçabilité)
Simulation des scénarios de tests et de validation des règles.

Les points négatifs sont :

Montée de compétences et le temps de formation des experts métiers
Complexité montante des règles métiers, on ne parle pas de deux règles avec un simple if else mais plutôt tout une logique implémentée dans un fichier excel donc il faut fournir un rendu scalable et facile à maintenir
Rigidité du moteur de règles
Difficulté d’exprimer certaines logiques complexes (certains cas demandent une certaine connaissance technique et algorithmique).