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 ?
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.
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.
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)?
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).
