Hiérarchies de Séparation de domaine
Créez une hiérarchie lors de la définition d’une architecture de domaine pour suivre vos processus et workflows.
Exemple de hiérarchies de séparation en domaines
- Dans l’exemple suivant, TOP est un domaine de processus. Il ne doit jamais contenir d’utilisateurs. Au contraire, TOP doit contenir les nouveaux processus développés par les propriétaires d’instance et les remplacements de 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 ne contient que les données « perdues » que vous devez réaffecter au bon domaine. Remarque :Lorsque les données ne sont pas affectées à un domaine spécifique, elles sont déplacées vers le domaine par défaut. Il est temporairement « perdu » et doit être affecté à son domaine correct.
- Les tâches et les utilisateurs sans domaine sont automatiquement placés dans le domaine par défaut lorsque vous créez ou mettez à jour les domaines. Vous pouvez remplacer cette action en désactivant 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 sont déplacés vers le domaine global.
- Ne déplacez pas de données entre les domaines lorsque vous utilisez l’instance.
- Si des données se retrouvent 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. Rappelez-vous que « global » est l’absence de domaine sur un enregistrement.
Par exemple, une table qui ne comporte aucun champ de domaine signifie que la table contient tous les enregistrements globaux. Une table qui a un champ de domaine 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 des enregistrements ne se retrouvent pas dans le domaine global sur des tables qui ne devraient 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/enfant : processus et données affectés
- Conception basée sur un flux de processus.
- N’oubliez pas que les domaines parents peuvent accéder à toutes les données des domaines enfants.
- Domaine « Contient » : seules les données sont concernées. Par exemple, faire en sorte que le SP dans le diagramme contienne TOP ne fait pas fonctionner les processus du SP dans le domaine TOP et vers le bas.
- Accorde des droits d’accès aux données à des personnes appartenant à des 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 performances avec des domaines et des ensembles de données volumineux.
- Visibilité : hiérarchie toujours visible par les utilisateurs une fois que vous avez fourni l’accès. Seules les données sont affectées, pas les processus.
- Accorde l’accès aux données d’un domaine à un autre domaine qui ne disposait pas de cet accès lors de la création de la hiérarchie parent-enfant.
- Permet aux utilisateurs de voir à tout moment toutes les données des domaines pour lesquels ils ont accès en visibilité, quel que soit l’enregistrement sur lequel ils travaillent. Remarque :À utiliser avec parcimonie, car la visibilité peut permettre un accès complet auquel vous n’avez peut-être pas l’intention.
Principes de base de la définition d’une hiérarchie de domaines
Cas d’utilisation sans restriction et restreints pour Séparation de domaine.
De nombreux SP ont des clients qui déclarent implicitement que l’accès à leurs domaines doit être étroitement réglementé, ce qui limite l’utilisation de la fonction « contient » au niveau du domaine TOP. Le diagramme suivant explique comment atténuer cette réglementation en divisant les domaines en domaines restreints et sans restriction.
Les clients existent dans un « vertical » spécifique de la hiérarchie de Séparation de domaine. Cela signifie qu’ils ne consomment que les processus définis dans leur domaine et tous les domaines parents au-dessus du leur dans la hiérarchie. Les processus définis dans des domaines qui ne sont pas dans leur hiérarchie linéaire parent-enfant ne s’appliquent pas.
Remarque :Les clients ou « locataires » sont des entités qui sont complètement séparées les unes des autres, pas comme les départements ou les unités commerciales qui partagent des ressources entre eux.- Les super verticaux (restreints, services de gestionnaire, etc.) sont autorisés tant que les clients n’appartiennent qu’à l’un d’entre eux.
- Les services, produits ou offres qui doivent être horizontalement disponibles 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 et Restricted.
- Placez les clients et leurs domaines qui n’ont pas de restrictions de visibilité SP sous Sans restriction.
- Placez les clients et leurs domaines qui ont cette exigence sous Restreint.
- Les administrateurs système peuvent ensuite utiliser les fonctions « contient » et « visibilité » de manière efficace et ciblée.
- Appliquez « contient » à Sans restriction, de sorte qu’un seul « contient » peut offrir une visibilité à la plupart des clients.
- Appliquez la visibilité de domaine à l’aide de « groupes de visibilité de domaine » à des domaines spécifiques, selon les besoins.
Le diagramme suivant décrit 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 que vous souhaitez intégrer à vos structures de domaine.
Pour en savoir plus sur l’architecture hiérarchique, reportez-vous à la section Architecture de référence du fournisseur de services.