An Overview of System Foundation Classes (SFC)

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. 'SFC 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.

System Foundation Classes - SFC

Introduction

SFC is a high level, object-based API which allows the Consumption, Publishing and Contribution of real-time streaming data from/to a Refinitiv Real-Time Distribution System (formerly known as TREP).

SFC is a Legacy API and is only supported with older compilers/IDEs/Operating systems (e.g. VS 2012, gcc 4.4.4, JDK 1.7, Windows 8, RHEL 6 etc)

Languages Supported

C++, Java and COM versions are available - the Java version is often referred to as JSFC and the COM version as SFCCOM.

Features

Key features/functionality of SFC are summarised below

Configuration

Uses a Configuration database that can be populated either from Windows Registry or an X-Resource style flat file. Config Database derived classes allow the reading of config (and writing in the case of the Registry) data to be used within an SFC application. Configuration values fall into two main categories

·         SSL Library configuration – transport/connectivity related

·         SFC API configuration – API level (e.g. queue sizes, retry, services)

Event model

SFC models real-time data, using an asynchronous event mechanism – which requires the developer to register and implement object-based event clients such as

·         Session

·         Record

·         Service

·         Field

As well as data events, the clients may also have to handle state/status events e.g. stale or inactive record events

Thread Safety

SFC is not designed to work in a multi-threaded environment. If your SFC application requires threading, only one thread can ever access SFC/ all uses of SFC objects must be locked to ensure that SFC is only accessed by one thread at a time.

Exceptions

SFC does not use exceptions and is not exception aware. If your SFC application uses exceptions, you have to ensure all SFC objects are cleaned up in the reverse order from which they were created.
Throwing an exception from an SFC event call-back should be avoided.

Data request and response

Requesting a streaming record typically involves:

·         Creating a Service object

·         Obtaining a record object (specifying the symbol) from the service object

·         Implementing an event client class and registering it to receive the events for the record

The response events received by the client class implemented call-back methods will include

·         Full Image

·         Updates

·         Record Info

·         State e.g. Stale, Not Stale, Inactive

Data and Transport Protocols

SFC supports the following data 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)

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

At the data object level, it supports Record, Page, TS1 and Chain objects.

In terms of Transport protocols, SFC supports Triarch/SSL, TIB/SASS2 & TIB/SASS3

Use cases

Commonly used to Stream or snap real-time data records, as well as Timeseries and Page based data. Also use for publishing Streaming records and Page based data, as well as Contributing data internally or externally.

Pros/Cons

Pros include:

·         High level, object-based

·         Support Chains, TS1 and Pages based data natively

Cons include:

·         Legacy - does not support the latest

o    Operating systems

o    Compilers

o    JDKs,

·         Cannot consume newer richer data content available such as Full-depth Order Books

·         Cannot publish newer richer data content such as Yield Curves, Full Depth Order Books & user-defined data models

·         Performance cannot keep pace with higher volatility markets

·         Latency is not low enough for algorithmic trading

·         Requires deployed or managed infrastructure

·         Cannot connect to Cloud-based data sources

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.