Produits Entr'ouvert » Passerelle

Précédemment l'idée était plutôt d'avoir la même API, plutôt qu'un connecteur "générique". (à la manière de l'API SMS, de l'API factures, de l'API famille).

Ce serait pas mal d'expliciter un plan dans ce ticket; on passe de "connecteur générique" à "API commune" via un changement de titre du ticket, sans détails, et là ça partirait quand même toutefois vers une part de code commun, avec déjà pour un endpoint un conflit explicite avec l'API existant dans le connecteur MDEL, ce qui amènera une grande joie lorsqu'à la mise à jour de passerelle il faudra en même temps aller éditer des workflows.

Un plan, ça pourrait commencer par réfléchir et définir précisément une API (genre dans une page du wiki, pas sous forme de code), qui aurait notamment comme caractéristique de ne pas avoir de endpoint en conflit avec ceux du connecteur MDEL, que ce connecteur puisse ensuite être étendu pour gérer à la fois son API et la nouvelle.

Il y a un début de page décrivant l'API générique: https://dev.entrouvert.org/projects/passerelle/wiki/Connecteur_Etat_Civil ou il y a encore pas mal de choses à rajouter.

Serghei Mihai a écrit :

Ok, donc une classe exposant les endpoints create et status permettant de créer et récuperer le statut d'un dossier respectivement.
La liste des paramètres obligatoires varie d'un connecteur à l'autre donc ici il faut vérifier les paramètres communs. Pour l'instant je n'ai identifié que demand_id.

Contrairement à ce que fait MDEL, je suis d'avis que les paramètres passés au connecteur doivent être dans le payload json, sans extra. Cela aide aussi à la comprehension de ce que est envoyé au connecteur dans l'appel webservice de wcs.

Normalment le demand_id est déduis du display_id envoyé dans le payload.

Il y a un début de page décrivant l'API générique: https://dev.entrouvert.org/projects/passerelle/wiki/Connecteur_Etat_Civil ou il y a encore pas mal de choses à rajouter.

• display_id et receipt_time qui sont envoyé dans le payload
• le type de la demande (Naissance, Mariage, Décès, ...) et le type de deocument (Copie Intégrale, Extrait avec Filiation, Extrait sans filiation, ...) concernant le document
• Noms et prénoms du demandeur
• Noms et prénoms de l'intéréssé

Je vais finir l'édition de la page.

• type_demande
• type_document
• prenom_demandeur
• nom_demandeur
• prenom_interesse
• nom_interesse

pour pouvoir les publier dans la doc de l'admin fonctionnel et ainsi que les clients/CPF soient autonomes dans la configuration de l'appel au connecteur d'état civil.

Et au passage utiliser plutôt "date_reception" et non "receipt_time". Le display_id peut rester tel quel.

Dans mon esprit on ne prend pas en compte les extras: tous les paramètres, documentés, doivent être dans un dico plat et lors de l'appel au webservice on leur attribue les bonnes valeurs issues du formulaire.

Serghei Mihai a écrit :

Dans mon esprit

Dans le mien aussi, mode "kiss" avec emphase sur "stupid".

formdata = self.check_keys(formdata) laisse trop penser que check_keys pourrait modifier formdata.

if (key not in formdata) and (key not in formdata.get('fields', {})): la référence à 'fields' me laisse penser qu'on n'en est pas encore à juste considérer les données explicitement transmises, qu'il y a encore un jeu avec la transmission automatique des champs dans w.c.s.

À ce titre-là, aussi, les suffixes _raw dans l'API semblent superflus.

