How to manage dictionary across various services and connections
I use ETA C++ API in Linux. We use EaaS (EMS) service that has multiple connection points across multiple data centers.
Since the serviceId is
used when requesting data dictionary, does the client application need to
download dictionary for every service id in the same connection and use it to decode response for the respective services ?
What is the best practice for an ETA application in handling data dictionary across data centers for the same services ?
In other words, when my application fails over to a different IP in the same or different data center, can it reuse the dictionary for the same service Id between different ADS servers.Best Answer
-
At any point of time, an ETA subscriber client is connected to only one infrastructure, via ADS. If a disconnect happens, followed by the reconnect, an ETA application is responsible for handling it, i.e. subscribing to and processing off, source directory and data dictionaries.
In the case of EMS infrastructure, yes, we expect the subscriber to get seeded with exact same dictionaries, but just in case an update took place just at the moment when the subscriber reconnected, I would pursue a consistent and safe approach, of requesting directory and dictionaries, on any connect, including a reconnect.
0
Answers
-
1. In case of EMS infrastructure, if the server provide data for multiple EMS services, do I need to request data dictionary for each service on a single connection ?
2. when you say "we expect the subscriber to get seeded with exact same dictionaries", are you saying that individual server IP's from different data center will share the same dictionary ?
3. This is a follow up question to #2. I'm planning to have my client application maintain a open connection to multiple IP's (for warm standby) from different data center for quick recovery. If the IP (primary) that I use to service my request goes down, I would like to route all my request to the second in line IP. In this case, I don't make a new connection that would initiate directory and dictionary requests. What do I do in this case ?
0 -
1. The data dictionaries (field dictionary and enum dictionary) are per connection to the infrastructure, rather then per service. So no.
2. I expect EMS hosted infra to supply the latest general data dictionary. But, you want to write defensive, fully safe solution, and be prepared even against a rare contingency, when updates are applied to the infrastructure, etc. Also what if you at some point decide to work with a deployed infra? So, on establishing connection, we suggest to request the dictionaries.
3. Following up on 2, in the solution when you are looking to have two connections to two different infrastructures, I would assume nothing about the same dictionary being very likely, when the app establishes the connection to the infra, the app requests source directory and dictionaries from that infra, and uses for subscriptions to that infra.
0 -
Is it possible to get an update for data dictionary on a open connection ?
Will TR disconnect the client before updating data dictionary forcing the client to re-initialize and re-request data dictionary ?
0 -
Refer to RDMUsageGuide in RFA package, the dictionary domain doesn't use update message.
0 -
Hello @RAJ
Let me address the follow-up questions,
RDM Usage Guide explains this aspect in the following passage:
"
Though updates are not sent on dictionary streams, Thomson Reuters recommends that the consumer make a streaming request (setting ReqMsg.InterestAfterRefresh to true) so that it is notified whenever the dictionary version changes.
"I.e. the dictionary update will not be published on the open stream. In the extremely rare event that the dictionary version changes on the infrastrcuture, the consumer will be notified on the open stream. To provision for this, the subscriber would need to re-request the dictionary.
There is not explicit provision to disconnect the client on the dictionary update.
Please keep in mind that marking your follow-up question as the correct answer is misleading to other developers, and effectively closes the discussion, does not seem you intend this?
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
- 683 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
- 626 Refinitiv Data Platform Libraries
- 5 LSEG Due Diligence
- 1 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
- 84 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