question

Upvotes
Accepted
LexiFi Dev avatar image
1 ●1 ●0 ●3

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.

eikoneikon-data-apieikon-com-apieikon-.net-api
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

4 Answers

Upvotes
Accepted
Alex Putkov.1 avatar image
39.2k ●75 ●11 ●27

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

LexiFi Dev avatar image 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 avatar image Alex Putkov.1 LexiFi Dev

I'm not quite sure I quite understand what you're asking. It might be helpful if you provide a general idea of what the application does and what end goal you're looking to achieve. My original understanding of the end goal was that you wanted to flag erroneous user input. As you learned trying to subscribe to the RIC does not yield the desired result because there are some service RICs, which return OK status, while from the user perspective these RICs do not exist.

LexiFi Dev avatar image LexiFi Dev Alex Putkov.1

Your original understanding was right, I just want to clarify the sentence "[...] the logic in your application to convert all lowercase user input RICs to uppercase" in order to avoid false-negatives. Should "all lowercase user input" be read as "all input that begins with a lowercase".

Alex Putkov.1 avatar image Alex Putkov.1 LexiFi Dev

My suggestion is to add some logic to user input validation, specifically handle the case when user input is all lowercase. All lowercase user input is always erroneous. You can return an error message and alert the user right away. Or you can assume that the user accidentally pressed Caps Lock and what the user meant to enter is an all uppercase RIC, which is a reasonable assumption and this is what Eikon application does.

Upvotes
Alex Putkov.1 avatar image
39.2k ●75 ●11 ●27

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

alain.frisch avatar image 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?

Alex Putkov.1 avatar image Alex Putkov.1 alain.frisch

By tsXXX do you meant literally "tsXXX"? Or do you mean XXX to represent some other 3 uppercase letters? Like "tsIBM" or something? Can you give a literal example? Because on my end "tsXXX" and "tsIBM" both come back with status Closed.

alain.frisch avatar image alain.frisch Alex Putkov.1

No, XXX was a generic placeholder. We observed that for instance tscol gave OK. This one is indeed all lowercase and would be blocked by the heuristic you suggest. Do you think that ts followed by anything with at least one uppercase letter would either be valid or return Closed?

Show more comments
Upvotes
LexiFi Dev avatar image
1 ●1 ●0 ●3

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?

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
Alex Putkov.1 avatar image
39.2k ●75 ●11 ●27

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

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Click below to post an Idea Post Idea