bridging apache kafka to tibco ems · 1. overview 1.1. document purpose with the release of tibco®...

TIBCO Software Inc. Global Headquarters

3307 Hillview Avenue

Palo Alto, CA 94304

Tel: +1 650-846-1000

Toll Free: 1

800-420-8450

Fax: +1 650-846-1005

www.tibco.com

Bridging Apache Kafka® and TIBCO Enterprise MessageTM Using TIBCO FTL® This document provides the steps for configuring and testing the bridge between TIBCO Enterprise Message Service, TIBCO FTL, and Apache Kafka

TIBCO fuels digital business by enabling better decisions and faster, smarter actions through the TIBCO Connected Intelligence Cloud. From APIs and systems to devices and people, we interconnect everything, capture data in real time wherever it is, and augment the intelligence of your business through analytical insights. Thousands of customers around the globe rely on us to build compelling experiences, energize operations, and propel innovation. Learn how TIBCO makes digital smarter at

www.tibco.com

http://www.tibco.com

http://www.tibco.com

!

Copyright NoticeCOPYRIGHT© 2018 TIBCO Software Inc. All rights reserved.

TrademarksTIBCO, the TIBCO logo, and TIBCO Enterprise Message Service are either registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or other countries. All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only.

Content WarrantyThe information in this document is subject to change without notice. THIS DOCUMENT IS PROVIDED "AS IS" AND TIBCO MAKES NO WARRANTY, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO ALL WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. TIBCO Software Inc. shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this material.

For more information, please contact:

TIBCO Software Inc.3303 Hillview Avenue Palo Alto, CA 94304 USA

©2018 TIBCO Software, Inc. All Rights Reserved. TIBCO Confidential and Proprietary !2

!

1. Overview 4 .....................................................................................................................1.1. Document Purpose 4 .....................................................................................1.2. Linux Kernel Version Support 4 ......................................................................1.3. Product/Component Version Support 4 ..........................................................1.4. Assumptions 4 .............................................................................................

2. Messaging Component Installation and Configuration 5 ...........................................2.1. Component Installation 5 ..............................................................................2.2. Post Installation 5 .........................................................................................

Figure 1 - /etc/profile additions 52.3. TIBCO Enterprise Message Service Configuration 5 .........................................

2.3.1. Tibemsd.conf 5 ...................................................................................Figure 2 - tibemsd.conf changes. 6

2.3.2. Transports.conf 6 ................................................................................Figure 3 - Transports.conf changes 6

2.3.3. Topics.conf 7 .......................................................................................Figure 4 - Topics.conf example 7

2.3.4. Optional Configuration File Changes 7 ...................................................Figure 5 - Queues.conf example 7Figure 6 - Bridges.conf example 7

3. TIBCO FTL Configuration 8 ............................................................................................3.1. Start the FTL Realm Server 8 .........................................................................

Figure 7 - FTL Startup 8Figure 8 - Running FTL Example 8

3.2. Configure the FTL Realm Server 8 ..................................................................Figure 9 - FTL Store Example 9Figure 10 - Setting TTL for Persistent Messages 10Figure 11 - FTL Configuration 11

3.3. Start the FTL Persistence Store (Tibstore) 12 ...................................................Figure 12 - FTL Persistence Store Startup 12

3.4. Start the EMS Server 12 .................................................................................Figure 13 - EMS Startup example 13

4. Kafka Bridge Configuration 14 ......................................................................................4.1. Configure and Start Zookeeper and the Kafka Broker 14 ...................................4.2. Configure the TIBCO-Kafka Source Connector 14 ............................................

4.2.1. Connect-standalone Properties file 15 ..............................................Figure 14 - connect-standalone.properties example 15

4.2.2. TIBFTL-kafka-connect-source Properties File 16 ..............................Figure 15 - tibftl-kafka-connect-source.properties example 17

4.3. Configure the TIBCO-Kafka Sink Connector 17 ................................................Figure 16 - tibftl-kafka-connect-sink.properties example 18

4.4. Starting the TIBCO-Kafka Connectors 18 ........................................................Figure 17 - Kafka Topics Creation example 18

5. Testing the Kafka-FTL Bridge 19 ...................................................................................5.1. Sending Messages from EMS 19 ....................................................................

5.1.1. Setting Up the EMS Send Tests 19 ....................................................5.1.2. Expected Results 20 .......................................................................

Figure 18 - FTL Output from EMS Send example 21Figure 19 - Kafka Output from EMS Send example 22

5.2. Sending Messages from Kafka 22 ..................................................................5.2.1. Setting Up the Kafka Send Tests 22 ..................................................5.2.2. Expected Results 23 .......................................................................

Figure 20 - FTL Output from Kafka Send example 23Figure 21 - EMS Output from Kafka Send example 24


!

1. Overview

1.1. Document Purpose With the release of TIBCO® Messaging - Apache Kafka Distribution, TIBCO provides connectors to bridge TIBCO FTL and Apache Kafka. The purpose of the document is to provide a guide on how to install, configure, and test the TIBCO bridge between TIBCO FTL, and Apache Kafka. Although there is no direct bridge from TIBCO Enterprise Message Service (EMS) and Apache Kafka, TIBCO EMS and TIBCO FTL can be bridged. This guide will provide the steps necessary for configuring the bridge between TIBCO Enterprise Message Service and TIBCO FTL, thus allowing messages to be sent/received from TIBCO EMS to Apache Kafka.

The document will outline:

• Configuration of EMS to bridge to FTL • Configuration of FTL to bridge to EMS and Apache Kafka • Configuration of FTL for persistence • Configuration of Apache Kafka • Configuration of a bidirectional tibftl-connector to bridge Kafka and FTL for simple string messages • Simple tests to ensure bidirectional message transfer between EMS/FTL and Kafka

For sending/receiving more complex message structures between the components, refer to the appropriate TIBCO messaging component documentation.

1.2. Linux Kernel Version Support This document covers the installation and configuration of EMS, FTL, and Kafka on Red Hat Linux 7.5, which is based on Linux kernel 3.10.0-693.21.1.

However, other Linux kernels can be used as well as Windows and macOS, so long as they are supported versions by the TIBCO Messaging components and Apache Kafka.

1.3. Product/Component Version Support • TIBCO Enterprise Message Service – version 8.4 or later is required • TIBCO FTL – version 5.4 or later is required • TIBCO® Messaging – Apache Kafka Distribution – Apache Kafka core 1.1, Repository 1.0, and Bridge 1.0

are all part of the distribution

1.4. Assumptions The reader of this document is familiar with the following concepts:

