How to create a publish/subscribe example with TIBCO BusinessWorks? 6 and TIBCO FTL®

Table of Contents

• Introduction
• Defining the communication pattern
• Building the application logic
• Adding delivery assurance

Introduction

This tutorial describes how to build a publish/subscribe example using TIBCO BusinessWorks? 6 and TIBCO FTL®. Lets take a simple use case for an order handling process. The first step in the process is to create a new order, then the order must be sent to three different applications for processing, lets call these applications A, B and C. Applications A and B need to process all orders, whilst application C only needs to process orders of type ?XYZ?. The message flow for this process can be depicted as shown below.

Before we start lets look at what tools we are going to use to build this example. TIBCO BusinessWorks? 6 will be used as the application development tool to model and execute the order handling process, TIBCO FTL® is used as the underlying messaging layer between the various components.

Note, some working knowledge of these tools is required to build this tutorial in your own environment. The attached pre-built examples can also be downloaded for reference.

The example in this tutorial uses the following products:

• TIBCO FTL® 5.2 Hotfix 1
• TIBCO FTL® 5.0 Client
• TIBCO ActiveMatrix BusinessWorks? 6.3.5 (requires TIBCO FTL® 5.0 client)

We?ll be using two graphical tools in building this example. The FTL Realm Server is used for defining how the various application components will communicate together, and BusinessStudio is used to build and execute the application processing logic for each component.

Defining the communication pattern

Firstly, ensure your FTL Realm Server is running. See running tibrealmserver in the FTL docs: Realm Server Executable Reference

To access the Realm Server UI open a browser and navigate to the appropriate URL, for a local server with default configuration go to http://localhost:8080

We?ll create FTL applications to represent the order producing and receiving sides of the order handling process.

Turn on edit mode then go to the applications page and select the ?+? to create the two new applications:

• OrderProducerApp
• OrderConsumerApp

Next, we?ll create an ?endpoint? for each FTL application and a transport to connect these endpoints together to enable the communication. 

Note, FTL is extremely flexible in how data can be distributed with a wide variety of transport options available for many different use cases. An endpoint is an abstraction used by the application components to insulate them from the communication transport details. These transport details can be changed by administration staff to easily support different deployment models without the need to change any application logic.

Create two endpoints:

• OrderProducerEP
• OrderConsumerEP

Note, for this simple example we?ll share the same FTL consumer application and endpoint definition for the three receiving components. However in a real use case you may prefer to separate these to each have its own application and endpoint definitions, particularly if the components are located in different environments that may involve different communication transports being used.

Your Applications screen should look as follows:

Now create transports for the underlying communication mechanism, we?ll choose dynamic TCP transports so the components can be easily deployed to different hosts. We?ll create two transports that work together in a client/server mode, the receiving components will use the client or ?connect? side and the sending side will use the server or ?listen? side. This allows us to easily connect additional receiving components in future if required.

Go to the transports page and select the ?+? to create two new transports, as follows:

• OrderProducerTP, Type:DynamicTCP, Mode:Listen
• OrderConsumerTP, Type:DynamicTCP, Mode:Connect

Ensure you configure the two transports as part of the same transport group so they work correctly together, the transport page should look as follows:

Now return to the Applications page and configure the transports to connect up the endpoints, the screen should look as follows:

Next, we?ll create a message format to define the message structure for the order message.

Go to the Formats page and select the ?+? to create a new Format, name the format ?Order?, and add the following fields:

• OrderID: Long
• OrderType: String
• OrderDetails: String

Now ensure to enable this message format to be used by the application components. Go back the the Applications page and view the application's details by clicking the ??? for each application. On the details page select the Order format so its added to the list of preloaded formats, and click save.

We?ve now completed the necessary configuration steps to define the communication for our order processing components, but before the configuration can be used we need to deploy the changes. Click the orange Deploy icon at the top of the page and verify all changes have been successfully deployed. 

Building the application logic

Open the BusinessStudio editor and create a new BusinessWorks project, for example called MyOrderProject.

Create two new FTL Realm Server Connection resources, one for each FTL application. Configure the Realm Server URL and browse to select the appropriate application name.

Create a new BusinessWorks process called CreateOrder and add the following activities:

• Timer activity, configure the activity to run once a second
• FTL Publisher

Connect the activities together and configure the FTL Publisher as follows:

• Set the FTL Ream Server Connection to the producer?s connection resource
• Browse and select the OrderProducerEP
• Choose Format as Predefined and browse to select the Order Format
• Configure the publisher input parameters for example as shown below.

We can test the producer process by using an FTL sample program to receive the messages sent by the BusinessWorks producer. For example, follow the notes in the <FTL Home>/5.2/samples and run the tibrecvex sample, then launch the BusinessStudio debugger to run the order producer process. Ensure you pass the tibrecvex program a valid FTL consumer application and endpoint name, check the sample receives the order messages.

Now lets complete the BusinessWorks project and create the BusinessWorks processes to receive the orders. Create a new BusinessWorks process called ReceiveOrderA and add the following activities:

• FTL Subscriber
• Log

Connect the activities together and configure the FTL Subscriber as follows:

• Set the FTL Ream Server Connection to the consumer?s connection resource
• Browse and select he OrderConsumerEP
• Choose Format as Predefined and browse to select the Order Format
• Configure the Log?s input parameters for example as shown below

Follow the same procedure to create another BusinessWorks process for receiver B, and again for receiver C.

For receiver C we?ll configure a content matcher to ensure it only receives orders of type ?XYZ?. This is done using a JSON syntax string of the form { "fieldname1" : value1 , ... , "fieldnameN" : valueN } for this case we want the simple matcher: {"OrderType":"XYZ"}

Note, since the field type is a string the value must be enclosed in quotes.

Now we?re ready to test the project, launch the debugger and check the console output, ensure receivers A and B receive both order types whilst receiver C only receives orders of type ?XYZ?.

Adding delivery assurance

For most fire and forget scenarios you?ll want to provide some assurance that messages will arrive at their intended destinations. This can be achieved in FTL with an out of band in-memory based persistence cluster. In this example we?ll create a cluster with a single server, for production systems a persistence cluster would comprise of a quorum of servers, typically 3.

To configure persistence go back the Realm Server UI and reenter edit mode. Go to the Clusters page and select the ?+? to create a cluster. Create a cluster called ?cluster? and single server called ?pserver?. Select Dynamic TCP as the protocol for the cluster and client communication.

Next we need to create a message store for our order example; go to the Stores page and select the ?+? to create a new message store. Name the store ?OrderStore? and assign it to our persistence cluster. Choose Publisher Mode Store->Confirm->Send for the highest assurance level, this ensures the message is not published until it has been safely persisted in the message store.

Next we need to configure three durables, one for each order receiving component. Click on the ??? above the store name to create the durables; DurableA, DurableB, DurableC. For Durable Type choose ?Static/Standard?, Acknowledgement Mode ?sync? and for Durables A&B Interest ?store all messages?. For Durable C choose Interest ?store matching messages? and specify a match field for OrderType with value XYZ. Your store configuration should now look as below:

Now we need to enable the message store to be used with our order endpoints. Go to the Applications page and for each endpoint select the OrderStore from the drop down.

Now deploy the changes made and check the deployment is successful.

Before we can retest the application we need to start the FTL persistence server, run the tibstore executable from the FTL installation for example:

 tibstore -n pserver -d data_dir -rs http://localhost:8080

Refer to tibstore Command Line Reference for details.

Return to the BusinessWorks designer studio and for each receiver process configure the appropriate durable name on the FTL Subscriber?s Advanced tab. Note, you can also, if required, select explicit acknowledgment and add a confirm activity to the process to ensure the message is not considered delivered until the process has successfully completed.

We can now also optionally remove the content matcher that was configured for the FTL Subscriber activity in the ReceiveOrderC process, since this is now defined for the durable on the store in the Realm Server. This is more flexible as it allows the matching to be configured administratively rather than statically set in process configuration.

Now test delivery assurance by first running just the order producer process. After several seconds stop the process and check the store has the messages saved using the Realm Server UI. Click on ?Services? at the top of the page, then select ?Stores?, then select our OrderStore. You should see messages saved for each of the durables as shown below.

Now return the BusinessWorks designer studio and run the receiver processes, verify all the pending messages are received.

Attachments

Download attachments from resources

ftl-orderhandlerconfig.json_.zip

bw6-orderhandlerproject.zip

ftl-orderhandlerconfig-persistent.json_.zip

bw6-orderhandlerproject-persistent.zip