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.
0
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.
0 -
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
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 685 Datastream
- 1.4K DSS
- 615 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
- 252 ETA
- 556 WebSocket API
- 38 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
- 651 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- 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
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 193 TREP Infrastructure
- 228 TRKD
- 917 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 90 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