Legacy API Migration
An Overview of the Refinitiv Robust Foundation API - RFA.NET
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.
- 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.
- 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
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).
Key feature/functionality of RFA are summarised below
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)
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.
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.
· 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
· 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.