Tibco Rendezvous Transport User Guide

The rendezvous transport may be configured following its schemaand the release may be downloaded here

Configuring the connector

A typical mule config for the connector would look as follows:

<tibcorv:connector name="main" service="2222" network="172.33.33.0" daemon="tcp:127.0.0.1:2222"/>

The configuration may include -

Property	Description	Default	Required*
service	tibrv service parameter		no
network	tibrv network parameter		no
daemon	tibrv daemon parameter		no
defaultWorkerWeight	available workers with higher weights will be assigned tasks first	1	no
defaultWorkerTasks	number of tasks to be assigned per worker	1	no
defaultSchedulerWeight	Higher weights increase likelyhood of being selected as the scheduler	1	no
defaultSchedulerHeartbeat	Frequency that heartbeats will be sent to members in a distributed queue	1.0	no
defaultSchedulerActivation	Duration members in distributed queue will wait before choosing a new scheduler	3.5	no

* Proper combination of service/network/daemon required to communicate with an RVD

Specifying endpoints

Inbound and outbound endpoints may be specified with:

<tibcorv:inbound-endpoint subject="test.*.b.c"/>
<tibcorv:inbound-endpoint subject="test.d.%3E"/>
<tibcorv:outbound-endpoint subject="test.cool"/>

Note that the wildcard ">" must be url escaped to %3E

Certified Messaging and Distributed Queues

Certified Messaging is supported both inbound and outbound, simply specify a cmname:

<tibcorv:outbound-endpoint subject="test.cool" cmname="ImCertifiable"/>
<tibcorv:inbound-endpoint subject="test.cool" cmname="DQueueName"/>

By default inbound endpoints with a cmname will be configured as members of a distributed queue. Multiple inbound endpoints with the same cmname will have messages distributed between them according to the parameters specified on the connector.

Variable Substitution in Outbound Endpoints

The variable substituion used in the 1.4.x implementation has been replaced using awesome mule expressions! You can use them to send to dynamically created outbout endpoints

 <tibcorv:outbound-endpoint subject="test.#[header:someMessageProperty]"

Data Handling

By default the inbound transformer TibrvMsgToMap will transform tibco specific types into their java equivalent and preserve the mapping in the TibrvMsg. Service components receive a Map as their input. Additionally the following values are added to the map:

Send subject with the key TibrvConnect.SEND_SUBJECT
Reply subject with the key TibrvConnect.REPLY_SUBJECT

The default outbound transformer ObjectToTibrvMsg will vary in behavior depending on input type. It would either:

Preserve TibrvMsgs passed into it
Create a TibrvMsg from a map. Mappings will be preservered in the TibrvMsg, the keys will be convereted to strings, and the values will be mapped to Tibrv appropriate types
Other objects will be inserted into a TibrvMsg with the key TibrvConnector.CONTENT_FIELD ("content")