Erreur à la création d'un objet par API

Erreur à la création d'un objet par API
0
Tags: #<Tag:0x00007f7691e28b28>

Bonjour, nous avons une erreur dans la réponse de retour à la création d’un objet :

Il semble que l’objet soit pourtant bien créé et sauvegardé.

En revanche, j’ai l’erreur “{“error”:“JSONObject[“data”] not found.”,“status”:500}” dans le contenu de la réponse de retour:

Auriez-vous une explication à un tel comportement ? A quel niveau investiguer sachant que l’objet est bien créé et les données présentes en base ?

Merci

Merci d’indiquer votre version/patchlevel/revision

Je viens de tester une création sur une release P24 à jour et ça marche:

Avez vous regardé les logs ? Il y a sans doute des indices sur votre pb dans celles-ci.
Sinon faites le test avec un autre client API que la page API tester: curl ou Postman ou dans le genre

Le problème se produit également avec postman et depuis notre bus de services.

Lorsque la création est tombée en erreur et que nous faisons un “REST GET - search object” sur l’objet en question dans la foulée, nous avons comme erreur :

Et dans nos logs Tomcat

21-Feb-2020 09:57:09.702 INFOS [http-nio-10428-exec-13] org.apache.coyote.http11.Http11Processor.service Erreur lors de l'analyse d'un en-tête de requête HTTP Note: toutes les occurrences suivantes d'erreurs d'analyse des requêtes HTTP seront enregistrées au niveau DEBUG
	java.lang.IllegalArgumentException: Un caractère invalide a été trouvé dans la cible de la requête, les caractères valides sont définis dans RFC 7230 et RFC 3986
		at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:469)
		at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260)
		at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
		at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
		at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1639)
		at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
		at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
		at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
		at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
		at java.base/java.lang.Thread.run(Thread.java:834)

Simplicité version :4.0 patch level P24Built on2020-02-20 23:46 (revision 33b1f370cc64d7c985e644e4e24860e0e5973a3b)

Puis-je avoir un export XML du record en question ?

Je vous l’ai envoyé par mail

Je ne pense pas que le “ô” soit le pb car c’est un libellé UI.
La valeur qui transite sur les APIs c’est le code “POLEEMPLOI”

Idem XML:

<fopIndividuOrigine>POLEEMPLOI</fopIndividuOrigine>

Je ne vois pas de raison à priori pour que ce record pose pb aux APIs, pas de caractères bizarre visibles (peut être un caractère invisible ?)

Que se passe-t-il quand on update ce record directement dans la UI ?

ça semble fonctionner dans mon navigateur

En revanche, j’ai sélectionné ma requête dans le navigateur -> copier comme cURL(cmd), ce qui me donne

curl "http://forpro.dev-sim.cr-bretagne.fr/forpro/ui/json/obj?action=update^&object=CrbFopIndividu^&inst=the_ajax_CrbFopIndividu^&context=5^&_md=true^&inline_documents=images^&inline_thumbnails=true^&inline_objects=true^&_=33b1f370cc64d7c985e644e4e24860e0e5973a3b_20200221101432" -H "Connection: keep-alive" -H "X-Requested-With: XMLHttpRequest" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36" -H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryKwSAhFLOymukAPbE" -H "Accept: */*" -H "Origin: http://forpro.dev-sim.cr-bretagne.fr" -H "Referer: http://forpro.dev-sim.cr-bretagne.fr/forpro/ui" -H "Accept-Encoding: gzip, deflate" -H "Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7" -H "Cookie: JSESSIONID=298EB9204850D39AC8E6F7D279CAB06B; _ga=GA1.2.506813756.1521474189; _clientid=HHOfjEljrpjWfsLsivPN_1579529002641; crowd.token_key=9Co0ZSpZkk2JVlQLCTIQYg00" --data-binary ^"------WebKitFormBoundaryKwSAhFLOymukAPbE^
Plus ?
Plus ? Content-Disposition: form-data; name=^\^"row_id^\^"^
Plus ?
Plus ? ^
Plus ?
Plus ? 9601^
Plus ?
Plus ? ------WebKitFormBoundaryKwSAhFLOymukAPbE^
Plus ?
Plus ? Content-Disposition: form-data; name=^\^"created_dt^\^"^
Plus ?
Plus ? ^
Plus ?
Plus ? 2020-02-21 09:12:12^
Plus ?
Plus ? ------WebKitFormBoundaryKwSAhFLOymukAPbE^
Plus ?
Plus ? Content-Disposition: form-data; name=^\^"created_by^\^"^
Plus ?
Plus ? ^
Plus ?
Plus ? designer^
Plus ?
Plus ? ------WebKitFormBoundaryKwSAhFLOymukAPbE^
Plus ?
Plus ? Content-Disposition: form-data; name=^\^"updated_dt^\^"^
Plus ?
Plus ? ^
Plus ?
Plus ? 2020-02-21 09:12:12^
Plus ?
Plus ? ------WebKitFormBoundaryKwSAhFLOymukAPbE^
Plus ?
Plus ? Content-Disposition: form-data; name=^\^"updated_by^\^"^
Plus ?
Plus ? ^
Plus ?
Plus ? designer^
Plus ?
Plus ? ------WebKitFormBoundaryKwSAhFLOymukAPbE--^
Plus ?
Plus ? ^" --compressed --insecure

