In a rule engine, the things that the project works with such as employees, inventory, parts, and so on are
concepts in the
ontology (knowledge model) of the project.
Events such as flight take-off, purchase of a mortgage, sale of stock, and so on are also part of the ontology, as are scorecards, which hold metrics. Rules are triggered by events and by changes in objects. For example, rules might cause a flight to be delayed if there is a certain problem at the airport.
JMS and Rendezvous channels represent physical connections to a resource, such as a Rendezvous daemon. Destinations in a channel represent listeners to messages from that resource, and they can also send messages to the resource. Arriving messages are transformed into simple events, and simple events sent out of BusinessEvents are transformed to the appropriate type of message (JMS or Rendezvous).
TIBCO BusinessEvents also includes Local channels, which allow you to pass events between two
rule sessions in the same project (Not required with multi-engine functionality).
●
|
Simple Event A representation of a single activity (usually a business activity) that occurred at a single point in time.
|
●
|
Advisory Event A notice generated by BusinessEvents to report an activity in the engine, for example, an exception.
|
BusinessEvents creates instances of simple events and time events based on user-configured event definitions. The following sections provide more detail on each type of event.
A simple event definition is a set of properties related to a given activity. It includes information for evaluation by rules, meta-data that provides context, and a separate payload -- a set of data relevant to the activity. For example, say you are interested in monitoring the creation of new employee records; you might create a simple event definition that includes important fields from the employee record, perhaps the social security number, department, and salary. You could then write a rule to create an instance of this simple event each time a new employee record is created.
A simple event is an instance of a simple event definition. It is a record of a single activity that occurred at a single point in time.
Just as one cannot change the fact that a given activity occurred, when an event is asserted, those values are used by working memory and any changes made after that time are ignored. (Before assertion you can use an event preprocessor to enrich the event, however.) Simple events expire when their time to live has elapsed, unless BusinessEvents has instructions to consume them prior to that time.
Example 1: A temperature sensor records a reading that is above a predefined limit. The payload might include the temperature-sensor ID, the reading, and the date and time. This simple event might trigger a complex event that would immediately notify a manager.
Example 2: A customer purchases four airline tickets from San Francisco, California to San Jose, Costa Rica. The payload might include the date and time of purchase, the date and time of the flight, the purchase price, the credit card number, the flight number, the names of the four passengers, and the seat assignments. This simple event alone may include no exceptions. However, it is possible that when examined within the context of other related events, an exception may arise. For example, one or more of the passengers may have booked tickets on another flight during the same time period.
●
|
Rule based A rule schedules the creation of a time-event instance at a given time.
|
●
|
Time-interval based (Repeat Every) BusinessEvents creates a time-event instance at regular intervals.
|
The BusinessEvents engine automatically asserts advisory events when it catches an exception that originates in user code but that is not caught with the
catch command of the BusinessEvents Exception type (available in the rule language).
Concepts have these characteristics:
A concept view is a visualization tool, providing an easy way to work with a group of concepts and their relationships. Here is an example of a concept view:
A score card serves as a static variable that is available throughout the project. You can use a ScoreCard resource to track key performance indicators or any other information. Use rules to view its value, use its value, or change its value. Note that unlike concepts and event definitions, which describe types of instances, each scorecard is both the description and the instance.
Rules define what constitutes unusual, suspicious, problematic, or advantageous activity within your enterprise applications. Rules also determine what BusinessEvents does when it discovers these types of activities. You can execute actions based on certain conditions on simple events, concept instances, time events, score cards, or a combination of these objects.
All rules exist inside of rule sets. Rule sets are groups of rules. At deployment time, you can select rule sets to use at runtime; you cannot select individual rules.
●
|
Standard — These functions are provided with BusinessEvents.
|
●
|
Ontology — BusinessEvents generates these functions based on the resources in your project.
|
●
|
Custom — You can write custom functions using Java and integrate them into BusinessEvents for use in rules.
|
●
|
Rule Function — In addition to Java-based custom functions, you can use rule function resources to write functions using the BusinessEvents rule language.
|
Standard functions include a set of temporal functions, which allow you to perform calculations based on a sampling of a property’s values over time. These functions make use of the history for that property. For more information, see
Temporal Functions.
TIBCO BusinessEvents Functions Reference, and
TIBCO BusinessEvents Language Reference, which lists the standard functions and explains how to add custom functions.
State Modeler is a UML-compliant application that allows you to model the life cycle of a concept instance — that is, for each instance of a given concept, you can define which states the instance will pass through and how it will transition from state to state.
States have entry actions, exit actions, and conditions, providing precise control over the behavior of BusinessEvents. Transitions between states also may have rules. Multiple types of states and transitions maximize the versatility and power of State Modeler.
Different projects have different object management requirements. For some, it is acceptable to destroy the objects once the rule engine cycle that needs them has completed. They require only memory-based object management. For others, the instances have value beyond the rule engine cycle and need to be persisted.
Related to object management is configuration of fault tolerance features. BusinessEvents supports a variety of object management and fault tolerance options.
Cache object management enables BusinessEvents to run in multi-engine mode. In this mode, load balancing ruleset chaining features are available at the agent level. This configuration provides a flexible way to load balance rule sets across multiple engines. It simplifies scalability, enabling you to run multiple inference agents on multiple nodes within the same cluster configuration.
Available in TIBCO BusinessEvents Enterprise Suite only, the query features enable you to perform snapshot queries and continuous queries using an SQL-like query language. You can then send query results to outbound destinations or use them in rules as desired. Details are provided in
TIBCO BusinessEvents Language Reference.