Instances of duplicates created cases

On our Pilot environment (Inter Mutuelles Assistance GIE – API – PILOT), we have had instances of duplicates created cases :

Tests carried out on Wednesday 07/06 at 10:20 a.m.

Case 1: Alban TALLUAU

Technical id refinitiv : 5jb7z0fs30311hqazmsddu707

correct caseID: PIVTALLUAUALBANF31265598

wrong caseID: PIVTALLUAUALBAN19791123

Case 2: Cedrick MARTIN

Technical id technique: 5jb6qgbnie8w1hqb7k67bg94m

correct caseID: LMDMARTINCEDRICKF31265642

wrong caseID : LMDMARTINCEDRICK19940114

In both cases, we only sent the correct caseID, but a case with the wrong caseID was created, although we did not send anything else

Can you verify that we only sent one case for each of the two examples. And maybe give us your logs of incoming requests from IMA PILOT account? We want to be sure the problem is on your end and not ours

Find more posts tagged with

worldcheck-one-api

#product

Accepted answers

kevin.borderon-ext

Hello @judith.pillado.lseg,

We have resolved our problem of duplicates cases. This ticket can be closed, thanks for your support.

Best regards,

Kévin

All comments

stephane.py

I forgot one point: the problem occurs when calling the "Patch" method of the API with the "ASYNC" parameter

judith.pillado.lseg

Hello@"stephane.py", thank you for reaching out. Unfortunately, we do not have access to the actual cases you (or any client) creates. However, can you please be more specific as to what your process looks like? For example, list the steps that you take when creating the cases, including all endpoints. Thanks.

Best,
Judith

judith.pillado.lseg

Hello @stephane.py - kindly look at my answer below and reply at your earliest convenience. Thank you!

stephane.py

Hello @judith.pillado.lseg

Here are some details:

The current steps that we use, are the next ones :

First of all, we check if our profil exists in IMA – Refinitiv Database

GET https://api-worldcheck.refinitiv.com/v2/caseReferences?caseId=PIVTALLUAUALBANF31265598

PIVTALLUAUALBANF31265598 : IMA code + Last name + First name + assistance case reference

Note: We changed our caseId, before we were using date of birth and now we use the assistance case reference

Two cases:

First case: Profil not referenced

API answers 404, so we create our new profil in IMA – Refinitiv Database, with :

POST https://api-worldcheck.refinitiv.com/v2/cases/saveAndScreen

With a body like this one :

The API answers, for i.e : Data to sign (request-target): post /v2/cases/saveAndScreen

We transform the received object in another object: CaseReferenceDetails(name, caseId, caseSystemId, nameTransposition, caseScreeningState, errors)

Then we request the new profil, in order to determine the profil status in Refinitiv database :

GET https://api-worldcheck.refinitiv.com/v2/caseReferences?caseId=PIVTALLUAUALBANF31265598

The API answers for i.e : Data to sign (request-target): get /v2/caseReferences

We transform the received object in another object: CaseReference(caseSystemId, caseId)

Finally, we update the profil in IMA – Refinitiv Database, with :

PATCH https://api-worldcheck.refinitiv.com/v2/cases/5jb7z0fs30311hqazmsddu707?screen=ASYNC

With a body like this one :

{"caseId":"PIVTALLUAUALBANF31265598","name":"ALBAN TALLUAU","providerTypes":["WATCHLIST"],"customFields":[{"typeId":"5jb7gvalygto1grja9cr08fjh","value":"F31265598","dateTimeValue":null}],"secondaryFields":[{"typeId":"SFCT_1","value":"UNSPECIFIED","dateTimeValue":null},{"typeId":"SFCT_2","value":null,"dateTimeValue":"19791123"},{"typeId":"SFCT_3","value":"FRA","dateTimeValue":null}],"nameTransposition":false}

The API answer for i.e: Data to sign (request-target): patch /v2/cases/5jb7z0fs30311hqazmsddu707

where 5jb7z0fs30311hqazmsddu707 is the technical Refinitiv Id

Second case: Profil referenced

The API answers 200, for i.e : Data to sign (request-target): get /v2/caseReferences

We transform the received object in another object: CaseReference(caseSystemId, caseId)

Finally, we update the profil in IMA – Refinitiv Database, with :

PATCH https://api-worldcheck.refinitiv.com/v2/cases/5jb7z0fs30311hqazmsddu707?screen=ASYNC

With a body like this one :

The API answer for i.e: Data to sign (request-target): patch /v2/cases/5jb7z0fs30311hqazmsddu707

5jb7z0fs30311hqazmsddu707 : Technical Refinitiv Id

To conclude, in both cases we have to use the patch method on our profil, in case we have some changements in our data.

stephane.py

Another exemple:

we sent only one case:

and two cases are created:

stephane.py

details on the wrong caseID

stephane.py

And the full logs of the corresponding case: (the time stamps of the servers are shifted by 2 hours, but it is in fact the same time )

-2023-06-15 16:13:12.245 - INFO 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.LoggingRequestInterceptor : ===========================request begin================================================

-2023-06-15 16:13:12.245 -DEBUG 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.LoggingRequestInterceptor : URI : https://api-worldcheck.refinitiv.com/v2/caseReferences?caseId=AZDBILLESYVESF31266512

-2023-06-15 16:13:12.245 -DEBUG 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.LoggingRequestInterceptor : Method : GET

-2023-06-15 16:13:12.245 -DEBUG 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.LoggingRequestInterceptor : Headers : {Cache-Control=no-cache, Accept=application/json, Authorization=Signature keyId="e63b7d82-8c35-4c6b-ba17-9c3cdba89b4c",algorithm="hmac-sha256",headers="(request-target) host date",signature="63XvQU2fN9XRAGQhgypo5pwlyxkPPAKKwGRdxfopVVs=", Date=Thu, 15 Jun 2023 14:13:12 GMT}

-2023-06-15 16:13:12.245 - INFO 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.LoggingRequestInterceptor : ==========================request end================================================

-2023-06-15 16:13:12.246 - INFO 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.RefinitivInterceptors : Data to sign (request-target): get /v2/caseReferences

host: api-worldcheck.refinitiv.com

date: Thu, 15 Jun 2023 14:13:12 GMT

-2023-06-15 16:13:12.794 - INFO 22544 --- [or-http-epoll-4] f.i.o.m.d.i.c.LoggingRequestInterceptor : ============================response begin==========================================

-2023-06-15 16:13:12.794 -DEBUG 22544 --- [or-http-epoll-4] f.i.o.m.d.i.c.LoggingRequestInterceptor : Status code : 404

-2023-06-15 16:13:12.794 -DEBUG 22544 --- [or-http-epoll-4] f.i.o.m.d.i.c.LoggingRequestInterceptor : Status text : Not Found

-2023-06-15 16:13:12.794 -DEBUG 22544 --- [or-http-epoll-4] f.i.o.m.d.i.c.LoggingRequestInterceptor : Headers : {Date=Thu, 15 Jun 2023 14:13:12 GMT, Content-Type=application/json, Transfer-Encoding=chunked, Connection=keep-alive, Cache-Control=no-cache, no-store, max-age=0, must-revalidate, Pragma=no-cache, Expires=0, Content-Security-Policy=default-src 'none'; frame-ancestors 'none', Strict-Transport-Security=max-age=15552000; includeSubDomains, X-Frame-Options=DENY, X-XSS-Protection=1; mode=block, X-Content-Type-Options=nosniff}

-2023-06-15 16:13:12.794 - INFO 22544 --- [or-http-epoll-4] f.i.o.m.d.i.c.LoggingRequestInterceptor : =======================response end=================================================

-2023-06-15 16:13:12.834 - INFO 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.RefinitivInterceptors : Data to sign (request-target): post /v2/cases/saveAndScreen

host: api-worldcheck.refinitiv.com

date: Thu, 15 Jun 2023 14:13:12 GMT

content-type: application/json

content-length: 909

{"groupId":"5jb7gvalygto1gqcvzppqojy9","providerTypes":["WATCHLIST"],"nameTransposition":true,"caseScreeningState":{"WATCHLIST":"INITIAL"},"cases":[{"caseId":"AZDBILLESYVESF31266512","entityType":"INDIVIDUAL","name":"YVES BILLES","customFields":[{"typeId":"5jb7gvalygto1grja9cr08fjh","value":"F31266512","dateTimeValue":null}],"secondaryFields":[{"typeId":"SFCT_1","value":"UNSPECIFIED","dateTimeValue":null},{"typeId":"SFCT_2","value":null,"dateTimeValue":"19780814"},{"typeId":"SFCT_3","value":"FRA","dateTimeValue":null}]},{"caseId":"PRFVALATTHIERRYF31266532","entityType":"INDIVIDUAL","name":"THIERRY VALAT","customFields":[{"typeId":"5jb7gvalygto1grja9cr08fjh","value":"F31266532","dateTimeValue":null}],"secondaryFields":[{"typeId":"SFCT_1","value":"UNSPECIFIED","dateTimeValue":null},{"typeId":"SFCT_2","value":null,"dateTimeValue":"19740621"},{"typeId":"SFCT_3","value":"FRA","dateTimeValue":null}]}]}

-2023-06-15 16:13:12.834 - INFO 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.LoggingRequestInterceptor : ===========================request begin================================================

