Tibco App Guide

8/10/2019 Tibco App Guide

1/101

TIBCO BusinessEvents

Extreme

Application Architects GuideSoftware Release 1.0.0

May 2012

The Power to Predict


2/101

Important Information

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDEDOR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITEDADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLEDSOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FORANY OTHER PURPOSE.

USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF ALICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSEAGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USERLICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THESOFTWARE (AND WHICH IS DUPLICATED IN THE LICENSE FILE) OR IF THERE IS NO SUCH SOFTWARELICENSE AGREEMENT OR CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATEDIN THE LICENSE FILE(S) OF THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMSAND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND ANAGREEMENT TO BE BOUND BY THE SAME.

This document contains confidential information that is subject to U.S. and international copyright laws andtreaties. No part of this document may be reproduced in any form without the written authorization of TIBCOSoftware Inc.

TIBCO, The Power of Now, TIBCO ActiveMatrix, TIBCO ActiveMatrix BusinessWorks, TIBCO Administrator,TIBCO ActiveSpaces, TIBCO Designer, TIBCO Enterprise Message Service, TIBCO Hawk, TIBCO RuntimeAgent, TIBCO Rendezvous, are either registered trademarks or trademarks of TIBCO Software Inc. in the United

States and/or other countries.EJB, Java EE, J2EE, and all Java-based trademarks and logos are trademarks or registered trademarks of SunMicrosystems, Inc. in the U.S. and other countries.

All other product and company names and marks mentioned in this document are the property of theirrespective owners and are mentioned for identification purposes only.

THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALLOPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAMETIME. SEE THE README.TXT FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON ASPECIFIC OPERATING SYSTEM PLATFORM.

THIS DOCUMENT IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS ORIMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS.CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BEINCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKEIMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED INTHIS DOCUMENT AT ANY TIME.

THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY ORINDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING

BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES.Copyright 2012 TIBCO Software Inc. ALL RIGHTS RESERVED.

TIBCO Software Inc. Confidential Information


3/101

TIBCO BusinessEvents Extreme Application Architects Guide

| iii

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiRelated Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

TIBCO BusinessEvents Extreme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Other TIBCO Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Connecting with TIBCO Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

This section provides links to helpful TIBCO resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

How to Join TIBCOmmunity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiiHow to Access TIBCO Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

How to Contact TIBCO Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Chapter 1 Introduction to TIBCO BusinessEvents Extreme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Whats Different About Complex Event Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Technical Requirements of a CEP System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

A Model-Driven Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Stateful Rule Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Main Product Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

TIBCO BusinessEvents Extreme Design-time Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

TIBCO BusinessEvents Extreme Administration Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Designtime Resource Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Channels and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Score Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Object Management and Fault Tolerance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Deploy-time and Runtime Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Application Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 2 Channels and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Channels and Events Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16


4/101


iv | Contents

Event Preprocessors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Preprocessor Use Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Types of Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Default Destinations and Default Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Message Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Types of Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Simple Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Time Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Advisory Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Simple Events Time to Live and Expiry Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Event Expiration and Expiry Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Chapter 3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Overview of Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Concept Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Inheritance Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Containment Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Reference Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Rules Governing Containment and Reference Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

When a Contained or Referred Concept Instance is Deleted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Loading Concepts into the Rete Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Query Catalog Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Contained and Referenced Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Use of Concepts in the Preprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Loaded Objects Are Not New and Do Not Trigger Rules to Fire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 4 Rules and Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Inferencing Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Rule Priority and Rank. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Organizing and Deploying Inferencing Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Rule Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Startup and Shutdown Rule Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

When Startup Rule Functions Execute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Chapter 5 Run-time Inferencing Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Runtime Architecture and Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Rule Evaluation and Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Understanding Conflict Resolution and Run to Completion Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Run to Completion Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48


5/101


Contents |v

Conflict Resolution Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

How the Rete Network is Built . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Testing the Truth of a Rules Conditions Using the Dependency Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

How a Rule Becomes Newly True . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Order of Evaluation of Rule Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Chapter 6 Concurrency and Project Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Designing for ConcurrencyTransactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Multi-JVM Rules Engine Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Concepts Are Shared Across Agents Transactionally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Scorecards are Local to the Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Events are Owned by the Rules Engine that Receives Them . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Multi-Agent Example Showing Event Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Transactional Isolation and Locking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Locking Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Deadlock Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Chapter 7 Threading Models and Tuning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Threading Models Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Scaling Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Event Preprocessor and Rete Worker Thread Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Shared Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Destination Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Callers Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Concurrent RTC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Concurrent RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81


6/101


vi | Contents


7/101


Figures |vii

Figures

Figure 1 Channels and Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 2 TIBCO BusinessEvents Runtime Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

Figure 3 Run to Completion Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Figure 4 Threading Models Quick Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64


8/101


viii | Figures


9/101


Tables | ix

Tables

Table 1 General Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Table 2 Syntax Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Table 3 Containment and Reference Concept Relationship Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34


10/101


x | Tables


11/101

TIBCO BusinessEvents Extreme Appllication Architects Guide

|xi

Preface

TIBCO BusinessEvents Extreme is a high-performance event processingplatform for applications that monitor, analyze, and respond to parallel eventstreams in and across the enterprise, making decisions, taking action, and runningservices in real-time. TIBCO BusinessEvents Extreme delivers dramatic newlevels of performance, scalability, and robustness for demanding Complex Event

Processing (CEP) and real-time event-driven applications.The platform automatically manages consistency for efficient parallel processingand high vertical scalability, while freeing applications from the complexity ofconcurrent and distributed programming. A hybrid Rules and Java programmingmodel enables applications to maximize the capabilities of both languages,seamlessly share data and events, and integrate to existing Java assets.

Topics

Related Documentation, page xii

Related Documentation, page xii

Typographical Conventions, page xv

Connecting with TIBCO Resources, page xviii


12/101


xii | Related Documentation

Related Documentation

This section lists documentation resources you may find useful.

TIBCO BusinessEvents Extreme

The following diagram shows the main documents in the TIBCO BusinessEventsExtreme documentation set.

TIBCO BusinessEvents Extreme Documentation

TIBCO BusinessEvents Studio, the design-time UI, is supported on Windows andLinux. The documentation set for TIBCO BusinessEvents Extreme is as follows.

TIBCO BusinessEvents

Extreme

Getting Started

TIBCO

BusinessEvents

Extreme

Application

Architects Guide

TIBCO

BusinessEvents

Extreme

Application

Developers

Guide

Java API

Reference

Legend PDF HTML

TIBCO

BusinessEventsExtreme Java

API Reference

TIBCO

BusinessEvents

Extreme

Installation

TIBCO

BusinessEventsExtreme Java

Developers

Guide

TIBCO

BusinessEvents

Extreme Sizing

Guide

TIBCO

BusinessEvents

Extreme Tuning

Guide

TIBCO

BusinessEventsExtreme

Administration


13/101


Preface |xiii

