Administration des processus
L’administration des processus permet aux administrateurs de définir des stratégies spécifiques à un domaine.
Les politiques définies plus bas dans la hiérarchie de domaine remplacent les politiques définies plus haut dans la hiérarchie de domaine. Lorsqu’ils sont 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 de l’application et du module
- Rôles d'application
- Filtres de module
Lorsque les utilisateurs disposent du rôle administrateur , toutes les politiques de l’instance sont alors disponibles, quel que soit le domaine affecté. Ils peuvent entrer un domaine spécifique, et seules les politiques de ce domaine ou de domaines supérieurs 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. Elle ne modifie pas l’enregistrement d’origine de la politique, de l’application ou du module. 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. Cette approche crée l’enregistrement de politique dans votre domaine qui remplace l’enregistrement de politique de niveau supérieur d’origine.
Ne changez pas la stratégie de niveau supérieur, puis le champ Domaine de cette stratégie. Cette approche ne crée pas d’enregistrement de politique dans votre domaine de niveau inférieur et ne conserve pas 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 appartenant à un autre domaine placé plus haut 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 sys_overrides est défini pour indiquer la politique, l’application ou le module de niveau supérieur qui est remplacé. Ultérieurement, 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. S’il n’existe aucune politique 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 domaine. La recherche de politiques de domaine se poursuit dans la hiérarchie des domaines jusqu’au domaine global. En l’absence de politiques de domaine à un niveau inférieur 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 Acme : Atlanta, Acme : San Diego et Acme : NY. Lorsque cet utilisateur ouvre un enregistrement dans le domaine Acme : San Diego, l’administration du 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 de domaine, l’administration des processus recherche des politiques provenant du domaine ACME. Si le domaine ACME n’contient aucune politique, l’administration des processus utilise les politiques de domaine globales, car il n’existe aucun autre domaine placé plus haut dans la hiérarchie des domaines.