Introduction to Tibco BusinessEvents

Business Events

Introduction:
TIBCO BusinessEvents™ allows you to abstract meaningful information from the large amount of data that moves through your distributed enterprise systems and take appropriate action. Users can define business rules on events, systems, services, or a combination of all of these and execute tasks. By detecting complex patterns within the real-time flow of simple events, BusinessEvents can help you to detect and understand unusual activity, recognize trends and advantageous situations, and monitor for specific forms of problematic activity. BusinessEvents delivers this business critical information in real time directly to TIBCO BusinessFactor™, TIBCO PortalBuilder®, or custom dashboards.
BusinessEvents also graphically models your business concepts, scenarios, and rules, allowing you to see both the big picture and the detailed view, predict the needs of your customers, make faster decisions, and take faster action.
Major Components in Business Events:
The above diagram presents the major components of TIBCO BusinessEvents and how they are inter-related.

TIBCO Designer—Designtime Activities
Many TIBCO products use TIBCO Designer as their design-time interface. TIBCO Designer hosts palettes for many different purposes. It also organizes project resources and makes the organization visible in graphical and folder-based ways. At design time, BusinessEvents makes use of some resources available in TIBCO BusinessWorks, such as the XML mapper. (BusinessWorks, licensed for use during BusinessEvents development only, is bundled with BusinessEvents software.)
BusinessEvents Workbench Palette
The BusinessEvents Workbench palette integrates with TIBCO Designer and is used at design time. Design time activities performed using the resources in this palette include building an ontology—a set of concepts, scorecards and events that represent the objects and activities in your business—and building rules that are triggered when instances of ontology objects that fulfill certain criteria arrive in events. The output of the design-time activities is an enterprise archive (EAR) file, ready to deploy (or configure for deployment as needed).
State Modeler
The Enterprise Suite of TIBCO BusinessEvents includes a state machine component. It allows you to model states of ontology concept instances and use those states in rules.
TIBCO Administrator—Deploy and Runtime Activities
TIBCO Administrator provides administrative access to BusinessEvents servers. You can use it to perform deploytime configuration, deploy EAR files, and manage the deployed servers. You can also perform many of these tasks at the command line.
BusinessEvents Server (Engine)—Runtime Activities
At runtime, the BusinessEvents engine processes the incoming events using a Rete network as the inferencing engine, and a set of rules that are triggered by conditions in incoming events.
A BusinessEvents server (more commonly referred to as an engine, because it normally does the work of an engine) can be deployed in different modes, to achieve fault tolerance and object management objectives. For example, a server can be used for cache storage only.

The major Design Concepts of Business Events are
Channels and Destinations
Events
Concepts and Concept Instance
Concept view
Scorecard
Rules and Rule set
Object management
State modeler
Query language for querying cached objects
1. Channels and Destinations:
Channels (except local channel) represent a physical connection to a resource, such as Rendezvous daemon. Destinations in a channel represent listeners to message from that resource, and they can also send messages to the resource. All destinations in a particular channel must use same server.
Channels are three types:
TIBCO Rendezvous channels: Connects TIBCO BusinessEvent to TIBCO Rendezvous sources and sinks.
JMs Channels: connect TIBCO BusinessEvents to TIBCO Enterprise message service provider sources and sinks
Local Channels: Connects multiple rule sessions at runtime.
BusinessEvents uses serializers to convert events to messages and a deserializer to convert from message to event. Serializers and deserializers are provided to RV and JMS (Local channels do require serializers).
Selecting a JMS Serializer:
Message Type
BytesMessageSerializer
TextMessageSerializer
Message
Yes
Yes
ByteMessage
Yes
No
MapMessage
Yes
Yes
TextMessage
No
Yes
StringMessage
Not supported
Not supported
OjectMessage
Not supported
Not supported




Selecting a RV Serializer:
Basic Serializer: The basic serializer, TibRvMsgSerializer serializer, is for efficient handling of events and messages that do not have payloads.
Serializer for event with payload: The TibRvMsgSerializerWithXMLPayload serializer allows you to move XML documents between Rendezvous message _payload_ fields and event payloads.


2. Events:
There are three different types of events are present. They are
Simple event
Time Event
Advisory Event