Aussi, avant ce code, n'y aurait-il pas besoin de relecture sur l'API proposée ? (pour ma part j'ai juste noté en passant un truc, qui a été pris en compte sans mise à jour de l'exemple, mais je n'ai pas eu de lecture détaillée).

À ce titre-là, aussi, les suffixes _raw dans l'API semblent superflus.

+1

Mais la page des spécifications contient encore des _raw.

Aussi, avant ce code, n'y aurait-il pas besoin de relecture sur l'API proposée ? (pour ma part j'ai juste noté en passant un truc, qui a été pris en compte sans mise à jour de l'exemple, mais je n'ai pas eu de lecture détaillée).

Je pense que si.

J'ai donc créé #17477 pour cette relecture.

Une version de l'api commune avec la version actuelle de la doc

/<connector>/<slug>/status/<demand_id>/ dans la documentation, je ne vois pas comment ce patch gère ça.

Je trouve toujours très peu d'utilité à cette écriture de code "mis en commun", particulièrement quand il n'est pas utilisé.

Faire :

-class MDEL(BaseResource):
+class MDEL(CivilStatusMixin, BaseResource):

Pour prouver que ça a un sens.

Et j'écrivais plus haut :

[...] déjà pour un endpoint un conflit explicite avec l'API existant dans le connecteur MDEL, ce qui amènera une grande joie lorsqu'à la mise à jour de passerelle il faudra en même temps aller éditer des workflows.

Ça sera nettement révélé ici.

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

Une version de l'api commune avec la version actuelle de la doc

/<connector>/<slug>/status/<demand_id>/ dans la documentation, je ne vois pas comment ce patch gère ça.

Je trouve toujours très peu d'utilité à cette écriture de code "mis en commun", particulièrement quand il n'est pas utilisé.

Faire :

[...]

Pour prouver que ça a un sens.

Et j'écrivais plus haut :

[...] déjà pour un endpoint un conflit explicite avec l'API existant dans le connecteur MDEL, ce qui amènera une grande joie lorsqu'à la mise à jour de passerelle il faudra en même temps aller éditer des workflows.

Ça sera nettement révélé ici.

J'avais cru comprendre que le plan était de spécifier/développer l'api commune. L'utiliser avec CityWeb puis par la suite faire un refactoring du connecteur MDEL pour qu'il l'utilise ensuite.
Faire un refactoring de MDEL en meme temps ne me dérange pas non plus. On va partir dessus sauf avis contraire.

J'avais cru comprendre que le plan [...]

Il y avait une invitation dans un commentaire plus tôt : « Ce serait pas mal d'expliciter un plan [...] ».

Sans nécessairement toucher plus avant au code du connecteur mdel dès maintenant, lui faire utiliser la classe, ça permettra déjà d'éviter les clashs de compatibilité, qui rendront la migration pénible. (ce que je notais "déjà pour un endpoint un conflit explicite avec l'API existant dans le connecteur MDEL, ce qui amènera une grande joie lorsqu'à la mise à jour de passerelle il faudra en même temps aller éditer des workflows.")

J'ai rajouté un test pour m'assurer que les payload au nouveau et au format "legacy" sont correctement traités.
Pareil pour l'intérrogation du endpoint status.

Je ne vois pas comment la présence du demand_id dans la query string, qui est le format "legacy" est gérée correctement par ce code :

    @endpoint(perm='can_access', pattern='(?P<demand_id>[\w-]*)')
    def status(self, request, demand_id=None, *args, **kwargs):
        """Return demand's status
        """ 
        if not demand_id and 'demand_id' not in request.GET:
            raise APIError('demand_id is required')

        demand = Demand.objects.get(demand_id=demand_id, resource=self)

Et je ne vais pas plus loin, et rembobine jusqu'à ce commentaire que je posais :

Ce serait pas mal d'expliciter un plan dans ce ticket; on passe de "connecteur générique" à "API commune" via un changement de titre du ticket, sans détails, et là ça partirait quand même toutefois vers une part de code commun, avec déjà pour un endpoint un conflit explicite avec l'API existant dans le connecteur MDEL, ce qui amènera une grande joie lorsqu'à la mise à jour de passerelle il faudra en même temps aller éditer des workflows.

Il faut vraiment s'arrêter et définir ce plan, parce que sinon à chaque relecture vont revenir des questions autour; les deux seules voies raisonnables que j'imagine :

• 1) Définir une API commune et rien d'autre, c'est le ticket #17477, on fait gaffe là-bas à ne pas créer d'API incompatible avec le connecteur MDEL existant et on peut rejeter ce ticket.
• 2) Définir une classe de base / mixin contenant les parties spécifiques passerelle d'un connecteur, il faut choisir un connecteur (MDEL ou CityWeb) et adapter/faire celui-ci en mettant en commun du code; c'est galère de gérer deux tickets et donc pareil, je rejetterais celui-ci.

Faire du code "hors sol" ici, ça va continuer à gravement me déranger.

Ne parlons ici que de 0001, et je relis pas tout le blabla précédent du ticket, mais dans 0001 selon moi il devrait apparaitre l'ensemble des possibilités décrites sur https://dev.entrouvert.org/projects/passerelle/wiki/Connecteur_Etat_Civil au lieu des quelques variables obligatoires. Il manque aussi un try/except sur le json.loads du payload.

(pour 0002 le transforme sur l'ensemble des valeurs, c'est pas bien, effets de bord garantis)

• des formulaires w.c.s inspiré de monservicepublic.fr:
  - https://psl.service-public.fr/mademarche/EtatCivil/demarche?action=NAISSANCE
  - https://psl.service-public.fr/mademarche/EtatCivil/demarche?acton=MARIAGE
  - https://psl.service-public.fr/mademarche/EtatCivil/demarche?action=DECES
• Un workflow basique envoyand la demande vers un connecteur AEC.

• certificate_type: birth, marriage, death, other
• applicant_status (qualité du demandeur): concerned, partner, parent, child, representative, other
• title: mr, ms, mx

Ces valeurs changent en fonction du connecteur. Vu que le connecteur est censé fournir des sources de données, on peut utiliser les valeurs fournies par le connecteur.
L'avantage que j'y trouve c'est que dans le code du connecteur, on a pas à faire une correspondance entre ces valeurs prédéfinis et les valeurs attendues par l'application à laquelle on se connecte en bout de chaine.

Josué Kouka a écrit :

Je me disais, est ce qu'il ne serait pas mieux de ne pas fournir des valeurs par defaut pour certains champs. Je parle de champs tel que:

