Dingvorlagen
Dingvorlagen stellen Basisfunktionen mit Eigenschaften, Diensten, Ereignissen und Abonnements bereit, die
Dinginstanzen bei der Ausführung verwenden. Jedes Ding wird aus einer Dingvorlage erstellt. Eine Dingvorlage kann eine andere Dingvorlage erweitern. Wenn Sie eine neue Version eines Produkts freigeben, fügen Sie einfach die zusätzlichen Merkmale der Version hinzu. Sie müssen dann nicht das gesamte Modell umdefinieren. Diese Modellkonfiguration bietet mehrere Ebenen der Generalisierung eines Assets. Eine Dingvorlage kann ein oder mehrere zusätzliche Merkmale ableiten, indem Dingformen implementiert werden. Wenn Sie eine Änderung an der Dingvorlage vornehmen, wird die Änderung an die Dinge übertragen, die diese Dingvorlage implementieren, wodurch die Wartung des Modells vereinfacht wird.
Eine Dingvorlage kann verwendet werden, um die Art eines Dings oder Asset-Klasse oder ein spezifisches Produktmodell mit einzigartigen Funktionen zu klassifizieren. Wenn Sie zwei Produktmodelle haben und ihre Interaktion mit der Lösung dieselbe ist (dieselben Eigenschaften, Dienste und Ereignisse), können Sie sie als eine Dingvorlage modellieren. Sie können Dingvorlagen klassifizieren, um Dinge zu Sammlungen zusammenzufassen, die in Mashups nützlich sind. Sie können separate Dingvorlagen für die Indexierung, Suche und zukünftige Entwicklung von Produkten erstellen.
Systemdefinierte Dingvorlagen
Es gibt mehrere systemdefinierte Dingvorlagen, die verwendet werden können, um Dinge für bestimmte Aufgaben zu erstellen. Einige dieser Dingvorlagen können als Dienstprogramme für verschiedene Dienste und Funktionen nützlich sein, wenn Anwendungen erstellt werden.
Die systemdefinierten Dingvorlagen sind folgende:
• Blog – Ein Blog-Ding wird verwendet, um einen Blog, Kommentare und/oder Diskussionsforum-Zusammenarbeitsobjekte in Mashups zu implementieren.
• Content Crawler – Ding zum Verarbeiten einer speziellen Schnittstelle zu einem externen System oder Inhaltsbereich. Sie definieren einen Dienst, um eine Liste des externen Inhalts abzurufen, der indexiert werden soll, und außerdem einen Dienst, um die Details für jedes Inhaltsobjekt abzurufen. ThingWorx indexiert anschließend die Daten und macht sie über die ThingWorx Suchfunktionen verfügbar.
• Database – JDBC-Verbindung mit beliebigem relationalem Datenbanksystem von Drittanbieter.
• Data Table – Eine Datentabelle ähnelt einer Tabelle in einer relationalen Datenbank und kann zum Speichern transaktionaler Datenzeilen in ThingWorx verwendet werden.
• File Repository – definierte ThingWorx Entität zum Speichern von externem Dateiinhalt. Wenn Sie Dateien zu/von einem Edge-Ding übertragen, sollten Sie dies in ein/von einem bestimmten Repository tun. Ein Datei-Repository verweist auf einen Ordner im Order ThingworxStorage/repository des Servers. Die Dienste eines Datei-Repositorys ermöglichen es Ihnen, Dateien im Ordner anzuzeigen und zu bearbeiten.
• Generic Thing – Basisding mit minimalen geerbten Merkmalen. Als optimale Vorgehensweise gilt es, eine benutzerdefinierte Dingvorlage zu definieren. Es gibt jedoch möglicherweise Fälle, in denen Sie eine einmalige Dingdefinition haben und ein allgemeines Ding verwenden möchten.
• Mail Server – Ein Mail-Server-Ding kann erstellt werden, wenn Sie E-Mail-Nachrichten von Ihrer Anwendung senden möchten.
• Edge – Ein Edge-Ding ist ein Gerät oder eine Datenquelle, der/die auf einem anderen Server installiert wird, normalerweise durch eine Firewall zu einem anderen Netzwerk. Ein Edge-Ding kommuniziert mit dem Server über ein lokal installiertes EMS. Ein Beispiel für ein Edge-Ding ist ein OPC-DA-Server.
• Edge Database – Ein Edge-Datenbankding dient der Kommunikation mit einer OLE-DB- oder ADO.NET-Datenbank oder -Datenquelle auf einem anderen Server oder Arbeitsplatz. Beispiele einer Edge-Datenbank sind Microsoft Excel oder Microsoft Access.
• Edge Enhanced – Ein Servermodell-Ding (remote installiertes Gerät oder remote installierter Datenspeicher), das Remote-Desktop-Tunneln oder Dateiübertragung unterstützen muss.
• Scheduler – Ein Scheduler-Ding kann verwendet werden, um auf Grundlage eines cron-Musters Jobs auszuführen, beispielsweise einmal täglich oder einmal in der Stunde.
• Source Control Repository – Ein Quellverwaltungs-Repository kann auf jeden beliebigen Ordner im Dateisystem des Servers verweisen, der das Stammverzeichnis Ihres lokalen Repositorys sein kann. Es wird von > verwendet.
• Stream – Zeitreihen-Datenspeicher.
• Timer – einfacher Zeitgeber, der ein Ereignis in einem definierten Intervall auslöst.
• Wiki – Zusammenarbeitsobjekt zum gemeinsamen Benutzen von Dokumenten und verknüpften Kommentaren in Mashups.
Wenn Sie eine bestimmte Instanz einer der System-Dingvorlagen erstellen, können Sie sie gemäß Ihren geschäftlichen Anforderungen und Ihrer IoT-Umgebung konfigurieren.
Systemdefinierte Remote-Vorlagen
Es können mehrere systemdefinierte Dingvorlagen verwendet werden, um über Web Sockets mit Edge-Geräten oder Datenspeichern zu kommunizieren. RemoteThing ist die Namenskonvention für die Verwendung von WebSockets zum Kommunizieren mit einem anderen Knoten oder Ding im Netzwerk. Die Dingvorlagen für das WSEMS und die SDKs sind wie folgt:
• RemoteDatabase – OLE-DB-Remote-Datenquelle.
• RemoteThing – Remote-Ding ohne Dateiübertragungs- oder Tunnelanforderungen. Wird auch für OPC-DA-Datenquellen-Dinge verwendet. Unterstützt Eigenschaften, Dienste und Ereignisse.
• RemoteThingWithFileTransfer – Remote-Ding plus Dateiübertragung.
• RemoteThingWithTunnels – Remote-Ding plus Tunneln.
• RemoteThingWithTunnelsAndFileTransfer – Remote-Ding mit Dateiübertragung und Tunneln.
• EMSGateway – Die EMSGateway-Dingvorlage wird verwendet, wenn Sie in der Lage sein möchten, das WSEMS als unabhängiges Ding zu verarbeiten. Dies kann in Situationen hilfreich sein, in denen das WSEMS auf einem Gateway-Computer ausgeführt wird und die Kommunikation für ein oder mehrere Remote-Dinge verarbeitet, die sich evtl. auf verschiedenen IP-Adressen in einem LAN befinden.
• SDKGateway – ähnelt EMSGateway; wird aber für eine SDK-Implementierung als Gateway verwendet.
Zusätzlich zu den obigen Dingvorlagen können die folgenden Remote-Vorlagen in einem Verbundspeicherszenario verwendet werden, in dem Sie die Persistenzobjekte auf einen anderen Server auslagern möchten, der für Festplatten-E/A optimiert ist:
• RemoteStream – Erstellen Sie ein lokales Proxy-Objekt zu einem Stream-Ding, das Daten auf einem anderen ThingWorx Server ausführt und persistent macht.
• RemoteValueStream – Erstellen Sie ein lokales Proxy-Objekt zu einem Wert-Stream-Ding, das Daten auf einem anderen ThingWorx Server ausführt und persistent macht.
• RemoteDataTable – Erstellen Sie ein lokales Proxy-Objekt zu einem Datentabellen-Ding, das Daten auf einem anderen ThingWorx Server ausführt und persistent macht.
• RemoteBlog – Erstellen Sie ein lokales Proxy-Objekt zu einem Blog-Ding, das Daten auf einem anderen ThingWorx Server ausführt und persistent macht.
• RemoteWiki – Erstellen Sie ein lokales Proxy-Objekt zu einem Wiki-Ding, das Daten auf einem anderen ThingWorx Server ausführt und persistent macht.
Dingvorlagen mit einer Erweiterung erstellen
Dingvorlagen, die mit einer Erweiterung erstellt werden, sind im Grunde dieselben wie die, die in ThingWorx Composer erstellt werden. Es handelt sich um Basisvorlagen, die verwendet werden, um Dinge mit denselben Eigenschaften, Konfigurationsparametern und Diensten zu erstellen. Der Unterschied zwischen der Erstellung in Composer und in einem Erweiterungsframework ist die Sprache, die für die Dienste und die Sichtbarkeit dieser Dienste verwendet wird.
Composer Vorlage:
• Verwendet JavaScript für Dienste
• Quellcode ist sichtbar
Extension SDK Vorlage:
• Verwendet Java für Dienste
• Quellcode ist nicht sichtbar
• Kann Konfigurationswerte definieren