• TIBCO product installation and configuration of EMS and FTL • Apache Kafka

Java 1.8 development is installed

All TIBCO messaging components are installed on the same server

Document only provides information for Red Hat Linux. Other Linux kernels should be similar


!

2. Messaging Component Installation and Configuration The following steps will outline installing and configuring TIBCO Messaging, which includes TIBCO EMS, TIBCO FTL, and the TIBCO Messaging - Apache Kafka Distribution (AKD).

2.1. Component Installation TIBCO EMS, FTL, and ADK should all be installed following their respective installation guides. All components are part of the TIBCO Messaging - Enterprise Edition which can be download from edelivery.tibco.com or TIBCO Messaging - Community Edition which can be downloaded from https://www.tibco.com/products/tibco-messaging/downloads . There are no special installation requirements.

2.2. Post Installation Follow the post installation steps for each of the respective messaging component. Once completed, it is recommended to update the /etc/profile with the following:

Figure 1 - /etc/profile additions

In this example, the TIBCO_HOME is /opt/tibco/product. The default will be /opt/tibco.

2.3. TIBCO Enterprise Message Service Configuration Once TIBCO Enterprise Message Service (EMS) has been installed, the component can be configured for the bridge to TIBCO FTL. The tibemsd, transports, and topics configuration files require modifications. Optional configuration changes can also be included for the bridges and queues configuration files.

Note: This document will show updating the conf versions of the EMS configuration files. If using Json, update accordingly.

Note: Do not start EMS after making the EMS configuration file changes. Wait until FTL has been started and configured.

2.3.1. Tibemsd.conf The tibemsd.conf must be updated to enable the tibftl_transport , module_path, and the FTL realmserver(s).

Set/add: ● tibftl_transports = enabled ● module_path = <EMS_HOME>/ems/8.4/lib/64:/<FTL_HOME>/ftl/5.4/lib ● ftl_url = URL of the FTL realmserver. ● ftl_discard_policy = new ● Other FTL parameters based on the FTL configuration (username, password, etc.)


https://edelivery.tibco.com/

https://www.tibco.com/products/tibco-messaging/downloads

https://www.tibco.com/products/tibco-messaging/downloads

!

● Add FTL (+FTL) to the console/trace logging ● Take note of the name of the EMS Server. The default is EMS-SERVER

The following example shows the modifications

Figure 2 - tibemsd.conf changes.

2.3.2. Transports.conf Transports.conf must be updated to include a new reference for a new transport type. In this case, FTL. Once the tibftl_transports is enabled in tibemsd.conf, TIBCO EMS expects the trasnports.conf to reference an FTL definition. The tibftl type must be defined, along with an ftl endpoint. There are other possible parameters, but at a minimum, the tibftl type and FTL endpoint must be defined. The following shows an example of what should be added to transports.conf to import messages to a topic (minimal) and persisted queue (optional).

Figure 3 - Transports.conf changes


tibrv_transports =disabled tibftl_transports =enabled module_path=/opt/tibco/product/ems/8.4/lib/64:/opt/tibco/product/ftl/5.4/lib

######################################################################## ## FTL setup. These global parameters are used only when FTL transports ## are enabled, and apply to all FTL transports. The "ftl_url" parameter ## is required when FTL transports are enabled. #########################################################################

ftl_url = http://192.168.0.138:8400 #ftl_url_secondary = #ftl_username = #ftl_password = #ftl_log_level = #

## FTL Event Queue discard policy parameters. ftl_discard_policy = new #ftl_discard_amount = #ftl_discard_max_events =

[FTLtopic] type = tibftl endpoint = FTLtopic

[FTLqueuein] type = tibftl endpoint = FTLqueuein queue_import_dm = TIBEMS_PERSISTENT

[FTLqueueout] type = tibftl endpoint = FTLqueueout

!

2.3.3. Topics.conf The last EMS configuration file that requires modifications to support the FTL bridge, is topics.conf. Topics.conf must be updated to include the topic which will be used to import and export messages to FTL. Create a new topic and define the FTL endpoint(s) which will be used to import/export messages.

Note: in the following example, two topics are created/used. The ftltopic topic is used to import and export messages, while the ftlqueueout topic is only used for exports.

Figure 4 - Topics.conf example

2.3.4. Optional Configuration File Changes The three EMS configuration files above are required. However, there are some optional changes which can be made. Queues can also be used to import messages from FTL. In addition, the queues can be persisted. Figure 3 provides an example of configuring transports.conf to import messages to a persisted queue.

However, queues cannot export messages to FTL. If a persistent queue is used to send messages to FTL, a bridge must be configured to bridge the queue to the topic exporting messages to FTL. The examples below show the queue definitions for importing and exporting messages FTL, and the bridge definition.

Figure 5 - Queues.conf example

Figure 6 - Bridges.conf example


ftltopic import=“FTLtopic”,export="FTLtopic" ftlqueueout export="FTLqueueout"

ftlqueuein import=“FTLqueuein",store=$sys.failsafe ftlqueueout store=$sys.failsafe,expiration=5

[queue:ftlqueueout] topic=ftlqueueout

!

3. TIBCO FTL Configuration The FTL configuration setup for testing the FTL-EMS bridge is done via the FTL Realm Server. Use the following to setup the FTL Realm Server configuration to create the FTL-EMS bridge, the Kafka-FTL bridge, as well as configuring FTL for persistence..

3.1. Start the FTL Realm Server Use the following to start the FTL Realm Server

● cd to $TIBCO_HOME/ftl/5.4/bin ● Create the directory for the realm data, as shown below ● Start the FTL Realm Server, using the following example. In the example the FTL Realm Server will

accept connections on HTTP host/port 192.168.0138:8400, the data directory is realm_store, and the logfile is realm.log.

Note: The realm server startup can be scripted, and started in the background.

Figure 7 - FTL Startup ● Ensure FTL is running.

Figure 8 - Running FTL Example

3.2. Configure the FTL Realm Server The section will show how to configure the FTL Realm Server. It will outline creating a cluster, persistence (tibstore), transports, applications, endpoints, and durables.

● In a web browser, go to the FTL URL. In the above examples, http://192.168.0.138:8400 ● Click on the Edit Mode button, slide it to on. ● Setting up persistence which will be used by both the Kafka and EMS bridges, should be the initial

configuration completed in the FTL Realm Server. Setting up Clusters and Stores is required for FTL persistence. Note: For this configuration, only one FTL persistence store is being configured and used. In a production environment, a minimum of three persistence stores is required.

