Une fois l’interface mise en œuvre, la bonne clé choisie et le processus rodé, il faut envisager les éventuelles suppressions dans l’application source.
Dans la mesure où celle-ci crée, modifie et détruit des données, il est nécessaire de refléter chacun de ces événements. La difficulté se situe souvent au niveau de la suppression.
Comment une application supprime t’elle des données ?
La façon la plus évidente est de remplacer une valeur par RIEN. Il faut toutefois être prudent sur l’idée du RIEN. Quand on parle d’une chaîne de caractères, RIEN est une chaîne (vide en l’occurrence).
Quand on parle d’un nombre , RIEN n’est pas un nombre donc il convient de savoir si RIEN a un sens ou si l’application se contente de mettre la valeur à 0, ce qui n’est clairement pas la même chose.
Le problème se complique franchement avec les dates où le RIEN certes peut exister, mais est souvent remplacé par la plus vielle date connue de l’application. Et suivant le cas, celle-ci peut être située en 1600, au 21/12/1899 ou au 1/1/1900 suivant l’humeur du concepteur de la base de données.
Mais le vrai problème est dans la suppression des objets
Si l’intégralité d’un objet disparait, la source ne le connait évidemment plus et cessera de fournir des informations le concernant. Il suffit donc de le supprimer dans la cible. Certes, mais comme la source n’en parle plus, on ne sait pas qu’on doit le supprimer.
Une solution coûteuse en traitement mais qui fonctionnera, est de marquer la date de mise à jour dans la cible pour chaque objet. Quand une date n’évolue plus c’est que l’objet n’est plus dans la source.
De façon plus élégante, il est souhaitable que la source fournisse une information d’obsolescence, un attribut, un statut, mais dans ce cas on continuera à recevoir les objets effacés à l’infini ce qui à terme posera de nouveau un problème de temps de traitement.
La solution idéale est de disposer d’un attribut comportant la date de destruction, qui pourra être filtré et éventuellement d’isoler les objets détruits dans un flux particulier.
Un exemple concret sur les annuaires LDAP
Dans ce cas particulier, on va utiliser la date du compte et l’attribut compte désactivé pour identifier les comptes à supprimer. On y associera une UO (unité d’organisation) « Comptes Désactivés » avec une durée de rétention suffisante des comptes qui y sont déplacés (quelque part entre la durée minimale de conservation des journaux de sécurité et la durée maximale de conservation des données privées dans le cadre du RGPD).
Un process de synchronisation aura donc loisir de traiter les disparitions, dès lors que les gestionnaires n’appuient pas froidement sur la touche suppression…
Ces articles pourrait vous intéresser :
Olivier Piochaud, PDG d’Apsynet
