ADH / ADS caching of RDM / Custom OMM models
I just want to confirm that my following understanding of RDM / OMM / ADH / ADS caching is correct.
I have always understood that for complex RDM models the ADH can handle caching of Updates to a single FieldEntry no matter how deep in the nested hierarchy.
For example with the YieldCurve model below, the provider publishes an Update (for an existing YC record) which contains a single FID 30200. The Payload being a Vector with a single Vector Entry x with an Action flag of Update. The payload of this Vector Entry x being a single FID 30202.
The ADH (on receipt of the above update) would modify its cached value of the YC Record to update FID 30202 for that one single Vector Entry x, leaving all the other fields for Vector Entry x intact and also all other vector entries intact.
When a consumer then requests a Refresh for the YC record he receives the latest image (which includes the latest value for FID 30202 for Vector Entry x).
Is the above understanding correct? OR would the provider have to publish for example the complete set of fields again for Vector Entry x?
If my above understanding is correct, can I also assume the same applies for custom OMM models? E.g. For a Custom OMM Model containing a FID with a Payload of a Vector and each VectorEntry contained a payload of a nested Vector with each VectorEntry containing a FieldList (as shown below)
My understanding is that the Provider can publish (for an existing Matrix record) an Update for just one single FID -1003 in the above nested FieldList (for a single nested VectorEntry) and the ADH cache will handle this correctly and update the one single FID, leaving all other FIDs and VectorEntries intact. Obviously, the payload for the Update message would need to contain a FID -1001 with a single VectorEntry (with the appropriate Position and Action="" which itself contained a single nested VectorEntry (with the correct Position & Action="" with a payload of a FieldList containing FID-1003.
Can someone please confirm my above understanding is correct or flawed ?
Best Answer
-
Yield Curve referenced in question:
Vector referenced in question:
The understanding is
correct. Provider just has to publish what is changed and just the field entries
that have updated within vector x. It does not need to republish entire vectors
due to nesting.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 中文论坛