● Click on Clusters, then on the + next to Clusters to create new cluster in the Cluster screen. ● Enter a new for the cluster, such as tibcluster ● Enter a Primary Set and Set Name. The defaults, Set1 is fine ● Enter the Dynamic TCP for both the Cluster Set Protocol, and for the Client Protocol ● Enter a name for the Server Name, such as tibstore. This will be the name for the persistence

store ● Enter a Weight of 10, and leave the other values at their defaults

● Click on Stores, then on the + next to Stores to create a new store in the Stores screen.. ©2018 TIBCO Software, Inc. All Rights Reserved. TIBCO Confidential and Proprietary !8

mkdir realm_store ./tibrealmserver --http 192.168.0.138:8400 --logfile realm.log --data realm_store

ps -aef |grep ftl tibco 3660 1 2 12:20 pts/2 00:00:00 /opt/tibco/product/ftl/5.4/bin/tibrs --http 192.168.0.138:8400 --logfile realm.log --data realm_store

http://192.168.0.138:8400

!

● Enter a Store name. It must be the same as the Server Name from creating the cluster. ● Enter the Persistent Cluster name created above. ● Click on the arrow in the under the Store. the Durable Name box will expand to show four

default durable templates, as shown in the following example.

!

Figure 9 - FTL Store Example

● Click on the “…” on top of the default_standard box, and click on View Details. This will show the TTL Setting and Discard Policy for the durable data. Leave the Message Limit and Discard Policy at the defaults. However, it is recommend to set the TTL setting for the messages for a reasonable time.

● Click on Save after making changes.


!

! Figure 10 - Setting TTL for Persistent Messages

● Create two new transports. Click on Transports, then click on the + next Transports in the Transports screen. ● Leave Group blank, enter a new transport name. Provide a name which represents it use, such as

queuein or queueout ● Use Dynamic TCP from the drop down menu for the Transport Type ● Create a second transport. It should also be Dynamic TCP.

● Once the cluster, store, and transports have been created, the applications can be created. Three applications will be created. One for the EMS bridges, and the other two for the Kafka bridge (sink and source).

● Create a new application for the EMS bridge. ● The name of the application must be the same as the name of the EMS Server. Default is EMS-

SERVER. In the following example, EMS-SERVER-GBA2 is the application name and the name of the EMS server.

● Three endpoints need to be created. These need to match the endpoint names from the EMS transports.conf. From the transports.conf example, create FTLtopic, FTLqueuein, and FTLqueueout.

● Enter the Store for the FTLqueuein and FTLqueueout endpoints. Use the store name create previously, tibstore. The FTLtopic endpoint does not need a store, since it will not be durable.

● For the FTLqueuein and FTLqueueout endpoints, use default_standard for the durable template. The FTLtopic endpoint does not need a durable template.

● For the transports, use default for the FTLtopic endpoint, use queuein for the FTLqueuein endpoint, and queueout for the FTLqueueout endpoint.

● Leave other columns as the default. ● Create the Kafka applications in the FTL Realm Server. The two Kafka-FTL bridge applications are

created similar to the EMS Bridge application. ● For the Kafka-FTL source bridge, the application name must match the name defined for the

ftl.application.name property in the tibftl-kafka-source properties file discussed in the next section.

● The endpoint for the source bridge application should be FTLqueueout, the store and durable template should be the same as the EMS bridge (tibstore and default_standard). The transport should be default, and the protocol should be Dynamic TCP. Leave all other columns at their default.


!

● For the Kafka-FTL sink bridge, the application name must match the name defined for the ftl.application.name property in the tibftl-kafka-sink properties file discussed in the next section.

● The endpoint for the sink bridge application should be FTLqueuein, the store and durable template should be the same as the EMS bridge (tibstore and default_standard). The transport should be default, and the protocol should be Dynamic TCP. Leave all other columns at their default.

● After verifying all applications, transports, stores, and clusters are configured, the configuration can be deployed. Click on Deploy at the top of the FTL Realm Server main screen. Use test to validate the configuration. Fix any problems that listed (if any), then deploy the configuration. Click Done.

After all three applications have been deployed, the FTL Realm Server configuration should be similar to the figure below.

!

Figure 11 - FTL Configuration


!

3.3. Start the FTL Persistence Store (Tibstore) Once the persistence store (tibstore) has been configured in the FTL Realm Server, the persistence store must be started. Us the following to start the persistence store.

Figure 12 - FTL Persistence Store Startup In the example above, tibstore is the name of the persistence store, and must be the same name used for the Server Name when defining the Cluster. Tib_store is the location for the store files, and tibstore.log is the log file.

Note: The realm server startup can be scripted, and started in the background.

Review the log file to ensure the persistence store started correctly.

3.4. Start the EMS Server After FTL is started and configured, start the EMS Server instance, using the modified EMS tibemsd.conf configuration file. Review the EMS log after EMS starts. The creation of the FTL transports should be observed with no errors, and the EMS server should be active.


cd $TIBCO_HOME/ftl/5.4/bin mkdir tib_store ./tibstore -rs 192.168.0.138:8400 -name tibstore -d tib_store --logfile tibstore.log

!

Figure 13 - EMS Startup example

FTL and EMS are now bridged to send/receive messages between the components.


TIBCO Enterprise Message Service. Copyright 2003-2017 by TIBCO Software Inc. All rights reserved.

Version 8.4.0 V14 7/20/2017

