Ding-Abonnements
Abonnements sind Dienste, die Ereignisse erhalten und auf sie antworten. Ein Abonnement enthält eine Quelle, normalerweise ein Ding. Ein Ding kann ein Abonnement für ein Ereignis haben, das mit einer Aktion antwortet. Wenn beispielsweise eine Entität das Ereignis Motor ist überhitzt auslöst, kann sie dieses Ereignis abonnieren, indem sie ein Abonnement des Typs Motor ausschalten auslöst. Dinge können Abonnements von den Dingvorlagen und Dingformen erben, die sie verwenden.
Ein Abonnement ähnelt einem Standarddienst, ist aber explizit mit einem Ereignis verknüpft. Dies ermöglicht es Ihnen, das Ereignis vom Code zu entkoppeln, der antwortet. Wie bei einem Dienst können Sie benutzerdefinierte Geschäftslogik implementieren, um auf das Ereignis zu reagieren. Sie können die Funktionen des Modells nutzen, wie Senden von E-Mails über ein Mail-Server-Ding, Schreiben in eine Datenbank oder Aufrufen beliebiger Dienste in der Plattform. Ein Abonnement hat im Gegensatz zu einem Dienst keine explizite Rückgabeausgabe. Ein Abonnement kann jedoch jeden anderen Dienst im Modell aufrufen, auf den der Thread-Sicherheitskontext Zugriff hat. Der Thread-Sicherheitskontext eines Abonnements wird auf denselben Thread-Sicherheitskontext des Ereignisses festgelegt, das ausgelöst wurde. Sie können die JavaScript-Bearbeitungsumgebung verwenden, die für das Implementieren von Diensten verwendet wird.
Abonnements haben eine definierte Eingabe. Dies ist das Datenpaket, das vom Ereignis ausgegeben und als Ereignisdaten bezeichnet wird. Wenn die Entität ein definiertes Ereignis abonniert, werden die Ereignisdaten an die Abonnementfunktion übergeben. Die Ereignisdaten werden durch den Data Shape des Ereignisses beschrieben. Innerhalb der Abonnementimplementierung dienen die Daten, die vom Ereignis übergeben werden, als Eingabe für die Skriptfunktion. Wenn eine Entität beispielsweise ein Ding-Datenänderungsereignis abonniert hat, wird die Abonnement-Skriptfunktion aufgerufen. Anschließend wird der Ding-Eigenschaftswert zusammen mit anderen relevanten Daten aus dem Ereignis als Teil der Ereignisdaten an die Funktion übergeben.
Viele Entitäten können dasselbe Ereignis abonnieren. Jede Entität erhält einen Aufruf des Abonnements mit den übergebenen Ereignisdaten. Eine Entität kann jede Aktion aus dem Abonnementskript verwenden, um die Lösungsanforderungen zu erfüllen.
Der Verwendung dieser Technik hat im Vergleich zu einem Dienst, der von einem anderen Dienst aufgerufen wird, unter anderem die folgenden Vorteile:
Ein Ereignis kann von einem oder mehreren Abonnements abonniert werden.
Ereignisse werden basierend auf der Systemaktivität aufgerufen, und es ist keine Benutzerinteraktion erforderlich.
Wenn mehr als ein Ding für ein Ereignis abonniert ist, können Sie ein Abonnement verwenden, anstatt mehrere Dienste zu verketten.
* 
Mehrere Abonnements für dasselbe Ereignis auf demselben Ding oder doppelte Abonnements werden in ThingWorx Version 8.4.0 und höher unterstützt.
* 
Ereignis-Trigger und Abonnements werden asynchron ausgeführt. Beispielsweise erhält eine API-Anforderung für die Eigenschaftsaktualisierung eine sofortige Antwort, wenn die Eigenschaftsaktualisierung abgeschlossen ist. Es wird nicht gewartet, bis die nachfolgenden Abonnements, die auf die Datenänderung antworten, abgeschlossen sind.
Mehrere Abonnements
Abonnements haben einen benutzerdefinierten Namen als eindeutige ID. Entitäten können mehrere Abonnements für ein Ereignis für ein Ding haben. Wenn beispielsweise eine Entität das Ereignis Motor ist überhitzt auslöst, kann sie dieses Ereignis mit dem Abonnement Motor ausschalten und dem Abonnement Arbeitsauftrag erstellen abonnieren, um den Motor warten zu lassen. Es können auch beliebig viele andere Abonnements für dieses Ereignis erstellt werden.
Wenn eine Dingvorlage oder Dingform ein Abonnement für ein Ereignis implementiert, können die Dinge, die diese Dingvorlage oder Dingform verwenden, ebenfalls Abonnements für dasselbe Ereignis erstellen, ohne dass beim Auslösen dieser Ereignisse ein Workaround erforderlich ist, um zusätzliche Maßnahmen zu ergreifen.
Verteilte Abonnements
* 
Die Funktion für verteilte Abonnements ist in einer reinen Hochverfügbarkeitsumgebung ab ThingWorx 9.4 und höher verfügbar.
Verteilte Abonnements ermöglichen die Verteilung von Abonnementausführungen auf alle ThingWorx Knoten, wenn ein Ereignis viele Instanzen von Abonnements auslöst. Dies ist beispielsweise der Fall, wenn viele Dinge dasselbe Zeitgeber- oder Scheduler-Ereignis abonnieren. Dies ermöglicht die horizontale Skalierbarkeit der Zeitgeber-/Scheduler-basierten Abonnementausführung über alle ThingWorx Knoten in Hochverfügbarkeitsumgebungen für eine bessere Ressourcenauslastung und Leistung. Über das Kontrollkästchen Verteilt auf der Registerkarte Abonnement wird dieses Verhalten aktiviert. Wenn das Kontrollkästchen Verteilt deaktiviert ist, werden Abonnements für Zeitgeber und Scheduler auf dem Knoten ausgeführt, worauf das Zeitgeber- oder Scheduler-Ereignis generiert wird. Weitere Informationen zur zugehörigen Konfiguration finden Sie hier:
Informationen zur lokalen Umgebung finden Sie unter SSL/TLS für AKKA konfigurieren.
Informationen zur Docker-Umgebung finden Sie unter Akka TLS-Kommunikation für ThingWorx konfigurieren.
War dies hilfreich?