Message Translation: TIBCO eFTL and TIBCO EMS

TIBCO eFTL software and TIBCO Enterprise Message Service software differ in the form of messages and in their subscription paradigm. To account for these differences, the eFTL server translates messages as they pass through its EMS side. These differences can affect developers of eFTL applications.

Content Matchers, Topic Names, and the _dest Field

TIBCO Enterprise Message Service software delivers messages based on topic names: publishers send each message to a specific topic, and subscribers receive the messages sent to a topic.

In contrast, TIBCO eFTL software delivers messages based on the content of named fields: a subscriber specifies a content matcher, and receives messages with matching fields and values.

To resolve this difference, the eFTL server translates according to the following table.

Translation
When an EMS channel forwards an EMS message into the eFTL side, it sets the _dest field of the eFTL message to the topic name of the EMS message.
When an eFTL client creates a subscription with a content matcher that matches against the _dest field, the EMS channel creates an EMS subscription to the corresponding topic.

EMS subscriptions can use the asterisk (*) and greater than (>) characters as wildcard elements. If an eFTL subscriber includes these elements in a content matcher, they become part of the EMS subscription, and the EMS server interprets them correctly.

When an EMS channel forwards an eFTL message into the EMS side, and the message contains a _dest field, the channel publishes the EMS message to the topic corresponding to value of the _dest field.
When an EMS channel attempts to forward an eFTL message into the EMS side, but the message does not contain a _dest field, or its _dest value is not a valid topic name, the channel discards the message, and does not publish it into the EMS side. The eFTL publisher receives an error callback.

Translation from the EMS Side into the eFTL Side

The eFTL server translates JMS message types according to the following body type table.

JMS Body Type Translation
Message Translates to an empty eFTL message: that is, its only field is _dest.
TextMessage The _text field contains the text string data.
MapMessage Fields and their values translate according to the following field type table.
Any other body type. The eFTL server discards messages with any other JMS body type.

The eFTL server translates JMS fields according to the following field type table.

JMS Field Type Translation
char, byte, int, long long
float double
char* string
Array of fixed point numbers Array of long
Array of floating point numbers Array of double
bytes The eFTL server discards byte array fields, omitting them from the translated message.

Translation from the eFTL Side into the EMS Side

All eFTL messages translate into EMS map messages. The eFTL server translates eFTL fields according to the following field type table.

EMS administrators do not configure translation in the EMS server.

eFTL Field Type Translation
long tibems_long
double tibems_double
string char*
long[] Array of tibems_long
double[] Array of tibems_double
message MapMessage
datetime A DateTime field translates into a nested MapMessage with two fields:
  • s represents whole seconds in a signed 64-bit integer. Zero denotes the UNIX epoch: midnight entering January 1, 1970, UTC.
  • n represents nanoseconds after the time that the s field denotes. Although the data structure stores this value in a signed 64-bit integer, this component is always non-negative, between zero and 999,999,999 (inclusive).

The EMS field name is the prefix _dateTime: concatenated with the FTL field name.

Array of string values A field containing an array of these types translates into a nested MapMessage.

The EMS field name is the prefix _stringArray: concatenated with the FTL field name.

The fields of the nested MapMessage contain the values of the array, and each field name is a string that denotes the corresponding array index: for example, 0, 1, 2, 3, and so on.

Array of message values A field containing an array of these types translates into a nested MapMessage.

The EMS field name is the prefix _msgArray: concatenated with the FTL field name.

The fields of the nested MapMessage contain the values of the array, and each field name is a string that denotes the corresponding array index: for example, 0, 1, 2, 3, and so on.

Array of datetime values A field containing an array of these types translates into a nested MapMessage.

The EMS field name is the prefix _dateTimeArray: concatenated with the FTL field name.

The fields of the nested MapMessage contain the values of the array, and each field name is a string that denotes the corresponding array index: for example, 0, 1, 2, 3, and so on.