Event Processing Rules
Event Processing Rules is a global server configuration property that defines:
what events will be suppressed before any processing, routing and storage;
how the system finds event duplicates and aggregates them to reduce total number of events;
how long persistent events will be stored in event history.
The format of the Event Processing Rules table:
Context Mask | Every record in the table defines processing rules for an event in every context matching this mask. For example, if we specify Expiration Period of 1 month for the "login" event (in the Event column) and set the Context Mask to " If the mask is not specified (i.e. NULL), the rule is applied to events in all contexts. | |
Event | Name of the event whose processing rules are defined by this record. | |
Pre-filter | Expression used to suppress events that do not match certain criteria. Suppressed events won't be stored in database, delivered to listeners, and processed by any system module. If pre-filter expression is defined, events will be suppressed if it returns FALSE. | |
Pre-filter Expression Resolution Environment: | ||
|---|---|---|
Context of event. | ||
Data Table containing event-specific data. | ||
0 | ||
Standard variables only. | ||
Deduplication ID Expression | Expression used to calculate deduplication IDs of events. The expression will be evaluated into a String. If the RAM-based events queue (whose size is defined by Number of Events to Store in RAM parameter) contains an event with the same deduplication ID, the current event will be treated as a duplicate of this event:
| |
Deduplication ID Expression Resolution Environment: | ||
Context of event. | ||
Data Table containing event-specific data. | ||
0 | ||
Standard variables only. | ||
Number of Events to Store in RAM | Number of events to keep in memory and use for finding duplicates according to Deduplication ID Expression. | |
Duplicate Dispatching | Defines whether an event those duplicates were found in memory should be further routed and delivered to subscribers (listeners). | |
Expiration Period | Duration of persistent storage. Default duration is 100 days, after which events are permanently deleted from the history records. You can customize the duration of storage ("time-to-live") for different events. Note that in practice events may be available in event history a little bit longer than specified by this setting, because the cleanup process (removing expired events) runs every several minutes. Zero expiration period value disables persistent storage of events pointed by the rule. | |
Enrichments | A table defining what enrichments are added to events pointed by the rule. This table has two columns:
Once a newly created event instance matches this rule, each value expression is evaluated to a string. A new enrichment with name taken from this table and value equal to the Expression result is added to the event instance. Event enrichment occurs before the event is saved in the event history database. | |
Enrichment Expression Resolution Environment: | ||
Context of event. | ||
Data Table containing event-specific data. | ||
0 | ||
Standard variables only. | ||
When an event occurs, Iotellect Server processes the Event Processing Rules table from the first to the last record. If the context in which an event has occurred matches the mask defined by a record, the server uses parameters defined in this record to store the event and stops going over the list, i.e the first match applies, even if masks in later lines also match the context. Thus, rules with narrower context masks should generally precede rules with wider masks.
If this context doesn't match any mask defined in the table, default parameters defined in the event definition will be used to store and process the event.
 | Example: assuming we have the following table of event processing rules: |
| Example: let's say we have the following event processing rule: |
Was this page helpful?