Rule Model
From RuleCore Support
The ruleCore CEP Server uses an approach based on active rules.
- Each rule is basically an active event processing entity reacting to specific combinations of inbound events over time. When a specific combination of events is found, an outbound reaction event is published with a summary of those events.
The combinations of events are specified using a concept of situations. A situation is a formal description of a combination of events as they happen over time along with optional timing restrictions.
- For example, in a retail store the situation Theft in Progress could be defined as an item with an RFID tag being picked up from the shelf and then moving past the checkout without being payed for.
In the example above the situation consists of a sequence which starts with a particular event, the item picked up from the shelf. Then it continues with two possible outcomes which are interesting to track. The situation is also defined per item, we track a sequence of events for a particular item. These two characteristics are typical for many rules and their situations.
When a rule triggers, its output is also an event generated by the action part of the rule. In the example above, a Theft Detected event could be created when the rule triggers in response to the detected situation. These events can used as input to other rules, creating a hierarchy or graph of rules.
The reactive and event-driven rules of ruleCore are designed to be used as a high-level component in an event driven SOA/EDA environment or any other event enabled platform where loosely coupled systems communicate using messages/events. The rules are natively event-driven and the ruleCore CEP Server is completely event-driven for a perfect fit into any event based enterprise architecture.
Contents |
Key Features
- Declarative - Rules are specified using a high-level declarative approach.
- Modular - Rules are defined using modular and re-usable building blocks.
- Automatic rule evaluation - Rules are evaluated automatically in response to inbound events. Advanced logic is used to determine which rules need to be evaluated in response to an inbound event.
- Rule life cycle management - Rule instances are created and deleted automatically in response to events. Rule instances are analyzed and deleted if their situation is determined to be undetectable.
- Powerful View Management - Each rule instance maintains its own view into the incoming event stream. The view provides a window into the incoming event stream in order to create a dynamic context for rule evaluation.
- Automatic event dispatching - Events are automatically delivered to the rule instances which need them. No special configuration is needed to feed the proper rule instances with events needed for their proper evaluation. The event stream views are also automatically managed and updated as needed in response to inbound events or to meet timing restrictions.
Basic Operation
Rules instances are created, evaluated and deleted in response to events entering the RuleCore Server.
A rule instance is created in response to special initiator events. The initiator events are normal user events with the special property that they can possibly be the first event in the detection of a situation.
The basic operation of rule evaluation consists conceptually of a number of steps:
- An inbound event arrives from an through an event transport protocol, JMS for example, to the Event I/O module. The inbound event could originate directly from a business application or delivered indirectly using an event bus (ESB).
- If the inbound event is authorized, it is re-sequenced in order to create one unified and ordered event stream for the rules in the engine to operate upon.
- Rule definitions are consulted to find out if new rule instances should be created of each particular rule type.
- Update the event stream views of each rule instance.
- Evaluate the situation for each rule instance in the context of the view.
- If the situation is detected, execute the rule's 'detected' action
- If the situation is determined to be undetectable, execute the rule's 'undetectable' action
All these steps are fully automatic, the only thing you as an user need to do is to send business events into the ruleCore CEP Server and it will automatically manage all steps needed to evaluate the rules and produce reaction events and send them back to you.
Structure of a Rule
The three major elements of a rule are:
- A view containing a semantically related selection of events.
- A situation to detect.
- An action part:
- An action to take when the situation is detected.
- An optional action to execute if the situation is determined to be undetectable.
Event Stream View
The view is updated from the stream of inbound events. Each rule instance has its own private view. The view definition contains a number of properties that must hold, at all times, for all events in order for them to be included in the view.
- The type view property is used to accept events of only certain types into the view.
- The age view property defines the maximum age for each event in the view. You could for example use the age property to let each rule instance see only events from the past 10 minutes.
- The count property defines the maximum number of events in the view. You could for example use this property to limit the view to contain only the last 100 received events.
- The chained property maintains a dynamically created logical chain of events. Events are accepted into the view only if they are members of the chain.
- The match property defines values in the event body of different events which all must match in order for them to be included in the same view.
- The assert property defines an XPath expression that must evaluate to true for all instances of a specified event type. The assert property could for example be used to compare a certain element in the event body with a constant.
Situation
A situation describes an interesting combination of multiple events as they occur over time.
A situation starts developing when a specific initiator event occurs. This is the first event in a sequence of events which could possibly lead to a fully developed situation consisting of multiple events. The situation develops over time and can either be detected at some point or automatically determined to be undetectable.
The progress of a situation as it develops can be followed by querying the ruleCore CEP Server about the state of a particular rule's situation. The degree of completion of a situation can be monitored to provide an early warning about a situation which might be detected soon.
Action
Actions are executed as the last part of a rule's evaluation in response to a detected situation, or optionally when it is determined that a partially detected situation can't be detected at any point in the future.
An action is used to create a new event. The new event is called the reaction event and is used to notify external systems about a detected situation. Different events can be created for a detected situation and for undetectable situations.
Lifecycle Management
Rule instances are automatically created by the ruleCore CEP Server based on user supplied rule definitions. Thus, a rule definition must be created by sending an AddRuleDef system event into ruleCore before any rule instances can be created.
A rule definition is initially offline when it is created. In order for any rule instances to be created from a definition it must be turned online with the RuleModeChange system event. When a rule is turned offline after being online, all rule instances of the rule are disabled and deleted.
Rule definitions can be removed by sending the DeleteRuleDef system event into ruleCore. A rule definition must be turned offline before it can be deleted.
A rule instance is automatically deleted after the rule has triggered. A rule can trigger either when a situation is detected or when internal logic determines that it is not possible to detect the situation in the future.