An Overview of the Refinitiv Robust Foundation API - RFA.NET

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 .NET API

Introduction

Refinitiv Robust Foundation API (RFA) is a 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.

RFA .NET use the Open Message Model (OMM) to allow rich hierarchical data types including full order book support (RFA .NET does not support the Legacy MarketFeed based format).

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.

RFA .NET is implemented as a wrapper around the RFA C++ version – resulting in lower performance than the native C++ version (due to the managed/unmanaged interop).

Features

Key feature/functionality of RFA are summarised below

Configuration

Uses a Configuration database that can be populated programmatically, from a flat file or Windows Registry. 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)

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 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

Using the OMM interface, writing a basic subscriber typically involves several steps including:

·         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

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) and ANSI page data. 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 orderbooks

·         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:

·         As a wrapper around RFA C++ version – it is not as performant as the native C++/Java versions

·         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 connect 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.