Development #10559
recevoir un document via webservice (wscall)
0%
Description
Lors du retour d'un appel webservice, si on reçoit un document (liste de mime-type à définir) alors on l'enregistre dans le journal comme AttachmentEvolutionPart, avec comme variable le nom de celle du webservice.
Puis, faire de même lors du déclenchement depuis un trigger, s'il est accompagné d'un doc.
Mime type acceptés :- application/* (sauf /json qui sera géré comme actuellement)
- image/*, audio/*, video/*
Usecase: permettre de récupérer un document de l'extérieur, dans le même format que s'il est généré depuis un modèle local.
Fichiers
Demandes liées
Révisions associées
tests: add a more high level test of wscall/attachment (#10559)
Historique
Mis à jour par Thomas Noël il y a environ 8 ans
Et en fait, peut-être : considérer TOUS les types mime, sauf application/json.
Mis à jour par Frédéric Péters il y a environ 8 ans
Veut-on être explicite sur le fait que l'appel est pour récupérer un fichier ? Ou on impose désormais un content-type posé correctement posé ?
Mis à jour par Thomas Noël il y a environ 8 ans
Frédéric Péters a écrit :
Veut-on être explicite sur le fait que l'appel est pour récupérer un fichier ?
J'ai envie de dire non.
Ou on impose désormais un content-type posé correctement posé ?
J'ai envie de dire oui, maintenant je me dis que ça va être un peu bête si on reçoit des text/plain "ok" ...
Mis à jour par Benjamin Dauvergne il y a environ 8 ans
Est-ce qu'on exigerait pas plutôt la présence d'un header Content-Disposition: attachment; filename=xxx ?
Mis à jour par Serghei Mihai (congés, retour 15/05) il y a environ 8 ans
- Lié à Development #10563: iparapheur: webservice de récuperation du statut d'un dossier ajouté
Mis à jour par Thomas Noël il y a environ 8 ans
- Fichier 0001-wscall-store-non-json-response-as-attachment-10559.patch 0001-wscall-store-non-json-response-as-attachment-10559.patch ajouté
- Statut changé de Nouveau à En cours
Voici une version draft, pour des premiers avis ; je ne coche pas "patch proposed"
Je me suis demandé un moment si je n'allais pas basculer d'abord dans l'utilisation de "requests" pour avoir quelque chose de plus "compréhensible" (lire : "habituel")... et puis bon. Voici.
Mis à jour par Frédéric Péters il y a environ 8 ans
C'est un peu trop magique à mon goût, révélé par le test où un xml est reçu, où précédemment ça générait une erreur et maintenant ça va tranquillement passer en pièce jointe. J'aurais donc été explicite là-dessus.
À ce stade, je me rends compte aussi que l'action devient un monstre, et pour le dompter en partant de l'UI, je sectionnerais, 1) requête : url, clé de signature, get ou post, données json, inclusion du formdata, 2) réponse : json ou pièce jointe ?, nom de variable, 3) erreurs : les différentes options de gestion d'erreur.
Mis à jour par Thomas Noël il y a environ 8 ans
- Lié à Development #10663: reorganiser l'UI de l'action wscall ajouté
Mis à jour par Thomas Noël il y a environ 8 ans
- Fichier 0001-wscall-can-store-response-as-attachment-10559.patch 0001-wscall-can-store-response-as-attachment-10559.patch ajouté
Voici un second draft.
Je suis pas encore bien à l'aise avec le « formdata.evolution[-1].add_part(attachment) », il faut que je vérifie ce que ça donne "en vrai"
Mis à jour par Frédéric Péters il y a environ 8 ans
Déplacer tout le nouveau bloc "if self.response_type: ... else: ..." dans une méthode séparée ?
Si on attend un fichier et que le résultat est vide, on doit vraiment accepter ça silencieusement ?
Mis à jour par Thomas Noël il y a environ 8 ans
- Fichier 0001-wscall-can-store-response-as-attachment-10559.patch 0001-wscall-can-store-response-as-attachment-10559.patch ajouté
Frédéric Péters a écrit :
Déplacer tout le nouveau bloc "if self.response_type: ... else: ..." dans une méthode séparée ?
Yep.
Si on attend un fichier et que le résultat est vide, on doit vraiment accepter ça silencieusement ?
J'ai donc adopté le comportement que oui, on considère que tout va bien et on stocke un fichier vide (contre rien du tout dans la version précédente).
Mis à jour par Thomas Noël il y a environ 8 ans
- Fichier 0001-wscall-can-store-response-as-attachment-10559.patch 0001-wscall-can-store-response-as-attachment-10559.patch ajouté
tests "en vrai" sur un httpbin avec jpeg, png, xml ... tout semble ok, sauf response.length toujours à 0.
Donc nouveau patch avec:
- workflow_data['%s_length' % self.varname] = response.length + workflow_data['%s_length' % self.varname] = len(data)
et c'est ok.
Mis à jour par Thomas Noël il y a environ 8 ans
- Patch proposed changé de Non à Oui
Et donc c'est une version à relire, dans le but d'être pushée.
Mis à jour par Frédéric Péters il y a environ 8 ans
"can store response as attachment" → "make it possible to store response as attachment".
+ fp_content = StringIO() + fp_content.write(data) + fp_content.seek(0)
Ça peut juste être fp_content = StringIO(data).
Mis à jour par Thomas Noël il y a environ 8 ans
- Fichier 0001-wscall-make-it-possible-to-store-response-as-attachm.patch 0001-wscall-make-it-possible-to-store-response-as-attachm.patch ajouté
Voici donc, avec un test qui va un peu plus loin et regarde le contenu du fichier joint.
Mis à jour par Frédéric Péters il y a environ 8 ans
- Fichier 0001-tests-add-a-more-high-level-test-of-wscall-attachmen.patch 0001-tests-add-a-more-high-level-test-of-wscall-attachmen.patch ajouté
Tu ajouterais au-dessus de la nouvelle partie du test un commentaire "# check storing response as attachment". (genre)
+ patch avec un test supplémentaire, qui m'incite à retirer le mimetypes.init() (quand il est laissé, le premier appel à guess_extension est ok mais le second obtient une chaine vide).
Mis à jour par Thomas Noël il y a environ 8 ans
- Fichier 0001-wscall-make-it-possible-to-store-response-as-attachm.patch 0001-wscall-make-it-possible-to-store-response-as-attachm.patch ajouté
Frédéric Péters a écrit :
Tu ajouterais au-dessus de la nouvelle partie du test un commentaire "# check storing response as attachment". (genre)
Fait.
(...) qui m'incite à retirer le mimetypes.init()
À mieux analyser l'affaire de ce mimetypes.init() : tout à fait, j'ai retiré. On gère les fichiers classiques, pour les autres on verra si le besoin arrive un jour (plutôt improbable)
Mis à jour par Frédéric Péters il y a environ 8 ans
Ok, go. (tu peux pousser mon test supplémentaire, ou le fais après, pareil).
Mis à jour par Thomas Noël il y a environ 8 ans
- Statut changé de En cours à Résolu (à déployer)
J'ai pushé les deux.
commit b060b706685d43176455a4097d28d0799c569d64
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Fri Apr 15 12:04:22 2016 +0200
tests: add a more high level test of wscall/attachment (#10559)
commit e1f9c6b4dc4e249c64425a74bd6e4956264ee7ba
Author: Thomas NOEL <tnoel@entrouvert.com>
Date: Thu Apr 14 15:47:11 2016 +0200
wscall: make it possible to store response as attachment (#10559)
Mis à jour par Thomas Noël il y a environ 8 ans
- Sujet changé de recevoir un document via webservice (wscall et trigger) à recevoir un document via webservice (wscall)
Mis à jour par Frédéric Péters il y a environ 8 ans
- Statut changé de Résolu (à déployer) à Fermé
wscall: make it possible to store response as attachment (#10559)