Bien utilisées, les règles permettent de personnaliser la manière dont DirXML envoie et reçoit les mises à jour.
Pour bien comprendre les règles, il faut connaître certains détails relatifs aux objectifs d'un module d'interface pilote.
Le développeur d'un module d'interface pilote tente, lorsqu'il l'écrit, d'inclure la possibilité de synchroniser tout ce que pourrait utiliser une entreprise qui déploie le pilote. Il le rédige de sorte que toute modification d'importance dans le système connecté soit détectée et transmise à Novell® eDirectoryTM.
Cette modification est enregistrée dans un document XML et mise en forme selon la spécification DirXML. L'extrait suivant présente l'un de ces documents XML.
<nds dtdversion="2.0" ndsversion="8.7.3">
<source>
<product version="2.0">DirXML</product>
<contact>Novell, Inc.</contact>
</source>
<input>
<add class-name="User" event-id="0" src-dn="\ACME\Sales\Smith"
src-entry-id="33071">
<add-attr attr-name="Surname">
<value timestamp="1040071990#3" type="string">Smith</value>
</add-attr>
<add-attr attr-name="Telephone Number">
<value timestamp="1040072034#1" type="teleNumber">111-1111</value>
</add-attr>
</add>
</input>
</nds>
Ensuite, selon ce que vous souhaitez obtenir, il peut vous être égal qu'un utilisateur nommé Smith, dont le numéro de téléphone est le 111-1111, a été ajouté à un système. Mais cela pourrait intéresser d'autres intervenants.
En fait, les pilotes sont conçus pour signaler toute modification importante, puis pour permettre de la filtrer ou la modifier comme vous le jugez adapté. Savoir quelles sont les modifications importantes et comment les traiter se gère dans le moteur, et non dans le module d'interface pilote.
Si une société n'est pas très concernée par les utilisateurs, elle peut installer un filtre qui bloque toutes les opérations relatives aux utilisateurs dans eDirectory ou dans le système connecté. Si elle est particulièrement concernée par ce sujet, elle peut installer un filtre inverse.
La définition de filtres visant à empêcher la synchronisation des objets qui ne vous intéressent pas constitue la première étape de la personnalisation des pilotes.
L'étape suivante définit ce que fait DirXML avec les objets qui ne sont pas bloqués par votre filtre. À titre d'exemple, voyons l'opération d'ajout dans le document XML qui précède. Un utilisateur nommé Smith, dont le numéro de téléphone est le 111-1111, a été ajouté à votre système connecté. En supposant que cette opération n'ait pas à être filtrée, DirXML doit décider ce qu'il faut faire avec cet utilisateur.
Pour prendre cette décision, DirXML applique un jeu de règles, dans un ordre spécifique (pour l'instant, nous allons ignorer les règles de transformation, qui surviennent avant que le filtre ne soit appliqué sur le canal Éditeur et en dernière étape sur l'abonné).
La première règle, celle de concordance, répond à la question " Cet objet se trouve-t-il déjà dans la banque de données ? ". Pour y répondre, vous devez définir les caractéristiques uniques à un objet. L'un des attributs habituellement vérifiés est l'adresse électronique, puisqu'elle est généralement unique (ainsi nous recevons tous notre part quotidienne de spam). Vous pourriez alors définir une règle qui indique " Si deux objets disposent de la même adresse électronique, ils représentent le même objet ".
En cas de concordance, DirXML note cette conclusion dans un attribut appelé association. Une association est une valeur unique qui permet à DirXML d'associer des objets dans des systèmes connectés.
Lorsque le système ne trouve aucune concordance, la deuxième règle, celle de la création, est appelée. La règle de création indique à DirXML les conditions sous lesquelles les objets doivent être créés. Vous pouvez rendre certains attributs obligatoires dans la règle de création. Si ces attributs n'existent pas, DirXML bloque la création de l'objet jusqu'à ce que les informations exigées soient fournies.
Une fois l'objet créé, la troisième règle, celle du placement, indique à DirXML où le situer. Vous pouvez indiquer que les objets doivent être créés dans une structure hiérarchique, identique à leur système d'origine, ou les placer dans un endroit totalement différent, en fonction d'une valeur d'attribut.
Si vous souhaitez placer des utilisateurs dans une hiérarchie en fonction d'un attribut d'emplacement sur l'objet, et les nommer selon leur nom complet, vous pouvez rendre ces attributs obligatoires dans votre règle de création. Vous vérifiez ainsi que l'attribut existe afin que votre stratégie fonctionne correctement.
Les règles permettent bien d'autres opérations. Grâce au Générateur de règles, vous pouvez facilement générer des valeurs uniques, ajouter et supprimer des attributs, générer des événements, envoyer des messages électroniques, etc. L'utilisation de XSLT pour modifier directement le document XML permet des transformations encore plus avancées (les modifications sont envoyées et reçues par eDirectory dans les documents XML).
Il ne faut pas oublier que les règles permettent de contrôler la manière dont DirXML gère les mises à jour.
Passez à Introduction aux règles pour en savoir plus sur les différents types de règles, puis au Définition des règles à l'aide du Générateur de règles pour vous frotter au Générateur de règles.
Les règles de transformation agissent à la manière d'un mécanisme de traduction entre DirXML et le système connecté. Elles transforment le schéma entre des systèmes et apportent des modifications préliminaires aux opérations entrantes, ainsi que des modifications définitives sur celles qui sortent.
À la base, les règles de transformation permettent de faire fonctionner correctement les règles citées précédemment (concordance, création, placement). La configuration par défaut de chaque pilote contient toutes les règles de transformation nécessaires. Vous n'avez donc pas à vous en inquiéter au début (la seule exception pourrait être la règle de concordance du schéma, que vous pouvez facilement modifier à l'aide d'une interface graphique dans iManager).
Une fois que vous aurez assimilé les types de règles de base, comprendre les règles de transformation pourra vous permettre de procéder à une personnalisation qui n'était pas disponible avec les règles de base.
Si vous n'avez jamais utilisé DirXML 1.x, il est inutile que vous consultiez cette section.
Sous DirXML 1.x, le terme règle décrivait un ensemble de règles, chacune des règles composant cet ensemble et les conditions et opérations de chaque règle, en fonction du contexte. Ce chevauchement des expressions générait une certaine confusion lorsque le contexte n'est pas clair.
Sous DirXML 2, le terme règle reprend ce qu'il désignait auparavant, pour décrire une transformation de haut niveau. Vous définissez maintenant un ensemble de règles, constitué d'une ou de plusieurs règles, chaque règle contenant un ou plusieurs principes. Le terme principe décrit maintenant un jeu de conditions et d'opérations.
Le tableau suivant illustre ce changement de terminologie.