Tibco Rendezvous Transport User Guide

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

Configuring the connector

Using the default distributed queue parameters, a typical mule config for the connector would look as follows:

<connector name="rvdConnector" className="org.mule.providers.tibrv.TibrvConnector">
    <properties>
      <property name="service" value="12345"/>
      <property name="daemon" value="tcp:123.456.123.456:1234"/>
      <property name="network" value="ross.theOtherOne.net"/>
    </properties>
  </connector>

Specifying endpoints

Inbound and outbound endpoints may be specified with:

<endpoint address="tibrv://plan.ole.subject" />

Certified Messaging and Distributed Queues

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

 <endpoint address="tibrv://subject.with.certified.messaging?cmname=foo" />

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

Users may specify variables on outbound endpoints which will be substituted with values in the message's properties. Properties should be deliminated with "$"

 <endpoint address="tibrv://the.next.word.is.a.variable.$KEY_NAME$?cmname=$ANOTHER_KEY$

Data Handling

By default the inbound transformer TibrvMsgToMap will transform tibco specific types into their java equivalent and preserve the mapping in the TibrvMsg. UMOs would receive a Map as their input. 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")