[TRA 15239] Export registre entrant

[silto]

Contexte

Cette PR ajoute l'export V2 des registres entrants.
Cet export rassemble :

• Registre RNDTS DND entrant
• Registre RNDTS TEXS entrant
• BSDD
• BSDA
• BSDASRI
• BSFF
• BSVHU
• BSPAOH

Les principaux composants permettant l'ajout de tout ça dans l'export se trouvent dans les fichiers registryV2 (pour les bordereaux) et registry (pour les registres RNDTS, dans libs).

Ces fichiers contiennent 3 composants principaux:

• toIncomingWasteV2 -> mapping pour passer de bordereau/ligne de registre au format d'export
• updateRegistryLookup -> méthode de mise à jour de la table RegistryLookup, qui sert à chercher les lignes à intégrer à l'export
• rebuildRegistryLookup -> méthode qui permet de recréer la table lookup, en cas de problème ou pour l'initialisation

les méthodes toIncomingWasteV2 sont utilisées au moment de l'export. Les méthodes updateRegistryLookup sont utilisées à la création/update/suppression de lignes de registre et de bordereaux (un peu comme les updates elastic).

Les méthodes rebuildRegistryLookup sont utilisées uniquement dans le script de rebuild (npx nx run back:rebuild-registry-lookup).

A part ça, beaucoup de changements de la structure des fichiers liés à l'export, parce que je me suis rendu compte que ça faisait plus de sens. Par exemple rassembler la logique d'export des registres dans back/registryV2 au lieu d'être splité dans libs/registry, ce qui n'est pas logique car libs/registry concerne les imports de registres RNDTS, pas les exports (qui concernent à la fois les bordereaux et les registres RNDTS).

Check d'intégrité

J'ai ajouté dans le script back/src/scripts/bin/rebuildRegistryLookup.ts un chek d'intégrité permettant de vérifier que les bordereaux apparaissant dans les registres V1 (elastic) apparaissent bien dans les registres v2 (lookup). Je me chargerai de run ce script de temps en temps en recette puis en prod afin de valider qu'il n'y a pas de drift après la création/modification de bordereaux.

A faire au deploy

Besoin de réindexer dans la table lookup après le merge:

npx nx run back:rebuild-registry-lookup

Points de vigilance pour les intégrateurs

Les anciens endpoints de registres ne changent pas, ces nouveaux exports sont séparés dans des endpoints registryV2 de façon à ne pas avoir de conflits et permettre une transition "douce".

Démo

export.registre.entrant.demo.mov

Ticket Favro

Inclure les déclarations de D(N)D entrant et TEXS D(N)D dans l'export de registre entrant

Checklist

• 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)
• Informer le data engineer de tout changement de schéma DB

[Riron]

Je me demande juste si on ne devrait pas mettre la MAJ du lookup avec l'indexation ES. Le risque étant la perte du côté transactionnel et la cohérence des données, évidemment. Mais ca séparerait vraiment le process registre du process bsd

[Riron]

👍

[sonarqubecloud]

Quality Gate failed

Failed conditions
7.9% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud