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 ?

Find more posts tagged with

elektron

status

elektron-sdk

refinitiv-realtime

elektron-transport-api

eta-api

rrt

source-directory

Accepted answers

umer.nalla

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.

All comments

umer.nalla

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.

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

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.

umer.nalla

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.

tinmyo.win

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

Jirapongse

@tinmyo.win

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

EXPLORE OUR SITES