| = Inferred expiration offset |
| |
| |
| Another way for the engine to calculate the expiration offset for a given event is implicitly, by analyzing the temporal constraints in the rules. |
| For instance, given the following rule: |
| |
| .example rule with temporal constraints |
| ==== |
| [source] |
| ---- |
| rule "correlate orders" |
| when |
| $bo : BuyOrderEvent( $id : id ) |
| $ae : AckEvent( id == $id, this after[0,10s] $bo ) |
| then |
| // do something |
| end |
| ---- |
| ==== |
| |
| |
| Analyzing the above rule, the engine automatically calculates that whenever a BuyOrderEvent matches, it needs to store it for up to 10 seconds to wait for matching AckEvent's. |
| So, the implicit expiration offset for BuyOrderEvent will be 10 seconds. |
| AckEvent, on the other hand, can only match existing BuyOrderEvent's, and so its expiration offset will be zero seconds. |
| |
| The engine will make this analysis for the whole rulebase and find the offset for every event type. |
| |
| |
| |
| [IMPORTANT] |
| ==== |
| An explicit expiration policy for a given event type overrides any inferred expiration offset for that same type. |
| ==== |
