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

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.

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

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.

Hello @clark.hon,

Fully agree with @Alex Putkov. 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.

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?