TIBCO BusinessEvents Extreme Installation: Read this manual for instructionson site preparation and installation, and project migration.

TIBCO BusinessEvents Extreme Getting Started: After the product is installed,

use this manual to learn the basics of TIBCO BusinessEvents Extreme: projectdesign and deployment. This guide explains the main ideas so you gainunderstanding as well as practical knowledge.

TIBCO BusinessEvents Extreme Application Architects Guide: Read this guide foroverview and detailed technical information to guide your work.

TIBCO BusinessEvents Extreme Application Developers Guide: Use this guidewhen you implement a project design in TIBCO BusinessEvents Studio. It

covers topics such as project-level tasks, resource-level tasks, and debugging,

TIBCO BusinessEvents Extreme Java Developers Guide: Use this guide toprogram TIBCO BusinessEvents Extreme in Java.

TIBCO BusinessEvents Extreme Administration: This book explains how toconfigure, deploy, monitor, and manage a TIBCO BusinessEvents Extremeapplication and the data it generates using the TIBCO BusinessEventsExtreme Administrator utility and other utilities provided with the product.

TIBCO BusinessEvents Extreme Sizing Guide: Read this guide for information onhow to size systems for deploying TIBCO BusinessEvents Extremeapplications.

TIBCO BusinessEvents Extreme Tuning Guide: Read this guide for informationabout tuning your TIBCO BusinessEvents Extreme installation.

Online References:

TIBCO BusinessEvents Extreme Java API Reference: This online referenceprovides the Javadoc-based documentation for the TIBCO BusinessEventsExtreme API.

TIBCO BusinessEvents Extreme Release Notes: Read the release notes for a list ofnew and changed features. This document also contains lists of known issuesand closed issues for this release.

Reference documentation for functions is available in the HTML documentationinterface for the TIBCO BusinessEvents Extreme documentation set.


14/101


xiv | Related Documentation

Other TIBCO Product Documentation

You may find it useful to refer to the documentation for the following TIBCOproducts:

TIBCO ActiveSpaces

TIBCO Rendezvous

TIBCO Enterprise Message Service

P f |


15/101


Preface |xv

Typographical Conventions

The following typographical conventions are used in this manual.

Table 1 General Typographical Conventions

Convention Use

ENV_NAME

TIBCO_HOME

BEX_HOME

TIBCO products are installed into an installation environment. A productinstalled into an installation environment does not access components in otherinstallation environments. Incompatible products and multiple instances of the

same product must be installed into different installation environments.

An installation environment consists of the following properties:

Name Identifies the installation environment. This name is referenced indocumentation as ENV_NAME. On Microsoft Windows, the name isappended to the name of Windows services created by the installer and is acomponent of the path to the product shortcut in the Windows Start > AllPrograms menu.

Path The folder into which the product is installed. This folder is referencedin documentation as TIBCO_HOME.

TIBCO BusinessEvents Extreme installs into a directory within a TIBCO_HOME.This directory is referenced in documentation as BEX_HOME. The default valueof BEX_HOMEdepends on the operating system. For example on Windowssystems, the default value is C:\tibco\be-x\1.0.0.

code font Code font identifies commands, code examples, filenames, pathnames, andoutput displayed in a command window. For example:

Use MyCommand to start the foo process.

bold code

font Bold code font is used in the following ways:

In procedures, to indicate what a user types. For example: Type admin .

In large code samples, to indicate the parts of the sample that are ofparticular interest.

In command syntax, to indicate the default parameter for a command. Forexample, if no parameter is specified, MyCommand is enabled:MyCommand [enable | disable]

xvi | Typographical Conventions


16/101


xvi | Typographical Conventions

italic font Italic font is used in the following ways: To indicate a document title. For example: See TIBCO BusinessEvents Extreme

Administration.

To introduce new terms For example: A portal page may contain severalportlets. Portlets are mini-applications that run in a portal.

To indicate a variable in a command or code syntax that you must replace.For example: MyCommand PathName

Keycombinations

Key name separated by a plus sign indicate keys pressed simultaneously. Forexample: Ctrl+C.

Key names separated by a comma and space indicate keys pressed one after theother. For example: Esc, Ctrl+Q.

The note icon indicates information that is of special interest or importance, for

example, an additional action required only in certain circumstances.

The tip icon indicates an idea that could be useful, for example, a way to applythe information provided in the current section to achieve a specific result.

The warning icon indicates the potential for a damaging situation, for example,data loss or corruption if certain steps are taken or not taken.

Table 1 General Typographical Conventions (Contd) (Contd)

Convention Use

Table 2 Syntax Typographical Conventions

Convention Use

[ ] An optional item in a command or code syntax.

For example:

MyCommand [optional_parameter] required_parameter

| A logical OR that separates multiple items of which only one may be chosen.

For example, you can select only one of the following parameters:

MyCommand param1 | param2 | param3

Preface |xvii


17/101


Preface |xvii

{ } A logical group of items in a command. Other syntax notations may appearwithin each logical group.

For example, the following command requires two parameters, which can beeither the pair param1 and param2 , or the pair param3 and param4 .

MyCommand {param1 param2} | {param3 param4}

In the next example, the command requires two parameters. The first parametercan be either param1 or param2 and the second can be either param3 or param4 :

MyCommand {param1 | param2} {param3 | param4}

In the next example, the command can accept either two or three parameters.The first parameter must be param1 . You can optionally include param2 as thesecond parameter. And the last parameter is either param3 or param4 .

MyCommand param1 [param2] {param3 | param4}

Table 2 Syntax Typographical Conventions

Convention Use

xviii | Connecting with TIBCO Resources


18/101


xviii | Connecting with TIBCO Resources

Connecting with TIBCO Resources

This section provides links to helpful TIBCO resources.

How to Join TIBCOmmunity

TIBCOmmunity is an online destination for TIBCO customers, partners, andresident experts, a place to share and access the collective experience of theTIBCO community. TIBCOmmunity offers forums, blogs, and access to a variety

of resources. To register, go to http://www.tibcommunity.com.

How to Access TIBCO Documentation

You can access TIBCO documentation here:

http://docs.tibco.com

How to Contact TIBCO Support

For comments or problems with this manual or the software it addresses, contactTIBCO Support as follows:

For an overview of TIBCO Support, and information about getting startedwith TIBCO Support, visit this site:

http://www.tibco.com/services/support If you already have a valid maintenance or support contract, visit this site:

https://support.tibco.com

Entry to this site requires a user name and password. If you do not have a username, you can request one.

|1
http://www.tibcommunity.com/http://docs.tibco.com/http://www.tibco.com/services/supporthttps://support.tibco.com/https://support.tibco.com/http://www.tibco.com/services/supporthttp://docs.tibco.com/http://www.tibcommunity.com/


19/101


|

Chapter 1 Introduction to TIBCO BusinessEvents

Extreme

