Skip to main content

Ingestion d'API planifiée avec alertes

Ce que vous allez construire​

Un pipeline d'ingestion qui appelle une API REST, aplatit le JSON reçu, parse les dates et archive le résultat en fichier, orchestré par un workflow qui l'exécute chaque jour à 6 h et envoie une alerte email en cas d'échec. Vous déploierez le tout sur un environnement, y configurerez le déclencheur cron, puis testerez avec Lancer maintenant.

Prérequis
  • Un projet et sa copie de travail dans le Studio (voir le tutoriel Du CSV à PostgreSQL, Étape 1) ;
  • Un runner connecté et un environnement créé dans le projet (par exemple dev, avec le runner comme cible d'exécution ; voir Environnements et déploiement) ;
  • Trois connexions dans le projet : une REST API (l'API à ingérer), une storage (destination des fichiers) et une SMTP (envoi des alertes) ; voir Créer une connexion.

Étape 1 : le pipeline d'ingestion​

Dans votre copie de travail, onglet Pipelines, créez un pipeline « Ingestion commandes » et enchaînez quatre bricks :

#BrickConfiguration
1REST APIMode autonome (aucune entrée connectée) : votre connexion REST API, endpoint: /orders, pagination selon l'API (page, offset…), data_path vers le tableau de résultats (ex. $.data).
2JSONUne opération flatten sur la colonne contenant l'objet imbriqué (ex. customer) : les champs deviennent des colonnes customer.nom, customer.ville…
3DatesUne opération parse sur la colonne created_at, avec son format explicite (ex. %Y-%m-%dT%H:%M:%S).
4Écriture fichierVotre connexion storage, format Parquet, nom de fichier commandes.

Exécutez une fois en Studio pour valider le pipeline (bouton d'exécution de l'éditeur) avant de passer à l'orchestration.

Étape 2 : le workflow d'orchestration​

Ouvrez l'onglet Workflows et créez un workflow « Ingestion quotidienne ». L'éditeur est le même canvas que pour les pipelines, avec les bricks d'orchestration (voir Orchestrer des pipelines).

L'éditeur de workflow Un enchaînement type : déclencheur, sous-pipeline, gestion d'erreur, notification.

Construisez le graphe suivant :

  1. Déclencheur : le point d'entrée du workflow (étape 3 ci-dessous) ;
  2. Exécuter un pipeline : sélectionnez « Ingestion commandes ». La brick expose deux sorties : Success et Fail ;
  3. Gestion d'erreur : reliez la sortie Success du sous-pipeline à son entrée. Si tout va bien, le signal sort par OK ; en cas d'échec amont, la brick bascule sur Sur erreur au lieu d'interrompre le workflow (paramètre Erreurs capturées : all) ;
  4. Alerte : reliez-la à la sortie Sur erreur, avec le canal email, votre connexion SMTP, destinataires, un sujet explicite (ex. « Echec ingestion commandes »), niveau error.

Étape 3 : déclarer le déclencheur chaque_jour_6h​

Sélectionnez la brick Déclencheur : son panneau liste les déclencheurs déclarés du workflow. Cliquez sur Ajouter un déclencheur, nommez-le chaque_jour_6h et choisissez le type Cron.

Aucune valeur de planification ici

La brick ne contient ni cron, ni fuseau, ni cible d'exécution : elle déclare seulement le déclencheur (nom, type, clé stable). Son fonctionnement se règle par environnement : c'est ce qui permettra de planifier dev et prod différemment avec le même workflow (voir Configurer les déclencheurs).

Étape 4 : commit, push et déploiement​

Le workflow doit être déployé sur un environnement pour être planifié :

  1. Commit : onglet Versions de la copie de travail ; stagez le pipeline et le workflow, choisissez l'intention semver, écrivez un message (« Ingestion commandes + orchestration ») puis Commit ;
  2. Push : la barre de branche propose Ouvrir une PR. Le push crée une release de vos commits et ouvre une pull request vers le projet société. Faites-la merger (ou mergez-la directement si le projet n'exige pas de revue) ;
  3. Déployer : sur le projet société, onglet Environnements, cliquez sur Déployer sur la carte de l'environnement dev et choisissez la release. Le déploiement pose un pointeur vers la release : aucune copie de contenu.

Étape 5 : configurer le cron sur l'environnement​

Toujours dans l'onglet Environnements, ouvrez dev puis son sous-onglet Workflows : la section Déclencheurs liste, groupés par workflow, tous les déclencheurs déclarés, dont votre chaque_jour_6h, avec sa configuration propre à cet environnement.

Les déclencheurs d'un environnement Chaque carte croise un déclencheur déclaré avec sa configuration dans l'environnement : activation, planning, options communes.

Sur la carte de chaque_jour_6h :

  1. activez l'interrupteur Activé (un déclencheur non configuré est désactivé par défaut) ;
  2. saisissez l'expression cron 0 6 * * * : l'aperçu Prochaine exécution se met à jour dès que l'expression est valide ;
  3. choisissez le fuseau horaire (Europe/Paris) ;
  4. cliquez sur Enregistrer.

Ces réglages s'appliquent directement à l'environnement, sans redéploiement : ils ne font pas partie du contenu de la release.

Étape 6 : tester avec « Lancer maintenant »​

Inutile d'attendre 6 h du matin : la carte du déclencheur propose Lancer maintenant, qui exécute immédiatement la version déployée du workflow sur le runner de l'environnement, avec ses valeurs de variables et de connexions.

Lancer un workflow sur l'environnement « Lancer maintenant » n'est possible que si l'environnement a un déploiement actif rattaché à un runner.

Pour vérifier la branche d'alerte, provoquez un échec (par exemple un endpoint invalide dans une copie de travail, re-commitée et redéployée) et relancez : l'email d'alerte doit arriver, préfixé du niveau error.

Étape 7 : lire les logs​

Ouvrez Monitoring : le run du workflow apparaît dans la liste, ainsi que celui du sous-pipeline. Cliquez pour ouvrir le détail.

Le détail d'une exécution Les logs en direct, filtrables par niveau, avec le déroulé des étapes dans le panneau latéral.

  • l'onglet Logs filtre par niveau (ALL, INFO, WARN, ERROR) et cherche en texte libre : repérez l'appel API, la pagination, l'écriture du fichier ;
  • la carte Contexte montre les connexions et variables résolues au moment du run, le bon réflexe quand dev et prod se comportent différemment ;
  • en cas d'échec, la carte Erreur remonte le premier message et la brick fautive, avec un raccourci de relance.

Pour aller plus loin​