Get Started - learn-tibco-cep/tutorials GitHub Wiki

In this tutorial, you will implement and test your first BE application and learn the key concepts of the TIBCO CEP platform.

Key Concepts of BE Applications

  • Concepts are structured, and stateful data objects that may be loaded in-memory, or stored in a cache cluster or persistent store;
  • Events are structured messages inbound from or outbound to a messaging or API service;
  • Connection Resources are configurations of external connections of messaging servers or API services of a supported protocol;
  • Event Destinations are definitions of messaging queues/topics or API endpoints that are typically associated with specified event types;
  • Rule Functions can be coded to perform preprocessing actions for events of specified types;
  • Rules implement business logic for creating or updating concepts and events under specified conditions;
  • EAR File is the deployable package of a BE application including the runtime components of an event processing agent;
  • CDD File is the runtime configuration for cluster instances and persistent storages of event processing agents.

Business Scenario

This tutorial introduces a very simple, but also very common event processing scenario:

  • Event-driven Action: When a FTL message is received, it checks if a Clock object specified by the message exists already, and if so, it resets the Clock, otherwise, it creates a new Clock;
  • No-event Action: If no FTL message is received for a clock, it increases the clock tick every 10 seconds. This demonstrates a common business use-case of missed events that are expected within a specified time window.

Prerequisites

This tutorial receives inbound events from the default endpoint of a FTL server. Thus, you must install TIBCO FTL as described in Prerequisites.

Tutorial Instructions

The following video leads you through the steps to build the application:

Build BE application in 10 minutes

The following video shows the steps to configure and run the application:

BE Get Started 2

Source Code

The complete BE project built by this tutorial can be downloaded from Demo. The README also describes the details of the artifacts that we have implemented in this tutorial.

You may clone the Demo repository, and import it into your BE studio workspace as a Existing TIBCO BE Studio Project.

Tips

By following the videos above, you have successfully developed and tested the first BE application from zero. You may still not clearly understand how these artifacts worked together at runtime. Developers from visual programming background may ask how I can visualize the path of the execution flow through the artifacts that we had spent 10 minutes to build. You are not alone because this tutorial did not explain any of such magic in a rule-based system.

To understand how a BE application works at runtime, you may want to read the BE online documentations at docs.tibco.com. However, following are a couple of quick-hit points that may help you to start with the most fundamental concepts.

Event-driven application is specified by CDD

BE application is event-driven, and so all runtime activities start by events. Inbound events arrive from channel destinations, which are specified in the Cluster Deployment Descriptor (CDD). Whenever you want to find how a BE application works at runtime, you would start by looking at the CDD file.

The Configuration Guide describes everything that you can specify at deployment time about the runtime architecture and behavior of a BE application. If you want to find only how inbound events are processed at runtime, however, you would start by looking at the Input Destination settings in the CDD. This section specifies the inbound message destinations and the associated preprocessor functions.

The preprocessor functions are the start points of the runtime execution flow. Based on the concepts and events retrieved or created by preprocessor functions, you would understand what rules or state machines will be triggered by the inbound events. This is how an experienced BE developer will understand the runtime behavior of a BE application.

For developers with visual programming background, BE studio generates a visualization of application artifacts, named project view diagram. This diagram is, however, usually too complex to view, unless you understand which artifacts to filter out.

Rule system is a unique programming paradigm

BE application is a rule-based system, which is a completely different programming paradigm than object oriented or functional programming. When you develop a rule-based application, the rules, not the sequence of functional executions, are at the center of your thinking. Some developers may have a difficult time to make such a paradigm shift, and thus implement a BE application using a functional design. It is possible to implement a BE application as mostly functions but very little rules. Doing so, however, would not take advantage of a rule system.

In a BE application, you can implement rules either as standalone rulesets, or as transitions in a state machine. Standalone rulesets are usually more flexible, and more performant at runtime. To realize the benefits of a rule-based application design using the BE platform, you may read the first a few chapters of the Architect's Guide, especially the section of Runtime Inferencing, which explains how rules in a BE application are executed at runtime.

 

Next Step: State Machine for Async Service