This chapter provides an overview of TIBCO BusinessEvents Extreme, includinga brief introduction to complex event processing and event-driven applications,and a description of the major product components

Topics

Whats Different About Complex Event Processing, page 2

Main Product Components, page 6 Designtime Resource Overview, page 8

Deploy-time and Runtime Overview, page 12

2 | Chapter 1 Introduction to TIBCO BusinessEvents Extreme


20/101


|

Whats Different About Complex Event Processing

Complex Event Processing (CEP) is a set of technologies that allows "events" to beprocessed on a continuous basis.

Most conventional event processing software is used either for Business ProcessManagement (BPM), TIBCO ActiveMatrix BPM for example, or for ServiceOriented Architecture (SOA), for example, TIBCO ActiveMatrix BusinessWorkssoftware.

CEP is unlike conventional event processing technologies, however, in that it

treats all events as potentially significant and records them asynchronously.Applications that are appropriate for CEP are event-driven, which implies someaspect of real-time behavior. To be more specific, the typical CEP application areacan be identified as having some aspect of situation awareness, sense andrespond, or track and trace, aspects which overlap in actual businesssituations.

Situation awarenessis about "knowing" the state of the product, person,

document, or entity of interest at any point in time. Achieving this knowledgerequires continuous monitoring of events to do with the entity, events thatindicate what situation or state the entity is in, or about to be in. As an example, adashboard indicates all performance indicators for a runtime production process.All the production plant events are monitored and the situation, or health, of theproduction process is determined via some performance indicators that areshown in real-time to one or more operators.

Sense and respondis about detecting some significant fact about the product,person, document or entity of interest, and responding accordingly. To achieve

this result the software does the following:

Monitors events that indicate what is happening to this entity.

Detects when something significant occurs.

Executes the required response.

As an example, you may monitor cell phone or credit card usage, detect that a cellphone or credit card is being used consecutively at locations that are too far apartfor real-time person-to-business transactions. Detection of such transactionsindicates that an act of fraud is in progress. The system responds accordingly,denying the transactions, and invoking the necessary workflow to handle thesituation as defined in standard procedures.

Whats Different About Complex Event Processing |3


21/101


|

Track and traceis about tracking the product, person, document or entity ofinterest over time and tracing pertinent facts like location, owner, or generalstatus. An example would be tracking events from an RFID-enabled inventory

control system where at any point in time you need to know how many widgetsare in what location.

Situation awareness, sense and respond, and track and trace can all beclassified as types of activity monitoring, for which the continuous evaluation ofincoming events is suitable. For this reason, CEP is often described as ageneralization of Business Activity Monitoring (BAM), although the eventprocessing task may be only indirectly related to business, as in the case of anengine monitoring application or process routing task.

Technical Requirements of a CEP System

CEP systems must be able to receive and record events and identify patterns ofthese events and any related data. CEP systems must also handle temporal ortime-based constraints, especially for handling the non-occurrence of events. Thefollowing TIBCO BusinessEvents Extreme features satisfy these requirements:

A rich event model, incorporating event channels (for different eventmechanisms, such as different types of messaging software) and destinations(for different types of events).

A pattern detection mechanism using a sophisticated, high performance,declarative rule engine.

The following features enrich the functionality made possible by the aboverequirements:

Java integration.

Fully transactional processing.

A rich object model, including keys.

A Model-Driven Approach

The TIBCO BusinessEvents Extreme engine can be described not only as a CEPengine but also as an event-driven rule engine or real-time rule engine. TIBCOBusinessEvents Extreme enables CEP problems to be solved through amodel-driven approach, in which the developer defines the event, rule, concept(class) and state models which are then compiled so that at run-time incomingevents are processed as efficiently as possible.

TIBCO BusinessEvents Extreme also tightly integrates imperative Java code: code

that processes events by changing program state and manipulating the data inconcept objects based on specified rules.



22/101


The various models are as follows:

Event model The event model describes the inputs into TIBCO BusinessEventsExtreme. Events provide information through their properties and (optionally)

through an XML payload. The event model provides the primary interfacebetween TIBCO BusinessEvents Extreme and the outside world, for input as wellas output. Typical event sources (or channels) are messages from TIBCORendezvous and TIBCO Enterprise Message Service middleware, eventsgenerated explicitly by TIBCO BusinessEvents Extreme, and other sources such asSOAP messages. Events can be used to trigger rules.

Concept model The concept model describes the data concepts and index keys

used in TIBCO BusinessEvents Extreme, which may be mapped from events ortheir payloads, or loaded by some other mechanism into TIBCO BusinessEventsExtreme. The concept model is based on standard UML Class and Class Diagramprinciples.

Rule model Rules provide one of the main behavioral mechanisms in TIBCOBusinessEvents Extreme. Rules are defined in terms of declarations(events andconcepts of interest), conditions(filters and joins on and between the attributes ofthe events and concepts), and actions. The underlying rule engine is based on an

algorithm called the Rete algorithm, which mixes all rules together into a type oflook-up tree, so that any additional concept instance or event can near-instantlycause the appropriate rule or rules to fire and invoke the appropriate actions.Rules are almost always defined in general terms (concepts or classes and events),so they apply to however many combinations of those events and classes exist inmemory at any one time. The combination of rule declaration and conditiondefines the event patternrequired for CEP operation. Rule actions that updateother concepts may cause other rules to become available for firing, a process

called inferencingorforward chaining. These types of rules are generally calledProduction Rules. The appropriate UML Production Rule Representation is stillunder development.

Rule functions Algorithms, procedures or functions may be usefully defined asparameterized rule functions and re-used as required in rule actions and otherareas where a behavior can be specified.

Stateful Rule Engine

TIBCO BusinessEvents Extreme uses a stateful rule engine that is transactionbased. At the beginning of a transaction, state is loaded into the rules engine.Rules execution may or may not modify concepts, depending on what the rulesspecify. Transactions ensure that actions run to completion and are executedatomically.

Whats Different About Complex Event Processing |5


23/101


For example, in credit card processing, the concept for a transaction can be set to afrom account transaction or a to account transaction depending on whetherfunds are going out of an account or into an account.

Managed Objects

TIBCO BusinessEvents Extreme features are available using Managed Objects,which provide:

Transactions

Distribution

Durable Object Store

Keys and Queries

Mapping of concepts to events

High Availability



24/101


Main Product Components

TIBCO BusinessEvents Extreme is a distributed event processing platformcovering multiple event processing use cases. Different use cases are supportedusing optional add-on products, available separately.

TIBCO BusinessEvents Extreme Design-time Components

Design-time activities performed using the TIBCO BusinessEvents Extreme

resources include building an ontology a set of concepts, scorecards, andevents that represent the objects and activities in your business and buildingrules that are triggered when instances of ontology objects that fulfill certaincriteria arrive in events. The output of the design-time activities is an enterprisearchive (EAR) file, ready to deploy (or configure for deployment as needed).

