Development #71368: Connecteur Esabora : lors d'erreurs, retourner les informations renvoyées par Esabora - Passerelle - Redmine Entr’ouvert

Development #71368

Connecteur Esabora : lors d'erreurs, retourner les informations renvoyées par Esabora

Added by Marie Kuntz 10 months ago. Updated 10 months ago.

Status:

Fermé

Priority:

Normal

Assignee:

Agate Berriot

Target version:

Start date:

Due date:

% Done:

Estimated time:

Patch proposed:

Planning:

Description

Sur une action webservice appelant le connecteur Esabora, on a une erreur 400 si on envoie une référence déjà présente dans Esabora.
Par ex : https://passerelle-nantes-metropole.test.entrouvert.org/manage/esabora/esabora-test-recette/logs/?log_id=73360

{"code":"WS_ERR_SQL","message":"23505 - ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique « iaff_cledoss_unik »\nDETAIL: La clé « (iaff_cledoss)=(215-1) » existe déjà."}

Est-il possible de catcher cette erreur dans le connecteur et de renvoyer au workflow l'info "clé dupliquée" (texte non contractuel) plutôt que cette erreur générique ? Ça permettrait une utilisation plus simple du connecteur par les admins fonctionnels.

(Dans l'idéal il faudrait pouvoir le faire pour les erreurs les plus courantes mais je ne connais pas les autres cas d'erreur)

Associated revisions

Revision 56b6baea (diff)
Added by Agate Berriot 10 months ago

esabora: return error content in response (#71368)

History

Updated by Thomas Noël 10 months ago

Il s'agirait de détecter « clé dupliquée » dans le message d'erreur, pour le remplacer par un message « clé dupliquée » ? Ça me parait pas très utile...

Tu peux déjà faire une analyse au niveau du workflow, en cas d'erreur 400, en regarder si « clé dupliquée » existe dans la réponse, et dans ce cas afficher une (tentative de) message à l'admin fonctionnel.

Je dis "tentative de message" car une telle erreur SQL peut avoir mille causes.

Je pense qu'il est préférable de surtout chercher à l'éviter. Est-ce qu'elle se produit régulièrement ? Dans quel(s) cas ?

Updated by Marie Kuntz 10 months ago

Justement, ce message n'apparait pas dans l'inspecteur, il faut aller chercher dans le connecteur.
Si on pouvait remonter response_content au niveau du wf, ce serait déjà super, ça éviterait qu'on doive faire des AR entre WF et logs du connecteur

Updated by Thomas Noël 10 months ago

Subject changed from Connecteur Esabora : traiter certaines erreurs différemment to Connecteur Esabora : lors d'erreurs, retourner les informations renvoyées par Esabora

Pigé, on a fait de simples « response.raise_for_status() » qui ne renvoient effectivement rien d'utile en dehors du code d'erreur.

Il faut qu'on pose une gestion d'erreur au niveau de la méthode post :

si le payload n'est pas du JSON, lever une APIError en y indiquant le status reçu et le payload "brut"
si le status de retour n'est pas 2XX alors lever une APIError en y indiquant le status reçu et le json reçu (c'est ce cas qui intéresse Marie)