Bausteine
Ein "Baustein", auch als Komponente bezeichnet, ist ein Implementierungsmuster in ThingWorx, um kleinere, unabhängige, in sich geschlossene, aber funktionsreiche Module zu erzeugen, die zum Erstellen von Lösungen verwendet werden können. Jeder Baustein wird erstellt, um einen bestimmten Zweck zu erfüllen, z.B. externe Datenintegration, Lösungsfunktionen, Ergänzungen der Benutzeroberfläche, Plattformfunktionen oder Manipulation und Verwaltung von Anlagen. Bausteine werden in geordneter Reihenfolge gestapelt, und bilden so eine Lösung, beginnend vom Basisbaustein bis zum Lösungsbaustein.
Ein einzelner Baustein besteht aus einem Satz von ThingWorx Entitäten, die in einem ThingWorx Projekt gesammelt werden und das als ThingWorx Erweiterung gepackt ist. Jeder Baustein basiert auf dem Basisbaustein (PTC.Basis), der die gesamte Bausteinarchitektur ermöglicht. Dieser Basisbaustein legt die Startstruktur für jeden Baustein mit den folgenden Entitäten fest:
• ThingWorx Projektentität – Kapselt und verwaltet alle Entitäten, aus denen sich der Baustein zusammensetzt.
• Einstiegspunkt-Entität – Basierend auf der Dingvorlage PTC.Base.ComponentEntryPoint_TT wird diese Entität verwendet, um alle Baustein-Metadaten wie Name, Beschreibung, Version, Liste der abhängigen Bausteine usw. zu enthalten.
• Manager – Basierend auf der Dingvorlage PTC.Base.CommonManager_TT enthält diese Entität die Funktionen eines Bausteins, einschließlich Dienste, Eigenschaften, Konfigurationen, Ereignisse usw.
• Berechtigungen – Berechtigungs-Benutzergruppen können basierend auf den Sicherheitszugriffsanforderungen für einen Baustein erstellt werden. Ein typisches Beispiel für eine Berechtigungs-Benutzergruppe ist ein granularer Zugriff auf CRUD-Dienste.
Das folgende Diagramm veranschaulicht den grundlegenden Inhalt eines Bausteins. Wie dargestellt, sind alle Bausteine vom Basisbaustein abhängig. Weitere Informationen finden Sie unter Basisbaustein.
Im Diagramm weisen Pfeile mit hohlen Köpfen und durchgezogenen Linien (
) darauf hin, dass sich eine Entität von der Entität aus erweitert, auf die der Pfeil zeigt, und Pfeile mit hohlen Köpfen und gestrichelten Linien (
) weisen darauf hin, dass eine Entität die Entität implementiert, auf die der Pfeil zeigt.
) darauf hin, dass sich eine Entität von der Entität aus erweitert, auf die der Pfeil zeigt, und Pfeile mit hohlen Köpfen und gestrichelten Linien () weisen darauf hin, dass eine Entität die Entität implementiert, auf die der Pfeil zeigt.Bausteintypen
Bausteine werden in der Regel in vier verschiedene Typen gruppiert, was auf ihr zugrunde liegendes Entwurfsmuster hinweist:
• UI-Baustein – Ein Baustein, der die Benutzeroberfläche als Haupt-Interaktionsschnittstelle verfügbar macht. Er kann Logik für UI-Zwecke zusätzlich zu Mashups enthalten. UI-Bausteine rufen in der Regel einen abstrakten Baustein oder einen Standard-Baustein auf.
• Abstrakter Baustein – Ein Baustein, der Dienstdefinitionen enthält und der die APIs als Haupt-Interaktionsschnittstelle verfügbar macht. Er sollte nur abstrakte Elemente enthalten und wird normalerweise von einem Implementierungs-Baustein begleitet. Er kann nach Bedarf auch Mashups enthalten.
• Implementierungs-Baustein – Ein Baustein, der die Dienstimplementierung bereitstellt, um eine Verbindung mit externen Datenquellen herzustellen oder Geschäftsregeln auf Datenebene bereitzustellen. In der Regel werden die in der abstrakten Komponente enthaltenen Dienste überschrieben.
• Standard-Baustein – Ein Baustein, der nicht mit einer eindeutigen Implementierung überschrieben werden soll, aber im Allgemeinen eine Kombination aus den abstrakten Bausteintypen und den Implementierungs-Bausteintypen ist. Ein Standard-Baustein kann nach Bedarf auch Mashups enthalten. Die meisten von Kunden entwickelten Bausteine sind von diesem Typ, da sie nicht so komplex sind wie die anderen Bausteintypen.
Bausteinkategorien
Bausteine werden in der Regel in vier gemeinsame Kategorien gruppiert, die lose nach ihrer Abhängigkeit von anderen Bausteinen verknüpft sind:
• Lösungsbaustein – In der Regel ein sehr einfacher Baustein, der Abhängigkeiten von allen für die Lösung benötigten Bausteinen aufweist. Diese Bausteinkategorie ist eine grundlegende Implementierung des Einstiegspunkts aus dem Basisbaustein innerhalb einer Projektentität. Beispiel: Der DPM Baustein (PTC.DPM)
• Lösungsspezifische Bausteine – Eine Kombination von Bausteinen vom Typ "Benutzeroberfläche" und Standard-Bausteine oder abstrakte Bausteine, basierend auf der Art und Weise, wie die Lösung auf den Markt kommt. Diese können basierend auf der Wiederverwendbarkeit der Geschäftslogikfunktionen in zwei weitere Kategorien aufgeteilt werden:
◦ Moduldarstellungs-Bausteine – Dies sind im Allgemeinen Benutzeroberflächen-Bausteine. Beispiel: Produktions-Dashboard-Baustein (PTC.ProductionDashboard) in der DPM Lösung
◦ Modullogik-Bausteine – Dies sind Bausteine, die eine Geschäftslogik-Schicht für viele zugrunde liegende Bausteine bereitstellen. Beispiel: Der Operations-KPI-Baustein (PTC.OperationKPI) in der DPM Lösung ruft eine Reihe von domänenspezifischen Bausteinen auf.
• Domänenspezifische Bausteine – Diese Bausteine stellen eine Sammlung von domänenspezifischen Funktionen bereit, die minimale Abhängigkeiten aufweisen. Beispiel: Schicht-Baustein (PTC.Shift), Grundcode-Baustein (PTC.ReasonCode) usw.
• Allgemeine Bausteine – Der gemeinsame Satz von Bausteinen, die von allen Lösungen verwendet werden können. Beispiel: Basisbaustein (PTC.Basis), Benutzerverwaltungs-Baustein (PTC.UserManagement), Modellverwaltungs-Baustein (PTC.ModelManagement) und Datenbankverbindungs-Baustein (PTC.DBConnection)