2018-05-23 17:13:45.161 Process started from '/opt/tibco/product/ems/8.4/bin/tibemsd'. 2018-05-23 17:13:45.161 Process Id: 2089 2018-05-23 17:13:45.161 Hostname: gba2 2018-05-23 17:13:45.161 Hostname IP address: [fe80::7ec8:2ae0:1605:5aa3] 2018-05-23 17:13:45.161 Hostname IP address: 192.168.0.138 2018-05-23 17:13:45.161 Reading configuration from 'tibemsd.conf'. 2018-05-23 17:13:45.161 Logging into file '/opt/tibco/cfgmgmt/ems/data/datastore/gba2-logfile' 2018-05-23 17:13:45.162 Server name: 'EMS-SERVER-GBA2'. 2018-05-23 17:13:45.162 Storage Location: '/opt/tibco/cfgmgmt/ems/data/datastore'. 2018-05-23 17:13:45.162 Routing is enabled. 2018-05-23 17:13:45.162 Authorization is disabled. 2018-05-23 17:13:45.162 FTL transports are enabled. 2018-05-23 17:13:45.162 The server will attempt to trace warnings about destinations that are growing unbounded above 107374182 bytes or 50000 messages. 2018-05-23 17:13:45.162 Set server properties 'large_destination_memory' and 'large_destination_count' respectively to alter these thresholds. 2018-05-23 17:13:45.164 Accepting connections on tcp://gba2/[::]:7222. 2018-05-23 17:13:45.164 Accepting connections on tcp://gba2/0.0.0.0:7222. 2018-05-23 17:13:45.164 Recovering state, please wait. 2018-05-23 17:13:45.165 Creating store '$sys.nonfailsafe' file '/opt/tibco/cfgmgmt/ems/data/datastore/async-msgs.db' ... 2018-05-23 17:13:45.165 Creating store '$sys.failsafe' file '/opt/tibco/cfgmgmt/ems/data/datastore/sync-msgs.db' ... 2018-05-23 17:13:45.165 Creating store '$sys.meta' file '/opt/tibco/cfgmgmt/ems/data/datastore/meta.db' ... 2018-05-23 17:13:45.232 Creating FTL Transport 'FTLqueueout' 2018-05-23 17:13:45.232 Global FTL Settings 2018-05-23 17:13:45.232 Realm server URL: http://192.168.0.138:8400 2018-05-23 17:13:45.232 Realm server Secondary URL: http://192.168.0.25:8400 2018-05-23 17:13:45.232 Username: (Unset) 2018-05-23 17:13:45.232 Password: (Unset) 2018-05-23 17:13:45.232 Log Level: warn 2018-05-23 17:13:45.232 Application Name: EMS-SERVER-GBA2 2018-05-23 17:13:45.232 Discard Policy: new 2018-05-23 17:13:45.232 Discard Amount: 5000 2018-05-23 17:13:45.232 Discard Max Events: 100000 2018-05-23 17:13:45.253 Connecting to the realm server. 2018-05-23 17:13:45.273 warn ques: tibEventQueue_Create (0x19ed0c0) Event queue (0x3e00000039) for discard policy DISCARD_NEW, the discard amount is ignored 2018-05-23 17:13:45.274 FTL Transport Settings 2018-05-23 17:13:45.274 Topic Import Delivery Mode: NON_PERSISTENT. 2018-05-23 17:13:45.274 Queue Import Delivery Mode: NON_PERSISTENT. 2018-05-23 17:13:45.274 Endpoint: FTLqueueout 2018-05-23 17:13:45.274 Import Parameters 2018-05-23 17:13:45.274 Match String: (Unset) 2018-05-23 17:13:45.274 Subscriber Name: (Unset) 2018-05-23 17:13:45.274 Export Parameters 2018-05-23 17:13:45.274 Format: (Unset) 2018-05-23 17:13:45.274 Constants (none). 2018-05-23 17:13:45.274 FTL transport 'FTLqueueout' is creating a publisher. 2018-05-23 17:13:45.292 FTL Transport 'FTLqueueout' created a publisher. 2018-05-23 17:13:45.293 Created FTL Transport 'FTLqueueout' 2018-05-23 17:13:45.293 Created TIBCO FTL transport 'FTLqueueout' 2018-05-23 17:13:45.293 Creating FTL Transport 'FTLtopic' 2018-05-23 17:13:45.293 FTL Transport Settings 2018-05-23 17:13:45.293 Topic Import Delivery Mode: NON_PERSISTENT. 2018-05-23 17:13:45.293 Queue Import Delivery Mode: NON_PERSISTENT. 2018-05-23 17:13:45.293 Endpoint: FTLtopic 2018-05-23 17:13:45.293 Import Parameters 2018-05-23 17:13:45.293 Match String: (Unset) 2018-05-23 17:13:45.293 Subscriber Name: (Unset) 2018-05-23 17:13:45.293 Export Parameters 2018-05-23 17:13:45.293 Format: (Unset) 2018-05-23 17:13:45.293 Constants (none). 2018-05-23 17:13:45.293 FTL transport 'FTLtopic' is creating a publisher. 2018-05-23 17:13:45.299 FTL Transport 'FTLtopic' created a publisher. 2018-05-23 17:13:45.299 Created FTL Transport 'FTLtopic' 2018-05-23 17:13:45.299 Created TIBCO FTL transport 'FTLtopic' 2018-05-23 17:13:45.299 Creating FTL Transport 'FTLqueuein' 2018-05-23 17:13:45.299 FTL Transport Settings 2018-05-23 17:13:45.299 Topic Import Delivery Mode: NON_PERSISTENT. 2018-05-23 17:13:45.299 Queue Import Delivery Mode: PERSISTENT. 2018-05-23 17:13:45.299 Endpoint: FTLqueuein 2018-05-23 17:13:45.299 Import Parameters 2018-05-23 17:13:45.299 Match String: (Unset) 2018-05-23 17:13:45.299 Subscriber Name: (Unset) 2018-05-23 17:13:45.299 Export Parameters 2018-05-23 17:13:45.299 Format: (Unset) 2018-05-23 17:13:45.299 Constants (none). 2018-05-23 17:13:45.299 Created FTL Transport 'FTLqueuein' 2018-05-23 17:13:45.299 Created TIBCO FTL transport 'FTLqueuein' 2018-05-23 17:13:45.308 FTL Transport 'FTLqueuein' has subscribed to queue ftlqueuein. 2018-05-23 17:13:45.308 Server is active.

!

4. Kafka Bridge Configuration Once the FTL and EMS components are configured and bridged, the TIBCO Kafka-FTL bridge can be configured. There are two connectors; source and sink. The source connector is used to publish messages to Kafka from FTL, and the sink connector will provide the ability to publish messages from Kafka to FTL. First configure and start the Kafka components.

4.1. Configure and Start Zookeeper and the Kafka Broker To use the TIBCO Kafka-FTL bridge, both Kafka Zookeeper and the Broker are required. This section will outline the steps to configure/start Zookeeper and the Broker.

● cd to $TIBCO_HOME/akd/core/1.1 ● Edit config/zookeeper.properties, if required. Take note of the Zookeeper client port. The default is

2181. ● Start Zookeeper in the background using the following command:

bin/zookeeper-server-start.sh –daemon config/zookeeper.properties ● Edit config/server.properties, if required, and set or take note of the listener(s) for the Broker

listening port. The default is 9092. ● Start the Kafka Broker in the background using the following command:

bin/kafka-server-start.sh –daemon config/server.properties ● Verify both processes are running

4.2. Configure the TIBCO-Kafka Source Connector The source connector requires two property files to be updated; $TIBCO_HOME/akd/core/1.1/config/connect-standalone.properties and $TIBCO_HOME/akd/bridge/1.0/config/tibftl-kafka-connect-source.properties.

