Hiérarchies Domain Separation
Créez une hiérarchie lorsque vous définissez une architecture de domaine afin de suivre vos processus et workflows.
Exemples de hiérarchies Domain Separation
- Dans l'exemple suivant, TOP est un domaine de processus. Il ne doit jamais contenir d'utilisateurs. À la place, TOP doit contenir les nouveaux processus que les propriétaires d'instances développent et les remplacements vers ces processus à partir du domaine global.
- Seul le fournisseur de service (SP) a accès au domaine par défaut. Ce domaine ne contient jamais d'utilisateurs actifs. Il contient uniquement les données « perdues » que vous devez réaffecter au domaine approprié. Remarque :Lorsque les données ne sont pas affectées à un domaine spécifique, elles se déplacent vers le domaine par défaut. Elles sont alors temporairement « perdues » et doivent être affectées au domaine approprié.
- Les tâches et les utilisateurs sans domaine sont placés automatiquement dans le domaine par défaut lorsque vous créez ou mettez à jour des domaines. Vous pouvez remplacer cette action en effaçant l'option Par défaut sur cet enregistrement ou en sélectionnant l'option Par défaut sur un autre enregistrement de domaine. Si vous n'avez pas encore défini de domaine par défaut, les tâches et les utilisateurs sans domaine se déplacent vers le domaine global.
- Ne déplacez pas les données entre les domaines lorsque vous utilisez l'instance.
- Si des données finissent dans le domaine par défaut, cela signifie que vous avez un problème de configuration ou de procédure à résoudre.
Vous ne voyez pas le mot « Global » dans ce diagramme car il n'y a pas de domaine global. N'oubliez pas que « global » se traduit par l'absence d'un domaine dans un enregistrement.
Par exemple, lorsqu'une table n'a aucun champ de domaine, cela signifie qu'elle contient tous les enregistrements globaux. Lorsqu'une table possède un champ de domaine, cela signifie que tout enregistrement sans domaine est un domaine global.
Le mot « global » se trouve dans le champ Domaine. Il y est placé automatiquement lorsque l'enregistrement n'a pas de domaine.
- Utilisez le domaine par défaut pour vous assurer que les enregistrements ne finissent pas dans le domaine global sur des tables qui ne doivent jamais avoir d'enregistrements globaux.
- Les propriétaires d'instances doivent ensuite trier les enregistrements dans le domaine par défaut et les déplacer vers le domaine approprié.
Hiérarchies de domaines
- Parent/Child (Parent/enfant) : processus et données affectés
- Conception basée sur un flux de processus.
- N'oubliez pas que les domaines parent peuvent accéder à toutes les données des domaines enfant.
- Domaine « Contains » : seules les données sont affectées. Par exemple, l'ajout d'un SP dans le TOP Contains du diagramme n'entraîne pas l'exécution des processus du SP dans le domaine TOP et dans les domaines vers le bas.
- Accorde des droits d'accès aux données aux personnes de groupes qui ont besoin d'un accès dédié à certains domaines.
- Contient des causes ou des conditions à ajouter aux requêtes de base de données qui peuvent entraîner des problèmes de performance avec des ensembles de données et de domaines volumineux.
- Visibility (Visibilité) : hiérarchie qui est toujours visible par les utilisateurs une fois que vous fournissez l'accès. Seules les données sont affectées, et non les processus.
- Accorde l'accès aux données d'un domaine à un autre domaine qui n'avait pas cet accès lors de la création de la hiérarchie parent-enfant.
- Permet aux utilisateurs de voir toutes les données dans les domaines pour lesquels ils ont une visibilité d'accès, tout le temps, quel que soit l'enregistrement sur lequel ils travaillent. Remarque :Utilisez cette option avec parcimonie, car la visibilité peut entraîner un accès complet que vous n'avez peut-être pas l'intention d'accorder.
Principes de base de la définition d'une hiérarchie des domaines
Cas d'utilisation avec et sans restriction pour la séparation de domaines.
De nombreux SP ont des clients qui déclarent implicitement que l'accès à leurs domaines doit être fortement réglementé, ce qui restreint l'utilisation de la fonction « contains » dans le domaine TOP. Le diagramme suivant explique comment atténuer cette réglementation en divisant les domaines en domaines avec restriction (Restricted) et sans restriction (Unrestricted).
Les clients se trouvent dans un « vertical » spécifique de la hiérarchie de séparation de domaines Cela signifie qu'ils n'utilisent que des processus définis dans leur domaine et tous les domaines parent au-dessus du leur dans la hiérarchie. Tous les processus définis dans les domaines qui ne sont pas dans leur hiérarchie parent-enfant linéaire ne s'appliquent pas.
Remarque :Les clients ou « locataires » sont des entités qui sont séparées les unes des autres, contrairement aux départements ou aux unités business, qui se partagent les ressources entre elles.- Les super verticaux (restreints, services de gestionnaire, etc.) sont autorisés tant que les clients n'appartiennent qu'à l'un d'eux.
- Les services, produits ou offres qui doivent être disponibles horizontalement pour tous les clients ne sont pas définis dans des hiérarchies de domaines distinctes.
- Sous TOP, vous pouvez créer deux domaines, Unrestricted (Sans restriction) et Restricted (Avec restriction).
- Placez les clients et leurs domaines qui n'ont pas de visibilité SP sous Unrestricted.
- Placez les clients et leurs domaines qui ont cette exigence sous Restricted.
- Les administrateurs système peuvent alors utiliser les fonctions « contains » et « visibility » de manière efficace et ciblée.
- Appliquez « contains » à Unrestricted pour qu'un seul « contains » puisse accorder une visibilité à la plupart des clients.
- Appliquez la visibilité de domaine à des domaines spécifiques selon les besoins à l'aide de « groupes de visibilité de domaine ».
Le diagramme suivant montre comment choisir le modèle de hiérarchie qui vous convient. Vous pouvez choisir des hiérarchies distinctes, hybrides ou partagées, en fonction des processus et des fonctionnalités souhaités dans vos structures de domaine.
Pour en savoir plus sur l'architecture des hiérarchies, consultez Architecture de référence du fournisseur de services.