But

Disposer de règles permettant de modifier les valeurs de certaines données remontées par OCS.
A l'heure actuelle, celles-ci sont :
  • nom du logiciel
  • version du logiciel
  • fabricants
  • modèles (ordinateurs, moniteurs, imprimantes, réseau, téléphones, périphériques)
  • types (ordinateurs, moniteurs, imprimantes, réseau, téléphones, périphériques)
  • OS (nom, service pack, version)

Ce qui est implémenté à l'heure actuelle

Le dictionnaire est implémenté pour les types ci-dessus dans la version 0.71.

Ajout de classes au moteur de règles

Le dictionnaire est basé sur le moteur de règles.
Un type de règle par type a été crée, reprenant la nomemclature suivante : RULE_DICTIONNARY_<TYPE>

Plusieurs classes du moteur de règles ont été crée afin de prendre en charge le dictionnaire :

Ajout de droits supplémentaires

Plusieurs droits ont été ajoutés afin de séparer la gestion des dictionnaires :
  • rule_dictionnary_software
  • rule_dictionnary_model
  • rule_dictionnary_type
  • rule_dictionnary_os

Ajout d'actions au moteur

J'ai ajouté 2 actions, en plus d'assigner :
  • assigner valeur depuis regex : permet de remplacer la valeur du champs par le résultat d'une regex (indiquer #0 renvoie le premier résultat de la regex, #1 le 2ème, etc..)
  • ajouter résultat regex : ajoute au champs le résultat de la regex (indiquer #0 renvoie le premier résultat de la regex, #1 le 2ème, etc..)

J'en ai profilé aussi pour ajouter une nouvelle option pour les actions des règles (à discuter avec MoYo pour voir si y'a plus simple):