Follow the TIBCO Messaging – Apache Kafka Distribution User’s Guide for configuring these properties files. It is recommended that copies be made of both files before editing. After updating the $TIBCO_HOME/akd/bridge/1.0/config/tibftl-kafka-connect-source.properties, copy the file to $TIBCO_HOME/akd/core/1.1/config


4.2.1. Connect-standalone Properties file Note: The tests in this document are based on the source connector being configured with the StringConverter. Ensure the converter in connect-standalone.properties is similar to the following example. It is also recommended that a non-default rest.port be added as shown below.

Figure 14 - connect-standalone.properties example

# Required list of Kafka brokers. bootstrap.servers=192.168.0.138:9092

# You MUST set this property to a directory that contains the archive file # ‘tibftl-kafka-connect-1.0.0.jar' # plugin.path=/opt/tibco/product/akd/bridge/1.0/lib

# You can combine the FTL bridge connectors with a variety of # converter classes, which determine the format for storing messages # on disk at the Kafka broker. # The following three examples configure the supported use cases. # Uncomment the configuration lines corresponding to your use case.

# Example 1: The source connector translates inbound FTL messages to # an FTL-specific JSON representation and stores the messages to disk # as JSON strings. As the source connector directly generates JSON # strings, use the built-in StringConverter to store them on disk. # Ensure that 'schemas.enable' is 'false' in the FTL source connector # properties file. # key.converter=org.apache.kafka.connect.storage.StringConverter value.converter=org.apache.kafka.connect.storage.StringConverter

# Example 2: The source connector translates inbound FTL messages to a # universal JSON message representation with schema. Attached schemas # promote interoperability with a wider variety of third-party sink # connectors. Ensure that 'schemas.enable' is 'true' in the FTL # source connector properties file. # # key.converter=org.apache.kafka.connect.json.JsonConverter # value.converter=org.apache.kafka.connect.json.JsonConverter key.converter.schemas.enable=false value.converter.schemas.enable=false

# Example 3: The source connector translates inbound FTL messages and # stores them to disk as Avro binary. Ensure that 'schemas.enable' is # 'true' in the FTL source connector properties file. Ensure also # that the TIBCO Messaging Kafka Avro client library jar is in your # CLASSPATH. Set the required parameters with the realm server # location and the schema repository location. The realm server and # schema repository must be running and reachable at those locations. # The schema repository must use the primary realm server. # # key.converter=com.tibco.messaging.kafka.avro.AvroConverter # value.converter=com.tibco.messaging.kafka.avro.AvroConverter # key.converter.ftl.realmservers = http://localhost:8080 # value.converter.ftl.realmservers = http://localhost:8080 # key.converter.schema.registry.url = http://localhost:8081/schema/v1 # value.converter.schema.registry.url = http://localhost:8081/schema/v1

# Kafka Connect must configure these required options, however, they # do not affect the behavior of the FTL bridge. For descriptions of # these options, see Apache Kafka documentation. # internal.key.converter=org.apache.kafka.connect.json.JsonConverter internal.value.converter=org.apache.kafka.connect.json.JsonConverter internal.key.converter.schemas.enable=false internal.value.converter.schemas.enable=false offset.storage.file.filename=/tmp/connect.offsets # # additional properties added rest.port=8084

http://localhost:8080


http://localhost:8081/schema/v1






!

4.2.2. TIBFTL-kafka-connect-source Properties File The tibftl-kafka-connect-source.properties properties file provides the connector information on how to connect FTL. This properties file must be updated with the appropriate Kafka topic, FTL Realm Server host and port, FTL endpoint, etc. The following example shows the values used for the tests in the next section.


# Name of this connector instance. name = tibftl-kafka-connect-source

# Required to use the source connector. Do not modify this value. connector.class = FTLSourceConnector

# The connector supports only 1 task at present, # and ignores any other value. tasks.max = 1

# Required. The source connector writes messages to # this Kafka topic. #topic = ftl-messages topic = FTL1

# Optional. # When false (the default), convert inbound FTL messages to JSON # representation without using schemas. # When true, first generate a schema corresponding to each message’s # content, then convert the FTL message to JSON representation, and # store the schema with the message. This two-pass conversion enables # broader interoperability with third-party Kafka sink connectors. # schemas.enable = true

# Required. The sink connector connects to the FTL # realm servers in this pipe-separated list. ftl.realmservers = http://192.168.0.138:8400

# Optional. The connector sends this user name credential # to the FTL realm server. # ftl.username = admin

# Optional. The connector sends this password credential # to the FTL realm server. # ftl.password = admin-pw

# Optional. FTL Realm Server trust type. # Valid values are: "file" and “everyone". # Do not use "everyone" except for convenience in development and # testing, as it is not secure. # ftl.trust.type = everyone

# FTL trust file path. # Required if 'ftl.trust.type' is set to ‘file'. # Supply a file path to the realm server's PEM-format certificate. # The connector reads the realm server's trust file from this path, # and uses that trust data in communications with the secure realm server. # ftl.trust.file = /path/to/realm-server-cert.pem

# Required. The FTL application name for this connector instance. # The connector is an FTL client application. # The FTL realm definition must configure an application definition # with this name for the connector. ftl.application.name = kafka-connect-source

# Optional. FTL application instance name. ftl.application.instance = default

# Optional. FTL client label to identify this connector # instance in FTL monitoring tools. # It is good practice to assign a unique client label # for each connector instance. # ftl.label = my-connector

# Required. FTL endpoint. # Supply the name of an endpoint in the FTL application definition. # The connector subscribes to messages from this FTL endpoint, # and sends them to the Kafka broker. #ftl.endpoint = kafka-connect-source-recvendpoint ftl.endpoint = FTLqueueout

# Optional. FTL content matcher. # The connector filters messages it receives on the ftl.endpoint # based on content. It translates and sends to the Kafka broker # only those messages that match this content matcher. # ftl.matcher = { "my-field": true }

# Optional. Debug level for the native FTL library. # Valid levels: "off", "severe", "warn", "info", "debug" and “verbose". ftl.log.level = info

http://192.168.0.138:8400

http://192.168.0.138:8400

!

Figure 15 - tibftl-kafka-connect-source.properties example

