For a deeper look into our DataScope Select SOAP API, look into:
Overview | Quickstart | Documentation | Downloads | Tutorials
i've been told that I need to split up my requests because they're "big" (I will defend to the grave that they shouldn't be classified as big even 20 years ago..)
anyway, so now I have a 100 requests, each for a months worth of data.
can I submit them all in parallel with the same token?
any limits on the parallelization of requests?
what happens server side? are the sequentially queued and executing in order anyway?
thanks
Hello @opsp,
Kindly note, that developer advocates, the team that moderates Refinitiv developer forums, and that I am part of, are experts on usage of many Refinitiv APIs, however, we do not directly design either products or APIs, rather, we share knowledge of thereof, making learning APIs and integration efforts efficient and smooth for client developers...
However, the feedback from the customers is what helps Refinitiv improve and evolve products and APIs.
You may wish to share the feedback on product with your Refinitiv account manager, and on API design, with us, aggregating it into a paragraph, or otherwise, and we will convey it to the relevant product group within Refinitiv on your behalf.
Or a more direct way to share feedback with Refinitiv is via Feedback Form on My Refinitiv
Hello @opsp,
This information, in my opinion, very pertinent for a well-designed integration solution, is communicated to the designer in DSS BEST PRACTICES & FAIR USAGE, the last passage of this section we are looking at.
For the majority of the request types, the actual requests that execute in parallel will be only 2. The other 48 ( if you submit 50 as permitted) will be queued. I personally, as a designer, in this situation, prefer never to submit more then 2.
If you are requesting Historical References or Elektron Timeseries, the number of actual requests executing in parallel is one: "...concurrent extraction processing is not supported for Historical Reference and Elektron Timeseries report templates...". I prefer not to submit requests to be queued, unless it's the queuing capability, that you require.
... I know that this is not what you would prefer, but hope this is helpful to learn, before investing time and effort into threading the request onto 50 parallel executions, at design stage, as, in my understanding, you are now?
Hello @opsp,
Please refer to DSS BEST PRACTICES & FAIR USAGE doc, section Extraction Limits: Concurrent Requests per Report Template Type.
The limits will depend on what request types you require.
"... You can submit a maximum of 50 concurrent requests per report template for all report types except Corporate Actions and Terms and Conditions (Maximum Concurrent Requests per Report Template = 500) and Intraday Pricing (Maximum Concurrent Requests per Report Template = 1500). ...
The number of concurrent extractions that can be processed on a per-report and per-user basis is two for all report templates except Intraday Pricing, Historical Reference, Elektron Timeseries report templates. Intraday Pricing supports concurrent extraction processing of up to 50 reports. Concurrent extraction processing is not supported for Historical Reference and Elektron Timeseries report templates. Any remaining user extraction requests remain in a Queued status. Once the maximum concurrent extractions complete, the next set of requests will be processed, and so on, until all requests are completed. ..."
thanks. dont forget the last part of the question:
what happens server side? are the sequentially queued and executing in order anyway?
ie, what is the actual underlying parallelization paradigm? do you have any benchmarks for optimum pace as a function of thread/request count?
yep--you're totaly right..i'm not loving the limitations but happy you've taught me!!
thanks again.