et j’ai aussi le problème :

Les APIs de la UI ne sont pas les mêmes que les API REST du endpoint API. Je ne comprends pas ce que vous faites…

Depuis l’UI l’update fonctionne

Je continue à ne pas comprendre ce que vous faites.

Ce qu’on appelle les APIs REST sont celles exposées sur le endpoint /api/rest, elles sont simples et peuvent être invoquées par de simples appels HTTP GET/PUT/POST/DELETE (ex: via curl, postman, etc.)

Les APIs internes, beaucoup plus complexes à manipuler, sont celles exposées sur /ui/json et /api/json ne sont pas sensées être appelées sans passer par les librairies wrappers JavaScript qu’on vous met à disposition (Ajax ou bundle Ajax+UI) et qui gèrent leur complexité.

Bref faites votre choix.

Je vous ai envoyé une copie d’écran des requête lancées lors d’une update depuis la UI, dans le but de répondre le plus précisément possible à votre question

J’ai simplement essayé de comprendre ce qui se passait dans un cas (par la UI) et dans un autre (par l’API REST).

Quoiqu’il en soit, l’erreur que nous rencontrions était bien par l’api REST que vient interroger notre bus de services.

Cette erreur ne s’est pas reproduite ces derniers jours sur notre traitement journalier d’insertion par l’API. Si le problème se reproduit, je reviendrai vers vous.

OK, revenons au pb initial:

java.lang.IllegalArgumentException: Un caractère invalide a été trouvé dans la cible de la requête, les caractères valides sont définis dans RFC 7230 et RFC 3986
		at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:469)

Au vu de cette log avec ses caractères accentués mal encodés je pense qu’il y a des pbs d’encoding déjà au niveau Tomcat et/ou systeme.

Du coup qu’il y ait des exceptions d’encoding à la réception de données ne m’étonne pas forcément.

Vérifiez que l’ensemble de votre chaîne de composants travaille bien en UTF-8, il suffit d’un seul élément de la chaine qui travaille dans un autre encoding pour induire des pbs inextricables.

Sinon regardez si votre pb ne viendrait pas d’un caractère étendu non inclus dans le UTF-8 de base, genre un emoji…

Peut-on laisser ce problème d’encodage provisoirement de côté et remonter au problème initial, car j’ai l’impression que cette erreur n’est pas liée au premier problème qui est toujours présent :

Je ne sais pas dans quelle autre direction investiguer pour résoudre ce souci.

Merci

Cette erreur est remontée si le service ne reçoit pas de données ou qu’elles ne sont pas intelligibles (le parser du JSONObject part en exception)

  • format json
  • encoding UTF-8

Merci de donner la requete complete du POST avec l’objet JSON sérialisé

Créez votre objet avec accent à la main depuis la UI + exportez sous designer cet objet en JSON, et comparez avec les data que vous envoyez via postman, il y a forcement une erreur dans votre message ou dans l’encoding UTF-8 (tomcat, proxy…).

Depuis l’UI j’ai créé mon individu :

puis je l’exporte en JSON:

{"objects":[{
  "name":"CrbFopIndividu",
  "action":"upsert",
  "data":[{
    "fopIndividuNir":"1851225888888",
    "fopIndividuCivilite":"M",
    "fopIndividuNomNaissance":"TEST AVEC ÀCCENT",
    "fopIndividuNomUsage":"TEST AVEC ÀCCENT",
    "fopIndividuPrenom":"TOTO",
    "fopIndividuIdentite":"TEST AVEC ÀCCENT TOTO",
    "fopIndividuDtNaissance":"1985-12-25",
    "fopIndividuPaysNaissance":"000",
    "fopIndividuEmail":"toto@test.com",
    "fopIndividuCommuneNaissance":"PARIS",
    "fopIndividuIdDe":"",
    "fopIndividuCodeInseeNaissance":"",
    "fopIndividuNirCertifie":"1",
    "fopIndividuDtMajDe":"",
    "fopIndividuOrigine":"OF"
    }]
}]}

Enfin en le créant par l’api (je change un peu le N° de sécu car c’est la clé):

Dois-je bien passer uniquement le contenu de ‘data’ extrait du json en paramètre du post ?

Egalement une capture réseau :

Le comportement est le même sans accent dans aucune des valeurs de champ et tous nos envois sont en erreur

Ok merci pour ces précisions, on va investiguer car ce n’est pas normal.

Bon, déjà peut on préciser de quelle version/patchlevel/revision on parle car il y a eu des changements sur les services REST. Je voudrais être sûr qu’on est pas en train d’investiguer un pb qui n’est plus d’actualité.

Au départ

et aujourd’hui