4.3. Configure the TIBCO-Kafka Sink Connector The sink connector requires two property files be updated; $TIBCO_HOME/akd/core/1.1/config/connect-standalone.properties and $TIBCO_HOME/akd/bridge/1.0/config/tibftl-kafka-connect-sink.properties. Follow the TIBCO Messaging – Apache Kafka Distribution User’s Guide for configuring these properties files. Only the tibftl-kafka-connect-sink.properties will need modification, since the connect-standalone.properties file was updated in the previous section. It is recommended that a copy be made before editing. After updating the $TIBCO_HOME/akd/bridge/1.0/config/tibftl-kafka-connect-sink.properties, copy the file to $TIBCO_HOME/akd/core/1.1/config. The tibftl-kafka-connect-sink.properties properties file provides the connector information on how to connect FTL. This properties file must be updated with the appropriate Kafka topic, FTL Realm Server host and port, FTL endpoint, etc. The following example shows the values used for for the tests in the next section.

Note: The Kafka topic must be different for the Kafka Topic used in the connect-source properties file.


# Name of this connector instance. name = tibftl-kafka-connect-sink

# Required to use the sink connector. Do not modify this value. connector.class = FTLSinkConnector

# The connector supports only 1 task at present, # and ignores any other value. tasks.max = 1

# Required. The sink connector reads messages from # the Kafka topics in this comma-separated list. topics = FTL2

# Required. The sink connector connects to the FTL # realm servers in this pipe-separated list. ftl.realmservers = http://192.168.0.138:8400

# Optional. The connector sends this user name credential # to the FTL realm server. # ftl.username = admin

# Optional. The connector sends this password credential # to the FTL realm server. # ftl.password = admin-pw

# Optional. FTL Realm Server trust type. # Valid values are: "file" and “everyone". # Do not use "everyone" except for convenience in development and # testing, as it is not secure. # ftl.trust.type = everyone

# FTL trust file path. # Required if 'ftl.trust.type' is set to ‘file'. # Supply a file path to the realm server's PEM-format certificate. # The connector reads the realm server's trust file from this path, # and uses that trust data in communications with the secure realm server. # ftl.trust.file = /path/to/realm-server-cert.pem

# Required. The FTL application name for this connector instance. # The connector is an FTL client application. # The FTL realm definition must configure an application definition # with this name for the connector. ftl.application.name = kafka-connect-sink

# Optional. FTL application instance name. # ftl.application.instance = instance-name

# Optional. FTL client label to identify this connector # instance in FTL monitoring tools. # It is good practice to assign a unique client label # for each connector instance. # ftl.label = my-connector

# Required. FTL endpoint. # Supply the name of an endpoint in the FTL application definition. # The connector reads messages from the Kafka broker # and publishes them on this FTL endpoint. #ftl.endpoint = kafka-connect-sink-sendendpoint ftl.endpoint = FTLqueuein

# Optional. Debug level for the native FTL library. # Valid levels: "off", "severe", "warn", "info", "debug" and “verbose". ftl.log.level = info

http://192.168.0.138:8400

http://192.168.0.138:8400

!

Figure 16 - tibftl-kafka-connect-sink.properties example

4.4. Starting the TIBCO-Kafka Connectors The tibftl-kafka connectors can be started separately, or together. To start the connectors:

● Ensure that copies of the tibftl-kafka-connect-source.properties and tibftl-kafka-connect-sink.properties have been copied to $TIBCO_HOME/akd/1.1/core/config.

● It is recommended to create the Kafka topic(s) before starting the connectors. In the examples above, FTL1 and FTL2 are the referenced Kafka topics, and will also be used for the testing in the next section. To create the Kafka topics, use the following. Substitute the appropriate Zookeeper host and port.

Figure 17 - Kafka Topics Creation example ● Start the tibftl-kafka source connector using the following:

cd $TIBCO_HOME/akd/core/1.1

bin/connect-standalone.sh config/connect-standalone.properties config/tibftl-kafka connect-source.properties

● Check for any errors. There will be numerous info messages, some warning messages, but there should be NO error messages.

● Start the tibftl-kafka sink connector using the following: cd $TIBCO_HOME/akd/core/1.1

bin/connect-standalone.sh config/connect-standalone.properties config/tibftl- kafka-connect-source.properties

● Check for any errors. There will be numerous info messages, some warning messages, but there should be NO error messages.

● If no errors are found, the connectors can be stopped, and restarted in the background. It is also possible to start both connectors in one process.

cd $TIBCO_HOME/akd/core/1.1 bin/connect-standalone.sh -daemon config/connect-standalone.properties config/ tibftl-kafka-connect-source.properties config/tibftl-kafka-connect-sink.properties

● Review $TIBCO_HOME/akd/core/1.1/logs/connectStandalone.out to ensure the connectors have started up properly.


cd $TIBCO_HOME/akd/core/1.1/bin ./kafka-topics.sh -zookeeper 192.168.0.138:2181 --create --topic FTL1 --replication-factor 1 --partitions 1 Created topic “FTL1". ./kafka-topics.sh -zookeeper 192.168.0.138:2181 --create --topic FTL2 --replication-factor 1 --partitions 1 Created topic "FTL2".

!

5. Testing the Kafka-FTL Bridge This section will outline simple tests of the connectors to ensure messages sent/received between Kafka and FTL, and FTL and EMS. Tests will show sending messages from EMS via FTL to Kafka, and sending message from Kafka to EMS via FTL.

Note: All of the tests shown are based in using an EMS non-persistent topic and no persistence in FTL. However, both FTL and EMS were configured to bridge persisted messages. After the following tests are performed, try testing send messages from Kafka to FTL/EMS via the FTL FTLqueue endpoint, and the EMS ftlqueuein queue.

5.1. Sending Messages from EMS In this section, EMS will send messages via FTL to Kafka. The EMS sample java application tibjmsMsgProducer, FTL sample program tibrecvex, and the Kafka kafka-connect-consumer.sh script will be used to test the bridge between the messaging components.

5.1.1. Setting Up the EMS Send Tests For these tests, the Kafka topic is FTL1, the FTL endpoint is FTLtopic, and the EMS topic is ftltopic are used.

Start the FTL receiver test program. In the following example, the FTL Realm Server is running on http://192.168.0.138:8400, the endpoint is FTLtopic, the FTL application is EMS_SERVER-GBA2, and the message count to receive is 5. cd $TIBCO_HOME/ftl/5.4/samples/bin ./tibrecvex -c 5 -e FTLtopic -a EMS-SERVER-GBA2 http://192.168.0.138:8400 # # ./tibrecvex # # TIBCO FTL Version 5.4.0 V9 # Invoked as: ./tibrecvex -c 5 -e FTLtopic -a EMS-SERVER-GBA2 http://192.168.0.138:8400 waiting for message(s)

Start the Kafka consumer script. In the following example, the Kafka Server is running on 192.168.0.138:9092, and is listening for messages on the FTL1 topic. cd $TIBCO_HOME/akd/core/1.1/bin ./kafka-console-consumer.sh --bootstrap-server 192.168.0.138:9092 --topic FTL1