Java

TIBCO BusinessEvents Extreme provides a robust Java API that lets you: Define and manage TIBCO BusinessEvents concepts.

Use Plain Old Java Object (POJO) classes that implement generation ofConcepts, ScoreCards, and Events in your application.

Map concepts to implementation-specific storage facilities.

Easily integrate standard Java frameworks.

TIBCO BusinessEvents Extreme Studio

TIBCO BusinessEvents Extreme Studio is an Eclipse-based project buildingenvironment. It organizes project resources and makes the project organizationand the project resources visible in graphical ways.

Perspectives

The Eclipse plug-ins for TIBCO BusinessEvents Extreme and for TIBCOBusinessEvents Extreme add-ons provide these perspectives:

TIBCO BusinessEvents Extreme Studio Development Provides resources forbuilding TIBCO BusinessEvents Extreme projects.

TIBCO BusinessEvents Extreme Studio Debug Provides resources for debuggingrules and rule functions in TIBCO BusinessEvents Extreme projects, as well as

testing running engines without debugging.

Main Product Components |7


25/101


TIBCO BusinessEvents Extreme Studio Diagram Provides interactive graphicalviews of a project that allow you to see relationships between project resources.

Details are provided in the TIBCO BusinessEvents Extreme Application Developers

Guide.

TIBCO BusinessEvents Extreme Administration Components

TIBCO BusinessEvents Extreme provides the following administrationcomponents:

TIBCO BusinessEvents Extreme AdministratorA web-based GUI that

communicates with a Domain Manager to manage and monitor nodes.BusinessEvents Extreme Administrator allows any Web Browser to be used tomanage TIBCO BusinessEvents Extreme solutions.

Console CommandsThe switchadmin utility provides a command line tool tosupport all administrative commands. The utility provides a simplemechanism to support scripting of operational functions.

JMX ManagementTIBCO BusinessEvents Extreme administrative commands

are supported using JMX. TIBCO BusinessEvents Extreme also exposes allevents as JMX notifications. This allows any off-the-shelf JMX console to beused to manage TIBCO BusinessEvents Extreme nodes.

Cluster Deployment Descriptor (CDD) EditorTIBCO BusinessEvents Extremeprovides a Cluster Deployment Descriptor (CDD) editor, which allows you toedit CDD files. A CDD file is an XML file used to configure a project fordeployment.

One EAR file and one CDD file define all the settings for all the engines andagents you want to deploy for a single application.Using the CDD editor, youedit the CDD file to specify deploy-time properties for an application.

To deploy any engine (processing unit) in the cluster, the only details neededare these: the EAR file, which contains all the project resources, the CDD file,and the name of the processing unit (a unit that deploys as an engine). You canchange deploy-time configuration settings in the CDD file, without having to

rebuild the EAR file.For detailed information on the BusinessEvents Extreme Administrator, consolecommands, and the use of JMX, see Chapter 10 of the TIBCO BusinessEventsExtreme Administrationdocument, Monitoring Applications.

For detailed information on using the CDD editor, see chapter 20 of the TIBCOBusinessEvents Extreme Application Developers Guide, Cluster DeploymentDescriptor (CDD).



26/101


BusinessEvents ExtremeDesigntime Resource Overview

In a rule engine, the things that the project works with such as employees,inventory, parts, and so on are conceptsin the ontology of the project, as arescorecards, which hold metrics.

Eventssuch as flight take-off, purchase of a mortgage, sale of stock, and so on arealso part of the ontology. Events can be created from messages arriving throughchannels. Events can also be generated internally, for use in the engine and tosend out messages to external systems.

Rulesare triggered by events and by changes in concepts and scorecards. Forexample, rules might cause baggage to be rerouted if there is a certain problem atthe airport. Rule functions are functions written in the rule language that can becalled from rules or other rule functions. Some rule functions serve specialpurposes at startup, shutdown, and in preprocessing events.

Designing the ontology and the rules well is key to a good CEP (complex eventprocessing) project.

The sections below provide detailed descriptions of the features mentionedabove.

Channels and Events

Channels represent connections to a resource, such as a Rendezvous daemon, JMSserver, or HTTP server or client.

A channel has one or more destinations, which represent listeners to messagesfrom that resource. Destinations can also be used to send messages to theresource.

Messages arriving through channels are transformed into simple events.Conversely, simple events sent out of TIBCO BusinessEvents Extreme aretransformed to the appropriate type of message.

TIBCO BusinessEvents Extreme processes three kinds of events. Only simple

events are used in channels.

Simple Event A representation of a single activity (usually a business activity)that occurred at a single point in time.

Time Event A timer. Generally created and used to trigger rules.

Advisory Event A notice generated by TIBCO BusinessEvents Extreme toreport an activity in the engine, for example, an exception.

BusinessEvents ExtremeDesigntime Resource Overview |9


27/101


TIBCO BusinessEvents Extreme creates instances of simple events and timeevents based on user-configured event definitions.

See Chapter 2, Channels and Events, on page 15.

Concepts

A concept definition is a definition of a set of properties that represent the datafields of an entity. Concepts are equivalent to UML Classes: they representclass-level information, and at runtime the instances of concepts are called objects.

Concepts can describe relationships among themselves. For example, an order

concept might have a parent/child relationship with an item concept. Adepartment concept might be related to a purchase_requisition concept basedon the shared property, department_id .

Concept properties can be updated by rules and rule functions (including rulefunctions whose implementation is provided by decision tables).

See Chapter 3, Concepts, on page 27.

Keys

The concept definition can optionally define one or more keys. An index ismaintained in shared memory for each key defined on a concept. This allowshigh-performance queries to be performed against concepts using a sharedmemory index.

QueriesConcepts can optionally have one or more keys defined. When a key is defined ona concept, an index is maintained in shared memory as concepts are created anddeleted. An index associated with a replicated concept is maintained on all nodesto which the object is replicated.

Query support is provided for:

Unique and non-unique queries

Ordered and unordered queries

Range queries

Cardinality

Explicit locking

The query mechanism is available for catalog functions.



28/101


Java Access

TIBCO BusinessEvents Extreme provides Java support for:

Concepts and events

Queries that are generated automatically from concept and event models

This allows concepts to be accessed directly in Java.

Score Cards

Ascore cardserves as a static variable that is available throughout the project. You

can use a ScoreCard resource to track key performance indicators or any otherinformation. Use rules to view a scorecard value, use its value, or change its value.Note that unlike concepts and event definitions, which describe types ofinstances, each scorecard is both the description and the instance.

A score card is similar to a global variable, except that with multiple activeinference agents, the value is local to the agent, and you can update the value of ascorecard in rules, but not the value of a global variable.

See Designing for ConcurrencyTransactions on page 56for some importantpoints about score cards.

Rules

