Produits Entr'ouvert » Passerelle

De ce que je lis dans le .docx les transferts SFTP sont gérés par la DSI, donc on a juste à produire des CSV dans un le répertoire media/gesbac/<slug>/publik_vers_gesbac/ en gros.

Non, nous devons envoyer les fichiers sur un SFTP de la DSI.
Ensuite Gesbac vient chercher (je ne sais pas comment) les fichiers dans ce répértoire, il les archive, etc.

Serghei Mihai a écrit :

Non, nous devons envoyer les fichiers sur un SFTP de la DSI.
Ensuite Gesbac vient chercher (je ne sais pas comment) les fichiers dans ce répértoire, il les archive, etc.

Alors ça doit être une interprétation de ça dans le .docx :

Les transferts des fichiers csv Publik vers le serveur SFPT seront initiés par un séquenceur DSI le soir après la fin de la saisie des validations des dossiers d’instruction de demande de badge.

Peut-être que ça passera par deux FTPs mais ce serait bien d'avoir confirmation dès maintenant avant de développer du fonctionnement final.

Il y a un seul SFTP (#35849) sur lequel nous déposons les fichiers.
Ensuite la DSI ou Gesbac se débrouillent pour les récupérer et les donner à manger au logiciel métier, archiver les fichiers posés.

C'est ce qu'on a convenu lors d'une réunion téléphonique.

Serghei Mihai a écrit :

Il y a un seul SFTP (#35849) sur lequel nous déposons les fichiers.
Ensuite la DSI ou Gesbac se débrouillent pour les récupérer et les donner à manger au logiciel métier, archiver les fichiers posés.

C'est ce qu'on a convenu lors d'une réunion téléphonique.

Leur demander de mettre à jour leur document, je suis désolé d'être tatasse mais vraiment c'est mieux quand ils écrivent noir sur blanc ce qu'ils vont faire/veulent qu'on fasse.

Concernant le SFTP à voir si tu préfères gérer ça hors passerelle (genre un énième script client) ou via le nouveau champ sftp développé pour MDEL (je pense que c'est mieux d'avoir le suivi des transferts dans les logs passerelle, ça fait gagner du temps).

for param in ['demand_date', 'demand_time', 'producer_code'...

Plutôt que répéter cette liste, tirer ça du schéma ?

_~~

Mais avant ça peut-être, j'essaie de comprendre le fond :

• Une demande est envoyée de w.c.s. au connecteur, celui-ci l'enregistre sous forme de deux lignes dans un fichier CSV sur un serveur SFTP distant.
• Quand il est demandé la réponse à dune demande, il se passe un truc avec du SFTP entrant et des fichiers CSV qui sont cherchés et un objet CSV qui est créé et un "data" qui est une liste (des réponses?).

_~~

Cet objet "FileHandler", en soit, il apporte quelque chose ? Il me semble que non et qu'il est plus commun d'avoir ces opérations de traitement dans la classe du connecteur, pas dans une classe intermédiaire qui fait rien.

Ouais ça va pas du tout, on peut pas gérer un fichier CSV distant comme ça, l'objectif à la lecture du .docx est clairement pas d'avoir du temps réel (ça dit clairement la DSI, tous les soirs, etc...).

J'aurai vu un truc en 2 temps :

• à chaque appel send:
  1. on cherche ou on crée un objet CSV dans un statut "open"
  2. on crée un objet CsvLine avec les données du formulaire, fini (aucun souci de concurrence possible, tout va bien)
• tous les n-période (tous les soirs disont) on prend le fichier CSV open le plus vieux, on le passe en "closed", ensuite on se connecte au FTP on pose un CSV avec l'identifiant incrémental du CSV (genre le .id ça doit suffir), quand c'est terminé on passe l'objet CSV en statut "sent"

Si jamais il était besoin de conserver l'état d'un formulaire pour les retours alors faut un objet FormData qu'on pourra relier à plusieurs CSV sortant ou rentrant.

Terminé.

Aussi si on vise un seul sftp je pense qu'un seul champ SFTPField suffit, chemin et préfixe peuvent être mis en dur (on parle d'un connecteur contrib/ après tout).

Benjamin Dauvergne a écrit :

Ouais ça va pas du tout, on peut pas gérer un fichier CSV distant comme ça, l'objectif à la lecture du .docx est clairement pas d'avoir du temps réel (ça dit clairement la DSI, tous les soirs, etc...).

J'aurai vu un truc en 2 temps :

• à chaque appel send:
  1. on cherche ou on crée un objet CSV dans un statut "open"
  2. on crée un objet CsvLine avec les données du formulaire, fini (aucun souci de concurrence possible, tout va bien)
• tous les n-période (tous les soirs disont) on prend le fichier CSV open le plus vieux, on le passe en "closed", ensuite on se connecte au FTP on pose un CSV avec l'identifiant incrémental du CSV (genre le .id ça doit suffir), quand c'est terminé on passe l'objet CSV en statut "sent"

Faire cela tous les n-périodes ou au moment de l'appel webservice depuis wcs, je ne vois pas différence.
Que la DSI (ou Gesbac) vienne récupérer les fichiers tous les soirs, toutes les n heures, c'est leur affaire.

Si jamais il était besoin de conserver l'état d'un formulaire pour les retours alors faut un objet FormData qu'on pourra relier à plusieurs CSV sortant ou rentrant.

Je ne vois pas ce besoin. Seul l'identifiant de la demande est nécessaire.

Benjamin Dauvergne a écrit :

Aussi si on vise un seul sftp je pense qu'un seul champ SFTPField suffit, chemin et préfixe peuvent être mis en dur (on parle d'un connecteur contrib/ après tout).

Je préfère garder 2 champs sans hardcoder le chemin. Le connecteur sera utilisé par ailleurs (Orléans est demandeur) et le chemin peut être différent.
En plus, malgré ce que la doc indique:

Répertoire des demandes :            publik_vers_gesbac
...
Répertoire des fichiers retours :            gesbac_vers_publik

Le connecteur sera utilisé par ailleurs (Orléans est demandeur)

S'il s'agit d'une vraie application derrière qui peut se retrouver ailleurs et dont l'interfaçage y sera également celui-ci, ça devrait plutôt aller dans passerelle.apps.

Ah bah ça y est, malgré le "(on parle d'un connecteur contrib/ après tout)" plus haut.

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

Ah bah ça y est, malgré le "(on parle d'un connecteur contrib/ après tout)" plus haut.

Il s'agit d'un connecteur ré-utilisable et pas spécifique à un client, donc dans apps.
J'ai mis à jour la branche avec prise en compte de tes remarques.

Ta lecture est bonne.
Quand une réponse à une demande est faite, ça vérifie s'il y a déjà un fichier CSV sur le SFTP correspondant à la demande. Ça stocke les données dans un modèle éviter d'interroger le SFTP pour la même demande.

• les appels SFTP ne devrait pas être faits de manière synchrone (sur le GET surtout ça va être affreux) mais en tâche de fond
• tu supposes qu'en ne mettant qu'une demande par fichier .csv et ne le nommant avec l'id de la demande tu auras le retour dans un fichier du même nom, et juste ce retour, je ne vois rien dans le .docx qui nous assure de ça; il est spécifié : plusieurs demandes par CSV entrant, pareil en sortie; ça me parait bizarre surtout sachant que certaines demandes (d'après la spéc) seront traitées par un agent.

