基础管理 > 管理用户参与 > 团队 > 使用本地团队和共享团队的最佳做法
  
使用本地团队和共享团队的最佳做法
要最有效地管理用户群体，请分析如何最有效地在站点或组织级别组织用户。如有可能，创建站点级别或组织级别的用户定义组以及组织级别的共享团队，然后在创建应用程序上下文时使用这些组和团队。
确定应在共享团队和本地团队中使用哪些角色时，请务必检查将要使用的团队模板，以便您可以根据需要将上下文团队中的角色与用在团队模板中的角色相匹配。
设计上下文团队
要让用户能够最有效地访问业务数据，请尽可能使用既能实现精确的访问控制，又可优化系统性能的上下文团队设计。
对于预计拥有数千产品、项目或存储库的任何站点，在设计上下文团队的结构时，都应特别注意遵守以下指导原则。甚至对于长期以来一直在使用的团队设计，也可在这些指导原则中找到潜在的优化方法。而小型站点也可从这些优化技术中获益。
通常，完全基于本地团队设计团队结构是最简单的。但是，本地团队是对内存和处理能力要求非常高的业务对象。团队结构越精细，其对诸如下列类型的系统资源的需求越大：
• 缓存
• 数据库查询
• 基于队列的进程，例如重新计算队列
• 系统中的搜索和常规用户交互
团队结构过于庞杂，再乘以数千个使用它们的产品和容器，会催生出大量的系统资源需求。复杂的团队结构不只会降低团队特定功能，在极端情况下，它们对系统资源的需求还会对整体系统性能产生不良影响。因此，要设计一个既满足业务需求又不会对性能造成负面影响的最佳团队结构，务必要做到精心规划。
设计团队结构的主要动机是，满足不同部分用户群体关于权限的业务需求，以访问应用程序上下文中的内容。在团队设计过程中请使用以下指导原则。
对权限需求进行分类
用户需要的权限通常分为两类：访问权限是否应基于应用程序上下文中的用户角色；或者，是否应独立于上下文中的用户角色将访问权限授予用户。进行这种区分将有助于您确定是授予独立于上下文的参与者访问权限还是授予特定于上下文的参与者访问权限。
独立于上下文的参与者
对于需要对象访问权限的参与者 (无论他们是否是对象所在的应用程序上下文的成员)，请使用以下参与者创建访问控制规则：用户、用户定义的组、组织或虚拟角色。
例如，假设组织中的所有用户都需要对组织中每个公用产品内处于“已发布”状态的“规范”文档具有“读取”权限。通过在组织的 /Default/PDM 域中所定义的策略访问控制规则为处于“发布”状态的“规范”文档类型授予“读取”权限，可强制实施此访问权限。
特定于上下文的参与者
对于需要基于其上下文角色来访问驻留在应用程序上下文中的对象的参与者，请使用系统组和动态角色创建访问控制规则。为角色创建访问控制规则时，请考虑该规则是否适用于动态角色，因为该角色在不同上下文中所需的权限都相同；或者，是否需要为系统组创建该规则，因为该角色在不同应用程序上下文中所需的权限会有所变化。
例如，假设负责设计产品的用户必须具有对特定类型数据的“创建”和“修改”权限。这仅适用于他们被分配了设计工作的产品。通过共享或本地团队中与设计师相关联的动态角色强制实施这些权限。
创建应用程序上下文时，如果上下文组之间的团队角色和角色中的参与者均相同，请考虑使用共享团队。如果两个应用程序上下文中的团队角色或角色中的参与者有所改动，请使用本地团队。如果应用程序上下文之间的改动较小，请考虑使用经本地扩展的共享团队。
当然，您也可以混合搭配这些方案；没有必要追求在所有情况下都使用一种方案。例如，对于存储库上下文，可以选择共享团队；对于某些产品和项目上下文组，可以使用本地团队；而对于其他产品和项目上下文组，可以使用经本地扩展的共享团队。
* 
对于广泛的权限需求，请考虑使用独立于上下文的参与者。这将使团队大小保持到最佳水平并减少对系统处理资源的影响。对于不同上下文之间有差异的权限需求，请使用特定于上下文的参与者。
下表更详细地阐述了用于管理团队权限的各种技术及其对性能的影响。
独立于上下文的参与者 (用户、用户定义的组、组织和虚拟角色)
系统资源效率
最适合的情况
其中，特定参与者组的权限需求不会因为应用程序上下文的不同而发生变更。
使用方式
根本不应将参与者添加到团队中。相反，应通过访问控制规则授予其必要权限。
示例
示例 1
整个组织需要对组织内每个公用产品中特定数据类型的“读取”权限。在这种情况下，系统可能已经提供了一种方案，将组织中的所有用户添加至每个产品的“访客”角色中。这是一种处理能力要求较高的方法。相反，用户可以通过访问策略规则向适当的管理域 (例如组织的 /Default/PDM 域) 中的特定对象类型提供“读取”权限。
示例 2
一组特定用户在每个应用程序上下文中执行“合规性审阅”功能。建立“合规性审阅”角色并将相同用户添加到每个应用程序上下文的该角色上将增加不必要的开销。相反，用户组可通过访问策略规则为适当管理域 (例如 Site’s / (Root) 域) 中的“合规性审阅”用户定义组提供必要权限。
其他注意事项
对于不是应用程序上下文团队成员的用户，应用程序上下文将不会在用户界面的“产品”、“存储库”、“项目群”或“项目列表”页面中列出。但是，用户可以搜索它们。如果用户具有相应权限，则会找到这些应用程序上下文。访问过的应用程序上下文将加载到导航器中的最近访问列表中，并且可在此列表中找到以供后续使用。
如果此类用户需要访问对非团队成员并非自动可见的操作，则可使用团队上“配置角色的操作”设置使此类操作对非团队成员可见。此类规则可能会通过上下文模板自动提供给新上下文。某些功能，例如参与工作流，可能还需要为非团队成员用户进行不同的设置。
此类用户导航到应用程序上下文中不同类型数据所需的访问策略规则可能会因案例而异。应标识出那些权限，并相应地进行授权。
详细信息
共享团队
特定于上下文的参与者 (系统组和动态角色)
系统资源效率
最适合的情况
• 参与者需要基于其在上下文中的角色访问驻留在应用程序上下文中的对象。
• 可将相同的团队结构应用于大量相似的应用程序上下文，而几乎无需或根本不必更改的情况。
• 在所有那些应用程序上下文中相同角色均具有相同用户或组功能的情况。
• 可进行本地扩展以满足其他需求 (请参阅下面的附加注意事项)。
使用方式
• 由于要向用户提供的权限具有通用特性，因此共享团队经常用于“存储库”团队。
• 在其他情况下，可能会创建多个共享团队以满足不同系列的“产品”和“项目”。
其他注意事项
未进行本地扩展时共享团队是最高效的。本地扩展团队会创建一个本地团队实例，这样就降低了共享团队可能具备的某些性能优势。根据共享团队在每个本地团队中修改的广泛程度，共享团队的真正优势可能根本无法实现。
详细信息
本地团队
特定于上下文的参与者 (系统组和动态角色)
系统资源效率
最适合的情况
• 参与者需要基于其在上下文中的角色访问驻留在应用程序上下文中的对象。
• 团队结构特定于每个应用程序上下文。
• 在团队角色中行使职责的参与者特定于每个应用程序上下文。
使用方式
• 根据职责，创建广泛的用户组。
• 将组添加到团队中的特定角色。
• 请勿为每个单独上下文创建唯一用户组。请考虑使用可重用的用户组。
其他注意事项
理想情况下，需要包括在本地团队中的参与者数应保持在最佳数量。
详细信息
设计团队时，需要避免一些常见实践。下表列出了其中的几种实践及其弊端。
低效的团队设计实践
弊端
最佳业务实践
将组织中的每个用户添加到每个团队中的“访客”角色 (或任何其他角色)，以授予对应用程序上下文数据的“读取”权限。
团队结构过于庞大，催生出大量的系统资源需求。
使用策略规则提供基本访问权限。将需要与团队直接关联的用户数保持为最佳数量。
通过为每个团队创建数以百计的角色来实现对权限的精确控制。
团队结构过于庞大，催生出大量的系统资源需求。
请记住在定义多个专用角色时的性能取舍。将团队中的角色数保持为最佳数量。
使用产品或存储库模板来指定应该在所有产品或存储库中为团队角色创建的相同策略访问控制规则。
这会导致不必要的重复，即会为每个产品中的相同角色创建相同的策略访问控制规则。
如有可能，请在“组织”级别为动态角色创建策略访问控制规则，而不是在每个应用程序上下文中重复它们。有关详细信息，请参阅在访问控制规则中使用动态角色。
在专用基础上为产品中的角色分配创建唯一的用户组。组不可重新使用，且特定于单个产品。
会产生多个具有类似参与者成员资格的用户组。这会使用户组的维护变得复杂，并导致 LDAP 过载。
将用户组织到可重用的用户组中，而无需为每个上下文创建唯一用户组。或者，将用户直接与团队关联，而不是创建用户组并将那些组与角色关联。第二种方法不如第一种高效。
其他优化技术
以下是与团队相关的一些实用系统优化技术。
• 考虑在上下文达到生命周期终止状态后，清除团队成员资格。DeleteLocalTeamRoles 实用程序可用于从现有应用程序上下文中删除本地团队角色。有关详细信息，请参阅删除本地团队角色。
• 请遵照最佳业务实践指导原则，调整 PrincipalCache 和 RemoteObjectIdCache 的缓存大小。这可确保这些缓存能够高效地满足团队结构的需要。有关详细信息，请参阅以下知识库文档。
◦ https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS71489
◦ https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS97931
• 请考虑使用 PopulateConfirmedUsersInCache 实用程序来预填充 PrincipalCache 中的条目，这样，缓存即可在系统启动时准备就绪。有关详细信息，请参阅以下知识库文档：https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS115189。
• 要优化缓存利用率，请通过定期维护参与者来解决已断开连接的状况。有关详细信息，请参阅管理已断开连接的参与者。
• 考虑将属性 wt.inf.team.wtusersUseAccessPolicyRules 设置为 true 是否适用于您的站点。如果设置为 true，则从模板创建应用程序上下文时，不会将系统生成的专用规则添加到参与者。有关详细信息，请参阅以下知识库文档：https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS180319。