Rulesdefine what constitutes unusual, suspicious, problematic, or advantageousactivity within your enterprise applications. Rules also determine what TIBCO

BusinessEvents Extreme does when it discovers these types of activities. You canexecute actions based on certain conditions which are defined using simpleevents, concept instances, events, score cards, or a combination of these objects.

Functions

TIBCO BusinessEvents Extreme offers the following types of functions for use inrules:

Standard These functions are provided with TIBCO BusinessEventsExtreme.

Ontology TIBCO BusinessEvents Extreme generates these functions basedon the resources in your project.

Custom You can write custom functions using Java that are automaticallyavailable in TIBCO BusinessEvents Extreme for use in rules.

BusinessEvents ExtremeDesigntime Resource Overview |11


29/101


Rule Function In addition to Java-based custom functions, you can use rulefunction resources to write functions using the TIBCO BusinessEventsExtreme rule language.

See Chapter 4, Rules and Functions, on page 39.

Object Management and Fault Tolerance

TIBCO BusinessEvents Extreme supports:

Shared memory object management, through a highly available distributedobject store.

Partitioning.

Synchronous and asynchronous replication.

Geographic redundancy.

For more information, see Chapter 6, Managed Objects, on page 57and thechapters following.

http://objectmanagement.pdf/http://objectmanagement.pdf/


30/101


Deploy-time and Runtime Overview

A TIBCO BusinessEvents Extreme design-time project is deployed as a TIBCOBusinessEvents Extreme cluster. The deployment can span multiple host servers.

You can use any of these deployment methods. It is recommended that you useonly one method for each cluster you are deploying, by using:

The TIBCO BusinessEvents Extreme Domain Manager to configure amanagement domain and a management server

For information on the Domain Manager, see chapter 3, Domains in the

TIBCO Business Events Extreme Administrationdocument.

The TIBCO BusinessEvents Extreme Administrator utility.

For information on the Administrator utility, see chapter 4, Deployment inthe TIBCO Business Events Extreme Administrationdocument.

The CDD editor and the TIBCO BusinessEvents Extreme Deployment Tool.

At the command-line. You specify the CDD file to use and the processing

unit within that CDD file. (See Starting a TIBCO BusinessEvents Engine atthe Command Line in TIBCO BusinessEvents Extreme Administration.)

For information on the Deployment Tool, see Deployment Tool, inchapter 14 of the TIBCO BusinessEvents Extreme Java Developers Guide.

All of the deployment methods use two resources: an EAR file and a clusterdeployment descriptor, which is an XML file.

The Enterprise Archive Resource (EAR) is the deployable version of a TIBCOBusinessEvents Extreme application. The EAR file contains runtime version of theproject ontology, the channel definitions, and so on. When you are finisheddesigning the project in TIBCO BusinessEvents Extreme Studio, you simplychoose a menu option to build the EAR.

The rest of this section focuses mainly on the deploy-time and runtimecomponents provided with TIBCO BusinessEvents Extreme. See TIBCOBusinessEvents Extreme Administration Components on page 7for a briefsummary at the component level.

Application Partitioning |13


31/101


Application Partitioning

BusinessEvents Extreme applications are deployed to one or more JVMs in anode. The number of JVMs on which to deploy an application is generally basedon application availability requirements, not performance. BusinessEventsExtreme applications always run in a concurrent multithreaded environment andscale in a single JVM.

Multiple JVMs may be deployed to:

Provide high-availability in either an active/active or active/backup

configuration across nodes on separate machines. Minimize or eliminate service disruption for network connections during

application upgrades by hosting network connectivity in one JVM andapplication logic in a another. This configuration allows the application logicto be upgraded without having to drop connectivity to remote clients.



32/101


|15


33/101


Chapter 2 Channels and Events

This chapter explains how messages arrive and leave through channels, and aretransformed to and from events.

Topics

Channels and Events Overview, page 16

Event Preprocessors, page 17

Types of Channels, page 18

Default Destinations and Default Events, page 19

Message Acknowledgement, page 21

Types of Events, page 22

Simple Events Time to Live and Expiry Actions, page 24

16 | Chapter 2 Channels and Events


34/101


Channels and Events Overview

Channels represent physical connections to a resource, such as a Rendezvousdaemon, JMS server, HTTP server or client, or any Java communicationframework.

Destinations in a channel represent listeners to messages from that resource, andthey can also send messages to the resource. All destinations for a particularchannel use the same server.

Arriving messages are transformed into simple events, using message data and

metadata. Simple events sent out of TIBCO BusinessEvents Extreme aretransformed to the appropriate type of message.

In addition to simple events, which work with incoming and outgoing messagesof various sorts, TIBCO BusinessEvents Extreme uses a special-purpose eventtype called SOAPEvent , which inherits from SimpleEvent . It is used for sendingand receiving SOAP messages in an HTTP channel. Two other types of events arealso used: time events and advisory events. These event types are described inTypes of Events on page 22.

Event Preprocessors |17

E t P


35/101


Event Preprocessors

Event preprocessors are rule functions with one argument of type simple event.(Event preprocessors are not used for time or advisory events.) Eventpreprocessors are multithreaded. An event preprocessor is assigned to adestination and acts on all events arriving at that destination. Event preprocessorsperform tasks after an incoming message arrives at the destination and istransformed into a simple event, but before it is asserted into the Rete network (ifit is events can be consumed in the event preprocessor).

You can aggregate events, edit events, and perform other kinds of event

enrichment in a preprocessor. You can also use preprocessors as explained below.

Improving project

efficiency

You can also use preprocessors to improve performance by avoiding unnecessaryRTCs in the inference engine. For example you can consume events that are notneeded.

Preprocessor Use Guidelines

Consuming events in a preprocessor is allowed It can be useful in someapplications and reduces the flow of messages into the Rete network. Such eventsare acknowledged immediately (if they require acknowledgement).

You can only modify events before they are asserted into the Rete network Ruleevaluation depends on event values at time of assertion, so values can be changedonly before assertion, that is, in the preprocessor.

You can create concepts but not modify existing concepts Modifying concepts thatalready exist in the system could disrupt an RTC. You can modify concepts thatwere created in the same preprocessor, however.

See Also

Loading Concepts into the Rete Network on page 36

Transactional Isolation and Locking on page 60

Concepts created in a preprocessor are not asserted until the RTC starts. So, forexample, after one event preprocessor ends and before its RTC begins, no otherpreprocessor can access the new concept.


T pes of Channels


36/101


Types of Channels

TIBCO BusinessEvents Extreme provides the following types of channels:

TIBCO Rendezvous channels Connect TIBCO BusinessEvents Extreme toTIBCO Rendezvous sources and sinks.

HTTP channels, including SOAP support An HTTP channel acts as an HTTPserver at runtime, enabling TIBCO BusinessEvents Extreme to serve requestsfrom clients, as well as to act as a client of other servers

