Chapter 1 Overview : Design Concepts

Design Concepts
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.
Designing the ontology and the rules well is key to a good CEP (complex event processing) project.
The sections below describe the features mentioned above in greater detail.
Channels and Destinations
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).
See Chapter 2, Working With Channels and Destinations
Events
BusinessEvents processes three kinds of events:
Simple Event  A representation of a single activity (usually a business activity) that occurred at a single point in time.
Time Event  A timer.
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.
Simple Events
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.
See Chapter 3, Working With Simple Events.
Time Events
A time event is an event definition that triggers the creation of event instances based on time.
There are two ways to configure a time event:
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.
See Chapter 4, Working With Time Events.
Advisory Events
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).
See Chapter 5, Working With Advisory Events.
Concepts and Concept Instances
Concepts have these characteristics:
Concepts can describe relationships among themselves. For example, an order concept might have a parent/child relationship with an item concept. A department concept might be related to a purchase_requisition concept based on the shared property, department_id. (See Concept Views)
Concepts can be created by importing table and view data from databases, and you can update the database definitions using RDBMS functions.
See Chapter 6, Working With Concepts and Chapter 7, Working With Database Concepts.
Concept Views
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:
Within a concept view you can create concepts and define relationships between concepts.
See Working With Concept Views.
Score Cards
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.
See Chapter 8, Working With Scorecards.
Rules and Rule Sets
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.
See Chapter 9, Working With Rules and Functions.
Functions
BusinessEvents offers four types of functions for use in 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.
See the following for more information:
Chapter 9, Working With Rules and Functions.
TIBCO BusinessEvents Functions Reference, and TIBCO BusinessEvents Language Reference, which lists the standard functions and explains how to add custom functions.
State Modeler
The State Modeler feature is available only in TIBCO BusinessEvents Enterprise Suite.
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.
See Chapter 10, Working With The State Modeler
Object Management and Fault Tolerance
An important aspect of most BusinessEvents applications is management of the objects created and modified at runtime.
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 and Multi-Engine Mode
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.
To gain an understanding of the options, read Chapter 14, Understanding Object Management and Fault Tolerance. Chapters following explain the topics in more detail.
Query Language for Querying Cached Objects
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.