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.

Introduction To Tibco EMS

JMS supports these messaging models:
Point-to-point(Queues)
Publish and Subscribe(Topics)
Multicast(Topics)

Point-to-Point
Point-to-point messaging has one producer and one consumer per message. This style of messaging uses a queue to store messages until they are received. The message producer sends the message to the queue; the message consumer retrieves messages from the queue and sends acknowledgement that the message was received.
More than one producer can send messages to the same queue, and more than one consumer can retrieve messages from the same queue. The queue can be configured to be exclusive, if desired. If the queue is exclusive, then all queue messages can only be retrieved by the first consumer specified for the queue. Exclusive queues are useful when you want only one application to receive messages for a specific queue. If the queue is not exclusive, any number of receivers can retrieve messages from the queue. Non-exclusive queues are useful for balancing the load of incoming messages across multiple receivers. Regardless of whether the queue is exclusive or not, only one consumer can ever consume each message that is placed on the queue.

Publish and Subscribe
In a publish and subscribe message system, producers address messages to a topic. In this model, the producer is known as a publisher and the consumer is known as a subscriber.
Many publishers can publish to the same topic, and a message from a single publisher can be received by many subscribers. Subscribers subscribe to topics, and all messages published to the topic are received by all subscribers to the topic. This type of message protocol is also known as broadcast messaging because messages are sent over the network and received by all interested subscribers, similar to how radio or television signals are broadcast and received.

Multicast
Multicast messaging allows one message producer to send a message to multiple subscribed consumers simultaneously. As in the publish and subscribe messaging models, the message producer addresses the message to a topic. Instead of delivering a copy of the message to each individual subscriber over TCP, however, the EMS server broadcasts the message over Pragmatic General Multicast (PGM). A daemon running on the machine with the subscribed EMS client receives the multicast message and delivers it to the message consumer.
Multicast is highly scalable because of the reduction in bandwidth used to broadcast messages, and because of reduced EMS server resources used. However, multicast does not guarantee message delivery to all subscribers.




Destinations overview:

1. Static: created by EMS administrator.
2. Dynamic: created by Client programs as needed for short-term use.
3. Tempprary: Temporary destinations are ideal for limited-scope uses, such as reply subjects.

EMS supports messages up to a maximum size of 512MB

JMS messages have a standard structure. This structure includes the following sections:
Header(required)
Properties(optional)
Body(optional)
JMS message types:
Message: This message type has no body. This is useful for simple event notification.
Text Message: A Java.Lang.String
MapMessages: A set of name/value pairs.
Bytes Messages: A stream of uninterrupted bytes. The bytes are not typed; that is, they are not assigned to a primitive data type.
StreamMessages: A stream of primitive values in the Java programming language. Each set of values belongs to a primitive data type, and must be read sequentially.
ObjectMessage: A serializable object constructed in the Java programming language.

Message Delivery Modes
The JMSDeliveryMode message header field defines the delivery mode for the message. JMS supports PERSISTENT and NON_PERSISTENT delivery modes for both topic and queue. EMS extends these delivery modes to include a RELIABLE_DELIVERY mode.

PERSISTENT
when a producer sends a PERSISTENT message, the producer must wait for the server to reply with a confirmation. The message is persisted on disk by the server. This delivery mode ensures delivery of messages to the destination on the server in almost all circumstances. However, the cost is that this delivery mode incurs two-way network traffic for each message or committed transaction of a group of messages

NON_PERSISTENT
Sending a NON_PERSISTENT message omits the overhead of persisting the message on disk to improve performance.
If authorization is disabled on the server, the server does not send a confirmation to the message producer.
If authorization is enabled on the server, the default condition is for the producer to wait for the server to reply with a confirmation in the same manner as when using PERSISTENT mode.
Regardless of whether authorization is enabled or disabled, you can use the npsend_check_mode parameter in the tibemsd.conf file to specify the conditions under which the server is to send confirmation of NON_PERSISTENT messages to the producer.
Figure 6 Non-Persistent Message Delivery

RELIABLE_DELIVERY
When using RELIABLE_DELIVERY mode, the server never sends the producer a receipt confirmation or access denial and the producer does not wait for it. Reliable mode decreases the volume of message traffic, allowing higher message rates, which is useful for messages containing time-dependent data, such as stock price quotations.

Message Selectors
A message selector is a string that lets a client program specify a set of messages, based on the values of message headers and properties. A selector matches a message if, after substituting header and property values from the message into the selector string, the string evaluates to true. Consumers can request that the server deliver only those messages that match a selector.
The syntax of selectors is based on a subset of the SQL92 conditional expression syntax.
Identifiers
Identifiers can refer to the values of message headers and properties, but not to the message body. Identifiers are case-sensitive.
Basic Syntax
An identifier is a sequence of letters and digits, of any length, that begins with a letter. As in Java, the set of letters includes _ (underscore) and $ (dollar).

flowControl
The flowControl property specifies the target maximum size the server can use to store pending messages for the destination. Should the number of messages exceed the maximum, the server will slow down the producers to the rate required by the message consumers. This is useful when message producers send messages much more quickly than message consumers can consume them. Unlike the behavior established by the overflowPolicy property, flowControl never discards messages or generates errors back to producer.
You can set flowControl using the form:
flowControl=size[KBMBGB]
where size is the maximum number of bytes of storage for pending messages of the destination. If you specify the flowControl property without a value, the target maximum is set to 256KB.
You can optionally include a KB, MB or GB after the number to specify kilobytes, megabytes, or gigabytes, respectively. For example:
flowControl=1000KB
Means 1000 kilobytes.
The flow_control parameter in tibemsd.conf file must be set to enabled before the value in this property is enforced by the server. See Flow Control for more information about flow control.

Connection Factory:
A connection factory is either dynamically created by the application or obtained from a data store by means of a naming service, such as a Java Naming and Directory Interface (JNDI) server or a Lightweight Directory Access Protocol (LDAP) server.



Fault Tolerance:

You can arrange TIBCO enterprise message service server fault tolerant operation by configuring pair of servers - one primary and backup. The primary server accepts client connection, and interacts with clients to deliver messages. If primary fails, backup server resumes operation on its place.

Shared State
A pair of fault tolerant servers must have access to shared state, which consists of client connections and persistent messages. This information is useful for backup server to resume its operation of current connections and messages.


Locking:

To prevent the backup server from assuming the role primary server, the shared state is locked by primary server during normal operation. If primary server fails, then lock is released and the backup server can obtain lock.


Configuration Files:

When a primary server fails, its backup server assumes as primary server and resume operations. Before becoming new primary server, the backup server re-reads all it configuration files. If configuration files are shared by two servers then administrative changes carry from old primary server to new primary server.


Detection:

The backup server detects the failure of primary server in either two ways:
1. Heartbeat failure: the primary server sends heartbeat messages to backup server to indicate that it is still operating. When a network failure stops the servers from communicating each other, the backup server detects the interruption in the steady stream of heartbeat.
2. Connection failure: The backup server detects its failure of TCP connection with primary server. When the primary process terminates unexpectedly, the backup server detects the broken connection.

Heartbeat Parameters

When the primary server heartbeat stops, the backup server waits for its activation interval (elapsed time since it detected the most recent heartbeat); then the backup server retrieves information from shared storage and assumes the role of primary server.

The default heartbeat interval is 3 seconds, and the default activation interval is 10 seconds. The activation interval must be at least twice the heartbeat interval. Both intervals are specified in seconds. You can set these intervals in the server configuration files.

Shared State:

The primary server and backup server must share same state. The server state includes three categories of information.
1. Persistent message data
2. Client connection of the primary server
3. Meta data about message delivery

Configuring Fault-Tolerant Servers
To configure an EMS server as a fault-tolerant backup, set these parameters in its main configuration file (or on the server command line):
· Server Set this parameter to the same server name in the configuration files of both the primary server and the backup server.
· ft_active In the configuration file of the primary server, set this parameter to the URL of the backup server. In the configuration file of the backup server, set this parameter to the URL of the primary server




Authorization and Fault-Tolerant Servers
EMS authorization interacts with fault tolerance. If authorization is enabled and the two EMS Servers are configured for fault tolerance, then both servers in a fault-tolerant pair must be configured as follows:
· The tibemsd.conf file for each server must have the same server name and password (the server and password parameters must be the same on each server).
· The user name and password in the users.conf file for each server must match the values of the server and password parameters in the tibemsd.conf file.

If the two EMS servers are not sharing a users.config file, make sure that you create a user with the same name as the EMS server, and set the user’s password with the value of the “Server” password.


Configuring Clients for Fault-Tolerant Connections

When a backup server assumes the role of the primary server during failover, clients attempt to reconnect to the backup server (that is, the new primary). To enable a client to reconnect, you must specify the URLs of both servers when creating a connection. Specify multiple servers as a comma-separated list of URLs. Both URLs must use the same protocol (either tcp or ssl).

The client attempts to connect to each URL in the order listed. If a connection to one URL fails, the client tries the next URL in the list. The client tries the URLs in sequence until all URLs have been tried. If the first failed connection was not the first URL in the list, the attempts wrap to the start of the list (so each URL is tried). If none of the attempts succeed, the connection fails.

For example, to identify the first server as tcp: //server0:7222, and the second server as tcp://server1:7344 (if first server is not available), you can specify:

serverUrl = tcp://server0:7222, tcp://server1:7344

Routes


Tibco Enterprise message service servers can route messages to other servers

1. Topic message can travel from one hop to multiple hops
2. Queue messages travel from one hop to home queue and to one hop from home queue.