Serghei Mihai a écrit :

Benjamin Dauvergne a écrit :

Ouais ça va pas du tout, on peut pas gérer un fichier CSV distant comme ça, l'objectif à la lecture du .docx est clairement pas d'avoir du temps réel (ça dit clairement la DSI, tous les soirs, etc...).

J'aurai vu un truc en 2 temps :

• à chaque appel send:
  1. on cherche ou on crée un objet CSV dans un statut "open"
  2. on crée un objet CsvLine avec les données du formulaire, fini (aucun souci de concurrence possible, tout va bien)
• tous les n-période (tous les soirs disont) on prend le fichier CSV open le plus vieux, on le passe en "closed", ensuite on se connecte au FTP on pose un CSV avec l'identifiant incrémental du CSV (genre le .id ça doit suffir), quand c'est terminé on passe l'objet CSV en statut "sent"

Faire cela tous les n-périodes ou au moment de l'appel webservice depuis wcs, je ne vois pas différence.
Que la DSI (ou Gesbac) vienne récupérer les fichiers tous les soirs, toutes les n heures, c'est leur affaire.

Ok, comme tu ne connais pas la fréquence des lecture, tu devrais tout de même ne pas écrire directement dans le fichier et passer par un fichier temporaire puis renommer.

Je ne vois pas ce besoin. Seul l'identifiant de la demande est nécessaire.

C'est perturbant d'avoir appelé ça CSV en fait, même si tu ne produis qu'un fichier CSV par demande ce serait plus clair d'appeler ça Formdata ou un truc du genre.

Benjamin Dauvergne a écrit :

Je ne suis toujours pas ok avec ce fonctionnement dont je ne vois pas en partie où ça colle avec la doc :

• les appels SFTP ne devrait pas être faits de manière synchrone (sur le GET surtout ça va être affreux) mais en tâche de fond
• tu supposes qu'en ne mettant qu'une demande par fichier .csv et ne le nommant avec l'id de la demande tu auras le retour dans un fichier du même nom, et juste ce retour, je ne vois rien dans le .docx qui nous assure de ça; il est spécifié : plusieurs demandes par CSV entrant, pareil en sortie; ça me parait bizarre surtout sachant que certaines demandes (d'après la spéc) seront traitées par un agent.

Et pour le dire plus franchement, la spec renvoie le numéro de la demande dans le CSV je ne vois pas pourquoi on passe par un mécanisme basé sur le nom du fichier alors qu'on a déjà tout ce qu'il faut au niveau du CSV (colonne 2 du CSV, je reconnais que de nous forcer à un entier c'est un peu chiant).

Benjamin Dauvergne a écrit :

• les appels SFTP ne devrait pas être faits de manière synchrone (sur le GET surtout ça va être affreux) mais en tâche de fond

Dans un deuxième temps j'imaginais un job genre hourly ou daily qui vient interroger le SFTP pour lire les fichiers réponses et stocker tout dans la base.
Comme ça peu d'appels GET deboucheront sur des appels SFTP.

• tu supposes qu'en ne mettant qu'une demande par fichier .csv et ne le nommant avec l'id de la demande tu auras le retour dans un fichier du même nom, et juste ce retour, je ne vois rien dans le .docx qui nous assure de ça; il est spécifié : plusieurs demandes par CSV entrant, pareil en sortie; ça me parait bizarre surtout sachant que certaines demandes (d'après la spéc) seront traitées par un agent.

Yep, c'est une possibilité, mais nous avons convenu d'envoyer un fichier CSV par demande et recevoir un fichier par retour.
Cela facilitera le "debug" à l'éditeur (cette "API" n'a jamais été utilisée nulle part, d'après l'éditeur).

Et ce n'est pas dans la doc non plus, mais nous avons convenu que "xxxxx" dans le suffixe du fichier contiendra la valeur du fichier demande.

Pour revenir à ton idée: l'objet "Formdata" (je renommerai "CSV") stockera les données de l'appel webservice et dans un job daily écrira les fichiers sur le SFTP. Avec les flags qui vont bien pour différencier ceux qui ont été déjà écrits.

Branche à jour avec possibilité d'écrire un fichier par demande et lecture dans un ou plusieurs fichiers de retour.

• print row
• des ')' tous seuls sur une ligne mal indentés (merci d'installer vim et khuno)
• moi j'utiliserai bêtement les jobs plutôt que daily pour poser tes formulaires (comme ça c'est fait ASAP mais pas de façon synchrone) et pour la lecture des réponses hourly plutôt.