$RULES_ACTIONS[<type de règle>][<nom de l'action>]['optional_actions']=array("regex_result","append_regex_result");

Cela permet, par action, de pouvoir définir un ensemble d'action supplémentaires (donc en plus de "assign" qui est par défaut). Dans le cas ci-dessus, les 2 actions ci-dessus sont décrites plus haut.

Ajout d'un cache pour le moteur de règles

Chaque dictionnaire de données possède sa propre table de cache. Celle-ci répond à la nomenclature suivante : glpi_rule_cache_<type>
Elle contient 3 types de champs :
  • rule_id : indique l'ID de la règle
  • les anciennes valeurs : le cache stocke les valeurs avant modification par le dictionnaire
  • les nouvelles valeurs : stockage des valeurs modifiées

L'utilisation du cache est décrite via l'attribut de classe use_cache dans RuleCollection.

Pour fonctionner, le cache a besoin des données suivantes :
  • DictionnaryRuleCollection :
    • use_cache : utilisation du cache (true)
    • cache_table : nom de la table de cache pour ce type
    • cache_paramsinput_value : tableau contenant la description des anciennes valeurs
    • cache_paramsoutput_value : tableau de description des nouvelles valeurs
Fonctionnement du cache, exemple du dictionnaire des fabricants :
  • un nouveau fabricant remonte depuis OCS
  • la fonction externalImportDropdown traite le nom du fabricant
  • le moteur de règles de fabricants est appelé avec comme valeur de départ le nom
  • une requête est effectuée dans la table du cache des fabricants (glpi_rule_cache_manufacturer) pour voir si le nom est présent
    • le nom est présent : le moteur de règle renvoie directement la valeur modifiée récupérér par la requête précédente
    • le nom n'est pas présent : le moteur de règles rejoue toutes les règles et, si le nom matche une règle, inscrit les données (ancien nom, nouveau nom) dans le cache
  • le nouveau nom est inscrit dans glpi_dropdown_manufacturer (s'il n'existe pas) et son ID est renvoyé

Le cache permet de réduire le temps de traitement du moteur de règles.

Il est possible de visualiser les données du cache, par type de règles, en cliquant sur le lien "Informations sur le cache" présent dans la page qui liste celles-ci.
Une fenêtre popup s'ouvre, indiquant le nom chaque règle, ainsi que le nombre d'éléments du cache s'y rapportant. En cliquant sur le nom, une page de détail apparaît qui liste tout le contenu du cache pour celle-ci.

Dictionnaire des fabricants

La table de cache s'appelle glpi_rules_cache_manufacturer.
Elle a la structure suivante :

CREATE TABLE @glpi_rule_cache_manufacturer@ (
  @ID@ int(11) NOT NULL auto_increment,
  @old_value@ varchar(255) NOT NULL,
  @rule_id@ int(11) NOT NULL,
  @new_value@ varchar(255) NOT NULL,
  PRIMARY KEY  (@ID@),
  KEY @rule_id@ (@rule_id@),
  KEY @old_value@ (@old_value@)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

  • old_value : la valeur du fabricant avant passage dans le dictionnaire
  • new_value : le nom du fabricant modifié

Le dictionnaire est appliqué à chaque fois que l'on appelle externalImportDropdown.

Réapplication du dictionnaire sur la base existante

Actuellement :
  • On sélectionne l'ensemble des fabricants
  • Pour chaque fabricant on lance le dictionnaire
  • Si l'ID du fabricant a changé
    • on modifie l'ID du fabricant dans l'ensemble des tables qui l'utilise (COMPUTER_TYPE, PRINTER_TYPE, SOFTWARE_TYPE, PHONE_TYPE, PERIPHERAL_TYPE, NETWORKING_TYPE, MONITOR_TYPE)
    • on supprime l'ancien fabricant

Dictionnaire des logiciels

Le cache des logiciels est stocké dans la table glpi_rule_cache_software.
Elle a la structure suivante :

CREATE TABLE @glpi_rule_cache_software@ (
  @ID@ int(11) NOT NULL auto_increment,
  @old_value@ varchar(255) NOT NULL,
  @manufacturer@ varchar(255) NOT NULL,
  @rule_id@ int(11) NOT NULL,
  @new_value@ varchar(255) NOT NULL,
  @version@ varchar(255) default NULL,
  PRIMARY KEY  (@ID@),
  KEY @rule_id@ (@rule_id@),
  KEY @old_value@ (@old_value@)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

  • old_value : le modèle avant passage dans le dictionnaire
  • manufacturer : le nom du fabricant
  • new_value : le nom du modèle modifié (ou blanc si aucune modification)
  • version : la version modifiée (ou blanc si aucune modification)

Le dictionnaire est appliqué à chaque fois que l'on appelle externalImportDropdown.
Les règles prennent comme critères le nom du modèle et/ou le nom du fabricant

Fonctionnement à l'heure actuelle (à discuter) :

Lors de l'import depuis OCS

Lorsqu'un logiciel est remonté d'OCS, le dictionnaire est appelé en passant le nom de celui-ci et le fabricant au moteur de règles. Ce-dernier renvoie le nom et la version (vide si non modifiée) qui seront ensuite traités dans le processus d'importation classique.

Je prends comme hypothèse qu'on ne peut pas utiliser le dictionnaire OCS et celui de GLPI en même temps.
Si le dico OCS est activé, alors celui de GLPI n'est pas appliqué
  • à discuter
  • voir comment prévenir l'utilisateur du fait que les 2 dicos sont incompatibles

Réapplication du dictionnaire sur la base existante

Processus à discuter.
Actuellement :
  • On sélectionne l'ensemble des logiciels de manière unique
  • Pour chaque logiciel, on récupère l'ensemble des versions
  • On passe le moteur de règle pour le logiciel, par version
    • si le nom ou la version n'a pas changé, on ne fait rien
    • si le nom ou la version a changé, on lance le processus de déplacement du logiciel et des licenses
Changement de nom et déplacement des licenses :
  • Si le nom du logiciel a changé :
    • rechercher si un logiciel de même nom existe déjà, si non, alors modifier le nom du logiciel
  • rechercher toutes les licenses du logiciel
    • pour chaque license : voir si une même license existe pour le logiciel
      • non : modifier glpi_license pour faire pointer sur un autre logiciel
      • oui : fusionner les 2 licenses
    • si le logiciel a changé, modifier glpi_inst_software

Une fois que toutes les licenses ont été traité, si besoin, l'ancien logiciel est supprimé.

Cette partie est à discuter :
  • gestion des conflits ?
  • création automtique d'un autre logiciel avec report des licenses dessus ?
  • mise à la poubelle, ou à un état particulier des logiciels supprimés, avec ajout d'un ligne dans l'historique ?

Dictionnaire des modèles

Chaque modèle possède une table de cache (type d'ordinateur, type de moniteurs, etc...). Celle-ci se nomme glpi_rules_cache_model_<type>.
Elle a la structure suivante :

CREATE TABLE @glpi_rule_cache_model_<type>@ (
  @ID@ int(11) NOT NULL auto_increment,
  @old_value@ varchar(255) NOT NULL,
  @rule_id@ int(11) NOT NULL,
  @new_value@ varchar(255) NOT NULL,
  @manufacturer@ varchar(255) default NULL,
  PRIMARY KEY  (@ID@),
  KEY @rule_id@ (@rule_id@),
  KEY @old_value@ (@old_value@)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

  • old_value : le modèle avant passage dans le dictionnaire
  • manufacturer : le nom du fabricant
  • new_value : le nom du modèle modifié

Le dictionnaire est appliqué à chaque fois que l'on appelle externalImportDropdown.
Les règles prennent comme critères le nom du modèle et/ou le nom du fabricant

Réapplication du dictionnaire sur la base existante

Actuellement :
  • On sélectionne l'ensemble des modèles
  • Pour chaque modèle on lance le dictionnaire
  • Si l'ID du modèle a changé
    • on modifie l'ID du modèle dans la table (chaque type de modèle est rattaché à une table)
    • on supprime l'ancien modèle

Dictionnaire des types

Chaque modèle possède une table de cache (type d'ordinateur, type de moniteurs, etc...). Celle-ci se nomme glpi_rules_cache_type_<type>.
Elle a la structure suivante :

CREATE TABLE @glpi_rule_cache_type_<type>@ (
  @ID@ int(11) NOT NULL auto_increment,
  @old_value@ varchar(255) NOT NULL,
  @rule_id@ int(11) NOT NULL,
  @new_value@ varchar(255) NOT NULL,
  PRIMARY KEY  (@ID@),
  KEY @rule_id@ (@rule_id@),
  KEY @old_value@ (@old_value@)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

  • old_value : le type avant passage dans le dictionnaire
  • new_value : le nom du modèle modifié

Le dictionnaire est appliqué à chaque fois que l'on appelle externalImportDropdown.

Réapplication du dictionnaire sur la base existante

Actuellement :
  • On sélectionne l'ensemble des types
  • Pour chaque modèle on lance le types
  • Si l'ID du type a changé
    • on modifie l'ID du type dans la table (chaque type est rattaché à une table)
    • on supprime l'ancien type

Dictionnaire des OS, Service Pack, Version

Même principe que pour les modèles, types etc...

Ancienne version de la page =
But ==

Disposer d'un dictionnaire dans GLPI qui permet de :
  • modifier le nom des logiciels
  • modifier le nom des fabricants

Propositions

  • utiliser le moteur de règles
  • implémenter un système de cache afin d'accélérer les performances
Chaque entrée du dictionnaire correspond à une règle du moteur :
  • Nom : nom de la règle
  • Critères :
    • nom original
  • Actions :
    • Assigner nom
    • Ignorer le traitement de l'item
Le dictionnaire doit permettre de :
  • modifier le nom du logiciel ou du fournisseur lors de l'import
  • pouvoir modifier les logiciels et fournisseurs existants
Ajouter :
  • un nouveau type de règles : RULE_DICTIONNARY
  • ajouter un droit de gestion du dictonnaire
  • modifier le moteur de règles pour permettre de vérifier la présence ou non d'une valeur dans une table avant de lancer traitement des règles

Questions

  • MoYo : A t'on besoin d'un dictionnaire pour autre chose ?
    • Walid : Les noms des écrans aussi, les types d'ordinateurs ?
  • MoYo : Un type de règle par table ou un type de règle globale ?
    • Walid : moi je serai pas contre une table par type. Ca permet d'avoir des tables plus petites
  • MoYo : est-ce que la version des logiciels est déterminante ?
    • Walid : non en fait c'est trop tordu, le nom du soft ça suffit amplement !
  • MoYo : Comment faire le clean du cache des règles (en stockant la règle associée à la valeur en cache)
    • Walid : pourquoi pas stocker directement dans une table 'ID élément' , 'nom élement','ID règle','valeur dico' ? comme ça c'est plus simple. Quand on veut modifier une règle, on fait un select en passant l'ID comme param
      • MoYo : c'est ce que je pensais :)
        • ajout d'une règle : on ajoute rien dans la table
        • un soft qui matche la règle mais n'est pas dans la table : on l'ajoute à la table
        • modification d'une règle du dico : on fait un update filtrée par ID ou on modifie juste le nom attribué par le dico -> rapide
          • MoYo : ca dépend de ce qui est modifié si c'est le résultat oui si ce sont les critères il faut supprimer les entrées
        • suppression d'une règle : on fait un delete de la règle par ID
  • Walid : pour appliquer les modifs sur la base existante, je pensais que les modifs devraient pas être appliquées dès que la règle est modifiée. Prévoir une page ou un bouton quelque part "appliquer les modifications au dictionnaire"
    • MoYo : oui un bouton réappliquer la règle ca me semble plus simple à gérer
  • Walid : pour stocker le nom original de l'élément, on ajoute un champs dans la table de l'élément du type "original name" ?
    • MoYo : pour moi il ne faut pas stocker le nom original, une fois modifié c'est le nouveau nom qui prime. Sinon on va se retrouver avec des masses de données en doubles. Comment gérer le fait dans les dropdowns par exemple que 2 original names amène au même display name ?
  • Walid : on crée un type de règles ? plusieurs ? pour les droits, on sépare qui a le droit au dico des softs, fournisseurs, etc ?
    • MoYo : déja il faut définir les tables que l'on veux dictionnariser. Si il y en a beaucoup il faut un droit global sinon ca sera ingérable.
    • Walid : pour les tables, ce qui vient d'OCS est effectivement un bon début :
      • glpi_software
      • glpi_dropdown_manufacturer
      • glpi_dropdown_model
      • glpi_dropdown_model_monitors
      • glpi_dropdown_model_networking
      • glpi_dropdown_model_peripherals
      • glpi_dropdown_model_phones
      • glpi_dropdown_model_printers
      • glpi_dropdown_os
      • glpi_dropdown_os_sp
  • Walid : est ce qu'on fait un seul type de règles ou n types ? si on en fait un seul, il faut ajouter un param quelque part qui permet d'indiquer si on parle de règles sur les logiciels, fournisseurs etc...

Questions complémentaires

  • Walid : des fois on se retrouve avec des logiciels dont le numéro de version est contenu dans le nom, et dont le numéro de version n'est pas correct (par exemple Correctif Windows XP - KB890859 (v. 1) ). Il serait intéressant d'imaginer un mécanisme configurable basé sur une regex qui permettrait de traiter en amont le logiciel pour en extraire une valeur de version correcte