Best Practices for Developing Solutions > Modeling your Assets > Working with Events, Alerts, and Subscriptions
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 solution. This results in data flow in the solution.
As of ThingWorx 9.4 and later, in an HA environment, use the Distributed Subscriptions capability when subscriptions are heavily executed. For example, when many Things subscribe to the same timer or scheduler event. For more information, see Thing Subscriptions.
While developing your solution, you could execute an automatic backup through the scheduler subscription.
While testing services that are defined in subscriptions, check the solution logs to verify that the subscription is running as expected.
For information about best practices on creating services for subscriptions, see Services.
Was this helpful?