GPF Generate Archive - Documentation¶

Description: Ce script est chargé de copier sur le stockage final tous les fichiers livrés au sein des livraisons en entrée. Cette copie doit permettre de créer une nouvelle donnée stockée ARCHIVE diffusable ou d’en mettre à jour une déjà existante. Voir le ticket originel : https://jira.worldline.com/browse/IGNGPF-553
Author and contributors: Loïc Bartoletti, Jean-Marie Kerloch, Julien Moura
Version: 1.6.0
Source code: https://gitlab.gpf-tech.ign.fr/geoplateforme/traitements-vecteurs/gpf_generate_archive
Last documentation build: 30 July 2024

Spécification initiale¶

Voir le ticket JIRA

Contexte¶

Ce script sera exécuté afin de copier sur le stockage final tous les fichiers livrés au sein des livraisons en entrée. Cette copie doit permettre de créer une nouvelle donnée stockée ARCHIVE diffusable ou d’en mettre à jour une déjà existante.

Description¶

Ce script doit vérifier qu’une pyramide rok4 livrée sur l’entrepôt correspond bien au format attendus et que les informations fournies par l’utilisateur correspondent.

Données en entrée¶

de 1 à n livraisons de type ARCHIVE

Données en sortie¶

une donnée stockée de type ARCHIVE sur un stockage S3

Paramètres¶

le descripteur indiqué plus bas se situe dans le S3 dans le bucket défini par output/stored_data/storage/type_infos/pot_name et le “chemin” du fichier sera stored_data/{output/stored_data/_id}/__descriptor.json. Aucun fichier des livraisons ne doit se nommer __descriptor.json (le malandrin).

Étapes et règles métier¶

Contrôler les données :
- Vérification des types des entrées sorties et storage (voir régle ci-dessus)
- Toutes les livraisons en entrée doivent avoir le même srs
- Si la donnée en sortie est MODIFYING, son srs doit aussi être le même
- les noms des fichiers livrés (à plat sans arborescence) doivent être uniques pour ne pas avoir de conflit lors du stockage à plat

Tâche métier :

Si la donnée en sortie est MODIFYING existe, récupérer, charger son descripteur, sinon en créé un nouveau vide

Pour chaque fichier dans chaque livraison :

copier le fichier à l’emplacement final sur le S3 (Bucket output/stored_data/storage/type_infos/pot_name et “chemin” du fichier sera stored_data/{output/stored_data/_id}/{file_name}. Dans le cas MODIFYING, le fichier est remplacé.
Générer le bloc dans le descripteur avec les informations suivantes (remplacer le précédent si le fichier à été remplacé) :

[
    {
        "file_length": "int --> taille du fichier en octets",
        "file_type": "string --> mime-type du fichier",
        "file_name": "string --> nom du fichier",
        "format": "list[string] --> même chose que file_type, sauf si le fichier est une archive (zip, 7z, tar, tar.gz, si possible d'extraire ces 4 formats simplement, sans à avoir à tout décompresser) dans ce cas, c'est la liste des mime_type des fichiers contenus dans l'archive",
        "crs": "string --> inputs[n]/upload/srs",
        "url": "string --> emplacement du fichier sur le S3",
        "md5": "string --> clé md5 du fichier",
        "relation": "string --> `alternate` ou `section` (obligatoire) --> si le fichier est une archive partielle (issue d'un découpage du genre 7z.001) alors section, sinon alternate"
    }
]

Informations à retourner en sortie du script¶

Dans output.stored_data :
- type_infos :
  - files_number : nombre de fichiers total dans la donnée en sortie (à l’exclusion du __descriptor.json)
- srs : la projection des livraisons en entrée
- size : la taille complète des fichiers de la données stockée en sortie sur le S3 en fin de processus, en octets
- ancestors : liste vide
Dans pipeline_status : Une ligne indiquant le status du script :
- SUCCESS : L’intégration n’a pas rencontré de problème, pour aucun des fichiers de la livraison.
- FAILURE : Une erreur est intervenu lors du calcul de pyramide : les livraisons en entrée et la donnée en sortie si déjà existante n’ont pas toutes le même srs deux livraisons en entrée contiennent un fichier avec le même nom
- TECHNICAL_ERROR : En cas d’erreur technique (erreur de lecture / écriture dans le S3)

Logs¶

Même régles que les autres scripts de vérification
Logs spécifiques à remonter aux USER :
- Les grandes étapes du processus (pas de log fichier par fichier)
- Les fichiers en erreur et la cause de l’erreur
- Les erreurs plus globales s’il y en a
Logs spécifiques à remonter aux ADMIN :
- Le traitement de chaque fichier et son résultat.
- Les erreurs techniques rencontrées

Points d’attention¶

RAS

Usage

Development

Miscellaneous

Credits