question

Upvotes
Accepted
69 9 17 18

TRTH v1 Webservice API TR Page requests

Hi all,

the current TRTH v1 Webservice API is offering a method to request TR pages. In the Web-Frontend this function is labeled as "SpeedGuide", in the WebService the method is just called "getPage".

Is it possible to use this method and to request pages using the REST API (DSS) as well?

If yes, can you provide more details on how to do this? Maybe a Postman example?

If no, can you please tell me if it is planned to support this, and what is the ETA for this development?

Thx!

dss-rest-apitick-history-rest-apipagespeedguide
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

@Philipp

Can you give an example of one of the pages you'd like to retrieve ?

For example this three pages: CNTSYFIX1, CNTSYFIX2, CNTSYFIX3

Let me look into this ...

Upvotes
Accepted
13.7k 26 8 12

@Philipp

There is not explicit page endpoint, however you can retrieve page data using the raw extraction report template. POST to the Extractions/ExtractRaw endpoint the following body:

{
  "ExtractionRequest": {
    "@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.TickHistoryRawExtractionRequest",
    "IdentifierList": {
      "@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.InstrumentIdentifierList",
      "ValidationOptions": {
        "AllowHistoricalInstruments": true
      },
      "UseUserPreferencesForValidationOptions": false,
      "InstrumentIdentifiers": [{
        "Identifier": "CNTSYFIX1",
        "IdentifierType": "Ric"
      }]
    },
    "Condition": {
      "MessageTimeStampIn": "GmtUtc",
      "ReportDateRangeType": "Range",
      "QueryStartDate": "2017-01-04T00:00:00.000Z",
      "QueryEndDate": "2017-01-05T00:00:00.000Z",
      "ExtractBy": "Ric",
      "SortBy": "SingleByRic",
      "DomainCode": "MarketPrice",
      "DisplaySourceRIC": true
    }
  }
}

Important note: see the ValidationOptions in the request. Page data will only be returned if you allow historical instruments in the validation options. This can be done in the request itself, or in your preferences (but this would allow it on a global scale, for all your request, so this is not necessarily what you want to do !).

The workflow for retrieving raw data is described in REST API Tutorial 3. In a nutshell, it is the following:

  1. Send request, receive response with HTTP status 202 Accepted. Body is empty. From the header of that response, pull out the value of field Location. That is a URL, like https://hosted.datascopeapi.reuters.com/RestApi/v1/Extractions/ExtractRawResult(ExtractionId='0x058e7d29ec5b5871')
  2. Run a GET on that URL. It might return a 202 again if the data is not ready yet.
  3. Repeat step 2 until you receive a 200 OK. The body of the response contains a JobId (a string): "JobId": "0x058e7d29ec5b5871"
  4. Run a GET on the following endpoint, which uses the JobId value as a parameter in the URL: Extractions/RawExtractionResults('0x058e7d29ec5b5871')/$value

This will deliver the data:

