@constantine.antonovich

Let me share my experience when dealing with Chain RIC.

First of all, my application just checks if the fields list contains REF_COUNT with 14 links fields and it must contain Next and Prev links fields. Then I will mark the RIC as a valid chain because it contains a valid chain template.

In theory, the way to process links fields should be the same as described in the pages you mentioned. But there is some case that the feed does not send the data according to the spec.

In the past, I found the case that some chain providers might automatically pass a list of string which is a value of 14 link fields. But it looks like, they do not verify if some fields contain an empty string or not. Some RIC just removed so they set to empty to preserve the number of Chain Records. Also, you might see the case that REF_COUNT is 14 but some fields in the links are empty. Or sometimes REF_COUNT is 10 but they also use LINK_12,13 and 14 and set the value of some link field to empty instead. Anyway, the number of non-empty link fields still matches with the REF_COUNT. Also, there is some case that REF_COUNT is 0 and all link fields are empty but when subscribing to the next Chain Record, it still contains a valid Chain REF_COUNT and Links. It looks like they use this approach to preserve the number of Chain Records and will have a plan to update it later.

With the following exception and issue that may occur for some Chain, therefore, my app will get RIC from 14 link fields by not checking the value of REF_COUNT. I assume that chain RICs presented in link fields should be valid RIC though the number does not match with REF_COUNT. Anyway, I have to logs unusual case to app logs and then reports these case to the content support team to get clarity from the team who take care of the Chain.

API or client app cannot change or populate content so this is the only way we can do to handle links field.

Hi @constantine.antonovich

I am not aware what your exact implementation requirements are and what the target consumer applications are. but...

If you are developing new applications and the consumers are not exiting chain subscribers, then you should consider looking into SymbolLists as an easier way to distribute a dynamic list of instruments.

If so, there is a good article by two of my colleagues on SymbolLists which you may find useful.