DSS API ScheduleExtractNow no response after 60 seconds

mdoberschuetz
mdoberschuetz Explorer

We use the following endpoint:

(https://hosted.datascopeapi.reuters.com/RestApi/v1/Extractions/Schedules('{0}')/ThomsonReuters.Dss.Api.Extractions.ScheduleExtractNow)

to force a schedule on DSS REST API.

We have noticed that no response comes back after 30 seconds. For long running requests we would expect a response with a HTTP StatusCode of 202 Accepted and a "monitor" url in the Location header to come back after that time.

We do not provide the Prefer header.

The call made before ScheduleExtractNow - RequestToken is successful.

I can provide ClientSessionId if required?

Best Answer

  • @mdoberschuetz

    According to the Async key machanism, the API defaults to synchronous responses.

    For long running requests, you need to define "respond-async" in the Prefer header to receive asynchronous responses such as HTTP statusCode of 202 Accepted and a monitor url.

    Could you try adding the "respond-async" in the Prefer header?

Answers

  • I can add the "Prefer:respond-async" header, but let me just understand what is going on at the moment when I send requests to the API.

    Ok so my request is treated as synchronous, so should I wait indefinitely for a response from the API? I will not receive a 202 response after a certain amount of time?

    What does the "30 second timeout" refer to in the following documentation:

    https://developers.thomsonreuters.com/datascope-select-dss/datascope-select-rest-api/docs?content=5598&type=documentation_item

    under the "How can I set my request to be asunchronous or sunchronous?" header?

  • @mdoberschuetz

    If the request is synchronous, you need to wait indefinitely for a
    response from API. You will not receive any 202 response. However, as
    stated in the Async Key mechanisms, this will fail if the request takes more than 25 minutes to process, after which the Thomson Reuters firewalls will disconnect the idle request.

    According to ODATA spec, the wait preference is used to specify upper
    bound on the length of time, in seconds, the client is prepared to wait
    for the service to process the request synchronously once it has been
    received.

    • If the request is asynchronous and the wait preference is specified,
      • API will respond synchronously, if the request take less than the specific length of time to process.
      • API will respond asynchronously, if the request take more than the specified length of time to process.
    • If the request is synchronous, API may interpret the wait as a request to timeout after the specified period of time.
  • @mdoberschuetz

    As an added note to Veerapath's excellent answers, it is a best practice to systematically add the "respond-async" in the Prefer header, because by defining that you want to use async mode there is no uncertainty on the workflow, and your program can work on other things instead of waiting idly for results.