Demystifying TIBCO: Business Events 101

Sumit Datta
9 min readJun 11, 2018

TIBCO’s suite of products was always an enigma for me. Many a times, I had thought of building some app using these products but never really got going. Recently, an opportunity came up to try out TIBCO’s Business Events and this time, I did not want to let it pass. However, learning Business Events solely using free online material is easier said than done. While there are quite a few online videos and tutorials that get you started, I was really surprised by the lack of materials that more than scratched the surface. Hence this post, for folks who are also starting like myself and who wants to build real solutions using Business Events.

First, the disclaimer. It is quite possible that some of the stuff mentioned here could be implemented more efficiently if you know Business Events very well. The idea is to show real solutions so that readers can build on top of them.

Now, let’s move forward. A quick introduction about Business Events. It is a platform suitable for taking actions — driven by business rules — on business events that occur in an enterprise. An example — when customer places an online order, it goes through payments, fulfillment and shipment processes. All of these could be treated as separate events and business users would specify the rules that determine how we process each of these events. Business Events is also very powerful in correlating events so that you can create great analytics out of it. Enough of prologue !! I hope you are still there with me :)

In the rest of this post, we will talk about how to build a set of APIs that can be consumed by a UI frontend to deliver an ecommerce site. To start with, I assume you have already installed Business Events and associated software. It comes with a Studio that is integrated into Eclipse IDE as a plug-in and therefore, very much suitable for development. Now, run the Business Events Studio and create a new Studio project. It will create a set of empty folders as shown below.

Folders created inside a new Studio Project

Before we move further, let’s talk about some of the key components in any Business Events project. The first thing you should know about is Shared Resources. Depending upon the kind of application you are developing, you have to define one or more Shared Resource. In this post, we are going to build a set of APIs that can be called by any client application using HTTP protocol. So, we will define a HTTP Resource — also called HTTP Connection — wherein you specify the host and port of the HTTP server that Business Events will start. Do note that Business Events internally embeds a Tomcat Engine, so, essentially, a Tomcat Engine is what Business Engine starts at your specified host and port. Apart from HTTP Resource, you can also create JMS Resource, JDBC Resource and so on and so forth. Once you define a HTTP Resource, you go on to create a Channel that uses this Resource. Think of a Channel as a conduit that connects to your HTTP Server. Within a Channel, you specify various Destinations. Each Destination essentially acts like a HTTP Endpoint that receives HTTP requests from calling application. You must now be wondering what happens when a HTTP request lands on a Destination. The answer to that lies in how you have defined a Destination. In each Destination, you either specify a Default Event — remember, Business Events is an Event-driven system — or you specify an Action Rule Function (and also click “Is Page Flow” checkbox). In this post, we will not consider Action Rule Functions — will talk about them later.

At this time, let’s go back to our service APIs. To begin with, we will provide a Product Search API, an Item Details API and an Add to Cart API and an Authentication API. The last named API will authenticate the client application and return a Token. Client application must pass on this token in all other API requests. Putting everything together, this is how my project looks so far.

HTTP Connection Shared Resource
HTTP Channel

In the Figure above, I have depicted how a “Authenticate” Destination has been configured. Notice that JSON Payload is checked ON, indicating it receives JSON Payload from calling application. I have also configured a default Event named “AuthRequest”. Therefore, when a HTTP Request lands on to this destination (without having Event name in its Payload), Business Event creates an instance of AuthRequest Event. Since this is a REST request, I have selected RESTMessageSerializer. Business Events supports SOAP Requests also — will describe them later when we talk about Web Services.

Next thing you need to know about are Events, Concepts and Rules and Rule Functions. A Concept in Business Events is similar to a Class in Java or C++except that it has only attributes but no methods. In Business Events, you use a Concept to store data, either temporarily or persist in some data store later on. An Event is an Entity that is mapped to Incoming or Outgoing Requests to/from Business Events. You can also create Events internally within Business Events as part of your message processing. There are two types of Events you can create — SimpleEvent or SOAPEvent. As the name suggests itself, if you are dealing with SOAP Request/Response, you will create SOAPEvents. Otherwise, create SimpleEvents. Irrespective of Event type, each Event allows you to specify set of Properties as well as its Payload. Also, each Event has a default Destination that you can specify. If a HTTP GET request lands on a Destination, Business Events creates an Instance of the Event that is marked as “Default Event” of that Destination and maps each Query Parameter and its corresponding value to the corresponding Property of the Event. Do note that it is case sensitive, so if the query parameter is named “param1”, the Event must also have a property named “param1”. In case of a HTTP POST, Business Events maps the HTTP Headers to Event Properties while HTTP Body is mapped to Payload of the Event. What is Event Payload? Here, you specify the data structure that will be created by Business Events in case of Incoming message. And deserialized in case of Outgoing message. If the Payload is JSON, you should specify the Concept that maps to Request JSON. If the Payload is XML, you have to define a XSD as a Resource within Studio so that Business Events can create an object using this XSD as reference. You have to then use XPath to parse the object and extract required data elements.