#RIC,Domain,Date-Time,Type,MsgClass/FID number,UpdateType/Action,FID Name,FID Value,FID Enum String,PE Code,Template Number,Key/Msg Sequence Number,Number of FIDs
CNTSYFIX1,Market Price,2017-01-04T03:25:06.576936652Z,Raw,UPDATE,UNSPECIFIED,,,,5144,,606,18
,,,FID,321,,ROW80_7,"[0`BOC CN                   /        |       /        |       /        |       /   ",
,,,FID,322,,ROW80_8,"[0`BOCI CN                  /        |       /        |       /        |       /   ",
,,,FID,323,,ROW80_9,"[0`PING AN SECS             /        |       /        |       /        |       /   ",
,,,FID,324,,ROW80_10,"[0`CIB SH                   /        |       /        |       /        |       /   ",
,,,FID,325,,ROW80_11,"[0`CMB CN                   /        |       /        |       /        |       /   ",
,,,FID,326,,ROW80_12,"[0`CITIC BK                 /        |       /        |       /        |       /   ",
,,,FID,327,,ROW80_13,"[0`EVRBRIT BK               /        |       /        |       /        |       /   ",
,,,FID,328,,ROW80_14,"[0`GTJA SECS                /        |       /        |       /        |       /   ",
,,,FID,329,,ROW80_15,"[0`SEALAND SECS             /        |       /        |       /        |       /   ",
,,,FID,330,,ROW80_16,"[0`ICBC CN                  /        |       /        |       /        |       /   ",
,,,FID,331,,ROW80_17,"[0`NANJING BK               /        |       /        |       /        |       /   ",
,,,FID,332,,ROW80_18,"[0`SHANGHAI BK              /        |       /        |       /        |       /   ",
,,,FID,333,,ROW80_19,"[0`SWHY SECS                /        |       /        |       /        |       /   ",
,,,FID,335,,ROW80_21,"[0`TODAY'S MID                       |                |                |           ",
,,,FID,336,,ROW80_22,"[0`NET CHG.                          |                |                |           ",
,,,FID,337,,ROW80_23,[0`PREV MID                   2.6662 |         2.7562 |         2.7821 |         2.,
,,,FID,339,,ROW80_25,"[0`TODAY'S RATES            /        |       /        |       /        |       /   ",
,,,FID,315,,ROW80_1,"[0`12:25 04JAN17 ",
CNTSYFIX1,Market Price,2017-01-04T03:30:06.377479953Z,Raw,UPDATE,UNSPECIFIED,,,,5144,,622,17
,,,FID,321,,ROW80_7,[0`BOC CN             2.8039/ 2.7039 | 2.8461/ 2.7461 | 2.8695/ 2.7695 | 2.9297/ 2.,
,,,FID,322,,ROW80_8,[0`BOCI CN            2.8000/ 2.7400 | 2.8400/ 2.7800 | 2.8600/ 2.8000 | 2.9200/ 2.,
,,,FID,323,,ROW80_9,[0`PING AN SECS       2.7900/ 2.6900 | 2.8400/ 2.7400 | 2.8700/ 2.7700 | 2.9200/ 2.,
,,,FID,324,,ROW80_10,"[0`CIB SH                UNQ/    UNQ |    UNQ/    UNQ |    UNQ/    UNQ |    UNQ/   ",
,,,FID,325,,ROW80_11,[0`CMB CN             2.8300/ 2.7300 | 2.9500/ 2.8500 | 2.9700/ 2.8700 | 2.9800/ 2.,
,,,FID,326,,ROW80_12,[0`CITIC BK           2.8100/ 2.7300 | 2.8600/ 2.7800 | 2.8800/ 2.8000 | 2.9400/ 2.,
,,,FID,327,,ROW80_13,[0`EVRBRIT BK         2.9300/ 2.3500 | 3.0497/ 2.7000 | 2.9500/ 2.6000 | 2.9900/ 2.,
,,,FID,328,,ROW80_14,[0`GTJA SECS          2.8000/ 2.7000 | 2.8500/ 2.7500 | 2.8700/ 2.7700 | 2.9300/ 2.,
,,,FID,329,,ROW80_15,[0`SEALAND SECS       2.7600/ 2.7300 | 2.8100/ 2.7700 | 2.8400/ 2.7900 | 2.8800/ 2.,
,,,FID,330,,ROW80_16,[0`ICBC CN            2.7700/ 2.7500 | 2.8200/ 2.7900 | 2.8400/ 2.8100 | 2.9000/ 2.,
,,,FID,331,,ROW80_17,[0`NANJING BK         2.7900/ 2.7400 | 2.8200/ 2.7800 | 2.8300/ 2.8000 | 2.9100/ 2.,
,,,FID,332,,ROW80_18,[0`SHANGHAI BK        2.7800/ 2.7200 | 2.8300/ 2.7700 | 2.8500/ 2.7900 | 2.9100/ 2.,
,,,FID,333,,ROW80_19,[0`SWHY SECS          2.8500/ 2.6500 | 3.0000/ 2.9000 | 2.8600/ 2.8100 | 2.8900/ 2.,
,,,FID,335,,ROW80_21,[0`TODAY'S MID                2.7555 |         2.8132 |         2.8231 |         2.,
,,,FID,336,,ROW80_22,[0`NET CHG.                   0.0893 |         0.0570 |         0.0410 |         0.,
,,,FID,339,,ROW80_25,[0`TODAY'S RATES      2.8005/ 2.7180 | 2.8545/ 2.7708 | 2.8624/ 2.7913 | 2.9200/ 2.,
,,,FID,315,,ROW80_1,"[0`12:30 04JAN17 ",
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Thanks a lot! I will have a detailed look at this. Looks like exactly what we need.

Upvotes
69 9 17 18

At first, thatnks for your help so far!

I have had a closer look at this way to request TR pages. As a peace of background, we are using this TR pages to cut out values for our processing logic. Customers are therefore defining cut out positions on TR pages. This is why it is very important for us to get the pages in exactly the right format (as in the SpeedGuide application).

I have made some further tests with other page request in the last hours. It look like this way of extraction you suggested above is delivering page update 'commands', it that correct?

In general it may work to use this information to construct the page content and then to re-apply the cut out mechanisms. This would mean additional effort to create a re-construction logic but may be a possible (maybe costly) way, as long as the update 'commands' are done in a common way for all pages.

I have executed this extraction for other pages and I got the impression that the update way for TR pages it not common for all of them. Can you please investigate if that is the case? If there are different update mechanisms for TR pages it will be impossible for us to implement converters etc. for all of the pages and this may even be very unstable due to changes in the page update mechanisms.

This is the DSS body of the example i have executed:

{ "ExtractionRequest": { "@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.TickHistoryRawExtractionRequest", "IdentifierList": { "@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.InstrumentIdentifierList", "ValidationOptions": { "AllowHistoricalInstruments": true }, "UseUserPreferencesForValidationOptions": false, "InstrumentIdentifiers": [{ "Identifier": "KIEVPRIME2", "IdentifierType": "Ric" }] }, "Condition": { "MessageTimeStampIn": "GmtUtc", "ReportDateRangeType": "Range", "QueryStartDate": "2016-09-29T00:00:00.000Z", "QueryEndDate": "2016-09-30T00:00:00.000Z", "ExtractBy": "Ric", "SortBy": "SingleByRic", "DomainCode": "MarketPrice", "DisplaySourceRIC": true } } }

I have also attached a screenshot of the SpeedGuide. This is the page content we are getting at the moment, and the format we need for our cut out logic.

Thanks for you help in advance!


icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
13.7k 26 8 12

@Philipp

Pages are difficult to handle, it is best to try to get the same data using logicized RICs !

Pages are not all updated in the same way. It seems CNTSYFIX1 only delivers full row UPDATEs, which are manageable, but we see KIEVPRIME2 is different: I retrieved its data since begin of this year, and received a set of partial UPDATE messages, as well as a single REFRESH message on 7 Jan 2017, with the entire content. A REFRESH delivers the full image of the entire page, which is easy to manage, whereas a partial UPDATE only delivers what has changed, encoded as individual changes to specific positions in the line.

The way pages are contributed and updated is beyond the scope of the API. I strongly advice you check with the Thomson Reuters support desk if the same data would also be available using RICs that deliver logicized data instead of pages, to avoid (as much as possible) use of pages, which as we see here can be difficult.

For the particular case of KIEVPRIME2 you will find the alternative RICs in the 1st column: the first one is KIEVPRIME=EFGU, a chain RIC which contains RICs KIEVPRIMEOND=EFGU, KIEVPRIME1WD=EFGU, etc.

As an example, to retrieve EoD prices for KIEVPRIME1WD=EFGU, here is the body of the ElektronTimeSeries POST request for to the Extractions/ExtractRaw endpoint:

{
  "ExtractionRequest": {
    "@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.ElektronTimeseriesExtractionRequest",
    "ContentFieldNames": [
      "Instrument ID",
      "Bid",
      "Ask",
      "Trade Date"
    ],
    "IdentifierList": {
      "@odata.type": "#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.InstrumentIdentifierList",
        "ValidationOptions": {
          "AllowHistoricalInstruments": true
        },
        "InstrumentIdentifiers": [
        {
          "Identifier": "KIEVPRIME1WD=EFGU",
          "IdentifierType": "Ric"
        }
      ]
    },
    "Condition": {
      "StartDate": "2016-01-01T00:00:00.000-00:00",
      "EndDate": "2016-12-31T00:00:00.000-00:00"
    }
  }
}

Note: for this instrument we must include the AllowHistoricalInstruments validation option.

It delivers the data:

Instrument ID,Bid,Ask,Trade Date
KIEVPRIME1WD=EFGU,18.5,19.5,2016/01/05
KIEVPRIME1WD=EFGU,18.5,19.5,2016/01/06
KIEVPRIME1WD=EFGU,18.5,19.5,2016/01/11
KIEVPRIME1WD=EFGU,18.5,19.5,2016/01/12
KIEVPRIME1WD=EFGU,18.5,19.5,2016/01/13
KIEVPRIME1WD=EFGU,18.5,19.5,2016/01/14
KIEVPRIME1WD=EFGU,18.5,19.5,2016/01/15
KIEVPRIME1WD=EFGU,,,2016/01/16
etc.

Hope this helps.


kievprime2.png (12.8 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

One thing I can say for sure: This really helps! Thx again!

Looks like TR pages via DSS are no longer an option for us.

I will get in touch with product development and our customers. We already offer both ways in our application, extraction by RIC and (for legacy reasons) extraction by TR Pages cut out mechanism. Maybe it is possible to fully switch to RIC based requests at the end of 2017. I will check that.

If that is not possible, is there another way in the TR world to request a TR page? Maybe not via DSS but using another tool? Maybe a standalone version of the SpeedGuide?

Do you need the latest snapshot, or historical data ?

We need historical data. We need the possibility to request pages for any given date and time.

Show more comments
Click below to post an Idea Post Idea