TIBCO Cloud™ Integration applications can use the Cloud FTL palette to send and receive messages. The messaging capability is powered by TIBCO FTL and comes pre-configured for all users. 
The cloud FTL palette is an OOTB solution to provide access to fast messaging service. With this option, the user does not require to have a subscription for TCM (Tibco Cloud Messaging). 

Please refer the below documentation for getting access to BW FTL plugin:
https://integration.cloud.tibco.com/docs/bw/GUID-91CEFCE8-6EC1-46D3-995A-2883BB6CAE11.html

Refer to the TIBCO FTL Concepts manual to understand general FTL concepts.
https://docs.tibco.com/pub/ftl/6.4.0/doc/html/GUID-C0EBAF36-A682-445D-B3EE-8E683330BE07-homepage.html
 

TIBCO Cloud Integration

There are 3 message format types available for each FTL plugin activity (Custom, Keyed-Opaque & Opaque). The user needs to choose the correct option as per his business requirement.

1) Keyed-Opaque:
When applications require efficient opaque messages and also require content matching, you can use the keyed opaque built-in format. Keyed opaque messages are optimized: though less efficient than the opaque built-in format, they are more efficient than an equivalent managed format. Applications can use content matchers to match against the key field.

2) Opaque:
Applications can use the built-in opaque format to exchange messages that contain unstructured data. Opaque messages are very efficient and can achieve very low-latency performance. Opaque messages are an excellent choice for streaming data. Content matchers cannot select opaque messages

3) Custom:  Can be defined by using the Input Editor. The Input Editor is enabled only for the Custom format option.

[NOTE: We're going to use the 'Custom' message format for our use-case. With this message format, the user gets control over message structure and one can define their own message schema.]

A. Pub/Sub Scenario:
In this integration type scenario, you can use publisher and subscriber activity in your implementation to send and receive the messages. You need to create a schema structure for your message that you want to publish and mapped the same into the input editor of 'CloudFTLPublisher' activity.

On subscriber you need to specify the content matcher, a content matcher selects a subset of messages from a message stream according to the fields and values in those messages. The syntax for example is, {"My-Long":123}.

Ex.1. Simple Message type:
Consider, you want to publish and subscribe to the below message using cloud FTL plugin in your implementation.

 { "ID": "string",    "primitive": "string" }

For publisher activity, you can create a simple schema quickly using a schema editor. And at the subscriber side, you can use content matcher {"ID": "string"} to select the messages that you want to pick from the stream. You need to understand that Subscriber will only pick those messages which match the content matcher defined.

Ex.2. Complex Message type:
In the above example we used a quite simple message structure, but in the real-time scenario will not have such a simple structure to publish and subscribe to the message. And if your message structure becomes complex then the subscriber will not work with the content matcher as above.

Let's take a same example with complex type element.

{ "elements": { "ID": "string",    "primitive": "string" } }

If you've requirement to publish elements data which again has two simple type elements, then, in this case, the {"ID": "string"} will not work and you'll not receive any published messages from the stream. Also, you'll not receive any error too, this will make things more difficult to identify the problem.

One can think to use below content matchers for subscriber:

{"elements": { "ID": "string"}} 
 OR
{"elements": { }}

These are not valid content matchers in FTL concepts and the BusinessWorks application will run into the error state.

[NOTE: The 'content-matcher' always works on the top level elements and it will not look for inner elements in the message structure. This is as per the FTL architecture.]

To overcome this situation, you need to modify your message schema and need to add an element at the top level which can be further used as a content-matcher in processing.

Ex. 
{ "matcher": "string",    "elements": { "ID": "string",     "primitive": "string" } }

This way you can use the 'matcher' element as content-matcher in implementation and it will not affect anything in implementation.

Please refer to the attached application [Cloud-FTL-PubSub-POC.zip] for more details about the implementation.

[NOTE: You can not test the cloud FTL palette at design-time and PUB and SUB activities need to be implemented in separate applications.]


B. Request/Reply Scenario:

In this scenario, we are going to use the CloudFTLRequestReply activity for sending a request message and on the Responder side, we're using 'CloudFTLSubscriber' and 'CloudFTLReply' activity. 

This is a similar implementation that we discussed in Ex.1. of Pub/Sub application. Here we are going to implement a ReST service which will get a request from the client for the particular type of 'message' and if that type is matching to the content-matcher that we defined in the 'Subscriber' activity, then the client will receive a response from the ReST service.

Please refer to the attached POC [FTLReqReply-ContentMatcher.zip] for more details of implementation.

TIBCO Cloud™ Integration applications can use the Cloud FTL palette to send and receive messages. The messaging capability is powered by TIBCO FTL and comes pre-configured for all users. 

TCI Cloud FTL: https://integration.cloud.tibco.com/docs/bw/GUID-91CEFCE8-6EC1-46D3-995A-2883BB6CAE11.html

TIBCO FTL Concepts: https://docs.tibco.com/pub/ftl/6.4.0/doc/html/GUID-C0EBAF36-A682-445D-B3EE-8E683330BE07-homepage.html