http://192.168.0.138:8400

!

Finally, run the EMS sample java application, tibjmsMsgProducer to send five messages to FTL. In the following example, the EMS server is running at tcp://192.168.0.138:7222, and the topic is ftltest. cd $TIBCO_HOME/ems/8.4/samples/java . ./setup.sh java tibjmsMsgProducer -server tcp://192.168.0.138:7222 -topic ftltopic message1 message2 message3 message4 message5

------------------------------------------------------------------------ tibjmsMsgProducer SAMPLE ------------------------------------------------------------------------ Server....................... tcp://192.168.0.138:7222 User......................... (null) Destination.................. ftltopic Send Asynchronously.......... false Message Text................. message1 message2 message3 message4 message5 ------------------------------------------------------------------------

Publishing to destination 'ftltopic'

Published message: message1 Published message: message2 Published message: message3 Published message: message4 Published message: message5

5.1.2. Expected Results After the TIBCO EMS publisher has sent the five messages, both the TIBCO FTL receiver program and the Kafka consumer script should receive the five messages. The output should be similar to the following. If FTL does not receive the messages, Kafka will not. Check the EMS and FTL bridge configuration. If FTL receives the messages, but Kafka does not, check the connector properties for problems.


!

FTL:

Figure 18 - FTL Output from EMS Send example


# ./tibrecvex # # TIBCO FTL Version 5.4.0 V9 # Invoked as: ./tibrecvex -c 5 -e FTLtopic -a EMS-SERVER-GBA2 http://192.168.0.138:8400 waiting for message(s) received message 1 message: {string:_text="message1", long:_emshdr:JMSDeliveryMode=2, long:_emshdr:JMSPriority=4, string:_emshdr:JMSMessageID="ID:EMS-SERVER-GBA2.BCF5AF9BC2BE:1", long:_emshdr:JMSTimestamp=1526413251321, long:_emshdr:JMSDeliveryTime=1526413251321, string:_emshdr:JMSDestination="TOPIC:ftltopic"} received message 2 message: {string:_text="message2", long:_emshdr:JMSDeliveryMode=2, long:_emshdr:JMSPriority=4, string:_emshdr:JMSMessageID="ID:EMS-SERVER-GBA2.BCF5AF9BC2BE:2", long:_emshdr:JMSTimestamp=1526413251321, long:_emshdr:JMSDeliveryTime=1526413251321, string:_emshdr:JMSDestination="TOPIC:ftltopic"} received message 3 message: {string:_text="message3", long:_emshdr:JMSDeliveryMode=2, long:_emshdr:JMSPriority=4, string:_emshdr:JMSMessageID="ID:EMS-SERVER-GBA2.BCF5AF9BC2BE:3", long:_emshdr:JMSTimestamp=1526413251322, long:_emshdr:JMSDeliveryTime=1526413251322, string:_emshdr:JMSDestination="TOPIC:ftltopic"} received message 4 message: {string:_text="message4", long:_emshdr:JMSDeliveryMode=2, long:_emshdr:JMSPriority=4, string:_emshdr:JMSMessageID="ID:EMS-SERVER-GBA2.BCF5AF9BC2BE:4", long:_emshdr:JMSTimestamp=1526413251322, long:_emshdr:JMSDeliveryTime=1526413251322, string:_emshdr:JMSDestination="TOPIC:ftltopic"} received message 5 message: {string:_text="message5", long:_emshdr:JMSDeliveryMode=2, long:_emshdr:JMSPriority=4, string:_emshdr:JMSMessageID="ID:EMS-SERVER-GBA2.BCF5AF9BC2BE:5", long:_emshdr:JMSTimestamp=1526413251322, long:_emshdr:JMSDeliveryTime=1526413251322, string:_emshdr:JMSDestination="TOPIC:ftltopic"}

!

Kafka:

Figure 19 - Kafka Output from EMS Send example

5.2. Sending Messages from Kafka Now that sending messages from EMS via FTL to Kafka, has been tested, messages sent from Kafka to EMS can be tested. The Kafka kafka-console-producer.sh script, FTL sample program tibrecvex, and the EMS sample java application tibjmsMsgConsumer will be used to test the bridge between the messaging components.

5.2.1. Setting Up the Kafka Send Tests

For these tests, the Kafka topic is FTL2, the FTL endpoint is FTLtopic, and the EMS topic is ftltopic will be used.

Start the FTL receiver test program. In the following example, the FTL Realm Server is running on http://192.168.0.138:8400, the endpoint is FTL1, the FTL application is EMS_SERVER-GBA2, and the message count to receive is 5. cd $TIBCO_HOME/ftl/5.4/samples/bin ./tibrecvex -c 5 -e FTLtopic -a EMS-SERVER-GBA2 http://192.168.0.138:8400 # # ./tibrecvex # # TIBCO FTL Version 5.4.0 V9 # Invoked as: ./tibrecvex -c 5 -e FTLtopic -a EMS-SERVER-GBA2 http://192.168.0.138:8400 waiting for message(s)


[tibco@gba2 bin]$ ./kafka-console-consumer.sh --bootstrap-server 192.168.0.138:9092 --topic FTL1 {"_text":"message1","_emshdr:JMSDeliveryMode":2,"_emshdr:JMSPriority":4,"_emshdr:JMSMessageID":"ID:EMS-SERVER-GBA2.BCF5AF9BC2BE:1","_emshdr:JMSTimestamp":1526413251321,"_emshdr:JMSDeliveryTime":1526413251321,"_emshdr:JMSDestination":"TOPIC:ftltopic"} {"_text":"message2","_emshdr:JMSDeliveryMode":2,"_emshdr:JMSPriority":4,"_emshdr:JMSMessageID":"ID:EMS-SERVER-GBA2.BCF5AF9BC2BE:2","_emshdr:JMSTimestamp":1526413251321,"_emshdr:JMSDeliveryTime":1526413251321,"_emshdr:JMSDestination":"TOPIC:ftltopic"} {"_text":"message3","_emshdr:JMSDeliveryMode":2,"_emshdr:JMSPriority":4,"_emshdr:JMSMessageID":"ID:EMS-SERVER-GBA2.BCF5AF9BC2BE:3","_emshdr:JMSTimestamp":1526413251322,"_emshdr:JMSDeliveryTime":1526413251322,"_emshdr:JMSDestination":"TOPIC:ftltopic"} {"_text":"message4","_emshdr:JMSDeliveryMode":2,"_emshdr:JMSPriority":4,"_emshdr:JMSMessageID":"ID:EMS-SERVER-GBA2.BCF5AF9BC2BE:4","_emshdr:JMSTimestamp":1526413251322,"_emshdr:JMSDeliveryTime":1526413251322,"_emshdr:JMSDestination":"TOPIC:ftltopic"} {"_text":"message5","_emshdr:JMSDeliveryMode":2,"_emshdr:JMSPriority":4,"_emshdr:JMSMessageID":"ID:EMS-SERVER-GBA2.BCF5AF9BC2BE:5","_emshdr:JMSTimestamp":1526413251322,"_emshdr:JMSDeliveryTime":1526413251322,"_emshdr:JMSDestination":"TOPIC:ftltopic"}

