Les abonnements sont des services qui reçoivent des événements et y répondent. Un abonnement contient une source, généralement un objet. Un objet peut disposer d'un abonnement à un événement qui répond par une action. Par exemple, si une entité déclenche un événement Surchauffe moteur, elle peut s'abonner à cet événement en déclenchant un abonnement Eteindre le moteur. Les objets peuvent hériter des abonnements des modèles d'objet et des formes d'objet qu'ils utilisent.

Un abonnement est similaire à un service standard. Il est cependant lié de façon explicite à un événement. Cela vous permet de découpler l'événement du code qui y répond. A l'instar d'un service, vous pouvez implémenter une logique métier personnalisée pour répondre à l'événement. Il est possible d'exploiter les caractéristiques du modèle, par exemple en envoyant des e-mails par l'intermédiaire d'un objet serveur de messagerie, en accédant en écriture à une base de données ou en appelant un service disponible sur la plateforme. A la différence d'un service, un abonnement ne renvoie pas une valeur explicite. Il peut cependant appeler un autre service du modèle auquel le contexte de sécurité du thread a accès. Le contexte de sécurité de thread d'un abonnement est défini sur le même contexte de sécurité de thread que celui de l'événement qui a été déclenché. Vous pouvez utiliser le même environnement d'édition JavaScript utilisé pour implémenter des services.

Les abonnements ont une entrée définie, qui est le paquet de données émis par l'événement et appelé données d'événement. Si l'entité s'abonne à un événement défini, les données de cet événement sont transmises à la fonction d'abonnement et décrites par la forme de données de l'événement. Dans l'implémentation de l'abonnement, les données transmises par l'événement agissent en tant qu'entrée pour la fonction de script. Par exemple, si une entité est abonnée à un événement de modification de données d'une propriété d'un objet, la fonction de script d'abonnement est appelée. La valeur de la propriété d'objet, ainsi que d'autres données pertinentes de l'événement, sont alors transmises à la fonction en tant que données d'événement.

De nombreuses entités peuvent s'abonner au même événement. La fonction d'abonnement de chaque entité est appelée et les données d'événement lui sont transmises. Une entité peut appliquer toute action définie dans le script d'abonnement afin de répondre aux exigences de la solution.

Les principaux avantages de cette technique par rapport à l'utilisation d'un service appelé à partir d'un autre service sont notamment les suivants :

Les abonnements possèdent un nom défini par l'utilisateur qui constitue leur identificateur unique. Les entités peuvent disposer de plusieurs abonnements à un événement sur un objet. Par exemple, si une entité déclenche un événement Surchauffe moteur, il peut s'abonner à cet événement avec un abonnement Eteindre le moteur et un abonnement Créer un bon de travail pour que le moteur soit vérifié par un technicien de maintenance. Vous pouvez également créer autant d'abonnements que vous le souhaitez pour cet événement.

Si un modèle d'objet ou une forme d'objet implémente un abonnement à un événement, les objets utilisant ce modèle d'objet ou cette forme d'objet peuvent également créer des abonnements au même événement, sans avoir à trouver des solutions de contournement pour déclencher des actions supplémentaires lorsque ces événements sont déclenchés.

Cette fonctionnalité permet de distribuer l'exécution des abonnements sur tous les noeuds ThingWorx disponibles lorsqu'un événement déclenche de nombreuses instances d'abonnements ; par exemple, lorsque de nombreux objets s'abonnent à un même timer ou planificateur. Elle assure une adaptation horizontale de la capacité d'exécution des abonnements aux timers/planificateurs en mobilisant les différents noeuds ThingWorx de l'environnement haute disponibilité pour optimiser l'utilisation des ressources et les performances. La case à cocher Distribué dans l'onglet Abonnement permet d'activer ce comportement. Lorsque la case Distribué n'est pas cochée, les abonnements aux timers et planificateurs sont exécutés sur le seul noeud où l'événement timer ou planificateur est généré. Pour plus d'informations sur la configuration associée, consultez les rubriques suivantes :