Administration des processus
L’administration des processus permet aux administrateurs de définir des stratégies spécifiques au domaine.
Les politiques définies en bas dans la hiérarchie des domaines remplacent les politiques définies en haut dans la hiérarchie des domaines. Lorsqu’ils se trouvent dans un domaine, les administrateurs peuvent définir des versions spécifiques au domaine de ces stratégies et paramètres globaux :
- Scripts clients
- Politiques système
- Noms des applications et des modules
- Rôles d'application
- Filtres de module
Lorsque les utilisateurs disposent du rôle administrateur , toutes les politiques de l’instance sont disponibles, quel que soit le domaine affecté. Ils peuvent entrer un domaine spécifique, puis seules les politiques de ce domaine ou d’un domaine supérieur sont visibles et traitées lors d’une transaction pertinente. Lorsqu’un administrateur modifie une politique qui se trouve dans un domaine supérieur ou le domaine global, le système crée automatiquement un nouvel enregistrement pour le domaine actuel de cet administrateur. Cela ne modifie pas la politique, l’application ou l’enregistrement de module d’origine. Ce nouvel enregistrement remplace l’original.
Pour apporter des modifications à une politique dans un domaine de niveau inférieur, accédez à ce domaine et modifiez la politique. Cette approche crée l’enregistrement de politique dans votre domaine qui remplace l’enregistrement de politique de niveau supérieur d’origine.
Ne modifiez pas la politique de niveau supérieur, puis le champ Domaine de cette politique. Cette approche ne crée pas d’enregistrement de politique dans votre domaine de niveau inférieur et ne conserve pas non plus l’enregistrement de politique pour le domaine de niveau supérieur.
Le champ sys_overrides indique qu’une politique, une application ou un module à un niveau inférieur de la hiérarchie remplace un enregistrement à un niveau supérieur. Le système définit automatiquement ce champ lorsqu’un administrateur tente de modifier une politique, une application ou un module qui appartient à un autre domaine supérieur dans la hiérarchie.
Plutôt que de modifier l’enregistrement de niveau supérieur, la tentative de mise à jour est changée en insertion et le champ de sys_overrides est défini pour indiquer la politique, l’application ou le module de niveau supérieur qui est remplacé. Plus tard, lorsque les enregistrements d’une transaction pertinente sont chargés, la politique, l’application ou le module spécifique au domaine de remplacement est utilisé à la place de l’original.
Domaines pour l’administration des processus
Par défaut, l’administration des processus utilise toujours le domaine de l’enregistrement pour déterminer les politiques à appliquer.
Le domaine de l’enregistrement a priorité sur le domaine de l’utilisateur. Si aucune politique n’est trouvée dans le domaine de l’enregistrement, l’administration déléguée recherche les politiques au niveau immédiatement supérieur de la hiérarchie de domaines. La recherche de politiques de domaine se poursuit dans la hiérarchie des domaines jusqu’à atteindre le domaine global. S’il n’existe aucune politique de domaine inférieure dans la hiérarchie des domaines, l’administration des processus utilise les politiques du domaine global.
Par exemple, Fred Luddy est un utilisateur du domaine ACME qui peut voir les enregistrements dans les domaines enfants des domaines enfants d’Acme : Atlanta, d’Acme : San Diego et d’Acme : NY. Lorsque cet utilisateur ouvre un enregistrement dans le domaine ACME : San Diego, l’administration des processus vérifie d’abord les politiques dans le domaine ACME : San Diego. S’il n’existe aucune politique à ce niveau de la hiérarchie des domaines, l’administration des processus recherche les politiques du domaine ACME. S’il n’y a pas de politiques dans le domaine ACME, l’administration des processus utilise les politiques de domaine globales, car il n’y a pas d’autres domaines supérieurs dans la hiérarchie de domaines.