How to ensure backward compatibility when encoding UPA 8.0 nanosecond resolution TIME/DATATIME field
As part of upgrading to UPA8.0 (C++) I have added microsecond/nanosecond support when encoding/decoding TIME/DATETIME fields.
In an environment running TREP 3.0 platform components UPA 8.0 consumers decode UPA 8.0 Publisher TIME fields as expected. No problem there.
However whilst performing tests with UPA 7.6 consumers on the same environment. I found that the 7.6 consumers cannot decode the TIME fields published by a UPA 8.0 publisher.
2016-04-15 10:00:41.322 WARN: FieldListInspector.cpp:182: Failed to decode fid 18 [TRDTIM_1]: RSSL_RET_INCOMPLETE_DATA
So my questions are:
1. Is this expected behaviour?
2. If so, how should I encode the high res time field in a UPA 8.0 publisher in such a way to ensure backward compatibility with older UPA clients?
Best Answer
-
This is an expected limitation, UPA 8 introduces a new message version with new data sizes and features which cannot be understood by earlier versions. For TIME field in particular you can manually decode the field in UPA 7.6 but the negatives outweigh the positives to simply moving to UPA 8.
For full backward compatibility only use the basic field types that are published on Elektron which surprisingly does not include DATETIME but separate DATE and TIME fields and microseconds or smaller are provided in another INT field, e.g. SALTIM_MS. Consult the RDMFieldDictionary file for the list of common fields that will be understood by all consumers.
Theoretically with a non-caching TREP a provider can inspect the version information of a request and encode the response appropriately for the features understood, such as nanoseconds. Practically though TREP is sending the request with the version information it was built with and not what the client sent and thus the information is lost.
1
Answers
-
I've just performed the same test in a TREP 2.6.1 environment without issue.
So this is looking more like a TREP 3.0 platform problem rather than a backward compatibility issue.
0 -
TREP 2.6.2 is built with UPA 7.6.0.L1, TREP 3.0.0 is built with UPA 8.0.0.L1, TREP 3.0.2 is built with ETA 3.0.1.L1+
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 中文论坛