Orchestrateur

L'orchestrateur est en charge d'exécuter les vérifications (Check) et traitements (Processing). Gitlab est la solution qui gère l'orchestration. En se basant sur le système de pipeline, il est possible de créer un workflow en laissant Gitlab gérer toute la partie technique. Ce workflow suit donc la syntaxe Gitlab CI. Le workflow peut se composer de différentes étapes (séquentielles et/ou parallèle).

Création d'une exécution (Pour les vérification seulement, sinon voir Création d'une exécution(V2))

Avant de déclarer un nouveau type d'exécution dans l'Entrepôt, il faut créer le descripteur de l'exécution. Ce fichier descripteur doit respecter la syntaxe Gitlab CI .gitlab-ci.yml https://docs.gitlab.com/ee/ci/yaml/. Le fichier peut avoir n'importe quel nom sauf .gitlab-ci.yml.

Variables disponibles

La variable d'environnement GPF_WORK_DIR donne le chemin du répertoire de travail contenant les fichiers de livraison pour l'exécution en cours.

Paramètres d'une exécution

A la racine du répertoire GPF_WORK_DIR, le fichier parameters.json contient toutes les informations nécessaires à l'exécution :

• executionId : identifiant de l'exécution à utiliser pour les logs
• userId : identifiant de l'utilisateur qui a lancé l'exécution
• paramètres : liste de clés/valeurs passer en paramètre pour l'exécution
• information de connexion BDD (url, user, password, schéma) dans le cas des traitements vecteurs
• information de conteneur Swift (url, token) dans le cas traitements raster
• TODO

{
    executionId: 1231544456-1546546-164565 (UUID),
    userId: 1231544456-1546546-164565 (UUID),
    inputParameters: {
        param1: value1,
        param2: value2,
        ...,
    },
    targetParameters: {
        databaseInfo: { // si traitement vecteur
            url: "",
            user: "",
            password: "",
            schema: ""
        },
        objectStorageInfo:{ // si traitement raster
            url: "",
            token: ""
        } 
    },
    technicalParameters:{ // paramètres pour le retour du statut
        databaseInfo: {
            url: "",
            user: "",
            password: "",
            schema: ""
        } 
    }

}

A la racine du répertoire GPF_WORK_DIR, le répertoire upload contient les fichiers de la livraison.

TODO dans quel dépôt on met les fichiers d'exécutions

Lancement d'une exécution

Lorsque l'API Entrepôt est appelé pour un lancement d'exécution, la géoplateforme traduit cet appel pour que l'orchestrateur puisse l'exécuter.

Exécution d'un workflow

• L'exécution Parent-Child
• Variables
• parameters.json
• Gitlab-ci.yml
• Gestion des erreurs

Niveau de logs

Variable d'envrionnement GPF_LOG_LEVEL avec comme valeurs possibles : DEBUG|INFO|WARN|ERROR

Possibilité de le surcharger dans la Parent pipeline -> à définir

Fin du traitement

{
    executionId: "",
    status: SUCCESS|FAILURE|TECHNICAL_ERROR,
    failures: [],
    trace: ""
}

FAILURE = le résultat de l'exécution n'est pas bonne (sens métier). TECHNICAL_ERROR = Erreur/Exception pendant l'exécution, elle n'a pas pu aboutir.

Rabbit

