Fixed Income Indexes

Hi, all,

I'm trying to get historical prices for fixed income indexes. But I get different results depending if I use RDP api (desktop session with Workspace app) and Eikon api (desktop session with Eikon desktop app).

This is code for RDP API:

import refinitiv.data as rd
bond_indexes = ['.BC144AG10P','.IBBEU01DF','.IBXXNSA6','.MERC8N0','.FTAUD-6M-EDEURT']
temp = rd.content.historical_pricing.summaries.Definition(
        bond_indexes, 
        fields = ["OPEN_PRC"],
        count=15, # 15 periods
        interval=rd.content.historical_pricing.Intervals.YEARLY
    ).get_data().data.df
non_na_counts = temp.count()
result_df = pd.DataFrame({'RIC': non_na_counts.index, 'Non-NA Values': non_na_counts.values})

This is code for Eikon API:

import refinitiv.data as rd
bond_indexes = ['.BC144AG10P','.IBBEU01DF','.IBXXNSA6','.MERC8N0','.FTAUD-6M-EDEURT']
temp = ek.get_timeseries(bond_indexes,fields='CLOSE',start_date='2010-12-31',  end_date='2023-12-31', interval='yearly')  
non_na_counts = temp.count()
result_df = pd.DataFrame({'RIC': non_na_counts.index, 'Non-NA Values': non_na_counts.values})

This is the comparison (e.g. for the 1st index Eikon has 14 years of data, while RDP doesn't have it). Could you pls advise if this is possible?

Also a general comment: as a Workspace Desktop is newer than Eikon, I was hoping that it will be faster. But somehow Eikon is much quicker in extracting data (I use in both cases the desktop version).

Also, apparently there is huge difference in API limits: using the Workspace (RDP) I'm able to retrieve only around 2500 indexes with 15 datapoints for each index without getting "429, too many requests" error, while with Eikon it seems there is no real limit (e.g. was no problem to get data for 35000 indexes * 15). And the question is why to decommission Eikon when it is better (at least for me)?

Would be great to hear you thoughts.

regards,
Alex

Find more posts tagged with

eikon-data-api

workspace-data-api

rdp-api

#content

#product

workspace-upgrade

Accepted answers

Anufriyev

Dear @jonathan.legrand ,

Thank you for your detailed answer - useful as always from you.

I wasn't aware that count and start/end could lead to different results, so will be using start/end in the future.

Regarding you clarifying questions:

- For Eikon API I was using Eikon Desktop (v4.0.64012), for RDP Api I was using Workspace App (v1.24.159). It also of course could be that in our company the Workspace is not yet roll-out fully, but just testing (and I have a privilege to test it).

- The RD SDK is 1.5.1 version

- The log file I will try to send you later.

My concern in this case is not so about the speed, but more about api limits. I was expecting them to be comparable, but the limits at least for me have big gap as I described in my initial post.

regards,

Alex

All comments

raksina.samasiri

Hi @Anufriyev ,

Thank you for posting this in the forum, I'm also facing the issue with mismatch result between the two library so I'm reaching out to the related team to check and will keep you updated.

Plus, as checked, the 'OPEN_PRC' might not be the proper field to be used to retrieve close price, could you try using 'TRDPRC_1' instead? However, this forum is dedicated to an API usage
question hence, the moderators on this forum do not have deep expertise in
every type of content available through Refinitiv products. Such expertise is
available through Refinitiv Helpdesk, which can be reached via MyRefinitiv.

Anufriyev

Thank you for the answer. Would be also great to hear an opining regarding the speed and api limits.

jonathan.legrand

Hi @Anufriyev, Please note that

(i) we advise using the Refinitiv Data Library (RD Lib.) as you did in the 1st code cell in your question, and not the Eikon Data API (EDAPI) as per the 2nd which will be deprecatred this / next year

(ii) to compare these two requests (from the content and access layer), one would need to input comparable agrumets (e.g.: with the same start and end dates). I did this myself and got the same results:

import pandas as pd
import refinitiv.data as rd
rd.get_config().set_param(
    param=f"logs.transports.console.enabled", value=False)
session = rd.open_session("desktop.workspace")
# session.set_log_level("DEBUG")

bond_indexes = ['.BC144AG10P','.IBBEU01DF','.IBXXNSA6','.MERC8N0','.FTAUD-6M-EDEURT']
temp0 = rd.content.historical_pricing.summaries.Definition(
        bond_indexes,
        fields = ["OPEN_PRC"],
        start='2011-12-31',
        end='2024-12-31',
        # count=15, # 15 periods
        interval=rd.content.historical_pricing.Intervals.YEARLY
    ).get_data().data.df
temp_content = temp0
non_na_counts0 = temp0.count()
result_df = pd.DataFrame(
    {'RIC': non_na_counts0.index,
     'Content Layer Non-NA Values': non_na_counts0.values})
temp1 = rd.get_history(
    bond_indexes,
    fields='OPEN_PRC',
    start='2011-12-31',
    end='2024-12-31',
    interval='1Y')
temp_access = temp1
non_na_counts1 = temp1.count()
result_df['Access Layer Non-NA Values'] = non_na_counts1.values

It looks as though the discrapency came from the use of `count=15, # 15 periods` in the 1st call and a start & end date in the 2nd.

(iii) When it comes to the speed of data retrivals, would you mind letting us know

(a) Which application are you using alogside your code? (Eikon? Workspace?)

(b) Which version of this application you are using? (Eikon 4?)

(c) Which version of the RD Lib. you are using in your pyhton code? You can find this out in Python with the comand `rd.__version__`.

(d) If you can create logs and send them over to us (in a comment below, as an attachement)This step is a little dificult. I explain how one can create such logs in this article. You can leave step (d) aside for now if it's too dificult, and we'll only require it if all other investigatory steps are fruitless. I actually added Python code in the text (cell) above where such logs can be outputed in-line (in your Python IDE). To activate it, you only have to change `value=False` to `value=True`.

Anufriyev

Dear @jonathan.legrand ,

Thank you for your detailed answer - useful as always from you.

I wasn't aware that count and start/end could lead to different results, so will be using start/end in the future.

Regarding you clarifying questions:

- The RD SDK is 1.5.1 version

- The log file I will try to send you later.

My concern in this case is not so about the speed, but more about api limits. I was expecting them to be comparable, but the limits at least for me have big gap as I described in my initial post.

regards,

Alex

jonathan.legrand

Hi @Anufriyev, Just a quick update; I am still liaising with my team internally, with regards to your issue, and I'll revert back to you on this Q&A Forum as soon as I have an answer.

jonathan.legrand

Hi @Anufriyev,

I got an update from our internal teams, and identified the issue as a mismatch between different databases. Finding the exact calls and responses that triggered this issue turned out to be very complicated. We are looking into rectifying the issue in the backend, but in the meantime, I thought it best to let you know a workaround using rd.content.fundamental_and_reference API and disabling the sort option:

rd.content.fundamental_and_reference.Definition(
    "LVMH.PA",
    ["TR.CashInterestPaid.fperiod", "TR.CashInterestPaid"],
    {"SDate": "FY0", "EDate": "FY-32", "Period": "FY0", "Frq": "FY", "scale": 6},
    extended_params={"output": "nosort"},
).get_data()

Anufriyev

Thank you for update @jonathan.legrand Unusual that "nosort" parameter is so important. Great to hear that your collegues took a deep look into the issue.

EXPLORE OUR SITES