Working with Events, Alerts, and Subscriptions
Events are used to indicate a change in condition in the ThingWorx platform. They can be triggered by a condition being met, by calling a service, or by making a REST call. ThingWorx has several standard types of events that are triggered based on certain conditions, for example when the value of a property changes (DataChange) or when a Thing is started (ThingStart).
An alert is a standard type of event that is based on a property's state. It is automatically triggered when the property value meets a particular condition that has been defined by a user.
A subscription is required to do something when an event, including alerts, is triggered. A subscription is a special service that is executed when the event it subscribes to is triggered.
Events require a predefined data shape. The data shape stores data associated with the event, which can be accessed by a subscription. You can add subscriptions to an entity in an extension to perform custom behavior when an event is fired.
Best Practices for Creating Events, Alerts, and Subscriptions
Use the following best practices while creating events, alerts, and subscriptions:
• Define naming conventions for your events, alerts, and subscriptions. Keep the following points in mind:
◦ Use a standard nomenclature across entities. For example: You can use a unique namespace prefix across different entity types to avoid conflicts.
◦ Provide meaningful names to the entities.
◦ Try to include a good description for every entity that you create.
◦ Avoid ambiguous names.
◦ Avoid long entity names wherever possible.
See the section Naming Entities for more information.
• Define all events and subscriptions at a Thing Shape level.
 |
It is recommended that you use Thing Shapes to define properties and services. If you define properties and services on a Thing Template, it is difficult to move their definitions to a Thing Shape.
|
• Define alerts individually for every property of the Thing, Thing Template, or Thing Shape.
• Ensure that events and alerts have a subscription tied to it. This ensures that whenever an event or alert is triggered, functionality is executed in the application. This results in data flow in the application.
• While developing your application, you could execute an automatic backup through the scheduler subscription.
• While testing services that are defined in subscriptions, check the application logs to verify that the subscription is running as expected.
For information about best practices on creating services for subscriptions, see Services.