JMS channels Connect TIBCO BusinessEvents Extreme to TIBCO Enterprise

Message Service provider sources and sinks.

Java channels Connect TIBCO BusinessEvents Extreme to a Javacommunication framework.

TCP channels Connect to data sources not otherwise available throughchannels, using a catalog of functions.

Support for SOAP Protocol

Support for SOAP protocol is provided by these features (using SOAP over

HTTP): A specialized event type whose payload is configured as a skeleton SOAP

message

A set of functions for extracting information from SOAP request messages andconstructing response messages.

A utility that constructs project resources based on the SOAP services WSDLfile (document style WSDLs with literal encoding are currently supported).

Each JMS Input Destination Runs a Session

Every JMS destination that is configured to be an input destination runs in its ownJMS Session. This provides good throughput on queues and topics for processing,and less connections.

Default Destinations and Default Events |19

Default Destinations and Default Events


37/101


Default Destinations and Default Events

Using default destinations and default events simplifies project configuration formany scenarios.

Incoming

Messages

Incoming messages can be mapped to a default event that you specify when youconfigure the destination. All messages arriving at that destination aretransformed into the default event type, unless they specify a different event.

For example, in Figure 1the channel is configured to listen to the flow ofmessages on Rendezvous. The ordersdestination directs TIBCO BusinessEvents

Extreme to map messages coming in on the subject, orders, to the new_ordersimpleevent.

Figure 1 Channels and Destinations

You can map incoming messages to specified event types. The technique isexplained in Mapping Incoming Messages to Non-default Eventsin the TIBCOBusinessEvents Extreme Application Developers Guide.

Outgoing

Messages

Outgoing messages can be sent to a default destination. When the destination isnot otherwise specified (for example in rules or rule functions), events are sent tothe destination you select as their default destination.

For example, in Figure 1the event credit_timeout is sent out through its defaultdestination credit .

You can send an event to the default destination of its event type using theEvent.sendEvent() or Event.replyEvent() functions.

TIBCOR

endezvous

RV Channel

Destination:orders

Default Destination:

credit

Default Event:

new_order

Event:credit_timeout

Subject:orders

Subject:

credit


You can send an event to a specified destination using the Event RouteTo()
http://../tib_be_developers_guide/channels.pdfhttp://../tib_be_developers_guide/channels.pdf


38/101


You can send an event to a specified destination using the Event.RouteTo() function.

Message Acknowledgement |21

Message Acknowledgement


39/101


Message Acknowledgement

For each message type (that is, each type of channel), TIBCO BusinessEventsExtreme acknowledges the receipt of messages according to the protocol of themessaging system.

Some messages do not require acknowledgement. For example reliableRendezvous messages do not require acknowledgement.

JMS messages might require acknowledgement, depending on the messageacknowledgement mode (see Setting the JMS Message Acknowledgement Modein TIBCO BusinessEvents Extreme Application Developers Guidefor a list of modes).

Message Acknowledgement Timing

An event is acknowledged as follows:

In a preprocessor: Immediately after the event is consumed.

During a run to completion (RTC) cycle, after the post RTC phase, but only if

the event has been explicitly consumed.


Types of Events
http://../tib_be_developers_guide/channels.pdfhttp://../tib_be_developers_guide/channels.pdf


40/101


Types of Events

TIBCO BusinessEvents Extreme 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. The SOAPEvent event type inheritsfrom SimpleEvent .

Time Event A timer. Time events can be configured to repeat at intervals, orthey can be scheduled using a function in a rule or rule function.

Advisory Event A notice generated by TIBCO BusinessEvents Extreme to

report an activity in the engine, for example, an exception.

TIBCO BusinessEvents Extreme creates instances of simple events and timeevents based on user-configured event definitions. The following sections providemore detail on each type of event.

Simple Events

A simple event definitionis a set of properties related to a given activity. It includesinformation for evaluation by rules, metadata that provides context, and aseparate payloada set of data relevant to the activity.

For example, suppose you are interested in monitoring the creation of newemployee records. You might create a simple event definition that includesimportant fields from the employee record, perhaps the social security number,department, and salary. You could then write a rule to create an instance of thissimple event each time a new employee record is created.

A simpleeventis an instance of a simple event definition. It is a record of a singleactivity that occurred at a single point in time.

Just as you cannot change the fact that a given activity occurred, once an event isasserted into the Rete network, you can no longer change it. (Before assertion youcan use an event preprocessor to enrich the event, however.) Simple events expirewhen their time to live has elapsed, unless TIBCO BusinessEvents Extreme hasinstructions to consume them prior to that time.

Inheritance You can use inheritance when defining simple events.

Attributes In addition to user defined properties, events have built-in attributes

for use in rules and rule functions. For example, simple events have theseattributes: @id , @extId , @ttl , and @payload . Concepts and scorecards also have

built-in attributes. See TIBCO BusinessEvents Extreme Application Developers Guidefor details.

Types of Events |23

Example 1: A temperature sensor records a reading that is above a predefined


41/101


limit. The payload might include the temperature-sensor ID, the reading, and thedate and time. This simple event might trigger a complex event that wouldimmediately 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 ofpurchase, the date and time of the flight, the purchase price, the credit cardnumber, the flight number, the names of the four passengers, and the seatassignments. This simple event alone may include no exceptions. However, it ispossible that when examined within the context of other related events, anexception may arise. For example, one or more of the passengers may have

booked tickets on another flight during the same time period.

Time Events

A time event is an event definition that triggers the creation of event instancesbased 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) TIBCO BusinessEvents Extreme creates a

time-event instance at regular intervals.

Advisory Events

Advisory events are asserted into the Rete network automatically when certain

conditions, for example, exceptions, occur. Add the AdvisoryEvent event type torules to be notified of such conditions. An advisory event expires after thecompletion of the first RTC cycle (that is, the time to live code is set internally tozero). The types of advisory events are described next.

Exception The TIBCO BusinessEvents Extreme engine automatically asserts anadvisory event when it catches an exception that originates in user code but that isnot caught with the catch command of the TIBCO BusinessEvents Extreme

Exception type. (For information on working with exceptions, see ExceptionHandlingin TIBCO BusinessEvents Extreme Application Developers Guide.)

Engine-Activated Advisory Event An advisory event is asserted when an enginehas finished starting up and executing startup functions (if any).


Simple Events Time to Live and Expiry Actions
http://../tib_be_developers_guide/rule-language.pdfhttp://../tib_be_developers_guide/rule-language.pdfhttp://../tib_be_developers_guide/rule-language.pdfhttp://../tib_be_developers_guide/rule-language.pdf


42/101


p p y

Events have a time to live (TTL) setting. Events cannot be modified after they areinitially asserted, but they can continue to trigger rules during their time to live.

Using TTL Options to Trigger Rules Correctly

