How to use Source Directory messages using ETA API
I’m using Elektron Transport C API 1.1.0 in Linux. Currently, the source directory messages are used only to identify service UP/DOWN messages.
The Consumer application in Elektron SDK doesn’t show how to use the different filters available in source directory messages.
The client application opens item stream from Elektron (ADS) end point for various asset classes(including international exchanges). Recently, we experienced an issue where the ADS dropped open streams due to maintenance and application didn’t receive item level status messages and the service didn’t go down. I was told that client application need to handle group status that comes in source directory updates.
As per my conversation with the Refinitiv support team, I’m interested in using all the filters available in source directory so that client application can recover from any failure that may happen in ADS and above.
Few things that popped up when reading the TransportAPIC80_RDMUsageGuide.pdf guide is below.
- How to use group id’s from item stream and source directory to handle group level notification ?
- How to use AcceptingRequests and Status from service filter ?
- How to use MergedToGroup information coming in group filter ?
Since the client application is using a low level ETA C API, is it recommended (and possible) to use Value Added API’s instead of the raw ETA C API ?
Is there any sample application or code you could point me as a starting point ?
Best Answer
-
Hi @RAJ
This is a detailed topic which will be best addressed by reading the TransportAPI_C_DevGuide in combination with the RDMUsageGuide which you have already referred to.
However, I hope the following will provide a summary of the key points.
As and when you open data item streams, they are assigned to a particular group. You can obtain the data item's group id from the groupId attribute of each item's Refresh and Status messages. Note that groups are defined on a per-service basis (so two services can use the same group ids)
To receive Group status notifications, when you make your SOURCE_DIRECTORY request you need to include the SERVICE_GROUP_FILTER for your filter value
e.g. RDM_DIRECTORY_SERVICE_INFO_FILTER | RDM_DIRECTORY_SERVICE_STATE_FILTER | RDM_DIRECTORY_SERVICE_GROUP_FILTER
You can then receive Source Directory related Messages and if they contain GROUP filter entries, you can extract the Group ID from the Filter entries. Once you extract this Group id from the filter entry, you can then apply any Status contained in the Filter entry to all the data individual data items with the same group ID.
As mentioned above, I recommend you read the documents for the fuller picture including
- RDMUsage guide sections for the Source Directory and the other Data domains you are consuming.
- DevGuide sections related to Group Status - including section 13.4 Item Group Use.
1
Answers
-
Hi @RAJ
Addressing your other questions:
AcceptingRequest indicates whether a service is actually ready to receive and service requests. It could be that whilst a provider is up and running, it cannot currently service your request e.g. due to a required resource not being available - and therefore it would indicate that it cannot Accept requests at this point in time.
MergedToGroup is used to let you know that items are being re-allocated from their current group to a different group i.e. all data items with a groupID of 'group' are now being moved to the new group with the id of 'mergedToGroup'. Therefore, your consumer application should change any stored groupID of data items to the new mergedToGroup.
1 -
Hi @Umer Nalla thanks for your answers.
Regarding State filter entry, does it mean that ServiceState can be Up (1) while AcceptingRequests is No (0)?
0 -
Yes, it is possible that ServiceState can be Up (1) while AcceptingRequests is No (0).
Refer to section 4.4.2 ServiceState and AcceptingRequests, the ServiceState and AcceptingRequests elements in the State filter entry work together to indicate the ability of a particular service to provide data.
If AcceptingRequests is False, new requests are rejected while existing streams remain unaffected (reissue requests can still be made for any item streams that are currently open to the provider).
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 中文论坛