Now, let’s delve deeper into our first API, Authenticate. In this API, we expect to receive two String elements, namely, accessKeyId and secretKey. And return a authToken String in response. In a real system, instead of secret key, you would probably receive a message signed by the secret key. The pics below show the two Concepts we have created for this API.

AuthenticationRequest Concept
AuthenticationResponse Concept

And here are the two Events defined — one mapped to Request and another to Response. Make sure that both Events have Default Destination set to “Authenticate” — the destination that we had created above.

AuthRequest Event — Standard Tab
AuthRequest Event — Advanced Tab — notice the Payload definition
AuthResponse Event

Till this time, we have defined the Destination and configured the Default Event for the Authenticate API. If a HTTP Request comes, Business Event will create an instance of AuthRequest Event and map the HTTP Body to AuthenticationRequest Concept. The only thing remaining now is processing of this request. This is where Rules (and Rule functions) come into play, which are kind of heart of Business Event engine. Business Event implements the popular RETE algorithm as the Rule Engine. As a developer, you write rules that tells Business Event Engine what to do when certain things happen. Here is the rule we have written for the Authenticate API — see below.

/*** @description This rule handles authentication calls* @author Sumit*/rule Rules.RequestAuthentication {attribute {priority = 5;forwardChain = true;}declare {Events.AuthRequest request;}when {}then {System.debugOut("Authenticate Request rule called");//
// Here, we should validate accessKeyId and secretKey
// For the time being, we are skipping that step
//
// Once validation is done, generate the TokenString tokenId = "TOKEN-"+String.valueOfDouble(Math.random());// Store the Token Id in memory, so that other API calls can be validated
// We are creating an instance of Authentication Concept with this
// token Id. This instance will remain in-memory and will be
// asserted by the Rule Engine
Concepts.Base.Authentication.Authentication(tokenId, tokenId);//
// Here, we are creating the AuthResponse Event and setting Token Id
// in the Payload
Events.AuthResponse response = Event.createEvent("xslt://{{/Events/AuthResponse}}<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<xsl:stylesheet xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\" xmlns:tns=\"www.tibco.com/be/ontology/Concepts/AuthenticationResponse\" version=\"2.0\"><xsl:param name=\"tokenId\"/><xsl:template name=\"Function\" match=\"/\"><createEvent><event><payload><tns:AuthenticationResponse><authToken><xsl:value-of select=\"$tokenId\"/></authToken></tns:AuthenticationResponse></payload></event></createEvent></xsl:template></xsl:stylesheet>");//
// Send the Response Event to the Destination of Request Event
//
Event.replyEvent(request, response);
// Consume the Request Event, so that processing is completeEvent.consumeEvent(request);}}

Here are few things to note. One, every rule has a priority attribute (1 to 10, 1 being highest). If Rule Engine determines two rules that matches, it will execute the rule having higher priority first. Second, the declare section indicates the Event or Concept that will be used in this rule. Whatever you declare in this section will be asserted by the Rule Engine and if found true (and if “when” clause is also true, provided you have put an assertion in “when” clause), the rule will be executed.

The logic inside the Authenticate rule is pretty self explanatory. We validate the accessKeyId and secretKey and then generate a Token. This token is stored in-memory inside a Concept object so that future API calls can be validated using this Token Id. Finally, we set this Token in the Payload of AuthResponse Event and send the Event to the destination of AuthRequest Event. That’s all.

Now, we are done with the implementation of Authentication API. The only thing remaining is to create a deployment descriptor that specifies various configurations of the Business Events Engine. The most important thing is the “Agent Classes” Tab where you add all the rules you have created so far inside the Inference Agent. You have to also configure each of the Destinations created earlier and specify URI and Preprocessor for these destinations. The URI when added to Tomcat host and port forms the URL that client application uses in order to send the HTTP Request. The pic below depicts the Configuration of Authenticate destination.

Configuration of Authenticate Destination

The final step is to build an ear file — for that, click on Project -> Build Enterprise Archive. If everything goes well, you will see a message that Enterprise Archive was built correctly. Now, click on Run and run the ear file. When the server has started successfully, you can test the Authenticate API using any client application. Here is the Request/Response using Postman.

That completes the first part of this post. We have successfully developed the first API using TIBCO Business Events. Phew !!

In Part 2, we will implement other APIs of our eCommerce Service. While doing so, we will also introduce various new aspects of Business Events. I hope you have found this post useful.

--

--

Sumit Datta

Loves dabbling in new technologies. All views expressed are mine.