An Overview of the Refinitiv Robust Foundation API - Java/C++

Whilst Refinitiv offers several current APIs and SDKs for working with Real-Time streaming data - many of our users have a considerable deployment of applications developed using our legacy APIs.

For many if not most of these applications, the original developers have moved on and the maintenance of these applications is the responsibility of someone who may have never coded with the underlying API or SDK.

For these applications, there will come a time, where the current maintainers will be asked to rewrite/migrate these legacy API applications to a current Refinitiv API. Based on my experience of working with our users, this is often a cause of considerable anxiety for the developer - particularly if they have never used the legacy APIs and are suddenly faced with the task of learning two APIs - the legacy one and the newer alternative.

However, I have usually found the developer does not need to learn the legacy API in much detail. When helping developers in this situation, I find the following is usually sufficient to enable them to understand the legacy application code enough to migrate it to the newer API.

1. Initially, a high-level overview outlining the key features of the legacy API helps the developer put things into context and gain a reasonable understanding of what the application is doing. 
   
2. I then follow this up with a walkthrough of key code snippets of an example application or their own codebase - highlighting key items such as configuration, initialisation, item subscription and so on.

In this document, I will attempt to document step 1 of the above. Whilst much of this information can be gleaned from the API's existing documentation, the information below would typically be spread out across several sections and/or documents.

Where it makes sense/is deemed necessary I will also provide an additional set of Migration Notes e.g. 'RFA to EMA Migration Notes' which would include what I typically cover in step 2 (and more). Links to any such notes will be added in the right-hand sidebar.

RFA C++ / JAVA API

Introduction

Refinitiv Robust Foundation API (RFA) is a high-performance data-neutral, thread-aware API for the Consumption, Publishing and Contribution of real-time streaming data from/to a Refinitiv Real-Time Distribution System (RTDS - formerly known as TREP) and offers low latency, high throughput data delivery (when using the OMM interface).

The most recent versions of RFA use the Open Message Model (OMM) to allow rich hierarchical data types including full order book support, whilst older versions of RFA use the Legacy MarketFeed based format which can only model flat field-value pair records.

As a Feature complete API, whilst RFA supports recent compilers/IDEs/Operating systems – it does not contain features available in our newer strategic APIs, such as Cloud connectivity or support for newer RTDS functionality.

Languages Supported

C++, Java (and .NET wrapper) versions are available

Features

Key features/functionality of RFA are summarised below

Configuration

Uses a Configuration database that can be populated

·         programmatically

·         from a flat-file

·         from Windows Registry (C++ Windows version)

·         from an XML file (Java version - using Java Preferences API)

Configuration classes allow the reading of config data to be used within an RFA application. Configuration values fall into two main categories

·         API configuration – Transport and API level (e.g. connection type, hostname, threading, retry, queue)

·         Application configuration – Application related (e.g. RIC codes, username, runtime parameters)

The RFA Java version supports the use of System and User trees for storing Common and User-specific config values respectively.

Event model

RFA uses an asynchronous event mechanism – which requires the developer to register and implement event-based clients to handle events. Depending on the version of RFA the type of events varies e.g.

For the legacy MarketData (MarketFeed) interface, the developer must process event types such as:

·         Market Data Item - data + status events

·         Connection - e.g. connection up/down)

·         Service - identify which services are available

·         Dictionary - dictionary availability/download

·         Entitlement / Authentication

For the current OMM based interface, the developer processes event types including:

·         Connection state

·         Item – which encapsulates a message containing data, status and acknowledgements

·         Command Errors – e.g. invalid command submitted

·         API Logging

Data request and response

For the legacy MarketData based interface, writing a basic subscriber typically involves several steps including:

·         Loading Configuration

·         Creating an Event Queue, Market Data Subscriber

·         Implementing a Market Data Client, Logger client etc

·         Loading the Data Dictionary

·         Creating a Market Data Item subscription and set the request parameters

·         Submitting the subscription request

·         Processing incoming events listed above (under Event model)

Using the OMM interface requires a slightly different process:

·         Loading Configuration

·         Create Event Queue

·         Create Logger and register interest Logger events

·         Create OMM Consumer

·         Register Interest in Connection and Error events

·         Load Dictionary

·         Create and submit Login request message to the server

·         Create and send data item request message to the server

·         Processing incoming events listed above (under Event model)

Data and Transport Protocol

Legacy RFA MarketData interface supports the following formats:

·         MarketFeed - delimited ASCII based wire data format, with Field identifiers and a dictionary used to parse the payload

·         TibMsg – self-describing binary-based wire format (messages are typically much larger due to the self-describing nature)

·         QForm – binary-based wire data format, with Field identifiers and a dictionary, used to parse the payload

In terms of Transport protocols, Legacy RFA supports SSL & TIB/SASS3

The strategic OMM interface supports the more efficient binary encoded Refinitiv Wire Format. Combined with the hierarchical container-based flexibility of OMM, this allows us to support richer content such as Full Depth Order books, Yield Curves and custom data models whilst delivering considerably greater throughput and lower latency.  

Use cases

Commonly used to Stream or snap real-time data records, as well as Timeseries(TS1) data and ANSI pages. Also used for publishing Streaming real-time data, as well as Contributing data internally or externally.

Pros/Cons

Pros include:

·         Lower level, message-based

·         Improved Flexibility over Legacy APIs

·         OMM interface can consume newer richer data content available such as Full-depth Order Books

·         OMM interface can publish newer richer data content such as Yield Curves, Full Depth Order Books and other custom defined data models

·         Improved Performance compared to Legacy APIs

Cons include:

·         Requires deployed or managed RTDS infrastructure (TREP)

·         Feature complete does not support more recent or future RTDS(TREP) functionality

·         Cannot connect to Cloud-based data sources

·         Cannot contribute to cloud-based Refinitiv Contributions Channel

This document should be read in conjunction with the linked Articles (see the upper right-hand side) - namely 'Choosing your Refinitiv Real-Time Streaming API' as well as any relevant Migration notes.