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

guithel · February 21, 2020, 9:17am

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

david · February 21, 2020, 9:30am

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

guithel · February 21, 2020, 9:59am

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)

david · February 21, 2020, 10:02am

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

guithel · February 21, 2020, 10:10am

Je vous l’ai envoyé par mail

david · February 21, 2020, 11:03am

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 ?

guithel · February 21, 2020, 12:52pm

ç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 :

david · February 21, 2020, 12:56pm

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…

guithel · February 21, 2020, 1:57pm

Depuis l’UI l’update fonctionne

david · February 26, 2020, 11:32am

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.

guithel · February 27, 2020, 8:48am

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.

david · February 27, 2020, 9:05am

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…

guithel · March 17, 2020, 1:51pm

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

Francois · March 17, 2020, 2:17pm

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…).

guithel · March 17, 2020, 2:55pm

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 ?

guithel · March 17, 2020, 3:06pm

Egalement une capture réseau :

guithel · March 17, 2020, 3:10pm

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

Francois · March 17, 2020, 3:29pm

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

david · March 17, 2020, 4:50pm

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é.

guithel · March 18, 2020, 8:18am

Au départ

et aujourd’hui