• certificate_type: birth, marriage, death, other
• applicant_status (qualité du demandeur): concerned, partner, parent, child, representative, other
• title: mr, ms, mx

Ces valeurs changent en fonction du connecteur. Vu que le connecteur est censé fournir des sources de données, on peut utiliser les valeurs fournies par le connecteur.
L'avantage que j'y trouve c'est que dans le code du connecteur, on a pas à faire une correspondance entre ces valeurs prédéfinis et les valeurs attendues par l'application à laquelle on se connecte en bout de chaine.

Oui ça me parait sain que pour les référentiels évidents tu définisses toi même ta nomenclature une fois pour toute et prévoir que chaque implémentation devra fournir un mapping vers sa nomenclature propre, s'agissant de l'état civil ça devrait représenter la totalité.

L'intérêt c'est aussi que ça nous permettra d'avoir aussi un formulaire pure d'état civil pour les villes qui n'ont pas de logiciel ou pas de connecteur.

Josué Kouka a écrit :

Une correction sur le try/except pour le decodage json.
Je ne vois pas trop mettre toute les variables dans le fichier __init__.py du coup, je joins la documentation dans un fichier readme.md.

Je te conseillerai d'éviter de mettre du code dans un init.py sauf si quelqu'un t'a donné une bonne raison de le faire, ça évite souvent des problèmes de boucle d'import, crée plutôt un fichier models.py ou mixin.py.

Adresse électronique (Exemple : nom@exemple.com)

Traditionnellement on utilise le champ "remarque" pour donner les exemples.

Maintenant il faut refaire le patch 0002.

Et comme on en est au commentaire 39 je te suggère de pousser une branche, ce sera plus simple à relire.

Benjamin Dauvergne a écrit :

Et comme on en est au commentaire 39 je te suggère de pousser une branche, ce sera plus simple à relire.

Ok, voici la branche https://git.entrouvert.org/passerelle.git/log/?h=wip/aec_interface

Mais dans la branche wip/aec_interface il y a du code à relire. Cette relecture est désormais proposée dans un autre ticket ?

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

Mais dans la branche wip/aec_interface il y a du code à relire. Cette relecture est désormais proposée dans un autre ticket ?

Non, c'est au même endroit.

Vu #24438 j'ai donc aussi regardé la gestion des dates dans le workflow proposé; ça ne va pas.

Josué qui me demande une relecture par jabber à qui je réponds ici : rebase ta branche.

Emmanuel Cazenave a écrit :

Josué qui me demande une relecture par jabber à qui je réponds ici : rebase ta branche.

Déja rebasé sur master.

Josué Kouka a écrit :

Emmanuel Cazenave a écrit :

Josué qui me demande une relecture par jabber à qui je réponds ici : rebase ta branche.

Déja rebasé sur master.

My bad.

Par contre "grosse branche", déjà d'autres intervenants, je laisse.

Brice Mallet a écrit :

OK pour passer connecteur AEC générique en test en l'état puisque validé par Orléans et Dreux (enfin le sera dès que disponible sur test, on se mord la queue).
Si Stéphane a le temps de valider par ailleurs, tant mieux, sinon je souhaite que l'on bascule en test quand même dès à présent (nécessaire pour Dreux)

Tel qu'indiqué le 13 juin, le formulaire Orléans a été construit pour être très complet, donc adresser toutes les configurations que pourraient se poser, dans le futur, les autres collectivités utilisatrices : en ce sens le formulaire est générique, jusqu'à preuve du contraire.
Mais ce formulaire fait appel à des source de données depuis le connecteur (liste des civilités, des genres, natures d'actes, types de personnes concernées, types de documents) et donc, pour cet aspect, je ne vois pas comment cela pourrait être généraliser puisque les référentiels peuvent être différents de logiciel en logiciel.
Et ce que j'indiquais, pour pouvoir valider dans le cas de / avec Dreux, j'ai besoin de disposer du connecteur en recette pour tester.

Mais ce formulaire fait appel à des source de données depuis le connecteur (liste des civilités, des genres, natures d'actes, types de personnes concernées, types de documents) et donc, pour cet aspect, je ne vois pas comment cela pourrait être généraliser puisque les référentiels peuvent être différents de logiciel en logiciel.

Les référentiels peuvent être différents mais les référentiels sont justement servis par passerelle, quand la donnée revient incorporée à la demande, le connecteur peut l'interpréter.

Imaginons le formulaire, il a un champ genre, alimenté par la source de données "genres" fournie par le connecteur. Le connecteur 1, il annonce m/f, en retour la réponse arrive, elle peut être traitée. Le connecteur 2, il annonce m/f/x, en retour la réponse arrive, elle peut être traitée.

(mais j'accepte l'abandon de l'idée)

(mais j'accepte l'abandon de l'idée)

Et de discuter à l'instant avec Serghei, et vu les échéances pour Dreux (mise en production début octobre alors que chantier ouvert depuis mars sur ce projet particulier), je suis pour malheureusement encore louper cette occasion et produire un 3ème connecteur état civil, celui pour Mélodie/ActesWeb d'Arpège.