In the context of expression rules, triggers are internal or external messages or stimuli that can be evaluated to determine if the Platform should execute the associated actions. When their associated trigger messages are generated, rules run. In this context, "run" means that the If expression (the condition) is evaluated. In other words, a trigger equates to the "event" that causes an expression rule to evaluate its condition.
The trigger you select for a rule determines which functions or actions you should configure in the rule. Not all functions and actions can be used for each trigger type. And not all triggers provide support for configuring actions. For example, the SetAlarmSeverity() action should be defined only for rules configured for Alarm triggers. See the supported functions and supported actions. For a cross-reference list of the triggers and their supported namespaces, and actions, see Using Appropriate Actions and Namespaces with Triggers for Expression Rules.
Trigger messages are generated when assets report data or information, or when another rule runs an action that generates a trigger message, or by the Axeda Platform SDK.
Triggers fall into three categories: asset-related, system-related, and universal. In general, use only asset-related namespaces with the asset-related triggers. You cannot use the system-related User namespace with asset-related triggers.
The asset-related triggers currently supported for expression rules are:
o Alarm - Alarm messages are generated whenever an alarm is created in the Platform. Alarms that have been disabled or suppressed do NOT generate an Alarm message. The Alarm may have been reported by an asset or generated from a rule. When an Alarm message occurs, the Platform evaluates all rules assigned to the Alarm trigger. You can use Alarm namespace symbols to evaluate Alarm expression rules.
o AlarmExtendedDataChange - AlarmExtendedDataChange messages generate whenever the extended data associated with an alarm is changed. Extended data is additional, custom information that may be associated with alarms. Several Alarm namespace symbols are provided for use when evaluating AlarmExtendedDataChange expression rules.
o AlarmSeverityChange - AlarmSeverityChange messages generate whenever the severity of an alarm is changed. This trigger can be used to track alarm severity levels and react (through an Expression rule action) to a change in severity. Several Alarm namespace symbols are provided for use when evaluating AlarmSeverityChange expression rules.
o AlarmStateChange - AlarmStateChange messages generate whenever the state of an alarm is changed by a SetAlarmState action. Several Alarm namespace symbols are provided for use when evaluating AlarmStateChange expression rules.
o AssetTimer - AssetTimer messages generate whenever the schedule for a timer is reached (for example, the timer period defined by the related timer schedule is reached). When an Asset Timer message occurs, the Platform creates separate messages for each device associated with the rules assigned to the AssetTimer trigger. This ensures the Platform applies the message for each device associated with the rules defined for that AssetTimer.
o ConfigurationValidation
- ConfigurationEvent messages generate whenever the actual configuration
for an asset is created or changed or the location for an asset or managing
asset changes, whether through the API/Web services or through an agent
configuration upload. When a ConfigurationEvent message occurs, the server
Platform evaluates all rules assigned to the ConfigurationValidation trigger.
The IF expression can use Configuration functions to lookup configuration
and validate whether the configuration contains the items and values one
expects.
ConfigurationValidation rules run differently, depending on the source
of the configuration change:
§ Agent configuration change - if the rule is evaluated in response to an Agent configuration file upload, then the THEN or ELSE expression will be executed depending on the outcome of the IF evaluation.
§ SDK API operation change - if the rule is evaluated in response to an SDK/API validation request, then the server evaluates the IF expression. If the rule is false, the server generates the specified validation message. (The server evaluates the Validation message expression and converts it to a single message string that can be shown to the end-user when configuration validation fails.) You do not define Then or Else expressions for ConfigurationValidation rules that run based on SDK/API operations.
Note: This trigger is an Axeda ConnectedConfiguration feature. If the Axeda Platform is not licensed for ConnectedConfiguration, you will not have access to this trigger.
o Data - Data messages generate whenever data items change, such as when an asset reports new readings, or a rule modifies a data item. Some functions can only be used with Data triggers; see the list of functions. When a Data message occurs, the Platform evaluates all rules assigned to the Data trigger.
o DefinedConfiguration - ConfigurationStoredEvent
messages generate whenever the configuration
for an asset has been changed, validated, AND persisted. DefinedConfiguration
rules are used to drive functionality specified for matched configurations.
When a ConfigurationStoredEvent message occurs, the Platform evaluates
all rules assigned to the DefinedConfiguration trigger. Several
Configuration namespace symbols are provided for use when evaluating DefinedConfiguration
triggers. (Does not support running actions.)
If you edit a previously created DefinedConfiguration expression rule,
then it takes at least 30 seconds to fetch assets to the Deployment
Wizard - Select Assets page to reflect the modified DefinedConfiguration
rule. Your Platform administrator may modify this time.
Note: This trigger is an Axeda ConnectedConfiguration feature. If the Axeda Platform is not licensed for ConnectedConfiguration, you will not have access to this trigger.
o Event - Event messages generate when an agent sends an event message to the Platform, such as when an asset reports new readings. When an Event message occurs, the Platform evaluates all rules assigned to the Event trigger.
o File - File upload messages are generated when a file upload completes. An expression rule can evaluate various attributes for the File namespace to then take appropriate action on the Platform.
o InactiveAlarm - InactiveAlarm messages generate whenever an alarm becomes inactive. An expression rule can evaluate an alarm and execute associated actions based on whether the alarm is active or inactive. Note that an alarm is sent in with a flag indicating active or inactive. If an alarm is initially sent in as inactive, no data is stored for the alarm and you cannot change its state. If an alarm is sent in as active and subsequently sent in as inactive, then data will have been stored for the alarm and you can change the state of the alarm. See also the Reevaluate() action.
o MobileLocation - MobileLocation messages generate whenever a new location (set of latitude/longitude coordinates) is received for an asset. For example, when a tracking asset reports a new location (latitude, longitude coordinates). When a MobileLocation message occurs, the Platform evaluates all rules assigned to the MobileLocation trigger.
Note: When specifying the Location variable for a rule assigned to a MobileLocation trigger, you can specify an unqualified "location". For all other triggers, you need to qualify this variable as "Location.location".
o Registration - Registration messages generate when an asset contacts the Platform, whether for the first time or after having been offline for a period of time. Use the Registration namespace and its attributes in an expression rule if you want to take action based on this trigger.
o StateChange - StateChange messages generate whenever the state of a named state machine changes. For example, the state machine moves from one state to another. Using the isentry symbol, you can configure rules that run when a state machine is entering or leaving a state (If StateChange.isentry OR If !StateChange.isentry). Typically, expression rules for this trigger type would be used within state machine states. (Note that state machines can be created and managed through Axeda Platform Web Services. Refer to the Axeda® Platform Web Services Developer's Reference Guide for complete information about state machine support.) Several State namespace symbols are provided for use when evaluating StateChange expression rules.
The system-related triggers currently supported for expression rules are:
o SystemTimer - SystemTimer messages generate whenever the schedule for a timer is reached. For example, a SystemTimer message may generate at the beginning of the next hour (for a rule timer schedule of "hourly") or on the first day of each month (for a rule timer schedule of "1st day of each month". Note that this is not the actual syntax for defining timer schedules.) When a Timer message occurs, the Platform evaluates all rules assigned to the SystemTimer trigger.
Note: Expression rules associated with System Timer, UserLogin, and UserLogout messages (triggers) cannot contain actions that require information regarding an asset. Actions supported with these Platform triggers are PublishObject, EnableRule, and DisableRule.
o UserLogin and UserLogout - These messages generate whenever a user logs in to or logs out of the Axeda Applications. The attributes of the User namespace allow you to take action based on their values.