Grundlegende Verwaltung > Benutzerteilnahme verwalten > Teams > Empfohlene Vorgehensweisen für die Verwendung von lokalen und gemeinsam benutzten Teams
Empfohlene Vorgehensweisen für die Verwendung von lokalen und gemeinsam benutzten Teams
Für eine möglichst effektive Verwaltung der Benutzer-Community analysieren Sie, wie die Benutzer am besten auf Standort- oder Organisationsebene organisiert werden. Erstellen Sie wenn möglich benutzerdefinierte Gruppen auf Site-Ebene oder Organisationsebene und gemeinsam benutzte Teams auf Organisationsebene, und verwenden Sie dann diese Gruppen und Teams bei der Erstellung von Anwendungskontexten.
Wenn Sie entscheiden, welche Rollen in gemeinsam benutzten und lokalen Teams verwendet werden sollen, stellen Sie sicher, die Teamvorlagen zu überprüfen, die verwendet werden, damit Sie die Rollen mit den Rollen in den Kontext-Teams vergleichen können.
Kontext-Teams entwerfen
Um Benutzern den effektivsten Zugriff auf Geschäftsdaten bereitzustellen, ist es wichtig, Kontext-Teams zu verwenden, die nicht nur für eine präzise Zugriffssteuerung, sondern auch für optimale Systemleistung konzipiert sind.
Für jeden Standort mit Tausenden von Produkten, Projekten oder Bibliotheken sollte besonders sorgfältig darauf geachtet werden, dass beim Entwurf einer Struktur für Kontext-Teams die folgenden Richtlinien berücksichtigt werden. In diesen Richtlinien können auch für lange verwendete Teamkonstruktionen mögliche Optimierungen gefunden werden. Auch kleine Standorte können von diesen Optimierungstechniken profitieren.
Der Entwurf von Teamstrukturen ist meist bei komplett lokalen Teams am einfachsten. Jedoch sind lokale Teams sehr arbeitsspeicher- und rechenleistungsintensive Geschäftsobjekte. Je durchdachter und feiner die Struktur eines Teams ist, umso größer sind die an Systemressourcen gestellten Anforderungen wie:
Caches
Datenbankabfragen
Warteschlangenbasierte Prozesse wie die Recompute-Warteschlange
Suchen und allgemeine Benutzerinteraktionen innerhalb des Systems
Sehr große und komplexe Teamstrukturen, multipliziert mit den Tausenden von Produkten und Containern, die diese verwenden, können Systemressourcen stark beanspruchen. Komplexe Teamstrukturen können nicht nur teamspezifische Funktionen verlangsamen, in Extremfällen können sie Systemressourcen auch so stark beanspruchen, dass die Leistung des Gesamtsystems beeinträchtigt wird. Sorgfältige Planung ist daher wichtig, um eine optimale Teamstruktur zu entwerfen, die den Geschäftsanforderungen zugutekommt und keine Leistungsbeeinträchtigungen mit sich bringt.
Die primäre Motivation beim Entwurf von Teamstrukturen besteht darin, Geschäftsanforderungen rund um Berechtigungen für verschiedene Segmente der Benutzer-Community beim Zugriff auf Inhalte in Anwendungskontexten zu erfüllen. Verwenden Sie die folgenden Richtlinien in Ihrem Teamkonstruktionsprozess.
Berechtigungsanforderungen kategorisieren
Berechtigungsanforderungen für Ihre Benutzer gehören im Allgemeinen zu zwei Kategorien: Zugriffsrechte auf Grundlage einer Benutzerrolle in einem Anwendungskontext oder Zugriffsrechte unabhängig von der Benutzerrolle in einem Kontext. Diese Unterscheidung hilft Ihnen dabei, festzulegen, ob der Zugriff kontextunabhängigen oder kontextspezifischen Teilnehmern gewährt werden soll.
Kontextunabhängige Teilnehmer
Für Teilnehmer, die Zugriff auf Objekte benötigen, unabhängig davon, ob sie Mitglied des Anwendungskontexts der Objekte sind, erstellen Sie Zugriffssteuerungsregeln unter Verwendung der folgenden Teilnehmer: Benutzer, benutzerdefinierte Gruppen, Organisationen oder Pseudo-Rollen.
Nehmen wir beispielsweise an, dass alle Benutzer in einer Organisation Leseberechtigung für Spezifikationsdokumente mit dem Status "Freigegeben" in jedem öffentlichen Produkt innerhalb der Organisation benötigen. Diese Zugriffrechte erzwingen Sie über eine Richtlinien-Zugriffssteuerungsregel, die in der Domäne "/Default/PDM" der Organisation definiert ist und dem Organisationsteilnehmer Leseberechtigung für den Spezifikationsdokumenttyp mit Status "Freigegeben" gewährt.
Kontextspezifische Teilnehmer
Für Teilnehmer, die Zugriff auf Objekte in einem Anwendungskontext auf Basis ihrer Rolle in diesem Kontext benötigen, erstellen Sie Zugriffssteuerungsregeln unter Verwendung von Systemgruppen und dynamischen Rollen. Bei der Erstellung von Zugriffssteuerungsregeln für Rollen sollten Sie berücksichtigen, ob die Regel für eine dynamische Rolle gedacht ist, ob die betreffende Rolle in jedem Kontext dieselben Berechtigungen benötigt oder ob die Rolle für eine Systemgruppe erstellt werden muss, weil sie in jedem Anwendungskontext unterschiedliche Berechtigungen benötigt.
Nehmen wir beispielsweise an, dass Benutzer, die für die Konstruktion eines Produkts zuständig sind, die Berechtigung zum Erstellen und Ändern für spezifische Datentypen haben müssen. Dies gilt nur für Produkte, bei denen ihnen Konstruktionsarbeiten zugewiesen sind. Diese Berechtigungen erzwingen Sie über die dynamischen Rollen, die Konstrukteuren in gemeinsam benutzten oder lokalen Teams zugewiesen sind.
Verwenden Sie bei der Erstellung eines Anwendungskontexts ein gemeinsam benutztes Team, wenn die Teamrollen und die Teilnehmer in diesen Rollen in verschiedenen Kontexten identisch sind. Verwenden Sie ein lokales Team, wenn für unterschiedliche Anwendungskontexte auch unterschiedliche Teamrollen oder unterschiedliche Teilnehmer in den Rollen erforderlich sind. Unterscheiden sich die Anwendungskontexte nur geringfügig, sollten Sie ein gemeinsam benutztes, lokal erweitertes Team in Erwägung ziehen.
Eine Kombination von Optionen ist durchaus möglich. Es muss keine Option für alle Fälle angewendet werden. So können Sie beispielsweise gemeinsam benutzte Teams für Bibliothekskontexte verwenden, lokale Teams für bestimmte Kombinationen von Produkt- und Projektkontexten und gemeinsam benutzte Teams, die lokal erweitert sind, für andere Kombinationen von Produkt- und Projektkontexten.
* 
Für umfassende Berechtigungsanforderungen sollten Sie kontextunabhängige Teilnehmer in Betracht ziehen. Dies sorgt für eine optimale Größe des Teams und reduziert die Auswirkungen auf die Systemverarbeitungsressourcen. Für Berechtigungsanforderungen, die von Kontext zu Kontext variieren, verwenden Sie kontextspezifische Teilnehmer.
Die folgenden Tabellen enthalten mehr Details zu den verschiedenen Techniken für das Verwalten von Berechtigungen für Teams und deren Auswirkungen auf die Leistung.
Kontextunabhängige Teilnehmer (Benutzer, benutzerdefinierte Gruppen, Organisationen und Pseudo-Rollen)
Systemressourceneffizienz
Wann am besten geeignet
Wenn die Berechtigungsanforderungen für bestimmte Teilnehmergruppen sich nicht von Anwendungskontext zu Anwendungskontext unterscheiden
Verwendungshinweise
Die Teilnehmer sollten nicht zum Team hinzugefügt werden. Stattdessen sollten ihnen die erforderlichen Berechtigungen über Zugriffssteuerungsregeln gewährt werden.
Beispiele
Beispiel 1
Eine komplette Organisation benötigt Lesezugriff auf spezifische Typen von Daten in jedem öffentlichen Produkt innerhalb der Organisation. In diesem Fall würde eine Option darin bestehen, alle Benutzer in der Organisation zur Gastrolle in jedem Produkt hinzuzufügen. Dies ist ein verarbeitungsintensiver Ansatz. Stattdessen kann Benutzern mithilfe von Zugriffsrichtlinien Lesezugriff auf bestimmte Objekttypen in einer geeigneten Domäne wie der Domäne "/Default/PDM" der Organisation gewährt werden.
Beispiel 2
Eine bestimmte Benutzergruppe führt Aufgaben im Rahmen der Compliance-Prüfung in jedem Anwendungskontext durch. Die Erstellung einer Rolle für die Compliance-Prüfung und das Hinzufügen derselben Benutzer zu dieser Rolle für jeden Anwendungskontext verursacht unnötigen Mehraufwand. Stattdessen können der Benutzergruppe die erforderlichen Berechtigungen mithilfe von Zugriffsrichtlinien für eine benutzerdefinierte Gruppe "Compliance-Prüfung" in einer geeigneten Domäne wie der Domäne "/" (Root) des Standorts gewährt werden.
Weitere Hinweise
Für Benutzer, die keine Mitglieder des Anwendungskontext-Teams sind, werden die Anwendungskontexte nicht auf der Seite "Produkt", "Bibliothek", "Programm" oder "Projektliste" der Benutzeroberfläche aufgeführt. Benutzer können sie jedoch suchen. Wenn Benutzer über entsprechende Berechtigungen verfügen, werden die Anwendungskontexte gefunden. Nach dem Zugriff werden die Anwendungskontexte in die zuletzt genutzten Listen im Navigator geladen und stehen dort zur späteren Verwendung zur Verfügung.
Wenn diese Benutzer auf Aktionen zugreifen müssen, die für Nicht-Teammitglieder nicht automatisch sichtbar sind, können die Einstellungen "Aktionen für Rollen konfigurieren" des Teams verwendet werden, um die nötigen Aktionen für Nicht-Teammitglieder sichtbar zu machen. Solche Regeln können mit Kontextvorlagen automatisch für neue Kontexte weitergegeben werden. Unter Umständen müssen auch einige Funktionen, z.B. die Teilnahme an Workflows, für Nicht-Teammitglieder anders eingestellt werden.
Die Zugriffsrichtlinienregeln, die für solche Benutzer für die Navigation zu verschiedenen Typen von Daten innerhalb des Anwendungskontexts benötigt werden, können von Fall zu Fall anders sein. Diese Berechtigungen sollten identifiziert und richtig gewährt werden.
Mehr Informationen
Gemeinsam benutztes Team
Kontextspezifische Teilnehmer (Systemgruppen und dynamische Rollen)
Systemressourceneffizienz
Wann am besten geeignet
Die Teilnehmer benötigen Zugriff auf Objekte innerhalb eines Anwendungskontexts, und zwar basierend auf ihrer Rolle in diesem Kontext.
Die gleiche Teamstruktur kann für mehrere ähnliche Anwendungskontexte angewendet werden, mit wenigen oder gar keinen Änderungen.
Die gleichen Benutzer oder Gruppen agieren in all diesen Anwendungskontexten in denselben Rollen.
Kann lokal erweitert werden, um weitere Anforderungen zu erfüllen (siehe "Weitere Hinweise" unten).
Verwendungshinweise
Gemeinsam benutzte Teams werden aufgrund der allgemeinen Berechtigungen, die Benutzern gewährt werden müssen, oft für Bibliotheksteams verwendet.
In anderen Fällen können mehrere gemeinsam benutzte Teams für verschiedene Produkte und Projekte erstellt werden.
Weitere Hinweise
Gemeinsam benutzte Teams sind am effizientesten, wenn sie nicht lokal erweitert werden. Beim lokalen Erweitern des Teams wird eine lokale Team-Instanz erstellt, die einige der Leistungsvorteile reduziert, die mit dem gemeinsam genutzten Team erzielt werden sollen. Abhängig davon, in welchem Maße das gemeinsam benutzte Team in jedem lokalen Team verändert wird, kann mit dem gemeinsam benutzten Team überhaupt kein echter Vorteil erzielt werden.
Mehr Informationen
Lokales Team
Kontextspezifische Teilnehmer (Systemgruppen und dynamische Rollen)
Systemressourceneffizienz
Wann am besten geeignet
Die Teilnehmer benötigen Zugriff auf Objekte innerhalb eines Anwendungskontexts, und zwar basierend auf ihrer Rolle in diesem Kontext.
Die Teamstruktur ist für jeden Anwendungskontext gibt spezifisch.
Welche Teilnehmer in den Teamrollen agieren, unterscheidet sich je nach Anwendungskontext.
Verwendungshinweise
Erstellen Sie breite Gruppierungen von Benutzern auf Grundlage ihrer Zuständigkeiten.
Fügen Sie die Gruppen bestimmten Rollen im Team hinzu.
Erstellen Sie keine eindeutigen Benutzergruppierungen für jeden einzelnen Kontext. Erwägen Sie, wiederverwendbare Benutzergruppen zu verwenden.
Weitere Hinweise
Idealerweise wird die Anzahl von Teilnehmern, die Mitglied eines lokalen Teams sein müssen, auf die optimale Anzahl festgelegt.
Mehr Informationen
Es gibt einige Vorgehensweisen, die es beim Entwurf von Teams zu vermeiden gilt. Die folgende Tabelle zeigt einige Vorgehensweisen und ihre Mängel auf.
Ineffiziente Vorgehensweise beim Team-Entwurf
Mängel
Empfohlene Vorgehensweise
Hinzufügen jedes Benutzers in der Organisation zur Gastrolle (oder zu einer anderen Rolle) in jedem Team, um eine Leseberechtigung für Anwendungskontextdaten zu gewähren.
Sehr große Teamstrukturen beanspruchen Systemressourcen sehr stark.
Stellen Sie grundlegende Zugriffsberechtigungen mithilfe von Richtlinienregeln bereit. Verwenden Sie als Anzahl der Benutzer, die einem Team direkt zugeordnet sein müssen, die optimale Anzahl.
Äußerst präzise Berechtigungskontrolle durch das Erstellen von Hunderten von Rollen für jedes Team.
Sehr große Teamstrukturen beanspruchen Systemressourcen sehr stark.
Denken Sie an den Leistungskompromiss, den Sie beim Erstellen vieler spezialisierter Rollen eingehen müssen. Verwenden Sie als Anzahl von Rollen in einem Team die optimale Anzahl.
Verwenden Sie Produkt- oder Bibliotheksvorlagen zur Angabe der gleichen Zugriffssteuerungsregeln, die für Teamrollen in allen Produkten oder Bibliotheken erstellt werden sollten.
Dies führt zu unnötiger Duplizierung, da die gleichen Richtlinien-Zugriffssteuerungsregeln für dieselbe Rolle in jedem Produkt erstellt werden.
Erstellen Sie wenn möglich Richtlinien-Zugriffssteuerungsregeln für dynamische Rollen auf Organisationsebene, anstatt sie in jedem Anwendungskontext zu duplizieren. Weitere Informationen finden Sie unter Dynamische Rollen in Zugriffsregeln verwenden.
Eindeutige Benutzergruppen werden adhoc für Rollenzuweisungen in Produkten erstellt. Die Gruppen werden nicht wiederverwendet und sind spezifisch für ein einzelnes Produkt.
Die Folge können viele Benutzergruppen mit ähnlichen Teilnehmermitgliedschaften sein. Dies erschwert die Pflege von Benutzergruppen und überlädt das LDAP.
Organisieren Sie Benutzer in wiederverwendbaren Benutzergruppen, anstatt eindeutige Benutzergruppen für jeden Kontext zu erstellen. Alternativ können Sie auch Benutzer direkt Teams zuordnen, anstatt Benutzergruppen zu erstellen und diese Gruppen Rollen zuzuordnen. Die zweite Methode ist nicht so effizient wie die erste.
Andere Optimierungstechniken
Nachstehend finden Sie einige nützliche Systemoptimierungstechniken in Verbindung mit Teams.
Erwägen Sie, Teammitgliedschaften zu bereinigen, sobald Kontexte das Ende ihres Lebenszyklus erreicht haben. Das Dienstprogramm DeleteLocalTeamRoles löscht lokale Teamrollen aus einem vorhandenen Anwendungskontext. Weitere Informationen finden Sie unter Lokale Teamrollen löschen.
Optimieren Sie Cache-Größen für PrincipalCache und RemoteObjectIdCache gemäß den Richtlinien für optimale Vorgehensweisen. Dies stellt sicher, dass die Caches die Anforderungen von Teamstrukturen effektiv erfüllen können. Sehen Sie sich die folgenden Artikel in der Wissensdatenbank an, um sich eingehender zu informieren.
Ziehen Sie die Verwendung des Dienstprogramms PopulateConfirmedUsersInCache in Betracht, um Einträge im PrincipalCache vorab zu füllen, sodass der Cache beim Systemstart vorbereitet wird. Sehen Sie sich den folgenden Artikel in der Wissensdatenbank an, um sich eingehender zu informieren: https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS115189.
Für eine optimale Cache-Nutzung führen Sie eine regelmäßige Wartung der Teilnehmer durch, um den nicht verbundenen Status zu lösen. Weitere Informationen finden Sie unter Nicht verbundene Teilnehmer verwalten.
Überlegen Sie, ob das Einstellen der Eigenschaft wt.inf.team.wtusersUseAccessPolicyRules auf "true" für Ihren Standort angemessen ist. Bei Festlegung auf "true" werden die vom System generierten Adhoc-Regeln nicht zu Teilnehmern hinzugefügt, wenn ein Anwendungskontext aus einer Vorlage erstellt wird. Sehen Sie sich den folgenden Artikel in der Wissensdatenbank an, um sich eingehender zu informieren: https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS180319.
War dies hilfreich?