The section after the action is called the postlude. The rule's postlude statement is evaluated after the action has been generated.
The postlude allows for effects. Effects are an important addition to the ECA pattern. Effects differ from actions in that they do not result in directive documents being sent to the endpoint. Instead, they cause side effects on the KRE system. Examples of effects include the following:
- Persistent variables. An effect might cause a permanent change to a persistent variable. Persistent variables allow context to be automatically maintained for an entity or an application across separate invocations of a rule set. See the documentation on persistent variables for more information.
- Control statements. Sometimes, you need affect the normal execution order. For example, the last statement causes the execution of the ruleset to terminate after the current rule.
- Explicit events. Explicit events allow a rule set to raise an event in response to incoming events.
- Scheduled events. Scheduled events are raised and evaluated at a specific time.
- Exception Handling Rules can raise error events that other rules respond to for handling exceptions.
- Explicit Logging An effect might direct the system to log something.
The rule postlude allows action to be taken based on whether or not the rule fired. The most common use is to manage persistent variables. You can also place explicit logging statements in the prelude.
Postludes are evaluated based on the status of the rule: fired, notfired, or always. The fired and notfired constructs take an optional else clause that is executed in the opposite state. Consequently, a postlude takes on of the following forms:
Since the else is optional, you will often see postludes without it:
The following section describe the various statements that a postlude can contain: