Encore et toujours des décisions

chaque employé a un numéro de badge unique, l’étape logique consiste à  faire du nouvel objet un attribut (c’est-à -dire, l’objet attributeSchema dF-HRBadgeNumber) que vous pouvez associer avec la classe utilisateur (c’est-à dire, l’objet classSchema utilisateur).

  Il faut ensuite décider si ce nouvel attribut sera obligatoire ou facultatif. Comme on veut que l’attribut figure dans chaque nouvelle instance utilisateur, il faut que le nouvel attribut soit obligatoire ; pas vrai ? Faux. C’est ici qu’entrent en ligne de compte les restrictions dont j’ai parlé précédemment. L’attribut mustContain d’un objet définit les attributs obligatoires de l’objet. Mais on ne peut pas modifier l’attribut mustContain d’un objet de catégorie 1 existant – et la classe utilisateur, qui fait partie du DIT de base, est un objet de catégorie 1. On pourrait penser à  un contournement logique consistant à  créer une nouvelle classe utilisateur, associer votre nouvel attribut comme un attribut obligatoire, puis utiliser la nouvelle classe utilisateur (plutôt que la classe utilisateur standard) pour créer les nouvelles instances d’utilisateurs. Mais, Microsoft a développé – et continuera sans aucun doute à  le faire – de nombreux outils qui travaillent avec (et dépendent de) l’utilisation par AD de la classe utilisateur standard (toutes les applications de management qui accompagnent Win2K, par exemple). Par conséquent, l’abandon de cette classe transformerait votre projet d’extension de schéma en un projet de développement d’outil de management Win2K. Par conséquent, la seule solution consiste à  associer l’attribut badgenumber à  la classe utilisateur comme un attribut facultatif.

  Décision suivante : comment mettre en oeuvre l’association. Evitez la tentation d’associer l’attribut par héritage. Cela reviendrait à  associer l’attribut à  une classe abstraite comme Top, Person ou organizationalPerson. Ces classes sont des classes X.500 bien définies, et un tel changement perturberait la compatibilité des définitions de classes avec les définitions X.500. Vous pourriez associer directement l’attribut à  la classe utilisateur, mais si vous créez de nombreux attributs d’extension pour servir diverses applications, vous aurez du mal à  déterminer l’origine ou le but des attributs associés par cette méthode. C’est pourquoi le meilleur moyen d’associer le nouvel attribut à  la classe utilisateur consiste à  créer un nouvel objet classSchema, dF-HR-EmployeeBadge et associer le nouvel attribut à  la classe auxiliaire. Comme le montre la figure 2, vous pourrez ensuite utiliser cette classe auxiliaire pour inclure le nouvel attribut badge-number dans la classe utilisateur. Une classe auxiliaire offre un moyen structuré de grouper les attributs d’extension d’après l’application ou la signification.

  Quand vous créez une nouvelle classe auxiliaire, vous pouvez dériver la classe d’une classe existante, définie comme une superclasse. Toutefois, dans notre exemple, la nouvelle classe est simplement un moyen d’associer un nouvel attribut à  la classe utilisateur et donc dF-HR- EmployeeBadge n’a nul besoin de dériver des attributs d’une classe existante. Vous pouvez simplement créer une nouvelle classe auxiliaire sans indiquer une superclasse. A présent, vous voyez clairement ce qu’il faut faire. Créez un objet classSchema auxiliaire (dF-HREmployeeBadge) avec un objet attributeSchema facultatif (dF-HRBadgeNumero) et ajoutez la nouvelle classe à  l’attribut auxiliaryClass de la classe utilisateur.