Thomson Reuters SFC External Adapter

The StreamBase section of the configuration file begins with the tag streambase. It contains three parameters. The first parameter is uri, which specifies the URI of the server. The default value is sb://localhost:10000. When using an adapter from StreamBase Studio, it can be convenient to set the value of the uri parameter to ${STREAMBASE_SERVER}. This will cause the adapter to use the STREAMBASE_SERVER environment variable for the URI. This variable is set by StreamBase Studio to point to the StreamBase Server instance where the application is running.

The second parameter is buffer-size. This parameter specifies how many inputs the StreamBase should buffer. A buffer-size of 0 will lead to slightly lower latency, at the expense of throughput. The third parameter is flush-interval. Flush interval specifies the maximum number of milliseconds that a value will sit in the buffer waiting to be delivered. Flush interval is an upper bound on the amount of latency introduced by buffering. Setting a very low flush interval will also lead to low latency at the expense of throughput. For minimal latency it is best to set a buffer-size of zero, rather than setting flush-interval to zero.

The Reuters section of the configuration file, rooted at the sfc tag, varies based on what sort of infrastructure you are using. There are a few parameters common to all kinds of infrastructure. First is the service parameter. This parameter specifies the name of the Reuters service to which the adapter will be connecting. Common Reuters service names are things like IDN_RDF and IDN_SELECTFEED. Another common configuration parameter is username. The username is passed to the DACS server, for permissions and entitlements tracking. Another DACS parameter is app-id, the application identifier, which is also passed to the DACS server and used for entitlement tracking. Finally there are the subscription parameters. For each subscription there is an entity beginning with the tag subscription. Attributes of this entity are item and handler. The item attribute specifies the Reuters item to subscribe to. This is usually a stock ticker, followed by a period, followed by a market identifier, such as IBM.N. The handler attribute specifies which input handler to use for this item. Input handlers are specified in the Adapter Section below.

This section describes the connection parameters for Reuters multicast market data systems. This includes the RMDS RTIC server, as well as the Classic TIC server. These two components are similar in that they distribute market data to clients over a multicast data bus. This multicast bus is usually, although not always, a TIBCO Rendezvous bus. The Thomson Reuters SFC adapter only supports the TIBCO Rendezvous bus.

The first parameter to specify is the infrastructure parameter. Specify a value of RMDS or TIC for this parameter. Both values enable multicast connections, but the value TIC will disable some DACS related code. The next parameter to specify is sass-version. Specify either sass2 or sass3, based on what data encoding is used in your market data system. If you are unsure, sass3 is probably the correct answer.

Next, specify the Rendezvous connection parameters. There are three parameters: service-port, network, and daemon. The service-port parameter is the numeric, or sometimes symbolic, name for the port on the multicast bus being used by the market data system.

The network parameter is a specification for the multicast bus in use. It can be broken down into three components all of them optional. The first component is the name of the network interface to use. The next component is the multicast group to join. The final component is the multicast group on which to publish. The three components are separated by semicolons in the specification. For example, "eth0;224.1.1.70;224.1.1.71" specifies all three components. To listen to more than one multicast group, separate groups with commas, as in "eth0;224.1.1.70,224.1.1.80;224.1.1.71". When no interface is specified, the interface corresponding to the IP address of the host name of the machine is used. Thus a specification such as ";224.1.1.70" could be sufficient for a machine with only one network interface. However, on Linux machines, often the IP address of the host name of the machine is set to 127.0.0.1 which will lead to using the lo (loopback) interface, which is generally not desired behavior. To listen to just the local broadcast domain rather than using multicast, specify only the interface, or leave this parameter blank to use the default interface.

The daemon parameter specifies where the Rendezvous daemon, rvd, is found on the network. A common configuration is for each host to run its own rvd. For this configuration simply leave the parameter blank. In other situations the daemon may be running on another host somewhere else on the network. In this case the host name and port number must be specified using the following format:

"tcp:hostname:port"

For example, "tcp:10.2.1.64:7500".

The Thomson Reuters SFC adapter also supports unicast connection to Reuters infrastructure, using the Source/Sink Library or SSL. This includes connections to the RMDS P2PS server as well as the Triarch sink_dist server. Connections to these servers are made over simple TCP connections with no multicast buses involved.

There are four parameters required for a unicast connection. The first parameter ssl-server, specifies the host name or IP address of the server to connect to. The next parameter, ssl-port, specifies the port number to use. The default value of 8101 is correct for most installations. The final two parameters, ssl-fid-db and ssl-enum-type, specify the filenames for the FID database. These files are traditionally named appendix_a and enumtype.def, respectively. By default they are searched for in several common locations, including the current directory.

