Concepts and Design of Refinitiv Data Libraries

Overview

Refinitiv Data Libraries are a suite of ease-of-use libraries and interfaces for Python, TypeScript/JavaScript and .NET providing access to streaming and non-streaming data services offered within the Refinitiv Data Platform.

Targeting both financial coders and professional developers, these libraries provide capabilities that cover simple use cases as well as the most advanced ones.

They are designed with simple and consistent interfaces enabling your applications to connect to the Refinitiv Data Platform through its different access points. Once connected, your applications can rely on ease-of-use objects and functions to access to the breadth and depth of data services available on the platform. For very specific needs they can also leverage the service agnostic lower layer that gives you access to fine grained details of each platform service.

Note: High performance scenarios – that represent a smaller part of customer use cases – are addressed by the Elektron SDK (C++, Java) and its APIs (Elektron Message API, Elektron Transport API).

General considerations

As previously outlined, the developer has the choice to access the platform from specific access point ranging from the desktop (Eikon/Refinitiv Workspace), via high-performance on-premise deployments (TREP) to cloud-based services (Refinitiv Data Platform).
Depending on the specific access point, developers should not have to learn and use different APIs. The same API and libraries should work seamlessly across the platform, using the same paradigms, experience the same functional behavior and receive the same data irregardless of how they choose to access content.

Depending on the application goals, what skill level and development experience is available, different types of developers will want to use this API with a large range of different use case scenarios.
These scenarios can be as basic as getting the current values of an instrument via a simple function call or can be as sophisticated as being alerted in real-time when values of an instrument change within the market.

Refinitiv Data Libraries will address these various needs by providing several abstraction layers and operation models as described below.

Platform Access Points

Depending on the access point it uses to connect to the Refinitiv Data Platform (either directly to the platform or via Eikon/Refinitiv Workspace or via a locally platform), your application will create and use one of the different session types defined by the libraries. With the exception of this session creation phase, the design of the Refinitiv Data Libraries is normalized to provide consistent interfaces, irregardless how you access content. For example, applications built to access streaming content from the Refinitiv Workspace can seamlessly switch to another supporting access point (like direct access to the Refinitiv Data Platform) with minimal code changes. The goal is to provide the developer an intuitive interface that defines consistent APIs through multiple access points when accessing data services within the platform.

The following diagram presents the different platform access points available to the developer:

Abstraction Layers

Refinitiv Data Libraries abstraction layers target different needs as well as different types of developers.
Depending on the skill and comfort level of the developer, the API offers general abstraction (Session & Delivery) layers specific to the delivery mode of the content to more business-specific (Content & Function) layers defining interfaces more suited to the nature of the data. But even the lower layers (Session & Delivery) provides an intuitive and easy to use interface.

All these layers can be used together in the same application.

Session layer

Depending on the access point it uses to connect to the Refinitiv Data Platform, access requires authentication and connection semantics in order to communicate and retrieve content. Refinitiv Data Libraries provide this managed access through an interface called a Session. Once the session has been established, it can be used with objects and functions of other layers to retrieve data from the platform.

Delivery layer

The Delivery layer implements classes that can be used to interract with the different delivery modes provided by the Refinitiv Data Platform to retrieve data:

• Request (HTTP Request/Response)
• Stream (WebSockets)
• Queue (Alerts)
• Files (bulk)

For each of these delivery modes, defined classes can be used to easily retrieve data from the platform in raw JSON format.

Classes defined in the Delivery layer are not dependent on any specific data service. They are service agnostic. Designed as a low abstraction layer of the library, the Delivery layer targets developers who need specific features that are not offered by other higher level abstraction layers (Content & Function). This layer targets the professional developer but can also be used by financial coders with good programming skills.

Content layer

The Content layer refers to logical market data objects, largely representing financial items like level 1 market data prices and quotes, Order Books, News, Historical Pricing, Company Research data and so on. These objects are built on top of the Delivery abstraction layer and provide value-add capabilities to manage and access the content within the interface.

For example, the Pricing interface is a thin layer on top of data services offering realtime market data. In addition, interfaces such as Historical Pricing and Environmental & Social Governance (ESG) are available to allow intuitive access to request and process results. While the native back-end data format supports JSON structured messages, the Content layer conveniently prepares data messages in a user-friendly format specific to the programming language. For example, Pandas DataFrames for Python, JSON in TypeScript/JavaScript and .NET.

The Content layer can easily be used by both professional developers and financial coders. It provides great flexibility for familiar and commonly used financial data models.

Function layer

The Function layer defines interfaces more suited to scripting languages such as Python. The goal of these interfaces is to allow researchers, data scientists or the casual developer to rapidly prototype solutions within interactive environments such as Jupyter Notebooks. The Function layer provides simplistic data access in a single function call such as retrieving News Headlines and Stories, retrieving historical intraday / interday data etc. Because this layer is built on top of the Content layer, it will benefit from convenient abstractions such as preparing data formats suitable for the specific programming language.

The Function layer can easily be used by both professional developers and financial coders. It provides simple and familiar access to popular scripting languages and preparing data results useful for the particlar language.

Note: This layer is only available in the Refinitiv Data Library for Python.

Operation Models

The abstraction layers outlined above provide several operation models that meet the needs of a large range of use cases, from the simplest to the more advanced. These models are synchronous, asynchronous and event-driven.

Synchronous

Method/function calls are blocking. The result related to the call is available as soon as the method/function returns control to the calling thread. Synchronous calls are extremely useful when prototyping within scripting environments such as Jupyter Notebooks.

Note: Because of the asynchronous nature of TypeScript and JavaScript, the synchronous operation model is not available in the Refinitiv Data Library for TypeScript/JavaScript

Asynchronous

Method/function calls are non-blocking and return control to the calling thread almost immediately, before the result of the call is available. The Asynchronous model allows the calling thread to perform other operations in parallel to the task requested by the method/function call. When done with the other operations, the calling thread can wait for the requested result to be available (e.g. async/await paradigm). Applications that require more sophisticated interfaces, such as GUI-based applications, will greatly benefit from asynchronous calls.

Event-driven

With this model, the application registers callback methods or lambda expressions that are called when the requested results are available. Mostly applicable to streaming data, the Event driven model can be mixed with the Synchronous model and the Asynchronous model.

When mixed with the Synchronous model, some of the callback methods or lambda expressions are called before the method/function returns control to the calling thread. When mixed with the Asynchronous model, callback methods or lambda expressions are generally called after the method/function returns control to the calling thread. Event-driven applications are quite common when building applications that work with streaming data.