Odd handling of bad fields

jeff.kenyon0
jeff.kenyon0 LSEG
in Refinitiv Data Platform Libraries

In trying to get RD working, I ran through the examples posted on https://pypi.org/project/refinitiv-data/, within a platform session (desktop session not an option for my purposes). This example was taking 9 *minutes* to return a response, and only returned the revenue number:

df = rd.get_data(
        universe=['IBM.N', 'VOD.L'], 
        fields=['BID', 'ASK', 'TR.Revenue']
    )
    print(df)

This example, on the other hand, came back in ~9 seconds:

response = fundamental_and_reference.Definition(
			['IBM.N', 'VOD.L'],
			['TR.BidPrice', 'TR.AskPrice', 'TR.Revenue']
).get_data()
print(response.data.df)

After messing about with this a while longer, I discovered that (apparently) the issue is in the rd.get_data function's ability to handle bad fields names. In the first example, 'BID' and 'ASK' are not acceptable field names and get dropped from the internal request, and if you change them to TR.BidPrice and TR.AskPrice, rd.get_data returns a response in ~9 seconds (and actually gives you data). If I change the fields list to ['ARTICHOKE','TR.Revenue'], ARTICHOKE gets dropped from the internal request, but I'm back to ~9 minutes waiting for the response.

My reason for posting:

  1. Can anyone on the RD/RPD team replicate this response delay when BID and/or ASK fields are part of the request?
  2. If so, maybe change the example on the https://pypi.org/project/refinitiv-data/ page?
  3. Modify rd.get_data to TELL you when you're requesting a field it cannot provide? The only error I'm seeing in the logging is the ConnectTimeout('timed out') at close to the five-minute mark.
  4. Document that, if response is abnormally/absurdly slow, the presence of a bad field could be the issue.
Tagged:

Best Answer

  • Jirapongse
    Jirapongse ✭✭✭✭✭
    Answer ✓

    @jeff.kenyon0

    In addition to the response from my colleague, I would like to explain how the get_data method works.

    df = rd.get_data(
            universe=['IBM.N', 'VOD.L'], 
            fields=['BID', 'ASK', 'TR.Revenue']
        )

    With the request above, there are two types of fields (a TR field and real-time fields). The real-time fields don't have the TR prefixed.

    To get data for the TR fields, the get_data method sends a request message to the DataGrid endpoint on RDP. The DataGrid endpoint on RDP doesn't support real-time fields (BID, ASK). Therefore, the get_data method sends an additional request to the Real-Time WebSocket streaming service to get data for the Real-Time fields.

    1692160479522.png

    Typically, most clients don't have permission to access real-time data on the Real-Time WebSocket streaming service. This is why the get_data method didn't display the BID and ASK values.

    on_complete_stream_event ({'ID': 5, 'Type': 'Status', 'Key': {'Service': 'ELEKTRON_DD', 'Name': 'IBM.N'}, 'State': {'Stream': 'Closed', 'Data': 'Suspect', 'Code': 'NotEntitled', 'Text': 'Access Denied: User req to PE(62)'}},)

    You can verify this behavior by enable logging in the RD library via the configuration file (refinitiv-data.config.json).

    1692160619425.png


Answers

Categories