Projet

Général

Profil

Bug #9889

enregistrer un maximum d'info en retour d'un appel webservice

Ajouté par Thomas Noël il y a environ 8 ans. Mis à jour il y a environ 8 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
Début:
06 février 2016
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Actuellement quand un webservice répond autre chose que 200, on enregistre juste le résultat "brut" dans le journal, ce n'est pas exploitable autrement que pour du debug. Or nos connecteurs passerelle savent pour la plupart renvoyer du JSON même en cas de 4xx, 500, etc. Par ailleurs, essayons de connaître la date d'enregistrement de ces valeurs.


Fichiers

Révisions associées

Révision 3637c3ef (diff)
Ajouté par Thomas Noël il y a environ 8 ans

wscall: store more informations after the call (#9889)

Historique

#1

Mis à jour par Thomas Noël il y a environ 8 ans

Ce patch :
  1. enregistre un time.localtime dans xxx_time
  2. enregistre un xxx_error_result si on arrive à lire du JSON dans les data d'une erreur
  3. enregistre toujours le xxx_status (auparavant on l'oubliait en cas de 200 avec un soucis de format JSON, je pense qu'il faut quand même garder l'info du 200, on a le saut "erreur json" pour savoir qu'il y a eu un soucis de format)
  4. et au passage j'ai approfondi les tests pour mieux vérifier le workflow_data en sortie
#3

Mis à jour par Frédéric Péters il y a environ 8 ans

Thomas Noël a écrit :

Ce patch :
  1. enregistre un time.localtime dans xxx_time

Je préférerais avoir datetime.datetime.now().isoformat()

  1. enregistre un xxx_error_result si on arrive à lire du JSON dans les data d'une erreur

Sans passer par un /tmp/data, présent pour debug j'imagine.

  1. enregistre toujours le xxx_status (auparavant on l'oubliait en cas de 200 avec un soucis de format JSON, je pense qu'il faut quand même garder l'info du 200, on a le saut "erreur json" pour savoir qu'il y a eu un soucis de format)

ok.

  1. et au passage j'ai approfondi les tests pour mieux vérifier le workflow_data en sortie

ok.

Attention au passage de 200 à // 100 == 2, si on a retour 204, le résultat sera une chaine vide, ça ne passera pas comme étant du json valide, ça sera marqué comme étant une erreur. (alors qu'aujourd'hui ça passait).

#4

Mis à jour par Thomas Noël il y a environ 8 ans

Frédéric Péters a écrit :

Thomas Noël a écrit :

Ce patch :
  1. enregistre un time.localtime dans xxx_time

Je préférerais avoir datetime.datetime.now().isoformat()

Yep.

  1. enregistre un xxx_error_result si on arrive à lire du JSON dans les data d'une erreur

Sans passer par un /tmp/data, présent pour debug j'imagine.

Arf.

Attention au passage de 200 à // 100 == 2, si on a retour 204, le résultat sera une chaine vide, ça ne passera pas comme étant du json valide, ça sera marqué comme étant une erreur. (alors qu'aujourd'hui ça passait).

Bien vu. Dans cette version je distingue donc d'abord 204 et 205, mais dans tous les autres cas on attend obligatoirement un JSON. Ca me semble correct ainsi...?

#5

Mis à jour par Frédéric Péters il y a environ 8 ans

Sans relire en détails, ok.

#6

Mis à jour par Thomas Noël il y a environ 8 ans

  • Statut changé de En cours à Résolu (à déployer)
  • Version cible mis à v1.33
commit 3637c3ef4d854fe2f5f59a25423ce33edf5fc5c9
Author: Thomas NOEL <tnoel@entrouvert.com>
Date:   Sat Feb 6 02:48:16 2016 +0100

    wscall: store more informations after the call (#9889)

#7

Mis à jour par Thomas Noël il y a environ 8 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF