Event Types

Available Events

  • Data:
    • ItemCreated
    • ItemUpdated
    • ItemDeleted
    • CollectionCreated
    • CollectionUpdated
    • CollectionDeleted
  • User:
    • UserCreated
    • UserUpdated
    • UserDeleted
  • Device:
    • DeviceCreated
    • DeviceUpdated
    • DeviceDeleted
  • Messsaging:
    • Publish
    • Subscribe
    • Unsubscribe

Attributes

When you define a trigger, you provide the following information:

  1. The event (described above)
  2. The code service to be executed
  3. Filters for the trigger

The process for firing triggers is very simple. When an event occurs in the system, the system passes the event information to the trigger processor. The trigger processor searches for triggers that match that event. When it finds such a trigger, its code service is invoked (in the background). The system uses trigger filters to perform the match. We will now discuss this important matching process

Filters and Trigger Matching

Each event specifies a set of filters that, when the event occurs, are passed to the matching system for processing. These are then compared to each user-defined trigger for that event. Details of how this match occurs is given below.

An event payload is also passed to the system. The payload contains other relevant information about the event. The paylood is passed as a proporty (or properties) to the code service for the trigger. For example, for the Data:ItemCreated event, there is a property “items” passed to the code service for the trigger.

The filters and payload passed for each event are as follows:

  • Data:ItemCreated
    • Filters: collectionId, collectionName
    • Payload: items:[itemId, …]
  • Data:ItemUpdated
    • Filters: collectionId, collectionName
    • Payload: query:the query used for the update operation
  • Data:ItemDeleted
    • Filters: collectionId, collectionName
    • Payload: query: the query used for the update operation
  • Data:CollectionCreated
    • Filters: none
    • Payload: collectionId
  • Data:CollectionUpdated
    • Filters: collectionId, collectionName
    • Payload: changes: {changeKey:changeVal, …}
  • Data:CollectionDeleted
    • Filters: collectionId, collectionName
    • Payload: collectionId
  • User:UserCreated
    • Filters: none
    • Payload: userId
  • User:UserUpdated
    • Filters: userId
    • Payload: changes: {changeKey:changeVal, …}
  • User:UserDeleted
    • Filters: userId
    • Payload: userId
  • Device:DeviceCreated
    • Filters: none
    • Payload: deviceName, device:{key: val, …}
  • Device:DeviceUpdated
    • Filters: deviceName
    • Payload: deviceName, changes:{key: val, …}
  • Device:DeviceDeleted
    • Filters: deviceName
    • Payload: deviceName
  • Messaging:Publish
    • Filters: topic
    • Payload: topic, body
  • Messaging:Subscribe
    • Filters: topic
    • Payload: userId, topic
  • Messaging:Unsubscribe
    • Filters: topic
    • Payload: userId, topic

How the filtering process works can best described using a couple of examples. First let’s look at Data:ItemCreated. When creating your trigger, you can optionally specify a collection id or a collectionName to apply to that trigger. This means that your trigger will only fire when an item is created in that collection. If you do not specify a collectionId or collectionName, your trigger will be executed whenever any item is created in your system, regardless of collection.

The situation is a bit different when creating triggers for the messaging subsystem. Here, the system takes into account MQTT’s wildcard capability. When creating triggers for Publish, Subscribe, and Unsubscribe, you can pass in the topic filter as a topic commands (ie, it can contain the ‘#’ and ‘+’ path elements). See the MQTT documentation for a description of wildcards. Of course, if you don’t use wildcards, the match must be exact. If, for any of events (Publish, Subscribe, and Unsubscribe), you do not provide a topic, all such events will match and fire your trigger.