[TRA 15238] Export SSD

[silto]

Features

Backend

• endpoint de mutation generateWastesRegistryExport pour lancer un export registre
• endpoint de query registryExports, registryExport pour récupérer les infos sur les exports effectués
• endpoint de query registryExportDownloadSignedUrl pour récupérer le lien de téléchargement d'un export

Frontend

• page d'exports registre v2

demo.export.updated.mov

Tech

Nouveau codegen GraphQL dans /libs

Afin d'avoir accès aux types graphQL dans /libs, ajout d'une génération de types équivalent à ceux de la backend dans /libs/back/codegen (équivalent à ce qui est fait pour la front). Il faut ensuite utiliser ces types en back et de retirer la génération legacy (pas fait dans cette PR pour ne pas l'alourdir inutilement). ⚠️ J'ai peut-être oublié la phase de génération (npx nx run @td/codegen-back:build) à des endroits (deployment, test,...), si vous pouvez vérifier.

Table RegistryLookup pour les exports

Afin d'avoir des exports performants, on utilise une table unifiée RegistryLookup, qui doit être mise à jour à la création/update/suppression de lignes de registres, mais aussi à la création/update/suppression de bordereaux, à la façon des updates d'elastic. Pour l'instant ce nouveau système de registre cohabite avec l'ancien, mais vise à le remplacer.
Cette table comporte des index et des système d'uuid pour permettre une recherche efficiente sur des millions de lignes.
Elle comprend une ligne par déclaration/bordereau et par type de registre d'export où celà doit apparaître. Pour les registres SSD traîtés ici, ils n'apparaissent que dans un seul registre (SSD), mais pour les bordereaux, ily aura une ligne par registre d'export concerné.
La logique de mise à jour de cette table se trouve dans libs/back/registry/src/lookup/utils.ts.

Lancement d'export et affinage des données

Les demandes d'export arrivant dans generateWastesRegistryExport passent par une validation des privilèges, puis les différents sirets accessibles à l'utilisateur sont triés, en fonction de si la demande est fait pour tous les établissements, un seul siret, ou en tant que délégataire. Les choix des différents filtres sont ajoutés à l'objet registryExport, qui sert de source d'infos pour le job d'export (comme ça pas besoin de refaire le traitement dans le job). Seules les dates (dateRange) sont transmises au job tel quel, car la structure du filtre de dates est un peu trop complexe pour la stocker dans registryExport avec toutes ses nuances (supérieur (ou égal), strictement supérieur, etc). Seule une version simplifiée des dates est stockée dans RegistryExport pour l'affichage.

Process d'exports et pipelines

La logique d'export dans back/src/queue/jobs/processRegistryExport.ts est faite pour optimiser le process au maximum. L'élément central est l'utilisation de streams pour récupérer les données depuis la db (dans streamLookup) puis de piper ces données dans des transformers (qui préparent la donnée), dans des utilitaires csv/xls pour créer les bons formats de fichier, puis dans le stream de sortie.
De cette façon, pas plus de quelques centaines de lignes sont en mémoire à la fois, et la lecture de la db se fait à la vitesse à laquelle les données peuvent être uploadées en sortie. Les valeurs de pagination de la lecture en db (pages de 100 lignes, avec un buffer de 200 lignes dans le stream) ont été choisies arbitrairement et peuvent probablement être affinées à l'avenir.

Changement de dependencies

• bump @codegouvfr/react-dsfr: 1.13.8 -> 1.14.5 pour avoir accès au nouveau composant de tooltip, utilisé dans la liste des exports pour éviter d'avoir à afficher toutes les entreprises concernées par un export dans le tableau
• bump uuid: 9.0.0 -> 11.0.3 pour avoir accès à UUID v7, qui permet de générer des UUID prenant un timestamp en entrée, et qui peuvent être classés par ordre chronologique. Utilisé pour la pagination avec curseur lors de l'export.

Déploiement

Ajouter un bucket S3, et ajouter la var d'env S3_REGISTRY_EXPORTS_BUCKET (déjà fait pour recette)

• Mettre à jour la documentation
• Mettre à jour le change log
• Documenter les manipulations à faire lors de la mise en production (sur le ticket Favro de release)
• S'assurer que la numérotation des nouvelles migrations est bien cohérente
• Informer le data engineer de tout changement de schéma DB

---

• Ticket Favro
• Autre ticket
• spec filtres

[Riron]

Top!
Y'aura pas mal de petits console log à cleaner, mais hâte de voir ça 🥳

[providenz]

Joli pavé bien dense, bravo :)
On gagnerait à avoir la description de la PR quelque part dans le dépôt pour comprendre facilement le fonctionnement global de la feature, ça fait longtemps qu'on parle d'une doc développeur interne, ça pourrait être l'occasion.

[sonarcloud]

Quality Gate passed

Issues
25 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.2% Duplication on New Code

See analysis details on SonarQube Cloud