Erreur 400 API "Object null not configured"

Erreur 400 API "Object null not configured"
0
Tags: #<Tag:0x00007f853522adc8>

Bonjour,

J’ai depuis hier l’erreur suivante :{"errors":[{"errorMessage":"Object null not configured","errorCode":"400","errorLevel":"error"}]} sur les GET de certains de mes objets alors que je n’ai fait aucune modification sur ces objets ou leur mapping. J’ai tenté de vider le cache mais ça ne change rien.

Les GET des objets qui renvoient cette erreur sont fait via (mon) navigateur ou via postman (de l’équipe de test en Inde). En revanche, les GET fonctionnent parfois correctement et renvoient bien les données (sur mon postman, à l’heure actuelle, en l’occurrence).

Les logs de l’environnement ne renvoient que lors des appels (pas d’erreur) INFO|awrfs02|com.simplicite.extobjects.RenaultSites.SitesServicesV1|get||Event: Elapsed time 43ms

Est-ce que ce type de problème est connu de votre côté ? Si non, comment puis-je investiguer pour tenter de comprendre ce qu’il se produit quand j’ai l’erreur ?

Merci d’avance.

Non je ne connais pas ce type de symptôme.

D’après ce que je relis dans le code, ne peut à priori se produire que si le mapping est incorrect/incohérent quelquepart…

Merci de me fournir les URLs appelée (y compris le mode d’authentification utilisé) et le code du mapping pour que je voies plus précisément de quoi on parle.

Juste pour mon info, est-ce qu’on parle d’une instance unique ou d’un cluster d’instance load-balancées ?

J’ai l’erreur :

  • En passant par le navigateur (avec basic authent d’un utilisateur qui a les droits) sur l’URL https://ope.rfs.ope.aws.renault.com/sites/v1/sites
  • Par postman en passant par l’Apigee de Renault (la plupart du temps, lors de l’écriture de mon premier message par exemple)

Je n’ai pas l’erreur :

On est sur un cluster d’instance load balancées (trois instances).

Le code de mapping de l’objet Sites (dans la classe SitesServicesV1 qui hérite de com.simplicite.webapp.services.RESTMappedObjectsExternalObject)

		addObject("sites", "SitesRealEstateSite");
		addField("sites", "identifier", "sitesReaIdentifier");
		addField("sites", "name", "sitesReaName");
		addRefField("sites", "cities", "cityId", "sitesResCitId");
		addField("sites", "cityName", "sitesResCitId.sitesCitName");
		addField("sites", "cityPostalCode", "sitesResCitId.sitesCitPostalCode");
		addField("sites", "countryId", "sitesResCitId.sitesCitCtyId");
		addField("sites", "countryName", "sitesResCitId.sitesCitCtyId.sitesCtyName");
		addField("sites", "countryCode", "sitesResCitId.sitesCitCtyId.sitesCtyCode2");
		addField("sites", "description", "sitesReaDescription"); // To be confirmed
		addField("sites", "effectiveDate", "sitesReaEffectiveDate");
		addField("sites", "endDate", "sitesReaEndDate");
		addField("sites", "activeStatus", "sitesGenStatus");

à ma connaissance c’était toi qui avais fait ce mapping et je ne l’ai jamais retouché pour cet objet.

Vos instances load-balancées sont elles bien en mode “sticky-sessions” ?

Normalement si vos instances load balancées ne servent que pour des accès API ça ne devrait pas poser de pb de ne pas être en mode “sticky sessions”.

Mais il y a peut être une subtilité (peut être liée à l’utilisation du mapping d’URI pour exposer sur /sites plutôt que le standard /api). Je vais regarder ça de plus près et je te dis.

Par contre pour les accès UI il est obligatoire d’être en mode “sticky sessions”.

Bonjour,

Je viens d’avoir confirmation par l’équipe dev ops que les instances sont bien configurées en sticky session. Elles l’étaient paramétrées à 60s et ont été reparamétrées à 90 minutes aujourd’hui.

ça ne change en revanche pas le problème d’erreur 400 “Object null not configured”. On a toujours la même situation.

Je ne sais pas quoi investiguer de plus, je n’ai pas de logs d’erreur en console.

J’ai tenté d’investiguer davantage avec @bmo :

L’erreur se produit :

Si on tente d’appeler l’objet directement via https://ope.rfs.ope.aws.renault.com/api/rest/SitesRealEstateSite on n’a pas d’erreur (attendu mais confirmé).

Les trois derniers tests mentionnés ont été fait via cURL, exemple : curl -v -k -H "X-Simplicite-Authorization: Bearer <récupéré via appel /api/login>" https://ope.rfs.ope.aws.renault.com/api/ext/SitesServicesV1/sites

Chaque appel successif de https://ope.rfs.ope.aws.renault.com/api/ext/SitesServicesV1/sites se voit attribuer une session id différente, qui ne restent pas dans les User session de l’onglet Operation de Simplicité après les appels.

Exemple de logs pour un call qui a marché (décroissant), avec le cURL cité plus haut curl -v -k -H "X-Simplicite-Authorization: Bearer <récupéré via appel /api/login>" https://ope.rfs.ope.aws.renault.com/api/ext/SitesServicesV1/sites :

2019-10-01 11:26:44,619 INFO [Logon] SIMPLICITE|http://1ea1ec1ebe8d:8080||SESSION|awrfs02|Logon|logout||Session utilisateur=awrfs02/84AB3A74FD22748686FE43058AED53B2 time=0:00:00 // Sans action de ma part ou autre call entre les deux, logout automatique
2019-10-01 11:25:06,163 INFO [com.simplicite.extobjects.RenaultSites.SitesServicesV1] SIMPLICITE|http://1ea1ec1ebe8d:8080||INFO|awrfs02|com.simplicite.extobjects.RenaultSites.SitesServicesV1|get||Event: Elapsed time 23ms
2019-10-01 11:25:06,146 INFO [com.simplicite.extobjects.RenaultSites.SitesServicesV1] SIMPLICITE|http://1ea1ec1ebe8d:8080||INFO|awrfs02|com.simplicite.extobjects.RenaultSites.SitesServicesV1|search||Event: Using api_SitesRealEstateSite_8815733883
2019-10-01 11:25:06,127 INFO [com.simplicite.util.Grant] SIMPLICITE|http://1ea1ec1ebe8d:8080||ICORED0001|awrfs02|com.simplicite.util.Grant|init||Info: awrfs02 connected using curl/7.65.1, timeout = 1800s
2019-10-01 11:25:06,096 INFO [Logon] SIMPLICITE|http://1ea1ec1ebe8d:8080||SESSION|awrfs02|Logon|login (direct)||Session utilisateur=awrfs02/84AB3A74FD22748686FE43058AED53B2 time=0

Je ne vois pas de logs quand le call (le même appel cURL) est en erreur (400, Objet null not configured).

OK on a ici plusieurs aspects à distinguer:

  1. Session:

Le endpoint API n’a pas besoin du cookie de session, s’il est là tant mieux mais sinon, sa logique est de retrouver, si elle existe, une éventuelle session associée au token ou d’en créer une nouvelle.

Au sein de cette session les instances d’objets métier utilisées sont géré par un pool synchronisé (donc pas de risque de comportements non thread safe).

Cette session est donc purement “technique” et donc transparente pour l’appelant (à part le cookie de session retourné par Tomcat qu’on peu ignorer), elle expire par défaut en 60s. Comme je l’ai dit dans un post précédent le reverse proxying en sticky session n’est obligatoire que pour les accès UI, il est facultatif dans le cas d’accès API.

  1. URI d’appel:

Oublions le cas des APIs standards (celles sur /api/rest/<object>) car ce n’est pas le sujet.

S’agissant des APIs customs, les 2 URI qui sont sensées marcher sont:

  • Sans mapping d’URI: /api/ext/SitesServicesV1/(..) (ex: /api/ext/SitesServices/sites)
  • Avec mapping d’URI: /sites/v1/(...) (ex: /sites/v1/sites)

Dans tes tests tu indiques une URI en /api/ext/SitesServicesV1/v1/sites, celle là n’est pas sensée marcher car il n’y a pas d’objet mappé sur le nom “v1” (elle reverra alors une erreur 400, avec le message “Object v1 not configured”).

Peux tu vérifier si la “tuyauterie” (reverse proxies, agrégateurs d’APIs etc.) par laquelle passent les URI chez vous sont bien configurées pour taper, au final au niveau Tomcat, sur l’une des base URI valides (i.e. soit /api/ext/SitesServicesV1 soit /sites/v1) ?

  1. Load balancing:

Si je comprends bien ce que tu fais comme test, tu tape au niveau du load balancer (ce que tu appelle le “backend”). Serait il possible de:

  • taper directement sur l’un (puis l’autre) des noeud Tomcat load balancé sans passer par le load balancer

ou

  • avoir un load balancer qui ne fasse, dans un premier temps, que du routage sur 1 seul neud Tomcat (autrement dit avoir un load balancer qui ne fait finalement que du reverse proxiing)

Il y a toujours des subtilités et des surprises avec les infrastructures à base de load balancers et bien sûr ce ne sont jamais les mêmes en fonction du load balancer utilisé.

Est-ce que vous utilisez toujours Traefik comme load balancer ?