Development #47856
Ajout d'un connecteur Sigerly
0%
Description
Les spécifications sont données dans #41935.
Fichiers
Révisions associées
Historique
Mis à jour par Nicolas Roche il y a plus de 3 ans
- Fichier 0001-sigerly-add-sigerly-connector-47856.patch 0001-sigerly-add-sigerly-connector-47856.patch ajouté
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
Tests écrit avec les données fournies dans la documentation en attendant que l'accès à services web soit ouvert.
Mis à jour par Nicolas Roche il y a plus de 3 ans
- Assigné à changé de Nicolas Roche à Pierre Cros
Voilà, tests écrit sur la base d'un envoie validé en préprod.
J'attends le feu-vert de Pierre avant d'aller plus loin.
Pour info,
Je crée une demande d'intervention avec le endpoint create et je récupère un id, qui à priori ne me servira à rien.
ex: 7830.
Ensuite j'attend :
Lorsque vous en faites la demande, elle tombe dans un "panier", et tant
qu'elle n'est pas convertie en intervention, c'est normal que vous ne la
récupériez pas.
Ensuite la demande est remontée par une recherche par date sur le endpoint query, avec de nouveaux ids :
"idinterv" : 22014, "id_demande_web" : 10914,
Et si on le connaît, alors on peut aussi récupérer la demande par son id_demande_web (via le même endpoint query).
l'id 22014 est l'id de l'intervention une fois qu'elle a été
créée, mais c'est l'id de la demande web qu'il faut passer en paramètre
(colonne id_demande_web de la table des interventions), car Entrouvert ne
peut pas avoir connaissance de l'id interne de l'intervention aprés la
demande car celle ci n'a pas encore été créée (elle est encore dans le
panier des demandes web).
Mis à jour par Pierre Cros il y a plus de 3 ans
Le connecteur n'est pas commandé encore donc on va effectivement attendre qu'il le soit.
Mis à jour par Nicolas Roche il y a plus de 3 ans
- Fichier 0001-sigerly-add-sigerly-connector-47856.patch 0001-sigerly-add-sigerly-connector-47856.patch ajouté
J'ai oublié de poser le patch.
Mis à jour par Nicolas Roche il y a plus de 3 ans
Je crée une demande d'intervention avec le endpoint create et je récupère un id, qui à priori ne me servira à rien.
Il s'agit bien en fait du même identifiant (de demande web) qui est retourné par le endpoint de création et que l'on peut utiliser sur le endpoint de consultation.
Il reste que lorsque l'on consulte une demande web, qui n'a pas encore été convertie en intervention en backoffice, on reçoit une liste vide ; ce qui est le même retour lors de la consultation d'une demande web inexistante.
(c'est en partie ce qui a induit la confusion ci-dessus)
Est-ce gênant pour l'intégration dans un workflow ?
Mis à jour par Frédéric Péters il y a environ 3 ans
+ description=_('Versement d’une demande d’éclairage public dans l’extranet du SIGERLY'),
et autre, _() c'est pour demander une traduction; pas applicable ici. (si tu décides de taper tout en français direct dans le connecteur, préviens et je ferme les yeux).
+ if response.status_code // 100 != 2:
Est-ce que juste response.ok ne peut pas dans la pratique fonctionner ?
+ display_order=1,
Ça n'apporte rien, si ? (et pareil pour le display_order=2 dans l'autre)
Mis à jour par Nicolas Roche il y a environ 3 ans
- Fichier 0001-sigerly-add-sigerly-connector-47856.patch 0001-sigerly-add-sigerly-connector-47856.patch ajouté
- Statut changé de En cours à Solution proposée
si tu décides de taper tout en français direct dans le connecteur, préviens et je ferme les yeux
je n'aurais jamais osé demander, mais vu tout le texte spécifique oui ça m'irait bien.
Est-ce que juste response.ok ne peut pas dans la pratique fonctionner ?
J'ai peur que non, je n'utilise pas HTTPMock dans les tests.
Ici c'est un bête copié/collé du connecteur solis qui ma semblé bien éprouvé.
Mais oui inutile de traiter les messages que 204 ici (à un moment j'espérais qu'ils m'aideraient à traiter le cas des demandes émises mais pas encore validée).
display_order=1,
oui, en fait ça ne sert à rien.
Mis à jour par Nicolas Roche il y a environ 3 ans
- Fichier 0001-sigerly-add-sigerly-connector-47856.patch 0001-sigerly-add-sigerly-connector-47856.patch ajouté
(avec black)
Mis à jour par Nicolas Roche il y a environ 3 ans
- Fichier 0001-sigerly-add-sigerly-connector-47856.patch 0001-sigerly-add-sigerly-connector-47856.patch ajouté
Est-ce que juste response.ok ne peut pas dans la pratique fonctionner ?
Oui, Sigerly ne renvoie que des erreurs applicatives (en 200) et donc pas besoin de parser de JSON sur les erreurs HTTP.
(et j'ai finalement utilisé HTTPMock pour les tests, ça les rend plus lisibles.)
Mis à jour par Frédéric Péters il y a environ 3 ans
'description': "Code insee de la commune : liste séparée par ':'",
INSEE en majuscules
description='Versement d’une demande d’éclairage public dans l’extranet du SIGERLY',
Plutôt "Envoi" que "Versement", et zappons aussi le côte "éclairage public", et le côté extranet, et le rappel que c'est Sigerly; et la forme à l'infinitf me semble plus commune dans les connecteur; bref, "Envoyer une demande" et (à ce compte ça pourrait tout à fait être en anglais mais je ne le demande pas).
description='Interroger le SIGERLY sur l’etat d’avancement d’une demande',
Même travail ici; "Récupérer le statut d’une demande".
Mis à jour par Nicolas Roche il y a environ 3 ans
- Fichier 0001-sigerly-add-sigerly-connector-47856.patch 0001-sigerly-add-sigerly-connector-47856.patch ajouté
Remarques prises en compte.
(si ça continue je n'aurais plus d'excuse pour ne pas tout faire en anglais)
Mis à jour par Frédéric Péters il y a environ 3 ans
- Statut changé de Solution proposée à Solution validée
Ok go ainsi.
Mis à jour par Nicolas Roche il y a environ 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit de1e45a50eda6e1ef38d874ca6ec6904d3ba071f
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date: Mon Oct 19 15:16:42 2020 +0200
sigerly: add sigerly connector (#47856)
Mis à jour par Frédéric Péters il y a environ 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
sigerly: add sigerly connector (#47856)