Para gestionar la comunidad de usuarios eficazmente, analice cuál es la mejor forma de organizar a los usuarios en el nivel del sitio o la organización. Siempre que sea posible, cree grupos definidos por el usuario en el nivel del sitio o la organización y equipos compartidos en el nivel de organización. A continuación, utilice esos grupos y equipos al crear los contextos de aplicación.

Al decidir qué roles se deberían utilizar equipos locales y compartidos, asegúrese de comprobar las plantillas de equipo que se utilizarán, de modo que pueda hacer coincidir los roles en los equipos de contexto con los roles utilizados en las plantillas de equipo de forma adecuada.

Para proporcionar a los usuarios un acceso más eficaz a los datos del negocio, es importante utilizar equipos de contexto diseñados no solo para un control de acceso preciso, sino también para un rendimiento óptimo del sistema.

Cualquier sitio que espere tener miles de productos, proyectos o bibliotecas debería prestar mucha atención en respetar las siguientes directrices cuando diseñe una estructura para los equipos de contexto. En estas directrices se incluyen posibles optimizaciones, incluso para diseños de equipos que se utilizan desde hace tiempo. Los sitios pequeños también pueden beneficiarse de estas técnicas de optimización.

A menudo, es más fácil diseñar una estructura de equipo basada por completo en equipos locales. Sin embargo, los equipos locales son objetos de negocio con una capacidad de procesamiento y de memoria muy exigente. Cuanto más elaborada y detallada sea la estructura de un equipo, mayor será su exigencia de recursos del sistema. Por ejemplo:

Las estructuras de equipo complejas y de gran tamaño, multiplicadas por los miles de productos y de contenedores que los utilizan, pueden exigir mucho de los recursos del sistema. Las estructuras de equipo complejas no solo pueden ralentizar la funcionalidad específica del equipo, sino que, en casos extremos, las exigencias de recursos del sistema pueden afectar negativamente al rendimiento de todo el sistema. Por consiguiente, es importante realizar una planificación minuciosa para diseñar una estructura de equipo óptima que responda a las necesidades del negocio y que no afecte negativamente al rendimiento.

El motivo principal de diseñar una estructura de equipo es satisfacer los requisitos empresariales en cuanto a los permisos para los distintos segmentos de la comunidad de usuarios para acceder al contenido dentro de los contextos de aplicación. Utilice las siguientes directrices en el proceso de diseño del equipo.

Las necesidades de permisos de los usuarios suelen entrar en dos categorías: si los derechos de acceso se deben basar en el rol de un usuario en un contexto de aplicación, o si los derechos de acceso se deben conceder al usuario, independientemente del rol de usuario en un contexto. Realizar esta distinción ayuda a determinar si el acceso se debe conceder a los participantes independientes del contexto o a participantes específicos del contexto.

Para los participantes que requieren acceso a los objetos, independientemente de si son miembros del contexto de aplicación en el que residen los objetos, cree reglas de control de acceso utilizando los siguientes participantes: usuarios, grupos definidos por el usuario, organizaciones o pseudo-roles.

Por ejemplo, supongamos que todos los usuarios de una organización necesitan disponer de permiso de lectura en documentos de especificaciones en el estado Liberado de todos los productos públicos de la organización. Aplique estos derechos de acceso a través de una regla de control de acceso de directiva definida en el dominio Default/PDM de la organización que conceda a la organización participante el permiso de lectura para el tipo de documento de especificaciones en el estado Liberar.

Para los participantes que requieran acceso según su rol a objetos que residen en un contexto de aplicación, cree reglas de control de acceso utilizando grupos del sistema y roles dinámicos. Al crear reglas de control de acceso para roles, se debe tener en cuenta si la regla debe ser para un rol dinámico, si las necesidades del permiso de ese rol son iguales entre contextos o si la regla se debe crear para un grupo del sistema, porque las necesidades del permiso del rol cambian entre contextos de aplicación.

Por ejemplo, supongamos que los usuarios que son responsables de diseñar un producto deben tener permiso de creación y modificación para tipos de datos concretos. Esto solo se aplica a productos con trabajo de diseño asignado. Aplique estos permisos mediante los roles dinámicos asociados con los diseñadores, en equipos compartidos o locales.

Al crear un contexto de aplicación, considere la posibilidad de utilizar un equipo compartido si los roles del equipo y los participantes en los roles son los mismos entre un conjunto de contextos. Si los roles del equipo o los participantes en los roles cambian entre los contextos de aplicación, utilice un equipo local. Si los cambios entre los contextos de aplicación son menores, considere la posibilidad de utilizar un equipo compartido que se amplíe localmente.

Es posible una disponer de una mezcla de estas opciones; no es necesario seguir una única opción para todos los casos. Por ejemplo, se pueden elegir equipos compartidos para contextos de biblioteca mientras se usan equipos locales para algunos conjuntos de contextos de producto y proyecto, y equipos compartidos ampliados localmente para otros conjuntos de contextos de producto y proyecto.

En las siguientes tablas se indican detalladamente las distintas técnicas para gestionar los permisos para equipos y su impacto en el rendimiento.

Existen algunas prácticas comunes que hay que evitar cuando se diseñan equipos. En la siguiente tabla se muestran varias prácticas e inconvenientes.

A continuación se describen algunas técnicas de optimización del sistema útiles relacionadas con los equipos.