Bausteine > Entwurfsmuster für Bausteine > Standard-Entwurfsmuster
Standard-Entwurfsmuster
Das Standard-Entwurfsmuster bietet die einfachste Möglichkeit, einen Baustein zu entwickeln, der der Bausteinstruktur entspricht, und die Erkennung durch den Rest der Lösung ermöglicht. Dies ist das häufigste Entwurfsmuster, das bei der Entwicklung von Bausteinen verwendet wird. Dieser Bausteintyp kann UI-Elemente sowie Geschäftslogik und Datenspeicherung enthalten. Er eignet sich ideal für die Verwendung durch Feld-Teams oder Kunden, die zusätzlich zu den von PTC bereitgestellten Inhalten eigene Funktionen erstellen möchten.
Das folgende Diagramm stellt die grundlegendsten Anforderungen für eine Gruppe von Entitäten dar, die als Baustein zu betrachten sind.
Diagramm mit den grundlegenden Entitäten, die für einen Satz von Entitäten erforderlich sind, damit dieser als Baustein betrachtet werden kann, einschließlich der Entitäten, die von anderen Entitäten implementiert werden oder die aus anderen Entitäten hervorgehen
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.
Erforderliche Entitäten
Die folgenden Entitäten sind für das Standard-Entwurfsmuster erforderlich:
Projekt – ThingWorx Projektentität, das die Bausteinentitäten enthält. Die empfohlene Namenskonvention enthält den Projektnamen in den Namen aller Entitäten, die Teil des Bausteins sind. Beispiel: Wenn ein Projekt PTC.BuildingBlock genannt wird, beginnen die Namen aller Entitäten im Baustein mit dem Projektnamen: PTC.BuildingBlock.EntryPoint, PTC.BuilingBlock.Management_TS usw.
Einstiegspunkt – Diese Entität erbt von der Dingvorlage PTC.Base.ComponentEntryPoint_TT alle Baustein-Metadaten, wie Name, Beschreibung, Version, Liste der abhängigen Bausteine usw. Jeder Baustein erbt von der Dingvorlage PTC.Base.ComponentEntryPoint_TT seine eigene Einstiegspunkt-Dingvorlage, z.B. PTC.BuildingBlock.EntryPoint_TT. Ein Einstiegspunkt-Ding wird aus dieser Dingvorlage erstellt, z.B. PTC.BuildingBlock.EntryPoint. Der Dienst DeployComponent für ein Einstiegspunkt-Ding kann überschrieben werden, um eine Aktion auszuführen, wenn der Baustein zuerst auf dem ThingWorx Server bereitgestellt wird.
Manager – Der Baustein-Manager ist die primäre Dienstschicht für den Baustein und bietet mehrere Funktionen für den Baustein. Zuerst fungiert er als Abstraktionsschicht für Entitäten, die den Baustein aufrufen. Zweitens wird er zum Konfigurieren von Menüoptionen und enthaltenen Mashups sowie der Information welche Manager verwendet werden sollen, wenn mehr als einer definiert ist. Jeder Baustein sollte über eine Manager-Dingvorlage verfügen, die PTC.Base.CommonManager_TT erweitert, z.B. PTC.BuildingBlock.Manager_TT. Der Manager selbst ist ein Ding, das auf der Baustein-Manager-Dingvorlage basiert. Die Manager-Dingvorlage implementiert auch eine Dingform (PTC.BuildingBlock.Management_TS). Diese Dingform sollte alle Dienste enthalten, die für den Baustein erforderlich sind. Für von PTC entwickelte Bausteine können diese Dienste als Anpassung überschrieben werden, sodass Lösungsentwickler Standarddienste für ihre eigenen Zwecke überschreiben können. Weitere Informationen finden Sie unter .
Optionale Entitäten
Das folgende Diagramm zeigt optionale Entitäten, die in das Standard-Entwurfsmuster eingeschlossen werden können. Im Diagramm wird der Baustein PTC.MfgModel als Beispiel für einen Baustein mit Modell-, Asset- oder Anlagenhierarchie verwendet, dessen Dingvorlagen die Modelllogik-Dingform im Baustein für das Standard-Entwurfsmuster implementieren. Entitäten mit gestrichelten Umrissen sind optionale Entitäten, die in diesem Muster für die nachfolgend beschriebenen spezifischen Zwecke enthalten sind. Andere ThingWorx Entitäten können auch in das Standard-Entwurfsmuster eingeschlossen werden. Diese Entitäten haben jedoch eine bestimmte Bedeutung.
Diagramm mit den erforderlichen und optionalen Entitäten, die in einen Standard-Entwurfsmuster-Baustein eingeschlossen werden können, einschließlich der Entitäten, die von anderen Entitäten implementiert werden oder die aus anderen Entitäten hervorgehen
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.
Die folgenden optionalen Entitäten sind im Standard-Entwurfsmuster enthalten:
Sicherheits-Entitäten – Berechtigungs-Benutzergruppen können erstellt und verwendet werden, um unterschiedliche Berechtigungen für jeden Baustein zu definieren. Eine Benutzerrolle ist einfach eine weitere Benutzergruppe, die jeder Berechtigungs-Benutzergruppe hinzugefügt wird.
Mashups – Das Standard-Entwurfsmuster ermöglicht das Hinzufügen von Mashups als Teil der Bausteinfunktionalität. Dies können Haupt-Mashups sein, die mit dem Master-Mashup verbunden sind, oder enthaltene Mashups, die von verschiedenen Bausteinen verwendet werden. Der Baustein-Entwickler bestimmt, welche Funktionen in welchem Baustein sind.
Modelllogik-Entitäten – Die Modelllogik-Dingform ist für die Verwendung durch Mashups oder andere Komponenten vorgesehen, die Organisationssicherheit für Anlagen erzwingen, indem die Organisationen nach Bedarf von ThingWorx verwendet werden. Dies ist erforderlich, wenn der Anwendungsfall die Sichtbarkeitssteuerung für einzelne Anlagen erfordert. Die in der Modelllogik-Dingform enthaltenen Dienste werden auf die hierarchischen Entitäten der Anlage angewendet. Sie stellen einen Wrapper für Dienste bereit, um den entsprechenden konfigurierten Manager über die Verwaltungs-Dingform für den Baustein aufzurufen. Alle Manager sind in der Konfigurationstabelle DefaultGlobalManagerConfiguration auf dem Ding PTC.BaseManager registriert. Manager können auch in der Konfigurationstabelle ManagerConfiguration jeder Entität konfiguriert werden, die die Dingform PTC.Base.ConfigManagement_TS implementiert, z.B. das Manager-Ding für einen Baustein oder ein Anlagenmodellding, das auf einer Dingvorlage basiert, die die Dingform (z.B. PTC.MfgModel.DefaultWorkUnit_TT) implementiert. Dies ermöglicht es unterschiedlichen Modellen, verschiedene Manager zu verwenden. Beispielsweise können zwei Standorte unterschiedliche Manager haben, die sie verwenden möchten, da sie Daten aus verschiedenen Quellen erhalten.
Wenn ein Dienst einen anderen Manager referenziert, sucht er zuerst die Tabelle ManagerConfiguration der Entität, die den Dienst aufruft, um festzustellen, ob ein Eintrag für den referenzierten Manager konfiguriert ist. Wenn dort kein Eintrag gefunden wird, sucht der Dienst in der Konfigurationstabelle DefaultGlobalManagerConfiguration im Ding PTC.Base.Manager.
War dies hilfreich?