Handling updates to OMM Container / Nested objects
Is there any documentation covering how to process an update response against an image for each of the OMM Container Data Types, and also how to process an Update action for those Data Types that support actions within an update response? The scenario that I am particularly interested in is when you have nested containers. I have looked in the various RFA Guides but can’t see anything definitive. I am also interested in how the ADS (in POP mode) would update the image in its item cache in response to such updates.
An example might provide some context behind the question.
Scenario 1:
We receive a refresh response containing a Field List with two entries (FID 1 & 2) where FID 1 is a String and FID 2 is a Field List containing two entries FID 3 (a String) & FID 4 (also a String).
If an update response is received containing FID 1 then we would simply set the existing value for FID 1 to the new value from the update.
If an update response is received containing FID 2 (itself containing a single String entry FID 5) then should the existing value for FID 2 be
a) set to the new value from the update (i.e. FID 2 becomes a Field List containing one entry: FID 5),
b) merged with the new value to generate a union of the two (i.e. FID 2 becomes a Field List containing three entries: FID 3, FID4, and FID 5)?
My assumption is that when the value of a container entry is a container itself, then you recursively apply the update to the content of that container rather than simply setting the value to be the new container (i.e. option b in the above Scenario). However, I haven’t seen that stated anywhere either with regard to how an OMM consumer should behave, or how the ADS would update its cached image in response to the update.
Any information in this area would be greatly appreciated.
Best Answer
-
The UPA Developers Guide contains a good write up of how container updates should be applied for each container type, as well as how each of the actions on a container entry (where applicable) should be applied.
Section 11.3 has a table that describes each container type and its entries, including how to apply content within. If it is a container with entry actions, there is a cross link to the detailed section for the container where there is a description of how to apply each action properly.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 中文论坛