2.1 Simple Events:
An event type includes three sets of information:
· Configuration, which includes a default destination, time to live(expiration period), and an expiry action.
· A set of Properties
· A Payload(optional)
Inheritance:
You can use inheritance to simplify configuration of events. A child event inherits
· All the parent events properties are inherited to child events.
· The parent event’s expiry action (if set). However, an expiry action set in the child event overrides the parent event expiry action.
· A parent event can’t have payload.
· If two events are related by inheritance, you can’t create a new property in one with a name that is already used in the other.
· If two unrelated events have properties that share a name, you cannot create an inheritance relationship between the two concepts

Time To Live (TTL):
Time To Live options are as follows:
Zero (0): the event expires after the completion of the first RTC cycle. Do not set to 0 if you want to correlate the event with a future event or other future occurrences of this event, as explained below.
One or higher (>0): the event expires after the specified time period has elapsed
A negative integer (<0): name="3360976">For each simple event definition, BusinessEvents allows you to specify the action(s) to take when that simple event expires, using the BusinessEvents rule language. For example, you can write an action that routes the simple event to a different destination, sends a message, or creates a new simple event. This action can be anything that is possible with the rule language. An expiry action can be inherited from the event's parent.
If an event is explicitly consumed in a rule, BusinessEvents does not execute the expiry action.

2.2 Time Event:
There are two types of time events. They are
1. Repeating Time Event: You can configure a time event to repeat at a configurable time interval.
2. Rule Based Time Event: A rule based TimeEvent resource has only a name and description. You finish configuring the event in a rule, using its ontology function. You can configure the event to be asserted after a period of time, and you can pass information to the event and specify it’s time to live.

2.3 Advisory Event:
The BusinessEvents engine automatically asserts an advisory event 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).
You never have to create or configure an event of type AdvisoryEvent. Only one event type is needed. It is called AdvisoryEvent, and it is available for selection from the resource list you see when you add a resource to the declaration of a rule in the rule editor.


3 Concepts:
Concept types are descriptive entities similar to the object-oriented concept of a class. They describe a set of properties. For example, one concept might be Department. The Department concept would include department name, manager, and employee properties.
Concept types are descriptive entities similar to the object-oriented concept of a class. They describe a set of properties. For example, one concept might be Department. The Department concept would include department name, manager, and employee properties.

· When BusinessEvents creates a concept instance, it automatically asserts it. (This is not true of events, which BusinessEvents only asserts if instructed to do so.)
· After BusinessEvents retracts an instance, it cannot re-assert it.


Concept property History: Each concept property includes a history, the size of which is configurable. The history size determines how many previous values BusinessEvents stores for that property.
If you set the history size to 0, BusinessEvents does not store historical values for the concept. It stores the value without a time and date stamp.
History Policy
BusinessEvents can record values using either of these policies:
· Changes Only BusinessEvents records the value of the property every time it changes to a new value
· All Values BusinessEvents records the value of the property every time an action sets the value even if the new value is the same as the old value.

Concept relationships: Concepts can have inheritance, containment and reference relationships with other concepts.
Inheritance Relationships
Definition: One concept inherits all the properties of another concept.
Concepts that are related to each other directly or indirectly by inheritance cannot have distinct properties that share a common name. Therefore, the following restrictions apply:
· If two concepts are related by inheritance, you cannot create a new property in one with a name that is already used in the other.
· If two unrelated concepts have properties that share a name, you cannot create an inheritance relationship between the two concepts.
·

Containment Relationships
Definition: One concept is contained inside another concept.
Note the following containment rules:
· A contained concept can have only one container concept. (Correspondingly, at runtime a contained instance can have only one container instance.)
· One container concept, however, can contain multiple different contained concepts.
· A contained concept can also act as a container concept.


For example, the concept Car contains the concept Wheels. The concept Car also contains other concepts, such as Door and Engine. The concept Car can contain multiple instances of a contained concept (such as Wheel) if the property is defined as an array.
But the contained concepts—Wheels, Doors, and Windows—cannot be contained by any other concept type. They can only be contained by the Car concept.

Runtime Behavior
The following statements apply to container and contained concepts at runtime:
· When BusinessEvents retracts a contained instance, under most circumstances, the value of the container’s property becomes null. The exception is when the property is configured as follows:
· The property allows multiple values. (It is a property array.)
· History is set to 1 or 0.

