Zugriffs-Modifizierer
Zugriffs-Modifizierer sind ein neues Konstrukt, das in ThingWorx 9.5 eingeführt wurde, damit Entwickler solche Artefakte (Entitäten und ihre Merkmale) identifizieren können, die vor externer Verwendung geschützt sind, sowie solche, die von Endbenutzern zur weiteren Anpassung oder Entwicklung verwendet werden können, einschließlich Erweiterung, Referenzierung und Wiederverwendung. Es ist auch möglich, Entitäten für die externe Verwendung zu öffnen und dabei einige der Merkmale zu schützen.
Auf die geschützten Artefakte kann von Laufzeitprüfungen nicht zugegriffen werden. Die meisten formal definierten Beziehungen werden zur Erstellungszeit validiert. Die Verwendung innerhalb von Codeblöcken von Diensten und Mashups wird jedoch nur zur Laufzeit überprüft. Die Laufzeitprüfungen können nicht vollständig fehlerfrei sein und dienen lediglich als Hilfe, um eine unsachgemäße Verwendung zu vermeiden. Die Deklaration von Zugriffs-Modifizierern bleibt die Source of Truth, und Entwickler sollten die betroffenen geschützten Artefakte nicht verwenden, wenn damit gegen die deklarierten Zugriffs-Modifizierer verstoßen wird. Solche geschützten Artefakte können geändert oder entfernt werden, und jede abhängige Verwendung, die gegen die Deklarationen verstößt, kann zu einem zukünftigen Zeitpunkt ohne Benachrichtigung fehlschlagen.
Ein Zugriffs-Modifizierer gibt den Umfang der Zugänglichkeit für Entitäten und Merkmale an.
In ThingWorx 9.5.0 werden Zugriffs-Modifizierer für die folgenden Entitäten und Merkmale unterstützt:
|
Entitäten
|
Merkmale
|
||||
|---|---|---|---|---|---|
|
• Dinge
• Dingvorlagen
• Dingform
• Dinggruppen
• Data Shapes
• Netzwerke
• Industrieverbindungen
• Integrations-Konnektoren
• Scheduler
• Zeitgeber
• Dashboards
• Menüs
• Medien
• Stildefinitionen
• Stilthemen
• Statusdefinitionen
• Datentabelle
• Streams
• Wert-Streams
• Blogs
• Wikis
|
• Eigenschaft
• Dienst
• Konfigurationstabelle
|
Die folgenden Entitäten unterstützen Zugriffs-Modifizierer nicht:
|
• Projekt
• Modell-Tag
• Benachrichtigung
• Daten-Tag
• Persistenter Anbieter
• Benutzergruppen
• Benutzer
• Organisationen
• Anwendungsschlüssel
• Verzeichnisdienste
• Authentifikatoren
• Mashup
• Mashup-Vorlage
• Master
• Gadget
• Lokalisierungstabellen
|
Zugriffs-Modifizierer sind in folgende Klassen unterteilt:
• KEIN – Fehlender Umfang wird als öffentlicher Umfang behandelt und kann auf eine Entität oder Merkmale angewendet werden. Jeder kann auf Entitäten oder Merkmale mit öffentlichem Umfang zugreifen.
◦ Auf Entitäten mit dem Umfang NONE kann jeder zugreifen.
◦ Ein Merkmal mit dem Umfang NONE erbt den Zugriffs-Modifizierer von der Entität, zu der es gehört.
• PRIVAT – Dieser Umfang kann auf eine Entität oder Merkmale angewendet werden, und der Zugriff ist nur innerhalb des Projekts möglich.
• EINGESCHRÄNKT – Dieser Umfang kann auf eine Entität oder Merkmale angewendet werden. Er fungiert als privater Umfang und fügt die Projekte mit dem Namespace und seiner Kind-Hierarchie der Liste der zugänglichen Elemente hinzu. Beispielsweise ist RESTRICTED[ptc.dpm.jobOrder] für alle Entitäten aus dem Namespace ptc.dpm.jobOrder und seinen Kind-Namespaces zugänglich, für alle anderen Entitäten jedoch privat.
 |
