SingleOpen and AllowSuspectData behaviour
UPA documentation states that if Login request from consumer has both SingleOpen and AllowSuspectData flags set, then provider is supposed to handle recovery automatically and consumer should never receive item status CLOSED_RECOVER.
What happens when consumer receives source directory message (RSSL_DMT_SOURCE) indicating the source is DOWN with Status info? Documentation says in such case the status should be applied to all streams for that source, but will status be CLOSED_RECOVER or OPEN with data SUSPECT?
Does consumer have to re-request all streams when source is UP again?
Best Answer
-
Just because a consumer requests for single open and suspect data, be aware that the application should look at the login response from the provider to confirm what values the provider is actually providing, as some providers may not support one or both options.
Assuming the login response from the provider indicates that single open is enabled, then yes, in theory, the consumer should never receive a closed recover status and the provider will perform recovery. With that said however, there is nothing within UPA which would prevent the provider from sending a closed recover status (other than documentation), so I would recommend to anyone developing a consumer application, to still prepare for the possibility of receiving such a status.
Regarding 'Status' contained within the state filter entry of the source directory, yes, when received, that status must be applied to all open streams within that service. ADS will follow the same rules, meaning with single open enabled, the status will be open / suspect when the service goes down and recovery will be performed in the ADS. With single open disabled, the status will be closed recover when the service goes down and all streams are closed. Same applies for group level statuses. But again, although this is the expected behavior, there is nothing preventing a provider from doing something differently.
Yes, on a closed recover status, the stream (or streams) are closed and it is the responsibility on the consumer to recall.
0
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