On TRTH REST API, Is there a better way to find if there was an error ?

When the RIC is wrong I get a 200 status code and I have
inspect/parse the notes trying to understand if there was an error. Is there a
better way to find if there was an error ? For example, when the start date is
after the end date I get a 4xx http status code. How do I understand
that there was an error ?
Extraction Services Version 11.0.36705 (cbb5015f7377), Built
May 2 2017 18:05:54
User ID: 9012332
Extraction ID: 2000000000470676
Schedule: 0x05bb4169ad8b3016 (ID = 0x0000000000000000)
Input List (1 items): (ID = 0x05bb4169ad8b3016)
Created: 25/05/2017 15:30:11 Last Modified: 25/05/2017 15:30:11
Report Template (24 fields): _OnD_0x05bb4169ad8b3016 (ID =
0x05bb4169bf1b3016) Created: 25/05/2017 15:30:04 Last Modified: 25/05/2017
15:30:04
Schedule dispatched via message queue (0x05bb4169ad8b3016)
Schedule Time: 25/05/2017 15:30:05
Processing started at 25/05/2017 15:30:05
Processing completed successfully at 25/05/2017 15:30:11
Extraction finished at 25/05/2017 14:30:11 UTC, with
servers: x04q13
Instrument <RIC,ESM9^9> expanded to 0 RICS.
Report suppressed because there are no instruments
Best Answer
-
I see two parts to the question:
1) How are errors handled? 2) How is “incorrect” data handled?An error response to a request
indicates the entire request failed to execute. This means the input
parameters supplied to the API were sufficiently bad that no sense could be
made of the request. Some requests allow data to be incorrect in some
way, but the incorrect data is not a sufficient reason to fail the whole
request.At the REST level, errors are
reported via HTTP status codes. A message is part of the response as
well. The client SDK translates the HTTP status codes into
exceptions.See: https://hosted.datascopeapi.reuters.com/RestApi.Help/Home/StatusCodes
Incorrect data such as an
unknown RIC supplied as input to an on-demand extraction do not cause the whole
extraction to fail. So they are not worthy of a REST API error.
However, the incorrect data IS worthy of being noted in the
response. The types of output vary by API endpoint used. Generally
speaking, this means the API returns data that indicates some sort of warning
condition.0
Answers
-
Hello @Beera.Rajesh
You should use HistoricalSearch function to verify if a RIC is valid.
For example:
Request:
POST https://hosted.datascopeapi.reuters.com/RestApi/v1/Search/HistoricalSearch
Authorization: Token <your_auth_token_goes_here>
Content-Type: application/json
Accept-Charset: UTF-8
Prefer: respond-async
{
"Request": {
"Identifier": "TRI.N",
"IdentifierType": "Ric",
"Range": {
"Start": "2017-01-01T00:00:00.000Z",
"End": "2017-05-24T00:00:00.000Z"
}
}
}Response: if the RIC is valid, the field Status in the response is "Valid". The Status field
indicates the the validity of the instrument represented.
HTTP/1.1 200 OK
{
"@odata.context": "https://hosted.datascopeapi.reuters.com/RestApi/v1/$metadata#Collection(ThomsonReuters.Dss.Api.Search.HistoricalSearchResult)",
"value": [
{
"Identifier": "TRI.N",
"IdentifierType": "Ric",
"Source": "",
"Key": "VjF8MHgzMDAwMDAwMDAwMDAwMDAwfDB4MzAwMDAwMDAwMDAwMDAwMHx8fHx8fHxUUkkuTnw",
"Description": "Historical Instrument",
"InstrumentType": "Unknown",
"Status": "Valid",
"DomainCode": "6",
"FirstDate": "1996-01-02T00:00:00.000Z",
"LastDate": "2017-05-26T00:00:00.000Z",
"History": []
}
]
}For more details of the function, please refer to
HistoricalSearch in REST API Reference Tree
Based on my test, if the RIC is wrong, empty value is returned:
Request:
POST https://hosted.datascopeapi.reuters.com/RestApi/v1/Search/HistoricalSearch
Authorization: Token <your_auth_token_goes_here>
Content-Type: application/json
Accept-Charset: UTF-8
Prefer: respond-async
{
"Request": {
"Identifier": "ESM9^9",
"IdentifierType": "Ric",
"Range": {
"Start": "2017-01-01T00:00:00.000Z",
"End": "2017-05-24T00:00:00.000Z"
}
}
}Response:
HTTP/1.1 200 OK
{
"@odata.context": "https://hosted.datascopeapi.reuters.com/RestApi/v1/$metadata#Collection(ThomsonReuters.Dss.Api.Search.HistoricalSearchResult)",
"value": []
}0 -
Thank you for the response, but client is more keen about how to identify the errors not just incase of RIC invalidity but in general if they receive any error after performing an extraction.
0 -
I have contacted TRTH specialist, Thomson-DSS_SWAT@thomson.com, who should be able to help you on this.
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
- 690 Datastream
- 1.4K DSS
- 629 Eikon COM
- 5.2K Eikon Data APIs
- 11 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 559 WebSocket API
- 39 FX Venues
- 15 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 25 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 279 Open PermID
- 45 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 716 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
- 106 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 95 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