In ThingWorx 9.5.0 kann nur ein Namespace (+Kinder; dies ist implizit) für den eingeschränkten Umfang hinzugefügt werden.
|
• INTERN – Dieser Umfang kann nur auf Merkmale angewendet werden. Ein Merkmal mit diesem Umfang ist nur innerhalb der jeweiligen Entität zugänglich.
|
|
Umfangszuweisungen werden für Entitäten und Merkmale persistent gemacht.
Ein Umfang kann für alle unterstützten Entitäten unabhängig von ihrem Projekttyp angewendet werden. Wenn einem Projekt kein Namespace zugewiesen ist, können nur die Umfänge "Kein" oder "Privat" auf Entitäten und "Kein", "Privat" oder "Intern" auf Merkmale angewendet werden.
|
|
|
Alle Entitäten und Merkmale haben nach der Migration zu ThingWorx 9.5 den Umfang NONE (nicht angegeben).
|
• Die Merkmalsebene kann keinen breiter gefassten Umfang haben. Beispiel: Wenn die Entität den Umfang PRIVAT hat, können die Merkmale nicht KEIN als Umfang haben.
• Wenn die einer Entität zugeordneten Objekte den Umfang KEIN haben, muss der Umfang für Objekte in der Liste EINGESCHRÄNKT, die auf Merkmalsebene zulässig sind, weiter oder enger gefasst oder gleich sein. Und für Entitäten mit anderen Umfängen muss der Umfang für Objekte in der Liste EINGESCHRÄNKT, die auf Merkmalsebene zulässig sind, gleich oder enger gefasst sein.
Anforderungen für das Erstellen eines Umfangs
Ein Umfang darf nur Großbuchstaben enthalten.
Standardumfang für Bausteinprojekte konfigurieren
Ein Standardumfang kann für Projekte vom Typ "Baustein" konfiguriert werden. Beim Erstellen einer neuen Entität wird diese Konfiguration als Standardzuweisung für den Umfang verwendet.
Der Standardumfang eines Projekts kann zur Laufzeit über Composer oder einen REST-Aufruf aktualisiert werden. Neue Entitäten, die in diesem Projekt erstellt werden, erben diesen Umfang. Der Umfang vorhandener Entitäten ist von der Änderung dieser Konfiguration nicht betroffen. Der Umfang einer Entität kann zur Laufzeit geändert werden.
|
|
Diese Konfiguration gilt nur für die Umfangsfestlegung, wenn Composer zum Erstellen von Entitäten verwendet wird.
|
Zugriffs-Modifizierer für eine Entität oder Merkmale festlegen
Ein Zugriffs-Modifizierer kann einer Entität oder Merkmalen mit folgenden Methoden zugewiesen werden:
• Durch Auswahl des Umfangs aus der Liste Umfang auf der Registerkarte Allgemeine Informationen in Composer.
• Durch Verwendung von Java-Anmerkungen.
• Durch XML- oder Erweiterungsimport.
• Durch Ausführen des Diensts SetAccessModifier unter der Ressource EntityServices. Dieser Dienst kann verwendet werden, um einen Zugriffs-Modifizierer in einem Massenvorgang für mehrere Entitäten und Merkmale festzulegen.
|
|
In ThingWorx 9.5.0 wird das Festlegen eines Zugriffs-Modifizierers über den Aufruf von Erstellungsdiensten in der Ressource EntityServices nicht unterstützt. Beispielsweise akzeptieren Erstellungsdienste wie CreateThing, CreateThingShape, CreateNetwork usw. keinen Zugriffs-Modifizierer als Argument.
|
|
|
Beim Erstellen einer Entität werden Zugriffs-Modifizierer nicht in Prüfungsprotokollen protokolliert.
|
|
|
Zugriffs-Modifizierer können mithilfe von Java-Anmerkungen zu Merkmalen hinzugefügt werden. Für das Hinzufügen von Zugriffs-Modifizierer auf Entitätsebene werden Anmerkungen jedoch nicht unterstützt. Auf Entitätsebene können Zugriffs-Modifizierer durch XML-Import hinzugefügt werden.
|
Festgelegten Zugriffs-Modifizierer für eine Entität oder Merkmale anzeigen
Durch Ausführen des Diensts GetAspects unter Ressourcen für EntityServices können Sie den Zugriffs-Modifizierer anzeigen, der für eine Entität oder Merkmale festgelegt ist.
Entitäten über Zugriffs-Modifizierer filtern
Entitäten können mithilfe von 
in Composer nach Umfang gefiltert werden.
in Composer nach Umfang gefiltert werden.
Zugriffs-Modifizierer protokollieren
Wenn ein Benutzer die Zugriffs-Modifizierer für eine Entität oder Merkmale erstellt, aktualisiert oder löscht, werden die Überprüfungen im Prüfungsprotokoll gepflegt.
Weitere Informationen finden Sie unter Prüfungsuntersystem.
| | Änderungen an einer Entität oder einem Merkmal durch andere Entitäts-, Mitglieds- oder Dienstaufrufe werden nicht geprüft. |
Entitäten von einem Projekt in ein anderes Projekt verschieben
Wenn Sie eine Entität projektübergreifend verschieben, bleiben der Umfang der Entität, Eigenschaften, Dienste und Konfigurationstabellen unverändert, wenn die Quellentität oder das Quellmerkmal den Umfang "Kein" oder "Privat" aufweist.
| | Ein Namespace, der gleich oder weiter gefasst als der Namespace des Zielprojekts ist, ist ein gültiger Namespace. Ein Namespace, der nicht gleich oder enger gefasst als der Namespace des Zielprojekts ist, ist ein ungültiger Namespace. |
Nachfolgend sind die verschiedenen Szenarien aufgeführt, die beim Verschieben von Entitäten mit dem Umfang "Eingeschränkt" von einem Namespace in einen anderen auftreten können:
• Szenario 1
Wenn die Entität über einen gültigen Namespace verfügt, ändert sich der Umfang nicht.
Beispiel: Wenn eine Entität mit dem Umfang RESTRICTED [dpm.sco.jobOrder] in ein Projekt mit dem Namespace (dpm.sco.jobOrder.scp.jobOrder12) verschoben wird, bleibt der Umfang der Entität gleich.
• Szenario 2
Wenn die Entität über einen ungültigen Namespace verfügt und das Zielprojekt keinen Standardumfang hat, ändert sich der Umfang der Entität in "Privat".
Beispiel:
◦ Wenn ein Ding mit dem Umfang RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12] in ein Projekt mit dem Namespace (abc.xyz.pqr) verschoben wird, ändert sich der Umfang des Dings in PRIVATE[abc.xyz.pqr].
• Szenario 3
Wenn die Entität über einen ungültigen Namespace verfügt und das Zielprojekt den Standardumfang "Eingeschränkt" mit exmptList hat, ändert sich der Umfang der Entität in den Standardumfang des Zielprojekts.
Beispiel:
◦ Wenn ein Ding mit dem Umfang RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12] in ein Projekt mit dem Standardumfang RESTRICTED[abc.xyz.pqr] verschoben wird, ändert sich der Umfang des Dings in RESTRICTED[abc.xyz.pqr].
◦ Wenn ein Ding mit dem Umfang RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12] in ein Projekt mit dem Standardumfang RESTRICTED[dpm.sco.jobOrder] verschoben wird, ändert sich der Umfang des Dings in RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12].
• Szenario 4
Wenn die Entität über einen ungültigen Namespace verfügt und das Zielprojekt den Standardumfang "Privat" hat, ändert sich der Umfang der Entität in den Standardumfang des Zielprojekts.
Beispiel:
◦ Wenn ein Ding mit dem Umfang RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12] in ein Projekt mit dem Standardumfang PRIVATE[dpm.sco.jobOrder] verschoben wird, ändert sich der Umfang des Dings in PRIVATE[dpm.sco.jobOrder].
◦ Wenn ein Ding mit dem Umfang RESTRICTED[dpm.sco.jobOrder.scp.jobOrder12] in ein Projekt mit dem Standardumfang PRIVATE[abc.xyz.pqr] verschoben wird, ändert sich der Umfang des Dings in PRIVATE[abc.xyz.pqr].
• Szenario 5
Wenn die Entität über einen ungültigen Namespace verfügt und das Zielprojekt keinen Namespace hat, ändert sich der Umfang der Entität in "Privat".
Beispiel: Wenn ein Ding mit dem Umfang RESTRICTED [dpm.sco.jobOrder.scp.jobOrder12] in ein Projekt ohne Namespace verschoben wird, ändert sich der Umfang des Dings in PRIVATE.
| | Wenn sich die RESTRICTED auf Entitätsebene ändert und die RESTRICTED der Merkmale ungültig sind, ändert sich der Merkmalsumfang in "Geerbt". |
| | Das Verschieben von Entitäten wird im Anwendungsprotokoll als Debugging protokolliert. |
Einschränkungen bei Zugriffs-Modifizierern
Für Zugriffs-Modifizierer gelten die nachfolgend aufgeführten Einschränkungen.
• Geerbte Merkmale werden beim Erstellen eines neuen Diensts oder Bearbeiten eines vorhandenen Diensts nicht im Abschnitt Ich/Entitäten angezeigt.
• Private Eigenschaften eines anderen Projekts sind beim Erstellen von Eigenschaftsbindungen sichtbar.
• Mashups haben keine Zugriffs-Modifizierer.
• Wenn der Entitätsname ein Sonderzeichen enthält und die Zugriffs-Modifizierer-Prüfungen zur Laufzeit nicht ausgeführt werden, führen Sie die nachfolgenden Schritte aus:
1. Codieren Sie den Namen im Base64-Format.
2. Fügen Sie ein Suffix im Format encodedname/b64 hinzu.
3. Übergeben Sie diesen Wert als twx-referrer-entity und verwenden Sie dabei REST-APIs.
• Wenn ein Entitätsname Zeichen enthält, die nicht in der Datei validation.properties aufgeführt sind, werden die Zugriffs-Modifizierer-Prüfungen während der Laufzeit nicht durchgeführt. Sie können der Datei Zeichen hinzufügen, indem Sie die Datei validation.properties konfigurieren. Fügen Sie die Werte für Validator.HTTPHeaderValue hinzu, oder ändern Sie diese. Weitere Informationen finden Sie unter Einstellungen des ESAPI-Validierers konfigurieren.