-2023-06-15 16:13:12.834 -DEBUG 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.LoggingRequestInterceptor : URI : https://api-worldcheck.refinitiv.com/v2/cases/saveAndScreen

-2023-06-15 16:13:12.834 -DEBUG 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.LoggingRequestInterceptor : Method : POST

-2023-06-15 16:13:12.834 -DEBUG 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.LoggingRequestInterceptor : Headers : {Cache-Control=no-cache, Accept=application/json, Content-Type=application/json, Authorization=Signature keyId="e63b7d82-8c35-4c6b-ba17-9c3cdba89b4c",algorithm="hmac-sha256",headers="(request-target) host date content-type content-length",signature="YerXg6lavKE0FE9M6TK9Yvsxx025wRR8MGvG5MkQWBI=", Date=Thu, 15 Jun 2023 14:13:12 GMT}

-2023-06-15 16:13:12.834 - INFO 22544 --- [tch_ion_lot2156] f.i.o.m.d.i.c.LoggingRequestInterceptor : ==========================request end================================================

-2023-06-15 16:13:13.176 - INFO 22544 --- [or-http-epoll-4] f.i.o.m.d.i.c.LoggingRequestInterceptor : ============================response begin==========================================

-2023-06-15 16:13:13.177 -DEBUG 22544 --- [or-http-epoll-4] f.i.o.m.d.i.c.LoggingRequestInterceptor : Status code : 200

-2023-06-15 16:13:13.178 -DEBUG 22544 --- [or-http-epoll-4] f.i.o.m.d.i.c.LoggingRequestInterceptor : Status text : OK

-2023-06-15 16:13:13.178 -DEBUG 22544 --- [or-http-epoll-4] f.i.o.m.d.i.c.LoggingRequestInterceptor : Headers : {Date=Thu, 15 Jun 2023 14:13:13 GMT, Content-Type=application/json, Transfer-Encoding=chunked, Connection=keep-alive, Cache-Control=no-cache, no-store, max-age=0, must-revalidate, Pragma=no-cache, Expires=0, Content-Security-Policy=default-src 'none'; frame-ancestors 'none', Strict-Transport-Security=max-age=15552000; includeSubDomains, X-Frame-Options=DENY, X-XSS-Protection=1; mode=block, X-Content-Type-Options=nosniff}

-2023-06-15 16:13:13.178 - INFO 22544 --- [or-http-epoll-4] f.i.o.m.d.i.c.LoggingRequestInterceptor : =======================response end=================================================

judith.pillado.lseg

Hi @stephane.py - thanks for the detailed response! I will look into it now and will report back my findings as soon as I can.

Blessings,

Judith

agnes.talluau

Bonjour Judith, Avez vous pu avancer sur notre problème.

Sans réponse de votre part, nous ne pouvons pas mettre en production.

Merci.

Agnès TALLUAU

judith.pillado.lseg

Hello @stephane.py, thank you for your patience while I gathered the information.

I have investigated the logs for the date of June 15, specifically the time that you have mentioned, and I can confirm that there was a single POST request sent AFTER you determined the if the Case ID was existent or not. There are no consecutive POST or PATCH endpoints within the logs, which would indicate that a duplicate case was created with the API. I am unable to attach the logs here, but I have emailed you directly and have attached them. Kindly review them at your earliest convenience.

As the next step, we can set up a call where we can go through your application to determine why there is a duplication of cases. Please feel free to respond to the email with your availability if you do desire to meet.

Blessings,

Judith

judith.pillado.lseg

Hello @agnes.talluau - apologies, I do not speak French. Kindly look at my response below.

agnes.talluau

Hello,

Nous avons besoin des logs de la journée du Vendredi 07 Juin (début des tests 10h20 - heure France).

Pouvez-vous nous les faire parvenir rapidement ?

Merci

kevin.borderon-ext

Hello @judith.pillado.lseg,

We are currently analyzing the two logs send (07th & 15th June), and we have found some calls that's seemed not be send by our side, for i.e logs from the 07/Jun/2023:08:29:06 +0000

To find others clues, is it possible to send us the log for the 13th June, we have made some tests at 2p.m, thanks.

Best regards,

Kévin

judith.pillado.lseg

Hi @kevin.borderon-ext - thanks for your message. I have emailed you the logs.

Blessings,

Judith

kevin.borderon-ext

Hello @judith.pillado.lseg,

We have resolved our problem of duplicates cases. This ticket can be closed, thanks for your support.

Best regards,

Kévin

judith.pillado.lseg

Hi Kevin, thank you for the update. Would you mind letting me know your findings and the steps you took to resolve? Thanks!

Blessings,

Judith

EXPLORE OUR SITES