timesales-futures-demo.txt attached is a python demo to download some futures time/sales data. The example uses the polling described in your sample tutorial code. However, is there an alternative way to just post a bunch of requests, store the requestid, and then retrieve these results at a later time (e.g. skipping the pausing/polling step)? In the old version of tick history you could submit a bunch of requests. For each request you would get back a request id and then sometime later you could come back to request to download the requestid, provided it had finished populating. Can you describe how this works in the new service? i.e. there used to be ability to make multiple asynchronous calls.
New posts are disabled while we improve the user experience.
You can browse the site, or for urgent issues, raise a query at MyAccount.
465
●3 ●5 ●3
Yes, this is possible:
- Issue the request as you normally do, but add the header: "Prefer: respond-async; wait=0". This will force the server to return once the request has been accepted without waiting.
- The response will include a monitor URL, like Location: .../Extractions/ExtractRawResult(ExtractionId='0x05806d0534ac2064')
- You can invoke that URL any time in the future (within 7 days of the initial request) to either get the status if it is not complete or have the results returned.
The monitor location is the handle to your job results. Do not parse this or use any id's returned, just use the monitor URL as-is since we may change this at any time.
In the link above there is a section on in-flight job management for an alternative approach.
11
●6 ●3 ●7
I found a similar response re asynchronous calls via here:
-------------------------------------------------------------------
Answer by Christiaan Meihsl Jan 31 at 04:00 AM
In a nutshell: yes, and this is a desirable feature.
In detail: the DSS REST API asynchronous mechanism is designed to support long running requests, which pose several problems:
- they require the connection to remain open for the duration of the request (firewalls might close idle connections).
- the user code must maintain a running process for the duration of the request, which could be quite long for large data amounts.
- long running requests drive the need for periodic status updates and the ability to cancel the request.
The DSS REST API conforms to OASIS OData standards for async. In addition to the standard asynchronous protocol defined by OData, which supports polling and status and progress updates, we added the ability to cancel a request, as well as manage the list of active asynchronous jobs.
To avoid data retrieval issues, the recommend practice is to use the asynchronous mechanisms. Using synchronous mechanisms might result in issues, especially when requesting large data sets. The typical symptom will be data requests that timeout without returning any data; this can occur randomly, as the server load influences extraction times.
-------------------------------------------------------------------
This appears to describe the type of calls I wish to issue against the service. However, I do not see a comparable python example. Can you explain what needs to be modified in my example python code to let the service know I am making an asynchronous call?