http://192.168.0.138:8400

!

Start the EMS consumer java application. In the following example, the EMS server is running at tcp://192.168.0.138:7222, and the topic is ftltest. cd $TIBCO_HOME/ems/8.4/samples/java . ./setup.sh java tibjmsMsgConsumer -server tcp://192.168.0.138:7222 -topic ftltopic

------------------------------------------------------------------------ tibjmsMsgConsumer SAMPLE ------------------------------------------------------------------------ Server....................... tcp://192.168.0.138:7222 User......................... (null) Destination.................. ftltopic ------------------------------------------------------------------------

Subscribing to destination: ftltopic

Finally, run the Kafka producer script, kafka-console-producer.sh, and send five messages. In the following example, the Kafka Server is running on 192.168.0.138:9092, and is sending messages on the FTL2 topic. cd $TIBCO_HOME/akd/core/1.1/bin ./kafka-console-producer.sh --broker-list 192.168.0.138:9092 --topic FTL2 >{"text":"message1"} >{"text":"message2"} >{"text":"message3"} >{"text":"message4"} >{"text":"message5"}

5.2.2. Expected Results After the Kafka publisher script has been used to send five messages {“text”:”message”}, both the TIBCO FTL receiver program and the TIBCO EMS consumer java application should receive the five messages. The output should be similar to the following. If FTL does not receive the messages, EMS will not. Check the connector properties for problems. If FTL receives the messages, but EMS does not, check the EMS and FTL bridge configuration.

FTL:

Figure 20 - FTL Output from Kafka Send example


# # ./tibrecvex # # TIBCO FTL Version 5.4.0 V9 # Invoked as: ./tibrecvex -c 5 -e FTLtopic -a EMS-SERVER-GBA2 http://192.168.0.138:8400 waiting for message(s) received message 1 message: {string:text="message1"} received message 2 message: {string:text="message2"} received message 3 message: {string:text="message3"} received message 4 message: {string:text="message4"} received message 5 message: {string:text="message5"}

!

EMS:

Figure 21 - EMS Output from Kafka Send example


java tibjmsMsgConsumer -server tcp://192.168.0.138:7222 -topic ftltopic

------------------------------------------------------------------------ tibjmsMsgConsumer SAMPLE ------------------------------------------------------------------------ Server....................... tcp://192.168.0.138:7222 User......................... (null) Destination.................. ftltopic ------------------------------------------------------------------------

Subscribing to destination: ftltopic

Received message: MapMessage={ Header={ JMSMessageID={null} JMSDestination={Topic[ftltopic]} JMSReplyTo={null} JMSDeliveryMode={NON_PERSISTENT} JMSRedelivered={false} JMSCorrelationID={null} JMSType={null} JMSTimestamp={Tue May 15 15:23:20 CDT 2018} JMSDeliveryTime={Tue May 15 15:23:20 CDT 2018} JMSExpiration={0} JMSPriority={4} } Properties={ JMSXDeliveryCount={Integer:1} JMS_TIBCO_IMPORTED={Boolean:true} JMS_TIBCO_MSG_EXT={Boolean:true} } Fields={ text={String:message1} } } Received message: MapMessage={ Header={ JMSMessageID={null} JMSDestination={Topic[ftltopic]} JMSReplyTo={null} JMSDeliveryMode={NON_PERSISTENT} JMSRedelivered={false} JMSCorrelationID={null} JMSType={null} JMSTimestamp={Tue May 15 15:23:43 CDT 2018} JMSDeliveryTime={Tue May 15 15:23:43 CDT 2018} JMSExpiration={0} JMSPriority={4} } Properties={ JMSXDeliveryCount={Integer:1} JMS_TIBCO_IMPORTED={Boolean:true} JMS_TIBCO_MSG_EXT={Boolean:true} } Fields={ text={String:message2} } } Received message: MapMessage={ Header={ JMSMessageID={null} JMSDestination={Topic[ftltopic]} JMSReplyTo={null} JMSDeliveryMode={NON_PERSISTENT} JMSRedelivered={false} JMSCorrelationID={null} JMSType={null} JMSTimestamp={Tue May 15 15:23:54 CDT 2018} JMSDeliveryTime={Tue May 15 15:23:54 CDT 2018} JMSExpiration={0} JMSPriority={4} } Properties={ JMSXDeliveryCount={Integer:1} JMS_TIBCO_IMPORTED={Boolean:true} JMS_TIBCO_MSG_EXT={Boolean:true} } Fields={ text={String:message3} } } Received message: MapMessage={ Header={ JMSMessageID={null} JMSDestination={Topic[ftltopic]} JMSReplyTo={null} JMSDeliveryMode={NON_PERSISTENT} JMSRedelivered={false} JMSCorrelationID={null} JMSType={null} JMSTimestamp={Tue May 15 15:24:03 CDT 2018} JMSDeliveryTime={Tue May 15 15:24:03 CDT 2018} JMSExpiration={0} JMSPriority={4} } Properties={ JMSXDeliveryCount={Integer:1} JMS_TIBCO_IMPORTED={Boolean:true} JMS_TIBCO_MSG_EXT={Boolean:true} } Fields={ text={String:message4} } } Received message: MapMessage={ Header={ JMSMessageID={null} JMSDestination={Topic[ftltopic]} JMSReplyTo={null} JMSDeliveryMode={NON_PERSISTENT} JMSRedelivered={false} JMSCorrelationID={null} JMSType={null} JMSTimestamp={Tue May 15 15:24:14 CDT 2018} JMSDeliveryTime={Tue May 15 15:24:14 CDT 2018} JMSExpiration={0} JMSPriority={4} } Properties={ JMSXDeliveryCount={Integer:1} JMS_TIBCO_IMPORTED={Boolean:true} JMS_TIBCO_MSG_EXT={Boolean:true} } Fields={ text={String:message5} } }

bridging apache kafka to tibco ems · 1. overview 1.1. document purpose with the release of tibco®...

Documents