Les traitements et les exécutions

Les traitements sont l'unique moyen sur la plateforme de créer des données stockées, diffusables. Ils permettent de transformer, optimiser, modifier les données destinées aux géoservices ou téléversées.

D'un point de vue technique, un traitement correspond à un script manipulant des données en entrée dans un format précis, et écrivant en sortie une donnée dans un format prédéfini.

D'un point de vue modèle, c'est une entité processing, commune à toute la plateforme. Chaque datastore aura accès à l'ensemble ou à une partie seulement des traitements disponibles sur la plateforme.

Utilisation des traitements

Utiliser un traitement revient à créer une exécution de ce traitement et la lancer au sein d'un entrepôt. Une entité processing execution appartient à un datastore.

Parcours des traitements disponibles au sein de l'entrepôt

L'API GET /datastore/{id}/processings permet de récupérer l'ensemble des traitements (avec pagination) disponibles dans l'entrepôt. Pour cibler plus précisément les livraisons voulues, il est possible de filtrer par nom : name=%chaîne% : nom complet ou partiel (% remplace au moins un caractère) des traitements voulues.

Voir les informations détaillées d'un traitement

Pour obtenir toutes les informations détaillées sur un traitement, en vue de l'utiliser, on utilise l'API GET /datastore/{id}/processings/{id}.

Sont présents :

• La description
• Le paramétrage
• Le type de donnée en entrée (livraison ou donnée stockée)
• Les vérifications exigées pour les livraisons en entrée
• Le type de données en sortie (livraison ou donnée stockée). Dans le cas d'une donnée stockée, on précise également les types de stockage possible (le premier sera celui par défaut si non fourni lors de la création d'une exécution).

Création de l'exécution de traitement

À la création de l'exécution avec POST /datastores/{id}/processings/executions, l'utilisateur va fournir :

• l'identifiant du traitement dont on veut créer une exécution
• 0 à n identifiants de livraisons en entrée
• 0 à n identifiants de données stockées en entrée
• un ensemble de clé-valeur comme paramètres
• une donnée en sortie :
  • soit un nom de livraison, pour que l'exécution génère une nouvelle livraison
  • soit un identifiant de livraison, pour que l'exécution modifie une livraison existante
  • soit un nom de donnée stockée, pour que l'exécution génère une nouvelle donnée stockée, et optionnellement des informations sur le stockage à utiliser (type et étiquettes)
  • soit un identifiant de donnée stockée, pour que l'exécution modifie une donnée stockée existante

Les contrôles suivants sont réalisés :

• l'entrepôt a-t-il accès au traitement demandé
• pour chaque livraison en entrée :
  • son type est-il accepté par le traitement précisé
  • a-t-elle passé avec succès toutes les vérifications requises
  • son statut est-il bien CLOSED ou CHECKING
• pour chaque donnée stockée en entrée :
  • son type est-il accepté par le traitement précisé
  • son statut est-il bien GENERATED ou MODIFYING
• pour chaque paramètre fourni, appartient-il à ceux prévu par le traitement
• pour chaque paramètre obligatoire du traitement, est-il bien fourni.
• pour la donnée en sortie :
  • si un nom est fourni et que c'est une donnée stockée, trouve-t-on un stockage correspondant aux informations fournies (type et étiquettes)
  • si un identifiant est fourni :
    • la donnée avec cet identifiant doit exister
    • son type doit correspondre à celui prévu en sortie du traitement
    • son statut doit être CLOSED pour une livraison, et GENERATED ou MODIFYING pour une donnée stockée
  • est ce que le quota sur le stockage cible n'est pas atteint

Dans le cas où toutes ces contraintes sont respectées, une exécution de traitement en statut CREATED est créée, et les paramètres non obligatoire avec valeur par défaut non fournis sont ajoutés.

À ce stade, aucune des données en entrée ou en sortie n'est verrouillée : il est possible de les supprimer, ce qui entraînera la suppression de cette exécution.

Il est aussi possible de supprimer une exécution CREATED (seul statut dans lequel il est possible de supprimer une exécution de traitement). Si la donnée en sortie avait été créée par cette exécution, elle est également supprimée.

Lancement de l'exécution de traitement

On peut lancer une exécution en statut CREATED via l'appel POST /datastores/{id}/processings/executions/{id}/launch. Dans un premier temps, l'exécution passe en statut WAITING : les données en entrée sont verrouillées (ne peuvent plus être supprimées) mais l'orchestrateur n'a pas encore commencé le travail.

Dans le cas où la donnée en sortie est une donnée déjà existante et en cours de modification (MODIFYING), il ne faut pas tout de suite déclencher le script pour éviter des conflits d'écriture. On attendra alors la fin de l'exécution responsable de ce statut pour lancer l'exécution suivante.

Fin de l'exécution de traitement

L'utilisateur peut consulter l'avancement de son exécution de traitement via l'appel GET /datastores/{id}/processings/executions/{id} ou même voir toutes les exécutions de traitement en cours avec GET /datastores/{id}/processings/executions?status='PROGRESS'.

Les transitions entre les différents statuts sont détaillées ici

Arrêt d'une exécution de traitement

Il est possible de demander l'arrêt d'une exécution en statut PROGRESSING via l'appel POST /datastores/{id}/processings/executions/{id}/abort (exécution anormalement longue, mauvaise donnée en entrée, mauvais paramétrage). Cela transmet à l'orchestrateur l'ordre d'interrompre le script en cours et passe l'exécution en statut ABORTED. Comme le script ne maîtrise pas l'arrêt (contrairement à une erreur rencontrée qui peut être gérée), la donnée en sortie devient UNSTABLE.

Consulter les exécutions de traitements au sein de l'entrepôt

L'API GET /datastore/{id}/processings/executions permet de récupérer l'ensemble des exécutions de traitements (avec pagination) dans l'entrepôt. Pour cibler plus précisément les exécutions voulues, plusieurs filtres, qui se cumulent, sont possibles :

• status=[statut d'exécution de traitement] : permet de préciser le statut voulu. Tous les statuts par défaut.
• processing=integer : identifiant du traitement dont on veut les exécutions.
• after=date : permet de préciser une date limite minimale de lancement des exécutions voulues.
• before=date : permet de préciser une date limite maximale de lancement des exécutions voulues.