The adapter section of the configuration file specifies input handlers. Each input handler has a name, a type, and a set of parameters. The name is used to reference it in the subscription section of the configuration file as well as for logging. The type is one of two built-in feed and other types, fat-tuple and meta-tuple.

The fat-tuple handler assumes that tuples will be wide and each tuple will contain all of the relevant fields. The parameters for the fat tuple handler are input-stream, item-field, resend-images, and stale-field. The input-stream is the stream to which data will be enqueued. The item-field specifies a field in the stream by name that will be populated with the name of the item for each value enqueued. resend-images is either true or false and indicates whether subscribing to an already-subscribed-to item results in an initial image being re-sent to input-stream. The message-type-field is optional and specifies the name of a string field in the stream that will be populated with one of the following values to indicate the type of Reuters message received: IMAGE, UPDATE, STALE, NOT_STALE, INFO, or INACTIVE. The active-field is optional and specifies the name of a boolean field in the stream that will be populated with true if the item is active and false otherwise. The stale-field is optional and specifies the name of a boolean field in the stream that will be populated with true if the item is stale and false otherwise.

The state-text-field is optional and specifies the name of a string field in the stream that will be populated with a description of the item's state.

The meta-tuple handler, also known as the thin tuple handler, uses a different representation for market data on a stream. In this representation each modified data field in a given item gets its own tuple on the stream. For this handler one must specify the stream and a variety of fields. Each field is specified by name and must exist and be of the correct type on the specified input stream. The item-field contains the Reuters item name for the data. The name-field contains the name of the change field. The type-field contains a string representation of the type of the changed data. The rest of the fields (int-field, double-field, string-field, timestamp-field) are used to contain the value of the change field. Only one of these is used for a given change record. The message-type-field is optional and specifies the name of a string field in the stream that will be populated with one of the following values to indicate the type of Reuters message received: IMAGE, UPDATE, STALE, NOT_STALE, INFO, or INACTIVE.

The active-field is optional and specifies the name of a boolean field in the stream that will be populated with true if the item is active and false otherwise. The stale-field is optional and specifies the name of a boolean field in the stream that will be populated with true if the item is stale and false otherwise. The state-text-field is optional and specifies the name of a string field in the stream that will be populated with a description of the item's state. The enumeration-type parameter, whose value is either string or int. This parameter specifies what type enumeration fields in the input data should be interpreted as. Lastly, there are optional parameters for inseparable fields. Inseparable fields are fields that are expected to be in every market data message, and will be replicated onto every tuple produced by the handler for that message. For example, exchange or trade time might be treated this way. These fields must appear in the input schema with the same name as in the market feed. Fields to be treated this way are specified by name with a series of parameters, inseparable-field.0, inseparable-field.1, and so on.

The last section of the configuration file begins with the tag dynamic. This section of the configuration file specifies parameters for the dynamic subscription features. These features allow the StreamBase application to control what kind of messages it receives from the adapter. There are three kinds of dynamic control: Subscribe, Unsubscribe and Timeseries.

This subsection begins with a subscribe tag. There is one required attribute, name, which is used for logging purposes. There can be zero, one, or multiple instances of this section, for multiple subscribe streams. An application controls the adapter by outputting a stream of new subscriptions. This output stream contains the name of the item to subscribe to and the name of the handler to use for the new subscription. The stream parameter specifies the name of the output stream for the adapter to subscribe to. The item-field parameter specifies the field in that output stream, by name, to use for the item. The handler-field parameter specifies the field to use for the handler name.

This subsection begins with a unsubscribe tag. There is one required attribute, name, which is used for logging purposes. There can be zero, one, or multiple instances of this section, for multiple unsubscribe streams. An application controls the adapter by outputting a stream of tuples that describe items and handlers to unsubscribe. The stream parameter specifies the name of the output stream for the adapter to listen for unsubscriptions on. The item-field parameter specifies the field in that output stream, by name, to use for the item. The handler-field parameter specifies the field to use for the handler name.

The Timeseries Data Request section begins with a timeseries tag. There is one required attribute, name, which is used for logging purposes. The Timeseries Request feature allows the application to request a sequence of Reuters TS1 data. There are two parameters in this section. The parameter request-stream specifies the stream by name on which Timeseries Requests will be received. The parameters response-stream specifies the stream by name to which responses will be enqueued. Requests are handled asynchronously and responses are delivered in the order in which they become available, ordering of requests is not preserved. Within a response, entries will be in time order.

Requests must follow a strict schema, and responses also follow a strict schema. The request schema is:

Granularity should be one of the support TS1 granularities: "tick", "daily", "calendar", "weekly", "monthly", "quarterly", "yearly", or "daily-open". The specific meaning of these granularities, and which ones are supported, is determined by your TS1 infrastructure.

The response stream schema must match the following schema: