Sécuriser les adresses dans APLyPro

[gtournadre]

Vu en COSUI ASP du 31 janvier 2025, les adresses APLyPro sont stockées sur 2 champs. SERAPIS attends des adresses normées. On utilise donc 2 balises pour envoyer l'adresse à SERAPIS mais ces balises sont limitées à 38 caractères. Les adresses ne sont donc pas forcément renseignées correctement.
Cela pose un réel problème pour envoyer les ordres de recouvrement qui souvent reviennent à l'ASP comme non distribués.
Ce besoin est en lien avec la mise à plat des appels Sygne et Fregata.

[gtournadre]

Pour sécuriser et harmoniser la récupération des adresses des élèves :
Ajouter une ligne 3 d'adresse à l'étudiant dans APLyPro.
1. Mapper Sygne :
L'adresse de l'élève est récupérée lors de l'appel individuel à partir de l'INE, objet "adrResidenceEle".
"codeCommuneInsee" :: "address_city_insee_code"
"codePostal" :: "address_postal_code"
"codePays" :: "address_country_code"
"adresseLigne1" :: "address_line1"
"adresseLigne2" :: "address_line2"
"adresseLigne3" :: "address_line3"
"libelleCommune" :: "adress_city

2. Mapper Fregata
L'adresse de l'élève est récupérer lors de le l'appel à l'établissement objet "adresseApprenant".
"communeCodeInsee" :: "address_city_insee_code"
"communeCodePostal" :: "address_postal_code"
"payscodeInsee" :: "address_country_code"
"ligne2" :: "address_line1"
"ligne3" :: "address_line2"
"ligne4" :: "address_line3"

Idéalement on peut limiter la taille des champs addre_line1, address_line2 et address_line3 car pour envoyer dans SERAPIS, on sera limité 38 caractères.

[pskl]

Chez Fregata c'est adresseIndividu l'objet en question et c'est celui que l'on utilise actuellement

Je serais plutôt partant de tout garder sur le même attribut comme on le fait maintenant avec address_line1 quitte à décomposer l'addresse.

1. Le risque de tronquage -> ca n'est plus possible, une erreur de validation apparaitrait au moment de la création du fichier
2. Risque d'avoir les mauvaises infos dans les mauvaises cases: quasi impossible à éviter je pense vu le côté disparate des infos que l'on a via API

Moi je verrais juste une addition c'est : en cas de longueur qui excède la limite découper les infos et les répartir sur les autres balises.

[gtournadre]

Effectivement adresseIndividu est un sous-objet de adresseApprenant.
Pourquoi pas tout cumuler dans adress_line1, mais alors le faire aussi pour Sygne, et par contre mettre un séparateur qu'on reconnaîtra, pour justement pouvoir ventiler le contenu de adress_line1 dans 1, 2 ou 3 balises du fichier SERAPIS

[gtournadre]

Suite au StandUp du 19 février 2025 :
Acté de garder une seule ligne Adresse dans APLyPro, qui contiendra les données des sytèmes sources séparées par des pipes |.
Ligne1 à Ligne 4 pour Sygne
Ligne1 à Ligne 7 pour Fregata
Dans Sygne, si en base la ligne ne contient rien, elle n'est pas servie.
Dans Fregata, toutes les lignes sont servie.
Il faudrait donc ajouter un test quand on moissonne Fregata pour éviter d'insérer le | si le champ est vide.

Pour envoyer un indu à SERAPIS, on alimentera l'adresse de la manière suivante :
<POINTREMISE> contenu entre début de adresse et premier | si nb de caractères inférieur ou égal à 38
<CPLTPOINTGEO> contenu entre premier | et second | si nb de caractères inférieur ou égal à 38
<CPLTDISTRIBUTION> contenu entre second | et troisème | si nb de caractères inférieur ou égal à 38
L'envoi du code postal, code insee commune et code insee pays ne change pas.

Si un tronçon de l'adresse qu'on doit envoyer supérieur à 38 caractères, alors la déclaration d'indu ne partira pas et on aura une erreur dans Sentry