Eikon .Net API: returns Status OK on some invalid RICs

Hello,

We are using Eikon .Net API to retreive initial informations (e.g. Currency, Exchange, ...) or current data (e.g. Bid, Ask, ...) from some user-supplied RIC. For this, we are using the SetupDataRequest API call, expecting to receive data through the callback OnDataReceived and checking for invalid tickers or miscellaneous errors through the callbacks OnStatusReceived/OnError.

For valid RICs, this whole process will work as expected but for invalid RICs, the API will always return an OK status for some very specific RICs and will return Closed (as expected) for the remaining majority.

You will find in the list a below some examples of misbehaving RICs :

- tb (and it seems that any derivatives like tba, tbaa, tbb, etc are affected)

- tr (and derivatives)
- ts (and derivatives)

and others, we did not explore thoroughly all combinations.

While their neighbor (ta, taa, ...) and other (foo, foobar, ...) invalid RICs work as expected, returning a Closed status.

This inconsistency is quite problematic for us. Is this expected? As it seems to be prefix-related, we are wondering whether there are some kind of reserved prefix that we should know?

Finally, what would you recommend to correctly handle these cases. We have implemented some kind of response timeout as a workaround but this obviously fragile.

Find more posts tagged with

eikon

eikon-com-api

eikon-data-api

eikon-.net-api

Accepted answers

Alex Putkov.1

RICs are case sensitive. There are no all lowercase RICs on Elektron datafeed with payload containing market data or anything else that might be of interest to you, your application or your users. There are some all lowercase service RICs, which may be used for service purposes (diagnostic, troubleshooting etc.). My suggestion is that you implement the logic in your application to convert all lowercase user input RICs to uppercase. Make sure to not convert mixed case RICs, as mixed case RICs are legitimate. This same logic to convert all lower case user input RICs to upper case is implemented in Eikon application.

All comments

Alex Putkov.1

LexiFi Dev

Thank you for answer, there is one particular point where we need some precision. You talk about normalizing "all lowercase [...] RICs" and do nothing on "mixed case RICs", experimentation showed us that we might need to ignore/normalize RICs that begins with a lowercase (tsxxx and tsXXX) and ignore mixed case RICs that do not begin with a lowercase. Can you confirm this?

Alex Putkov.1

There are numerous legitimate mixed case RICs that start with a lowercase letter. RICs that start with "a" (e.g. sUSCPI) are historical only RICs and provide timeseries for economic indicators. RICs that start with "t" (e.g. tIBM) provide tick history for equities. I'm afraid I cannot know if any of these RICs are of any use to your application, and therefore if for your application mixed case RICs that start with lowercase letter can be considered valid. Perhaps it might be helpful if you give some examples of what you came across in your experimentation and how it affects your application.

alain.frisch

Here is the scenario: users can choose some underlying through their RIC in the application; when they do so, we want to validate the RIC using the Eikon API and get some of its static refernce data (currency, etc). We understand that all-lowercase inputs are necessarily invalid and could be either rejected or turned into all uppercase. But this only deal with some invalid inputs. The API often returns an error code to flag other invalid inputs. But when it returns OK (e.g. for tsXXX) and no other data, how should our application know the RIC is actually invalid?

LexiFi Dev

So I tried tIBM, it indeed returned a "NoPermission" status, however, tsIBM will returned a "OK" status. I tried further more with "tFOO" and "tARCH.PA", they returned respectively "OK" and "NoPermission", the general rule seems to be : "tSOMERIC" will return "NoPermission" if SOMERIC is valid and "OK" otherwise.

Your two examples of RICs beginning with a lowercase seems to be modifiers of existing RICs, have you got an exhaustive list of these prefixes?

Alex Putkov.1

"NoPermission" means the RIC exists, but the user is not entitled to view it. "tIBM" indeed exists, as do "tARCH.PA" and "tFOO". The latter does not return any useful payload, but the RIC exists. I guess this is a remnant of something that existed in the past and was never removed. The whole system providing tick data for stocks through RICs starting with "t" is an archaic legacy system, which is still used by a few clients.
The RIC "tsIBM" does not exist, and I do not reproduce it returning "OK" status. The status I see on my end is "Closed".
The general rule: "tSOMERIC will return NoPermission if SOMERIC is valid and OK otherwise" is definitely incorrect.
The RICs starting with lowercase letters may be modifiers of the RICs following that lowercase letter, as is the case for "tIBM" and "tARCH.PA", which provide tick history for "IBM" and "ARCH.PA". But in other cases the RICs starting with a lowercase letter may not be modifiers of anything. They may be RICs in their own right. Or as in the case of "tFOO" they may be remnants of something that ceased to exist, but was never cleaned up.

EXPLORE OUR SITES