Bug? Backend Failure? Cannot get NQc1 / NQU0 bid/ask ticks on Sep 4 between 8:21 and 14:52...

Chon11201120

When I tried to get historic BID/ASK ticks of NQc1 and NQU0, strangely I got the following result:

with start 8:21 and end 14:52, none is returned.
with start 8:20 and end 08:21, 2491 ticks were returned.
with start 14:52 and end 14:53, 14441 ticks were returned.

Here are the codes and screen capture for your reference.

Code: Code.JPG

Result: Time between 8.21 and 14.52.JPG

Please help and advise! Thanks a lot!

Find more posts tagged with

eikon

eikon-com-api

Accepted answers

Alex Putkov.1

@Chon11201120

Since we cannot reproduce the issue on our end, and since it's so strangely specific to a couple of RICs and very particular time window, we really need to capture the HTTP request going out on the wire from your machine and the response from the Web service. You can use Fiddler or any other HTTP analyzer of your choice to capture the HTTP traffic.

All comments

Alex Putkov.1

This is very strange. Are you able to consistently reproduce this? I just tried on my end, and I couldn't reproduce it. I got 60K ticks as expected, which is the max number of ticks the backend returns for a single request.

Chon11201120

Yes, it is very strange. I can always reproduce it. Have the code ".WithTimeZone(TimezoneType.Instrument)"?

Alex Putkov.1

Yes, I used the .WithTimeZone(TimezoneType.Instrument). Not that it matters because with the default value of TimezoneType.GMT the request still returns 60K ticks.

Is the issue you experience specific to this exact time window? Can you reproduce it if you request the same time window for today or for last Thursday? Or if you pick any window last Friday that is say 1 hour long?

Would you be able to use Fiddler to capture the HTTP request that goes on the wire? When you execute the request for the timeseries you should see an HTTP POST to https://amers1.timeseries.cp.thomsonreuters.com/ExternalSOAP_Handler endpoint containing the parameters of the request. The expected response to this request is an XML containing the list of chunks with the metadata for each chunk including the number of points.

zoya faberov

Hello @Chon11201120

Fully agree with @Alex Putkov.1 that the raw request should work and return 50k results. Suspecting two issues, from looking at the code.

Is a large request, may take long, would test it first on the same request, shortening the interval to a much smaller one, to see if you get the result quickly. For example:

request = timeSeries.SetupDataRequest("JPY=")
                .WithView("BID")
                .WithAllFields()
                .From(new DateTime(2020, 8, 4, 8, 21, 0))
                .To(new DateTime(2020, 8, 4, 9, 52, 0))
                 .WithInterval(CommonInterval.Tick)
                .OnDataReceived(DataReceivedCallback2)
                .WithTimeZone(TimezoneType.Instrument)
                .CreateAndSend();
        }

Not every tick has a volume. HasVolume results in false. Which would be why the callback may not print any results. Would try to see the results first, then tune the callback, for example:

  private void DataReceivedCallback2(DataChunk chunk)
        {
            foreach (ITickData tick in chunk.Records.ToTickRecords())
            {
                Console.WriteLine("Received Ticks");
                if (tick.Timestamp.HasValue && tick.Value.HasValue  )
                {
                    Console.WriteLine(
                        "time={0}: val={1} vol={2} ",
                        tick.Timestamp.Value,
                       tick.Value,
                        tick.Volume
                    );
                };
            }

Once you get the result back (?), may prefer to cut up the request interval into several smaller sub-intervals, so you can meet your requirement, and get the results back quickly.

Chon11201120

Hello .@zoya.farberov

Tried. I got the same problem.

Chon11201120

There is a big different about with and without the timezone specified.

My problem happens in the very specific time period with only NQc1 or NQU0. I can get ticks from any other period and also any other instruments, like YMc1.

I still can reproduce it now.

Chon11201120

I would like to emphasis the problem occurs ONLY with NQc1 within ONLY Sep 4 8:21 to 14:52.

I have tried with other time period with NQc1, the code works and can get a lot of tickets. For example, Sep 4 8:20 to 8:21 and Sep 4 14:52 to 14:53.

I have tried with other RICs, like YMc1. The code works and get a lot of tickets any time.

It is a problem specific to NQc1.

It is a problem specific to Sep 4 8:21 to 14:52 local exchange time zone.

With other timezone for Sep 4 8:21-14:52, they are simply different time.

For such a long period, there must be ticks with value and timestamp... You may find the BID/ASK information of the period by TAS. But the API did not get the ticks.

Any idea?

Alex Putkov.1

@Chon11201120

EXPLORE OUR SITES