Administration de base > Gestion de la participation des utilisateurs > Equipes > Pratiques recommandées pour l'utilisation des équipes locales et partagées
Pratiques recommandées pour l'utilisation des équipes locales et partagées
Pour gérer votre communauté d'utilisateurs de la manière la plus efficace possible, étudiez la meilleure méthode pour organiser vos utilisateurs au niveau du site ou de l'organisation. Lorsque cela est possible, créez des groupes définis par l'utilisateur au niveau du site ou de l'organisation et des équipes partagées au niveau de l'organisation, puis utilisez ces groupes et équipes lors de la création de contextes d'application.
Lorsque vous décidez quels rôles doivent être utilisés dans les équipes locales et partagées, veillez à bien contrôler les modèles d'équipe qui seront utilisés afin de pouvoir faire correspondre de manière appropriée les rôles des équipes associées au contexte aux rôles utilisés dans les modèles d'équipe.
Conception des équipes associées au contexte
Pour fournir aux utilisateurs un accès très efficace aux données métier, il est important d'utiliser des équipes associées au contexte qui sont conçues non seulement pour un contrôle d'accès précis, mais également pour des performances du système optimales.
Tout site comptant proposer des milliers de produits, projets ou bibliothèques doit respecter les directives indiquées ci-dessous lors de la conception d'une structure pour des équipes associées au contexte. Les optimisations potentielles figurent dans les directives suivantes même pour les conceptions d'équipe qui sont utilisées depuis longtemps. Les sites de plus petite taille peuvent également tirer parti de ces techniques d'optimisation.
Il est souvent plus facile de concevoir une structure d'équipe basée entièrement sur des équipes locales. Toutefois, les équipes locales sont des objets métier utilisant beaucoup de mémoire et de puissance de traitement. Plus la structure d'une équipe est élaborée et affinée, plus la demande qu'elle impose aux ressources système est importante :
Caches
Interrogations de base de données
Processus basés sur les files d'attente, par exemple la file d'attente de recalcul
Recherches et interactions utilisateur générales dans le système
Des structures d'équipe très importantes et complexes, multipliées par les milliers de produits et de conteneurs qui les utilisent, peuvent imposer une forte demande aux ressources système. Des structures d'équipe complexes peuvent non seulement ralentir les fonctionnalités propres aux équipes, mais dans des cas extrêmes, les demandes qu'elles imposent aux ressources système peuvent nuire aux performances globales du système. Par conséquent, il est important de planifier soigneusement la conception d'une structure d'équipe optimale qui répond aux besoins professionnels et ne nuit pas aux performances.
La principale motivation en termes de conception d'une structure d'équipe est de répondre aux exigences métier associées aux permissions des différents segments de la communauté d'utilisateurs pour l'accès au contenu dans des contextes d'application. Utilisez les directives suivantes dans votre processus de conception d'équipe.
Classer les besoins liés aux permissions
Les besoins liés aux permissions accordées à vos utilisateurs sont classés en deux catégories, selon que les droits d'accès sont basés sur le rôle d'un utilisateur dans un contexte d'application ou accordés à l'utilisateur indépendamment de son rôle dans un contexte. Cette distinction vous aide à déterminer si l'accès doit être accordé à des participants dissociés du contexte ou à des participants associés au contexte.
Participants dissociés du contexte
Pour les participants qui requièrent un accès aux objets, qu'ils soient ou non membre du contexte d'application hébergeant les objets, créez des règles de contrôle d'accès à l'aide des participants suivants : utilisateurs, groupes définis par l'utilisateur, organisations ou pseudo-rôles.
Par exemple, supposons que tous les utilisateurs d'une organisation doivent disposer d'une permission de lecture sur les documents de spécification présentant l'état Officiel pour chaque produit public au sein de l'organisation. Appliquez ces droits d'accès par le biais d'une règle de contrôle d'accès aux politiques définie dans le domaine /Default/PDM de l'organisation qui accorde au participant de l'organisation une permission de lecture pour le type Document de spécification à l'état Officiel.
Participants associés au contexte
Pour les participants qui nécessitent un accès aux objets résidant dans un contexte d'application en fonction de leur rôle dans le contexte, créez des règles de contrôle d'accès à l'aide de groupes système et de rôles dynamiques. Lorsque vous créez des règles de contrôle d'accès pour les rôles, déterminez si la règle doit s'appliquer à un rôle dynamique, si les besoins liés à la permission pour ce rôle sont identiques entre les contextes ou s'il est nécessaire de créer la règle pour un groupe système en raison du fait que les besoins liés à la permission du rôle varient selon les contextes d'application.
Par exemple, supposons que les utilisateurs chargés de concevoir un produit doivent disposer de la permission de création et de modification pour des types de données spécifiques. Celle-ci s'applique uniquement aux produits pour lesquels le travail de conception leur est affecté. Appliquez ces permissions par le biais des rôles dynamiques associés aux concepteurs, dans des équipes partagées ou locales.
Lorsque vous créez un contexte d'application, envisagez d'utiliser une équipe partagée si les rôles de l'équipe et les participants affectés aux rôles sont identiques entre un ensemble de contextes. Si les rôles de l'équipe ou les participants affectés aux rôles varient entre les contextes d'application, utilisez une équipe locale. Si les modifications entre les contextes d'application sont mineures, vous pouvez utiliser une équipe partagée qui est étendue localement.
Un assortiment d'options est certainement possible ; il n'est pas nécessaire de poursuivre une seule et même option pour tous les cas. Par exemple, vous pouvez choisir des équipes partagées pour des contextes de bibliothèque tout en utilisant des équipes locales pour certains ensembles de contextes de produit et de projet, et des équipes partagées étendues localement pour d'autres ensembles de contextes de produit et de projet.
* 
Pour les vastes exigences de permission, envisagez d'utiliser des participants dissociés des contextes. Cela maintient l'équipe à un niveau optimal et réduit l'incidence sur les ressources de production du système. Lorsque les besoins en matière de permissions varient selon les contextes, utilisez des participants associés aux contextes.
Les tableaux ci-après fournissent plus d'informations sur les différentes techniques de gestion des permissions pour les équipes et sur leur impact sur les performances.
Participants dissociés des contextes (utilisateurs, groupes définis par les utilisateurs, organisations et pseudo-rôles)
Efficacité des ressources système
Cas les mieux appropriés
Lorsque les exigences de permissions de certains groupes de participants ne changent pas d'un contexte d'application à l'autre.
Utilisation
Les participants ne doivent pas être ajoutés à l'équipe. Il convient de leur accorder les permissions nécessaires via des règles de contrôle d'accès.
Exemples
Exemple 1
L'ensemble d'une organisation doit disposer d'un accès en lecture aux types de données spécifiques de chaque produit public dans l'organisation. Dans ce cas, une option pourrait consister à ajouter tous les utilisateurs de l'organisation au rôle d'invité dans chaque produit. Il s'agit d'une approche nécessitant un traitement intensif. Vous pouvez plutôt accorder aux utilisateurs un accès en lecture à des types d'objet spécifiques dans un domaine d'administration approprié, tel qu'un domaine d'organisation, par défaut ou PDM, via des règles d'accès.
Exemple 2
Un groupe d'utilisateurs particulier exécute les fonctions de validation de la conformité dans chaque contexte d'application. L'établissement d'un rôle de validation de la conformité et l'ajout des mêmes utilisateurs à ce rôle dans chaque contexte d'application induisent des coûts indirects inutiles. Au lieu de cela, il est possible d'octroyer les permissions nécessaires au groupe d'utilisateurs par le biais de règles d'accès pour un groupe défini par l'utilisateur de validation de la conformité, au sein d'un domaine d'administration approprié, tel que le domaine / (Root) du site.
Remarques supplémentaires
Pour les utilisateurs qui ne sont pas membres de l'équipe associée au contexte d'application, les contextes d'application ne sont pas répertoriés dans les pages Produit, Bibliothèque, Programme ou Liste de projets de l'interface utilisateur. Toutefois, les utilisateurs peuvent les rechercher. S'ils disposent des permissions appropriées, ils trouveront les contextes d'application. Les contextes d'application sont alors chargés dans les listes Accédés récemment du navigateur, où ils peuvent être utilisés ultérieurement.
Si ces utilisateurs doivent accéder à des actions qui ne sont pas automatiquement visibles aux non-membres de l'équipe, les paramètres de l'option Configurer les actions des rôles dans l'équipe peuvent être utilisés pour rendre de telles actions visibles pour les non-membres de l'équipe. Ces règles peuvent être automatiquement fournies à des nouveaux contextes via des modèles de contexte. Il se peut que certaines fonctionnalités, comme la participation aux processus, doivent également être configurées différemment pour les utilisateurs qui ne sont pas membres de l'équipe.
Les règles d'accès nécessaires pour que ces utilisateurs accèdent à différents types de données dans le contexte d'application peuvent varier au cas par cas. Ces permissions doivent être identifiées et accordées de façon appropriée.
Autres informations
Equipe partagée
Participants associés aux contextes (groupes système et rôles dynamiques)
Efficacité des ressources système
Cas les mieux appropriés
Les participants nécessitent un accès aux objets résidant dans un contexte d'application en fonction de leur rôle dans le contexte.
La même structure d'équipe peut être appliquée à plusieurs contextes d'application similaires avec peu ou pas de modification.
Les mêmes utilisateurs ou groupes ont les mêmes rôles dans tous ces contextes d'application.
L'équipe peut être étendue localement pour répondre à des besoins supplémentaires (consultez la section "Remarques supplémentaires" ci-dessous).
Utilisation
Les équipes partagées sont souvent utilisées comme équipes de bibliothèque en raison de la nature générique des permissions à accorder aux utilisateurs.
Dans d'autres cas, vous pouvez créer plusieurs équipes partagées pour répondre aux besoins de différents ensembles de produits et de projets.
Remarques supplémentaires
Les équipes partagées sont très efficaces lorsqu'elles ne sont pas étendues localement. L'extension locale de l'équipe crée une instance d'équipe locale, ce qui réduit certains des avantages en termes de performances que l'équipe partagée est censée fournir. En fonction de l'extension de l'équipe partagée dans chaque équipe locale, le véritable avantage lié à l'équipe partagée peut ne pas être atteint du tout.
Autres informations
Equipe locale
Participants associés aux contextes (groupes système et rôles dynamiques)
Efficacité des ressources système
Cas les mieux appropriés
Les participants nécessitent un accès aux objets résidant dans un contexte d'application en fonction de leur rôle dans le contexte.
La structure d'équipe est propre à chaque contexte d'application.
Les participants qui opèrent dans les rôles de l'équipe sont propres à chaque contexte d'application.
Utilisation
Créez de larges regroupements d'utilisateurs en fonction de leurs responsabilités.
Ajoutez les groupes à des rôles spécifiques de l'équipe.
Ne créez pas de regroupements d'utilisateurs uniques pour chaque contexte. Pensez aux groupes d'utilisateurs réutilisables.
Remarques supplémentaires
Dans l'idéal, il convient de maintenir un nombre idéal de participants dans l'équipe locale.
Autres informations
Voici certaines pratiques courantes à éviter lorsque vous concevez des équipes. Le tableau ci-dessous répertorie plusieurs pratiques et leurs points faibles.
Pratique de conception d'équipe inefficace
Points faibles
Bonne pratique
Ajout de tous les utilisateurs de l'organisation au rôle d'invité (ou à tout autre rôle), dans chaque équipe, pour accorder la permission de lecture sur les données de contexte d'application.
Des structures d'équipe de très grande envergure imposent une forte demande sur les ressources système.
Fournissez des permissions d'accès de base à l'aide de règles de politique. Maintenez un nombre idéal d'utilisateurs devant être directement associés à une équipe.
Création d'un contrôle très précis des permissions par le biais de centaines de rôles pour chaque équipe.
Des structures d'équipe de très grande envergure imposent une forte demande sur les ressources système.
N'oubliez pas les concessions en termes de performances liées à la définition de nombreux rôles spécialisés. Maintenez un nombre idéal de rôles dans une équipe.
Considérons l'utilisation des modèles de produit ou de bibliothèque pour définir les règles de contrôle d'accès globales à créer pour les rôles d'équipe de l'ensemble des produits ou des bibliothèques.
Cela entraîne une duplication inutile, dans une configuration où les mêmes règles de contrôle d'accès sont créées pour un même rôle dans chaque produit.
Dans la mesure du possible, créez des règles de contrôle d'accès pour des rôles dynamiques au niveau Organisation au lieu de les dupliquer dans chaque contexte d'application. Pour plus d'informations, consultez la rubrique Utilisation de rôles dynamiques dans les règles de contrôle d'accès.
Des groupes d'utilisateurs uniques sont créés sur une base ad hoc pour les affectations de rôles dans les produits. Les groupes ne sont pas réutilisés et sont propres à un seul produit.
Cela peut entraîner une configuration dans laquelle de nombreux groupes d'utilisateurs présentent des participants identiques. Cela complique la maintenance des groupes d'utilisateurs et surcharge le LDAP.
Organisez les utilisateurs en groupes d'utilisateurs réutilisables au lieu de créer des groupes d'utilisateurs uniques pour chaque contexte. De même, associez directement des utilisateurs à des équipes au lieu de créer des groupes d'utilisateurs et de les associer à des rôles. La seconde méthode n'est pas aussi efficace que la première.
Autres techniques d'optimisation
Voici quelques techniques utiles d'optimisation du système associées aux équipes :
Pensez à nettoyer l'appartenance à une équipe une fois que les contextes ont atteint le statut de fin de vie. L'utilitaire DeleteLocalTeamRoles supprime les rôles d'une équipe locale dans un contexte d'application existant. Pour plus d'informations, consultez la rubrique Suppression de rôles d'une équipe locale.
Réglez les tailles du cache pour PrincipalCache et RemoteObjectIdCache en suivant les directives recommandées. Ce faisant, ces caches peuvent répondre efficacement aux besoins des structures d'équipe. Pour plus d'informations, consultez les articles suivants de la base de connaissances :
Envisagez d'utiliser l'utilitaire PopulateConfirmedUsersInCache pour prérenseigner des entrées dans PrincipalCache, de manière à amorcer le cache lors du démarrage du système. Pour plus d'informations, consultez l'article suivant de la base de connaissances : https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS115189.
Pour valoriser au maximum le cache, exécuter des activités régulières de maintenance des participants afin de résoudre les erreurs de déconnexion. Pour plus d'informations, consultez la section Gestion des participants déconnectés.
Déterminez si la définition de la propriété wt.inf.team.wtusersUseAccessPolicyRules sur vrai convient à votre site. Si cette propriété est définie sur vrai, les règles ad hoc générées par le système ne sont pas ajoutées aux participants lorsqu'un contexte d'application est créé à partir d'un modèle. Pour plus d'informations, consultez l'article suivant de la base de connaissances : https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS180319.
Est-ce que cela a été utile ?