Enhanced Symbol Lists require Provider support?

Within RFA 8.x, the Enhanced Symbol List functionality states:
"When data is requested along with names on the symbol list, RFA opens the items listed in the symbol list response for the consumer application."
From this, we can clearly see that the RFA API will provide the convenience of opening the items automatically within the symbol list when it returns from the Provider. This is a nice convenience as the RFA client doesn't have to code for this. In fact, a nice diagram is outlined here describing exactly that.
However, for reasons not exactly clear to me, the Provider needs to support this as indicated in the Login Response message (search for SupportEnhancedSymbolList on that page). In fact within this question, part of the answer also explains the Provider has to support this capability i.e.
"Even then not all providers may support the "enhanced" concept of sending all the symbol list constituents from the single request..."
Yet, the description (and diagram) of what an Enhanced Symbol List clearly states the API at the client side will do all the work for you.
Can someone clear up the confusion. Exactly what support does a Provider need to provide for Enhanced Symbol Lists?
Best Answer
-
The "SupportEnhancedSymbolList" is generated by RFA consumer to indicate that the version of RFA supports the Enhanced Symbol List feature. This means that an RFA8 consumer application always receives SupportEnhancedSymbolList=1 in Login refresh message‘s
AttribInfo.Attrib.With this feature, RFA sends request for items from the symbol list on the consumer application's behalf. If the back end server supports batch feature, RFA will send the item requests as batch. Otherwise, RFA will send the item request as individual request.
0
Answers
-
Thank you - this makes sense. Yet, I don't know why the documentation states "Provider", not "RFA" when discussing "SupportEnhancedSymbolList". This is the source of confusion.
0 -
I think the point here is that if the Provider does not support the Enhanced function then RFA will provide the functionality on the developers behalf.
A Provider (e.g. ADS) could support 'Enhanced Symbol List request' whereby it sends the data for the items in the Symbol List and it would indicate this in the Login response when the consumer connects to it. And if it did support it, then RFA would not need to individually request each item in the list.
0
Categories
- All Categories
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 684 Datastream
- 1.4K DSS
- 613 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
- 248 ETA
- 552 WebSocket API
- 37 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
- 630 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
- 26 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 191 TREP Infrastructure
- 228 TRKD
- 915 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 86 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