RFA API connection - fields supported

Background:
We have a created a new JAVA RFA API adaptor.
We wish to subscribe to many Reuters RICs via TREP
The minimum set of fields we wish to read in from these RICs include the following:
BID; ASK; PRIMACT_1; SEC_ACT_1; HST_CLOSE; TRADE_DATE; VALUE_TS1; VALUE_DT 1; QUOTIM_MS;
(potentially more fields will be read)
Questions:
- Upon requesting the RIC will the first update, from Reuters for the RIC, always contain every field supported. In other words should we always expect to receive all 295+ fields to provide a full snapshot of the RIC's fields on startup?
- Once the first snapshot of RICs has been sent by Reuters will we only receive further updates if something changes on the RICs' fields?
- Depending upon the RIC requested, will the subsequent updates from Reuters only provide fields which have changed? Or will the subsequent updates provide all fields relevant for the RIC whether they have changed or not?
- Will the respective Date fields always be sent if the Time fields have been updated?
- Will the latest BID field always be accompanied with the latest ASK field even if only the BID field has changed and the ASK field remains the same?
- Will the latest PRIMACT_1 field always be accompanied with the latest SEC_ACT_1 field even if only the PRIMACT_1 field has changed and the SEC_ACT_1 field remains the same?
Best Answer
-
The initial Refresh message should always contain every field available for that RIC - even if the field is empty.
In terms of your remaining questions, the answers are not quite definitive. This is because the API is 'content agnostic' - in the sense that it will pass on whatever it receives from the upstream connection - it does not try and apply any business logic etc to the updates.
Generally speaking you should only receive an update when one or more fields change. However, it is possible to sometimes receive an update where no fields have changed - this could be because the originating exchange or venue has issued an update - even though a field has not obviously changed.
The updates you do receive will include fields that the feed considers to have changed or are in someway related to a field that has changed - but this will be a subset of the Refresh.
You may also receive an unsolicited Refresh occasionally - e.g. after an item has gone Stale/Suspect and then subsequently transitioned to OK state.
In terms of matching Date and Time field, generally the feed tries to minimise the payload and will not send a Date field unless the date has changed e.g. you should not expect to receive a TRADE_DATE in the update each time there is a trade - only a TRDTIM_1 for example.
Likewise for BID / ASK / PRIMACT_1 / SEC_ACT_1 - you should expect to receive BID independently of ASK if only BID or ASK has changed since the last update. However, it is possible to receive a BID and ASK even if only one has changed - again depending on the originating venue / asset class etc.
One other thing you may be interested is the View request functionality - where you can ask the server to filter the Fields it sends you in the Refresh + Update messages. See Section 13.3 of the RFA Developer Guide for more details and the StarterConsumer_BatchView.java example too.
One thing I should mention is that if you are in the early stages of your RFA JAVA adaptor development, then I strongly recommend you explore the Elektron Message API of the Elektron SDK. Not only is he Elektron SDK is our strategic API, it is also much easier to learn, implement and maintain and in the longer term will receive any new features and functions (unlike RFA which is feature complete)
0
Answers
-
Thank you. That makes sense regarding the fields.
BTW- for now we will not switch to Elekron. This is because the development is fairly well progressed.
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 685 Datastream
- 1.4K DSS
- 615 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 252 ETA
- 556 WebSocket API
- 38 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 275 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.9K Refinitiv Data Platform
- 651 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 193 TREP Infrastructure
- 228 TRKD
- 917 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 90 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