· Under these conditions, BusinessEvents deletes the entry in the array that corresponds to the retracted concept, reducing the array size by one.
· Under these conditions, BusinessEvents deletes the entry in the array that corresponds to the retracted concept, reducing the array size by one.
· When BusinessEvents replaces one contained instance with another, it retracts the instance that it replaced.
· When BusinessEvents asserts or retracts a container instance, it automatically asserts or retracts the contained instance along with any other contained instances at lower levels of the hierarchy.
· When BusinessEvents modifies a contained instance, it automatically modifies the container instance.



Reference Relationships
A concept reference includes a property that references the ID of another concept.
· When BusinessEvents retracts a concept that is the target of a concept reference, under most circumstances, the value of the concept reference property becomes null. The exception is when the property is configured as follows:
· The property allows multiple values. (It is a property array.)
· History is set to 1 or 0.
· Under these conditions, BusinessEvents deletes the entry in the array that corresponds to the retracted concept, reducing the array size by one.
· At design time, in the rule editor, you can access referenced properties in the rule’s action area, but not in the condition area.






4 Concept view:
You can optionally work with concepts and their relationships using a graphical user interface called a concept view. You create new concepts and create new relationships between the concepts.








5. Scorecard:

Scorecard is special type of concept. A scorecard 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.
Unlike concepts and events, each scorecard resource is itself a single instance — it is not a description for creation of instances. You create the scorecard at design time. Its values can be viewed and updated using rules.
It is more accurate to say there is one instance of a scorecard per rule session. When a BusinessEvents engine runs with multiple rule sessions, each rule session has its own instance of the score card.
It is not necessary to add scorecards to the declaration of a rule, because there is only one instance of each scorecard in a deployed BusinessEvents application. Any change causes all rules that use the scorecard in their conditions to be evaluated.

Rule:
A rule includes a declaration of entity types, and (optionally) one or more conditions, which evaluate to true or false, and one or more actions, which fire when all conditions evaluate to true.
Within the Actions panel, semicolons separate statements; one statement can span multiple lines; one line can include multiple statements. However (unlike conditions) there is only one action. The action might be to execute tasks, create an instance, modify property values in an instance, create and send a simple event, or something else.

Rule Sets
A rule set is a container for rules. All rules exist within a rule set. The main reason to group rules in rule sets is so that you can deploy different rule sets to different BusinessEvents Archives, resulting in different rule sessions at runtime. Your project design determines which rules to put in each rule set.


Rule Priority
BusinessEvents rules are declarative rather than procedural: there is no inherent order for processing. The priority property allows you to specify which rules should fire first.
When a simple event enters BusinessEvents, it triggers BusinessEvents to create an agenda for fireable rules, where the highest priority rule fires first. After firing the highest priority rule, BusinessEvents reevaluates all dependent rules and modifies the rule agenda as needed.

Understanding Rule Functions
A rule function is a function you write in the BusinessEvents rule language for use in a project. To create a rule function, you use a RuleFunction resource.
Rule functions may take arguments and may return a value. The return type can be set to void, indicating that the rule function does not return anything.
You can use rule function in the same way as the standard (provided) functions, custom functions, and ontology functions (which are created automatically from the entity types). You can use rule functions in rule conditions and rule actions.
You can assign rule functions to be used as event preprocessors, and as startup and shutdown actions.
All rule functions created for a project are available project-wide, in any rule session.
Virtual Rule Functions
Virtual rule functions have arguments but no body or return type. The implementation of virtual rule functions is provided by decision tables in Decision Manager.
You can use virtual rule functions in rules in BusinessEvents in the usual way. However, the implementation of the virtual rule function must be provided in an external class that is exported from the Decision Manager Rule management server and placed in a known location. The classes are loaded at system startup, or using JMX while the system is running.


Functions
BusinessEvents offers four types of functions for use in rules. They are
· Standard: These functions are provided with businessEvents.
· Ontology: BusinessEvents generates these functions based on the resources available in the project.
· Custom: we can write our own functions using java and integrate them into businessEvents for use in Rules.
· Rule function: with the help of rule function resources, you can write functions using businessEvents rule language.

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.

Object Management
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.
Part of object management is configuring for fault tolerance so that objects in memory are not lost in the event of a system failure. BusinessEvents supports a variety of object management and fault tolerance options.

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.