@lmeyeridricks

Let us do a live test to determine the reason for this.

Will you be available for a call on Monday. Let me send you a webex invite to your email address so that we can connect to test and fix this.

@lmeyeridricks

Can you please provide us the request headers and response headers from Postman Console both for the failed request and the successful request?

You can use Ctrl+Alt+C to open the Postman console in Postman.

Hello @Irfan.Khan

Here is the information you asked for. Nothing changed about the request body in between making these two requests. It is the same one as in my initial post. I just hit the send button again until it worked.

FAILURE (400):

Request Headers:

Date: Thu, 09 Jan 2020 09:35:46 GMT
Content-Type: application/json
Authorization: Signature keyId="{OUR_KEY_ID}",algorithm="hmac-sha256",headers="(request-target) host date content-type content-length",signature="rejW9suyS5T/XOfK+7/JDH7aopqVhMCldhKil+gD7Lg="
Content-Length: 639
User-Agent: PostmanRuntime/7.20.1
Accept: */*
Cache-Control: no-cache
Postman-Token: 21d799e8-27b0-4699-a290-b725fb814e2c
Host: rms-world-check-one-api-pilot.thomsonreuters.com
Accept-Encoding: gzip, deflate
Connection: keep-alive

Response Headers:

Transfer-Encoding: chunked
Date: Thu, 09 Jan 2020 09:35:47 GMT
Connection: close
Server: ""

Response Body:

null

SUCCESS (200):

Request Headers:

Date: Fri, 10 Jan 2020 08:01:11 GMT
Content-Type: application/json
Authorization: Signature keyId="{OUR_KEY_ID}",algorithm="hmac-sha256",headers="(request-target) host date content-type content-length",signature="rNJJOPV2i3yOtXPN4BJ2VSmKuVgeIPzCa2t5htGdjsA="
Content-Length: 639
User-Agent: PostmanRuntime/7.20.1
Accept: */*
Cache-Control: no-cache
Postman-Token: 39c1a443-d3c9-4d4c-b494-00d4b8e254d2
Host: rms-world-check-one-api-pilot.thomsonreuters.com
Accept-Encoding: gzip, deflate
Connection: keep-alive

Response Headers:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Date: Fri, 10 Jan 2020 08:01:14 GMT
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Server: ""
Connection: close

Response Body

{
    "caseId": "LOCAL_TEST_448eaadd-58cd-46df-9db7-4167572231af_2",
    "results": [
        {
            "resultId": "5nzbfq8s45qw1eb02fkn5fzwc",
            "referenceId": "e_tr_wci_2692",
            "matchStrength": "EXACT",
            "matchedTerm": "PUTIN,Vladimir Vladimirovich",
            "submittedTerm": "Влади́мир Влади́мирович Пу́тин",
            "matchedNameType": "AKA",
            "secondaryFieldResults": [
                ... etc
            ],
            "sources": [
                "b_trwc_PEP N"
            ],
            "categories": [
                "PEP"
            ],
            "creationDate": "2020-01-10T08:01:14.508Z",
            "modificationDate": "2020-01-10T08:01:14.508Z",
            "primaryName": "Vladimir PUTIN",
            
            ... etc
        }
    ]
}

We are experiencing exactly the same problem. Some requests fail randomly, then succeed with the exact same payloads.

@dmitry34

We have had a live test where it seems that the special characters in the 'name' field have been the cause. @Irfan.Khan was able to replicate the behavior on his side.

It seems (so far) to work reliably in Pilot using only the standard english alphabet characters [a-zA-Z]. It fails occasionally (but succeeds after some retries) with non-standard characters as in my examples above (Влади́мир Влади́мирович Пу́тин).

Irfan has said that a ticket will be raised to investigate the issue.

@dmitry34

We received feedback from Irfan Khan that the issue had been resolved on Pilot. I have retested with party names:

Влади́мир Влади́мирович Пу́тин

习近平

Recep Tayyip Erdoğan

بشار حافظ الأسد

And all of these now work consistently (for us) on Pilot. We never noticed any issue on the Production environment.