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

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!
Best Answer
-
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.
0
Answers
-
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.
0 -
Yes, it is very strange. I can always reproduce it. Have the code ".WithTimeZone(TimezoneType.Instrument)"?
0 -
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.
0 -
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.
0 -
Hello .@zoya.farberov
Tried. I got the same problem.
0 -
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.
0 -
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?
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 687 Datastream
- 1.4K DSS
- 622 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 557 WebSocket API
- 38 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 276 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.9K Refinitiv Data Platform
- 679 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 91 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