Nom des queues à définir/renseigner. (Variable d'environnement pour laisser la possibilité de changer ?)

UPDATE executionResult SET status = '' AND result = "{JSON}"

Création d'une exécution (V2)

Avant de déclarer un nouveau type d'exécution dans l'Entrepôt, il faut créer le descripteur de l'exécution. Ce fichier descripteur doit respecter la syntaxe Gitlab CI .gitlab-ci.yml https://docs.gitlab.com/ee/ci/yaml/. Le fichier peut avoir n'importe quel nom sauf .gitlab-ci.yml.

Variables disponibles

La variable d'environnement GPF_WORK_DIR donne le chemin du répertoire de travail contenant le fichier parameter.json

Paramètres d'une exécution

A la racine du répertoire GPF_WORK_DIR, le fichier parameters.json contient toutes les informations nécessaires à l'exécution :

• executionId (_id) : identifiant de l'exécution à utiliser pour les logs
• job_name : nom de la pipeline
• pipeline_status : map clé valeur, qui contien le nom et le status d'un job
• parameters : liste de clés/valeurs passer en paramètre pour l'exécution
• inputs: objet en entrée qui servira aux scripts
• output: objet en sortie qui est attendu.
• dans l'objet global_variables:
• information de connexion BDD (url, user, password, schéma)
• information de conteneur Swift (url, token)

{
    _id*    uuid
    job_name*    string
    pipeline_status: {  --> c'est une map qui contient pour chaque job de la pipeline le résultat
        string: string // job_name: SUCCESS|FAILURE|TECHNICAL_ERROR    
        job_name1 : SUCCESS,
        job_name2 : FAILURE
        ...
    },
    inputs*    {
        uploads    [{
            _id*    string
            type*    stringEnum(uploadType)
            name*    string 
            type_infos* {dépend du type de livraison}
            srs* string 
            extent {
                west BigDecimal // precision = 13, scale = 10  EG: 140.0094623500
                east BigDecimal
                north BigDecimal
                south BigDecimal
            }
            size    long
            storage: {
                _id* string
                name string
                type stringEnum(storageType)
                type_infos { dépend du type de storage }
            }
        }]
        stored_datas    [{
            _id*    string 
            type* stringEnum(storedDataType) 
            name*    string
            type_infos* {dépend du type de donnée stockée}
            srs    string
            extent {
                west BigDecimal
                east BigDecimal
                north BigDecimal
                south BigDecimal
            }
            size long 
            storage: {
                _id* string
                name string
                type stringEnum(storageType)
                type_infos { dépend du type de storage }
            }
        }]
    }
    output*  (Obligatoire uniquement dans le cas d'un processing, pas pour un checking) 
    {
       upload    {
           _id* string 
           type* stringEnum(uploadType)
           name* string
           type_infos* {dépend du type de livraison}
           srs* string
           extent {
               west BigDecimal
               east BigDecimal
               north BigDecimal
               south BigDecimal
           }
           size long
           storage: {
               _id* string
               name string
               type stringEnum(storageType)
               type_infos { dépend du type de storage }
           }
       }
       stored_data    {
            _id*    string
            name*    string
            type*    stringEnum(storedDataType)
            type_infos* {dépend du type de donnée stockée}
            srs    string
            extent {
                west BigDecimal
                east BigDecimal
                north BigDecimal
                south BigDecimal
            }
            size long 
            storage: {
                _id* string
                name string
                type stringEnum(storageType)
                type_infos { dépend du type de storage }
            }
        }
    },
    parameters*    {
        "name1": "value1",
        "name2": "value2"
    },
    global_variables* {
        postgresql* {
            user*:
            pass*:
        } 
        swift* {
            identity_api_version,
            auth_url,
            project_domain_name,
            region_name,
            tenant_id,
            tenant_name,
            user_domain_name,
            username,
            password
        } 
    }
}

Exemple pour une donnée vectorielle

Exemple pour une donnée vectorielle
{
    _id*    uuid
    job_name*    string
    pipeline_status: {
        vector_integration : SUCCESS    --> le nom du script de votre coté
    },
    inputs*    {
        uploads    [{
            _id*    string,
            type*    VECTOR,
            name*    string,
            type_infos* {},
            srs* string,
            extent {
                west BigDecimal
                east BigDecimal
                north BigDecimal
                south BigDecimal
            }
            size    long
            storage: {
                _id* string
                name string
                type : SWIFT
                type_infos {
                    pot_name: string
                }
            }
        }]
    }
    output* (Obligatoire uniquement dans le cas d'un processing, pas pour un checking)
    {
       stored_data    {
            _id*     string
            name*    string
            type* : "VECTOR_DB"
            type_infos* { // --> null si GENERATING, et rempli si MODIFYING
                relations: [
                    name: string
                    type: TABLE | VIEW
                    attributes: string[]
                    primary_key: string[]
                ]
            }
            status* : MODIFYING / GENERATING
            srs    : string    // --> null si GENERATING, et rempli si MODIFYING
            extent {
                west BigDecimal
                east BigDecimal
                north BigDecimal
                south BigDecimal
            } // --> null si GENERATING, et rempli si MODIFYING
            size :    // --> taille en octets du schéma
            storage: {
                _id* string,
                name string,
                type : POSTGRESQL,
                type_infos {
                    host,
                    port,
                    database_name
                }
            }
        }
    },
    parameters*    {
        "srs": "EPSG:4326"
    },
    global_variables* {
        VOIR MESSAGE GENERAL
    }

}

Lancement d'une exécution

Lorsque l'API Entrepôt est appelé pour un lancement d'exécution, la géoplateforme traduit cet appel pour que l'orchestrateur puisse l'exécuter.

Exécution d'un workflow

• L'exécution Parent-Child
• Variables
• parameters.json
• Gitlab-ci.yml
• Gestion des erreurs

Niveau de logs

Variable d'envrionnement GPF_LOG_LEVEL avec comme valeurs possibles : DEBUG|INFO|WARN|ERROR

Possibilité de le surcharger dans la Parent pipeline -> à définir

Fin du traitement

le resultat d'un traitement est attendu dans un fichier nommé result.json, qui contiendra la même structure que le parameter.json avec les donnée mise à jour que les scripts auront générés.

liste des donnée qui sont suceptible de changer.

• Dans output.upload ou output.stored_data :
• type_infos de
• srs
• extent
• size
• Dans pipeline_status : Une ligne par job terminé

FAILURE = le résultat de l'exécution n'est pas bonne (sens métier). TECHNICAL_ERROR = Erreur/Exception pendant l'exécution, elle n'a pas pu aboutir.

Rabbit

Nom des queues à définir/renseigner. (Variable d'environnement pour laisser la possibilité de changer ?)

UPDATE executionResult
SET status = '' AND result = "{JSON}"