Set the events time to live so that it can trigger the rules you intend. If a rulecorrelates different events, you must ensure that those event instances are all inthe Rete network concurrently. Time to live options are as follows:

Zero (0): the event expires after the completion of the first RTC cycle. Do notset to 0 if you want to correlate the event with a future event or other futureoccurrences of this event, as explained below.

One or higher (>0): the event expires after the specified time period haselapsed. The TTL timer starts at the end of the action block of the rule orpreprocessor function in which the event is first asserted.

A negative integer (


43/101


greater than the maximum period that can elapse between sending eventAand sending eventB .

If you do not know the order in whicheventA

andeventB

are sent, set theTTL for both simple events to a time greater than the maximum time betweenthe occurrence of the two simple events.

Event Expiration and Expiry Actions

After the time to live (TTL) period, the event expires and is deleted from the Retenetwork. Any expiry actions are taken.

Expiry Actions

For each simple event definition, TIBCO BusinessEvents Extreme allows you tospecify one or more actions to take when the event expires, using the TIBCOBusinessEvents Extreme rule language. For example, you can write an action thatroutes the simple event to a different destination, sends a message, or creates anew 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, TIBCO BusinessEvents Extreme doesnot execute the expiry action.


44/101

|27

Chapter 3 Concepts


45/101


This chapter discusses TIBCO BusinessEvents Extreme concepts, which arecreated from information in messages or built in rules.

Topics

Overview of Concepts on page 28

Concept Relationships on page 30

28 | Chapter 3 Concepts

Overview of Concepts


46/101


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 beDepartment. The Department concept would include department name, manager,and employee properties.

Java Access to Concepts

Concepts in TIBCO BusinessEvents Extreme can be accessed and dynamicallymodified by Java code in your application. Concepts and events are automaticallyexposed as Java classes for Java programming.

Keys and Queries

Java definitions for TIBCO BusinessEvents Extreme allow you to define keys andqueries for Managed Objects.

Runtime Behavior of Concepts

Rules at runtime can create instances of concepts. For example, when a simpleevent arrives, a rule can create an instance of a concept using values present in theevent. Rules can also modify existing concept instance property values.

Also, concepts can be created or modified by Java code in your application.

Concepts must be explicitly deleted when no longer needed or they will steadily

increase memory usage. Use theInstance.deleteInstance()

function or themanagedObjectDelete() Java method to delete concept instances.

Depending on other factors, adding, modifying, and deleting concept instancescan cause TIBCO BusinessEvents Extreme to evaluate or re-evaluate dependentrules, as explained in Understanding Conflict Resolution and Run to CompletionCycles on page 48.

Concepts are automatically asserted into the Rete network when created. When

they are created from Java, they must be explicitly asserted.

Concept Relationships

Concepts can have inheritance, containment and reference relationships withother concepts. See Concept Relationships on page 30.

Overview of Concepts |29

Exporting Concepts to XSD Files

Y t t d t t t XML S h D fi iti (XSD) fil


47/101


You can export concept and event types to XML Schema Definition (XSD) files.XML schemas are used for interoperability between TIBCO BusinessEventsExtreme and third party tools or SOA platforms that use well-defined XML formessage communication, transformation, and validation.


Concept Relationships


48/101


Concepts can have inheritance, containment and reference relationships with

other concepts.

Inheritance Relationships

Definition One concept inherits all the properties of another concept, similar to Java, where asubclass inherits all the properties of the superclass that it extends.

You can define a hierarchy of inheritance, where each concept in the hierarchyextends the concept above it.

The relationship is defined by the Inherits From field in the concept resourceeditor.

Concepts that are related to each other directly or indirectly by inheritance cannothave distinct properties that share a common name. Therefore, the followingrestrictions apply:

If two concepts are related by inheritance, you cannot create a new property inone with a name that already exists in the other.

If two unrelated concepts have properties that share a name, you cannot createan inheritance relationship between the two concepts.

Also, TIBCO BusinessEvents Extreme does not allow you to create an inheritanceloop; for example, if Concept A inherits from Concept B, Concept B cannot inherit

from Concept A.At runtime, a rule on a parent concept also affects all its child concepts. Forexample, suppose the concept Coupe inherits from the concept Car. A rule on Caris therefore also a rule on Coupe.

Concept Relationships |31

Containment Relationships


49/101


Definition One concept is contained inside another concept.

You can define a hierarchy of containment, where each concept in the hierarchy iscontained by the concept above it.

The relationship is defined using a ContainedConcept property in the containerconcept.

Deep containment relationships can cause memory issues. When TIBCOBusinessEvents Extreme retrieves a concept from cache, its child concepts are alsoretrieved. When you modify a child concept, its parent concepts are considered to

be modified. It is recommended that you keep concept relationships shallow. SeeTable 3, Containment and Reference Concept Relationship Rules, on page 34for

these and other rules governing the behavior of concepts linked by containment,and also reference. The table can also help you to choose which is the appropriatetype of relationship for your needs.

Containment Example: Car with Wheels, Doors, and Engine

The following example illustrates some of the rules that are listed in Table 3. Toconfigure a concept Car to contain a concept Wheel, you add a

ContainedConcept property, Wheels for example, whose value is an instance ofthe concept Wheel. The Wheels property provides the link between the containerand contained concept:

Car (Concept) Wheels (property) Wheel (Concept)

The concept Car contains four instances of the contained concept Wheel, so youdefine the property as an array.

The concept Car could also contain other concepts, such as Door and Engine,defined in a similar way using ContainedConcept properties.

When working with container and contained concepts in the rule editor, the XSLTmapper and XPath builder show the entire hierarchy of properties.

In the rule editor, you can also use the @parent attribute to get the parent of acontained concept instance.


However, the contained concepts Wheel, Door, and Engine cannot becontained by any other concept type. They can only be contained by the Car

t F l th t Wh l t b t i d i th t


50/101


concept. For example, the concept Wheel cannot be contained in the conceptMotorbike, if it is already contained by the concept Car.

Reference Relationships

DefinitionOne concept instance references another concept instance.A concept that is the target of a reference can itself refer to one or more otherconcepts. Reference relationships are not, however, hierarchical.

The relationship is defined by a ConceptReference property in the referringconcept.

See Table 3, Containment and Reference Concept Relationship Rules, on page 34for rules governing the behavior of concepts linked by containment or reference.

The table also helps you to choose which is the appropriate type of relationshipfor your needs.

Reference Example: Order with SalesRep and Customer

The following example illustrates some of the rules that are listed in Table 3.

A container concept can link to a contained concept using only oneContainedConcept property. You can use inheritance, however, to achieve aresult similar to that gained by the general programming technique of linking tomultiple contained class properties. Suppose you extend the concept Wheel bycreating child concepts CarWheel and MotorcycleWheel. You can then useCarWheel as the concept contained by Car, and MotorcycleWheel as the conceptcontained by Motorcycle. Rules that apply to Wheel also apply to CarWheel and

MotorcycleWheel, because of inheritance.

Depending on your needs, another option would be to use a referencerelationship instead of a containment or inheritance relationship.

Properties of concept references cannot be used in a condition.


To configure a concept Order to reference a concept SalesRep, you add aConceptReference property, Rep for example, whose value is the ID of conceptSalesRep The Rep property provides the link between the referring and


51/101


SalesRep. The Rep property provides the link between the referring andreferenced concepts:

Order (Concept) Rep (property) SalesRep (Concept)

You can also define additional reference relationships such as:

Order (Concept) BackupRep (property) SalesRep (Concept)

Order (Concept) Lines (property array) LineItem (Concept)

Order (Concept) Cust (property) Customer (Concept)

Customer (Concept) Orders (property) SalesRep (Concept)

Reference Examples: Self Reference

A concept definition can have a reference relationship to itself. This is generallybecause the instances of one concept definition can have reference relationships toother instances of the same definition. For example:

A ListItem concept has a next property which is a reference to a ListItem concept.

A Person concept has a spouse property which is a reference to a Person concept.

A Person concept has a children property which is an array of references toPerson concepts.

Rules Governing Containment and Reference Relationships

By comparing the rules in Table 3, you can decide which type of relationship touse in a particular case.


Table 3 Containment and Reference Concept Relationship Rules

Containment Reference


52/101


One concept is contained in another One concept points to another

Designtime Rules

One container concept can contain multiple different contained concepts, and a contained conceptcan itself also act as a container concept.

One referring concept (that is, the concept that has the ConceptReference property) can have areference relationship with multiple referenced concepts, and a referenced concept can also refer toother concepts.

A container concept can link to a containedconcept using only one ContainedConcept property. (Some other object orientedlanguages do allow you to reuse object types inparent object properties.)

A referring concept links to a referenced conceptusing multiple ConceptReference properties.(That is, multiple ConceptReference propertiescan reference the same referenced concept.)

A contained concept can have only onecontainer concept.

A referenced concept can be referred to bymultiple referring concepts

Runtime Rules

When one contained instance is replaced with

another, TIBCO BusinessEvents Extremeautomatically deletes the instance that itreplaced. You do not have to delete the replacedinstance explicitly.

When one referenced instance is replaced with

another, TIBCO BusinessEvents Extreme doesnotdelete the instance that it replacedautomatically. It may not be appropriate todelete the referenced instance. If you want to

delete the referenced instance, do so explicitly.

When a contained instance is modified, thecontainer instance is also considered to bemodified. The reasoning can be seen by a simpleexample: a change to the wheel of a car is also achange to the car. Rules that test for modifiedinstances would return the Car concept instance

as well as the Wheel concept instance.

When a referenced instance is modified, thereferring instance is notconsidered to bemodified. The reasoning can be seen by a simpleexample: a change to the support contract for acustomer is not a change to an order thatreferences that customer.

When a container instance is asserted or deleted,the contained instance is also asserted ordeleted, along with any other containedinstances at lower levels of the containmenthierarchy.

When a referring instance is asserted or deleted,the referenced instance is notalso asserted ordeleted.


When a Contained or Referred Concept Instance is Deleted

This section describes the handling of deletes.


53/101


Property Settings(ContainedConcept or ConceptReferenceProperty)

Effect of deleting a Contained or ReferencedConcept:

Single value property The value of the ContainedConcept orConceptReference property becomes null.

Multiple-value property (array) The array entry that held the deleted concept isremoved, reducing the array size by one.

Note Delete higher position numbers before lowerposition numbers to ensure the correct entries aredeleted. The array entry that held the deletedconcept is removed, reducing the array size by one,and reducing by one the index of every entry in thearray at a higher index than the deleted one. (Whendeleting multiple entries at once, delete higherposition numbers before lower position numbers toensure the correct entries are deleted.)


Loading Concepts into the Rete Network


54/101


Before an event can trigger rules execution, any concepts required for the rule

execution must be loaded into the Rete network. When rule execution completes,the Rete network is cleared.

These mechanisms are used to populate the Rete network with concepts:

Executing a query in an event preprocessor.

Explicitly loading concepts from Java before injecting an event.

Query Catalog Functions

All concepts with keys defined have query catalog functions generated thatperform a query using the specified key. Query results from a unique key areloaded into the Rete network when the query is performed. Query results from anon-unique key are loaded into the Rete network as part of iterating over theresult set. If the entire result set is not iterated over, the concepts that were notiterated over are not loaded into the Rete network.

It is also possible to explicitly load concepts into the Rete network from Java. Theconcept Java bindings provide a method to load concepts. This provides a veryflexible mechanism to load arbitrary concepts into the Rete network for rulesexecution based on arbitrary application logic.

The following is an example of a generated function that loads concepts into theRete network:

Contained and Referenced Concepts

Concepts contained or referenced in other Concepts are loaded on demand intothe Rete Network and do not have to be explicitly loaded by an application.

Use of Concepts in the Preprocessor

A general best practice is to perform queries in an event preprocessor. If you loadthe objects in the preprocessor, then the rules themselves do not have to takeaccount of the need to load the objects during execution. For example, in thepreprocessor, you could preload an order concept using the ByOrderId key in theevent as follows:

Concepts.Order order = Order.lookupByOrderId("read",orderEvent.orderId);

Loading Concepts into the Rete Network |37

Loaded Objects Are Not New and Do Not Trigger Rules to Fire

The loaded objects do not behave like newly arrived entities. They are nott d th i l d t t i l Th i l t d t


55/101


asserted: their presence alone does not trigger rules. They are simply restored tothe Rete network. They behave as if they had never been removed. For example,rules do fire if there is a join condition between the entity loaded from cache andanother entity that is asserted or modified in the same RTC.

Also if you modify the object that you reloaded, it can trigger the rule.



56/101


|39

Chapter 4 Rules and Functions


57/101


This chapter considers the part that rules and functions play in a TIBCOBusinessEvents Extreme application.

Topics

Rules, page 40

Rule Functions, page 42

Startup and Shutdown Rule Functions, page 43

Startup and Shutdown Rule Functions, page 43

40 | Chapter 4 Rules and Functions

Rules


58/101


Most rules in TIBCO BusinessEvents Extreme are used for inferencing. However,

regular business rules also have a role to play.

Inferencing Rules

Inferencing rules are at the heart of TIBCO BusinessEvents Extreme. Inferencingrules are declarative, and at runtime are executed based on the outcome of eachconflict resolution cycle (see Understanding Conflict Resolution and Run to

Completion Cycles on page 48).A rule includes the following parts:

A declaration of entity types

(Optionally) one or more separate conditions, which evaluate to true or false

An action, which is eligible to execute only when all conditions evaluate totrue.

Statements in a rule action might create or modify concept instances, create andsend simple events, c

Documents

Tibco App Guide