Moteur de règle

Le moteur de règle va être utilisé pour :

Il doit donc être suffisamment générique pour pouvoir servir dans les cas pré-cités.

Implémentation
Base de données =
Une règle est composée de 3 éléments :
  • une description
  • un ensemble de 1 à n critère(s)
  • un ensemble de 1 à n action(s) à effectuer une fois la règle vérifée

3 tables sont ajoutées dans la base de données :
  • glpi_rules_description : indique la description de la règle
    CREATE TABLE @glpi_rules_descriptions@ (
    @ID@ int(11) NOT NULL auto_increment,
    @FK_entities@ int(11) NOT NULL default '-1', <- indique si la règle est globale (FK_rules à -1) ou par entité
    @rule_type@ smallint(4) NOT NULL, <- type de règle (affectation de machines, droits depuis ldap, businessrules etc)
    @ranking@ int(11) NOT NULL, <- indique le rang de la règle par rapport aux autres règles
    @name@ varchar(255) NOT NULL, <- titre de la règle
    @description@ text NOT NULL, <- description de la règle
    @match@ varchar(255) NOT NULL, <- 'AND' ou 'OR' indique si critères sont traités en tant que (A & B & C) ou (A | B | C)
    PRIMARY KEY  (@ID@)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1; 
    
  • glpi_rule_criterias : indique tous les critères dont est composée une règle
    CREATE TABLE @glpi_rules_criterias@ (
    @ID@ int(11) NOT NULL auto_increment,
    @FK_rules@ int(11) NOT NULL,
    @criteria@ varchar(255) NOT NULL, <- indique le champs à vérifier (TAG, domaine etc)
    @condition@ smallint(4) NOT NULL, <- indique la condition (is, is_not, contain, not_contain, begin, end)
    @pattern@ varchar(255) NOT NULL, <- indique l'expression à vérifier
    PRIMARY KEY  (@ID@)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
    
  • glpi_rules_actions : cette table décrit les actions à faire quand une règle est vérifiée.
    CREATE TABLE @glpi_rules_actions@ (
    @ID@ int(11) NOT NULL auto_increment,
    @FK_rules@ int(11) NOT NULL, <- clef indiquant à quelle règle l'action est rattachée
    @action_type@ varchar(255) NOT NULL, <- indique le type d'action à effectuer si la règle est vérifiée (set, add, delete etc)
    @field@ varchar(255) NOT NULL, indique le champs sur lequel la règle s'applique
    @value@ varchar(255) NOT NULL, indique la valeur que doit recevoir le champs si la règle est vérifiée 
    PRIMARY KEY  (@ID@)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
    

Proposition d'implémentation

Tous les modules ayant besoin du moteur de règles générique n'ont pas obligation de se servir de tous les champs de la base de données.
Par exemple, il est possible de définir seulement des règles à portée globale, et donc de ne pas se servir du champs FK_entities dans glpi_rules_descriptions.

Les types de conditions pour vérifier une règle sont :
  • IS : la valeur à traiter est exactement la même que celle définie dans la règle
  • IS_NOT : la valeur à traiter n'est pas la même que celle définie dans la règle
  • CONTAIN : la valeur à traiter contient la valeur définie dans la règle
  • NOT_CONTAIN : la valeur à traiter ne contient pas la valeur définie dans la règle
  • BEGIN : la valeur à traiter commence par la valeur définie dans la règle
  • END : la valeur à traiter se termine par la valeur définie dans la règle
Les types d'actions en cas de vérification de la règle sont :
  • set : affecte une valeur à un champs ex " on affecte l'id 14 au champs assign"
  • add : ajoute une valeur à un champs ex "on incrémente une valeur " (non utilisé pour le moment)
  • delete : efface la valeur d'un champs (non utilisé pour le moment)
    etc les types d'action pourront être ajoutés au fur et à mesure des besoins. Pour le moment on a juste besoin du "set"

Fonctionnement du moteur

Le moteur s'appuie sur différentes classes :
  • RuleDescription : objet permettant d'accès à la description des règles. Son ID est considéré comme l'ID de la règle
  • RuleCriteria : objet qui stocke un critère d'une règle
  • RuleAction : objet qui stocke une action qui doit être déclenchée si la règle matche
  • Rule : classe qui permet de manipuler une règle complète (Description + n Critères + n Actions).
Lorsque l'on veut utiliser le moteur de règle pour un usage bien précis (affectation, droits ldap, business rules etc...), il faut créer sa propre classe qui étend Rule.
Par exemple, pour les affectations de machines à une entité, la classe OcsAffectEntityRule a été crée.
Chaque classe qui étend Rule doit implémenter les fonctions suivantes :
  • processAllRule()