Administración básica > Gestión de la participación de los usuarios > Equipos > Prácticas recomendadas para utilizar equipos locales y compartidos
Prácticas recomendadas para utilizar equipos locales y compartidos
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.
Diseño de equipos de contexto
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:
Cachés
Consultas de base de datos
Procesos basados en cola, como la cola de recalcular
Búsquedas e interacciones generales del usuario en el sistema
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.
Categorizar las necesidades de permiso
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.
Participantes independientes 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.
Participantes específicos del contexto
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 el caso de requisitos de permiso amplios, se debe considerar el uso de participantes independientes del contexto. De este modo, el tamaño del equipo quedará en un nivel óptimo y se reducirá el impacto en los recursos de procesamiento del sistema. En el caso de necesidades de permisos que varían entre contextos, se deben utilizar participantes específicos del contexto.
En las siguientes tablas se indican detalladamente las distintas técnicas para gestionar los permisos para equipos y su impacto en el rendimiento.
Participantes independientes del contexto (usuarios, grupos definidos por el usuario, organizaciones y pseudo-roles)
Eficiencia de recursos del sistema
Cuando sea más adecuado
En el caso que los requisitos de permiso para determinados grupos de participantes no cambien de un contexto de aplicación a otro.
Cómo se utiliza
Los participantes no deben añadirse al equipo. En su lugar, se les debe conceder los permisos necesarios mediante reglas de control de acceso.
Ejemplos
Ejemplo 1
Toda la organización necesita permiso de lectura a tipos de datos específicos de todos los productos públicos de la organización. En este caso, una opción podría haber implicado la adición de todos los usuarios de la organización al rol de invitado de todos los productos. Este es un enfoque de procesamiento intensivo. En su lugar, se puede otorgar a los usuarios permiso de lectura mediante las reglas de directivas de acceso a tipos de objeto específicos de un dominio administrativo adecuado, tal como el dominio /Default/PDM de la organización.
Ejemplo 2
Un grupo concreto de usuarios realiza las funciones de revisión de conformidad en todos los contextos de aplicación. Si se establece un rol de revisión de conformidad y se añaden los mismos usuarios a ese rol en todos los contextos de aplicación, se incrementan innecesariamente los gastos indirectos. En su lugar, el grupo de usuarios puede recibir los permisos necesarios a través de reglas de directivas de acceso para un grupo definido por el usuario de revisión de cumplimiento, en un dominio administrativo adecuado, como el dominio /(raíz) del sitio.
Consideraciones adicionales
Para los usuarios que no son miembros del equipo de contexto de aplicación, los contextos de aplicación no aparecerán en la página del producto, biblioteca, programa o lista de proyectos de la interfaz de usuario. Sin embargo, los usuarios pueden buscarlos. Si los usuarios disponen de los permisos adecuados, pueden encontrar los contextos de aplicación. Una vez que se haya accedido a ellos, los contextos de aplicación se cargarán en las listas acceso reciente en el navegador y se pueden encontrar allí que para un uso posterior.
Si estos usuarios necesitan acceder a acciones que no son automáticamente visibles a los miembros que no pertenecen al equipo, se pueden utilizar las opciones de configuración Configurar acciones para los roles en el equipo para que estas acciones sean visibles a los miembros que no pertenecen al equipo. Estas reglas se pueden proporcionar automáticamente a los nuevos contextos a través de las plantillas de contexto. Es posible que, para los usuarios que no sean miembros del equipo, sea necesario configurar algunas funcionalidades de manera diferente.
Las reglas de directivas de acceso necesarias para que estos usuarios naveguen a tipos de datos diferentes dentro del contexto de aplicación pueden variar de un caso a otro. Estos permisos se deberán identificar y conceder correctamente.
Más información
Equipo compartido
Participantes específicos del contexto (grupos del sistema y roles dinámicos)
Eficiencia de recursos del sistema
Cuando sea más adecuado
Los participantes requieren acceso a los objetos que residen en un contexto de aplicación según su rol en el contexto.
La misma estructura del equipo se puede aplicar a varios contextos de aplicación similares, realizando unos pocos cambios o ninguno.
La misma función de usuarios o de grupos en los mismos roles en todos los contextos de aplicación.
Se puede extender localmente para satisfacer necesidades adicionales (consulte Consideraciones adicionales a continuación).
Cómo se utiliza
Los equipos de biblioteca utilizan a menudo equipos compartidos debido a la naturaleza genérica de los permisos que se deben proporcionar a los usuarios.
En otros casos, se pueden crear varios equipos compartidos para que se apliquen a distintos conjuntos de productos y proyectos.
Consideraciones adicionales
Los equipos compartidos son más eficientes cuando no están extendidos localmente. Al extender el equipo localmente, se crea una instancia del equipo local, lo que reduce algunas de las ventajas de rendimiento que se esperan de un equipo compartido. En función de si se modifica muy extensivamente el equipo compartido en cada equipo local, es posible que la ventaja real del equipo compartido no se note en absoluto.
Más información
Equipo local
Participantes específicos del contexto (grupos del sistema y roles dinámicos)
Eficiencia de recursos del sistema
Cuando sea más adecuado
Los participantes requieren acceso a los objetos que residen en un contexto de aplicación según su rol en el contexto.
La estructura de equipo es específica de cada contexto de aplicación.
Los participantes que funcionan en los roles del equipo son específicos de cada contexto de aplicación.
Cómo se utiliza
Cree agrupaciones de usuarios amplias según las responsabilidades.
Añada los grupos a los roles específicos del equipo.
No cree agrupaciones de usuarios únicas para cada contexto individual. Considere el uso de grupos de usuarios reutilizables.
Consideraciones adicionales
Idealmente, el número de participantes que precisan estar en el equipo local debe mantenerse en un número óptimo.
Más información
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.
Práctica ineficaz de diseño de equipo
Inconvenientes
Práctica recomendada
Añadir todos los usuarios de la organización al rol Invitado (o a cualquier otro rol) en cada equipo para conceder permisos de lectura a datos de contexto de aplicación.
Las estructuras de equipo de gran tamaño exigen mucho de los recursos del sistema.
Proporcione permisos de acceso básicos mediante reglas de directivas. Reduzca a un número óptimo el número de usuarios que necesiten estar directamente asociados a un equipo.
Crear un control muy preciso de los permisos creando centenares de roles para cada equipo.
Las estructuras de equipo de gran tamaño exigen mucho de los recursos del sistema.
Se debe tener en cuenta que definir muchos roles especializados afecta al rendimiento. Reduzca a un número óptimo el número de roles en un equipo.
Utilizar plantillas de producto y biblioteca para especificar las mismas reglas de control de acceso de directiva que se deben crear para los roles de equipo en todos los productos o bibliotecas.
Esto se traduce en una duplicación innecesaria en la que se crean las mismas reglas de control de acceso de la directiva para el mismo rol en cada producto.
Siempre que sea posible, cree reglas de control de acceso de directiva para roles dinámicos en el nivel de la organización en lugar de duplicarlos en cada contexto de aplicación. Para obtener más información, consulte Uso de roles dinámicos en las reglas de control de acceso.
Se crean grupos de usuarios exclusivos de manera puntual para las asignaciones de roles de productos. Los grupos no se reutilizan y son específicos a un único producto.
Puede dar lugar a muchos grupos de usuarios con afiliaciones de participantes parecidas. Esto complica el mantenimiento de grupos de usuarios y sobrecarga el LDAP.
Organice a los usuarios en grupos de usuarios reutilizables en lugar de crear grupos de usuarios exclusivos para cada contexto. Como alternativa, asocie los usuarios directamente a los equipos en lugar de crear grupos de usuarios y asociar estos grupos a los roles. El segundo método no es tan eficaz como el primero.
Otras técnicas de optimización
A continuación se describen algunas técnicas de optimización del sistema útiles relacionadas con los equipos.
Considere limpiar las afiliaciones a los equipos una vez que los contextos han alcanzado el estatus de la final de vida. La utilidad DeleteLocalTeamRoles borra los roles de equipo local de un contexto de aplicación existente. Para obtener más información, consulte Borrado de roles de equipo local.
Adapte los tamaños de caché para PrincipalCache y RemoteObjectIdCache según las directrices de prácticas recomendadas. Esto garantiza que estas cachés puedan responder con eficacia a las necesidades de las estructuras de equipo. Para obtener más información, consulte los siguientes artículos de la base de técnicas prácticas.
Se debe considerar el uso de la utilidad PopulateConfirmedUsersInCache para rellenar previamente las entradas de PrincipalCache, de modo que la caché se prepare al iniciarse el sistema. Para obtener más información, consulte el siguiente artículo de la base de técnicas prácticas: https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS115189.
Para una utilización óptima de la caché, realice un mantenimiento periódico de los participantes para resolver el estado desconectado. Para obtener más información, consulte Gestión de participantes desconectados.
Considere si definir la propiedad wt.inf.team.wtusersUseAccessPolicyRules en verdadero es adecuado para el sitio. Si se define en verdadero, las reglas puntuales generadas por el sistema no se añaden a los participantes cuando se crea un contexto de aplicación a partir de una plantilla. Para obtener más información, consulte el siguiente artículo de la base de técnicas prácticas: https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS180319.
¿Fue esto útil?