Trace 3 - Nouveau flux d'export avec jobs
Architecture de jobs pour lancer un export sans bloquer le navigateur.
Conception d'une architecture d'export robuste
Compréhension des besoins métier et utilisateurs
Trace 3
Passage à un export asynchrone avec jobs
Trace 3 - Nouveau flux : création du job, envoi des données, génération serveur, historique et téléchargement.
La Trace 3 ci-contre est un diagramme du nouveau flux d'export Cockpit. Elle représente le passage d'un export direct, où l'utilisateur attend le fichier, vers un export asynchrone basé sur un job. Dans la Trace 3, l'export cesse d'être une simple requête HTTP longue et devient un traitement suivi dans le temps. C'est ici que j'ai travaillé le savoir-faire concevoir un traitement long comme une tâche suivie.
Les différentes zones du diagramme représentent les responsabilités du frontend et de l'API. Le frontend déclenche l'export, envoie les données et interroge l'état du job. Le backend conserve l'identifiant, le statut, la progression, le lien de fichier et les informations nécessaires à l'historique utilisateur. Cette séparation rend le système plus robuste, car une génération longue n'oblige plus l'utilisateur à rester bloqué sur une action unique. Le choix du job sert donc aussi à adapter l'architecture à l'expérience utilisateur, pas seulement à organiser le backend.
- Le frontend crée un job dans l'API PHP et reçoit un identifiant.
- Le backend stocke le statut, la progression, la taille, le lien de fichier et les informations d'historique.
- L'utilisateur peut retrouver le fichier plus tard dans le menu d'export, au lieu de rester bloqué sur la page.
Fonctionnement simplifié
- L'utilisateur lance une recherche Cockpit avec ses filtres.
- Le frontend transforme les résultats en feuilles et lignes d'export.
- L'API PHP crée un job dans MySQL.
- Le frontend envoie les données par batches.
- L'API PHP génère le fichier puis l'enregistre sur le stockage.
- Le frontend poll le statut et affiche la progression.
- L'utilisateur télécharge le fichier depuis l'historique.
La première étape pour obtenir ce fonctionnement a été de raisonner sur le cycle de vie d'un export. Il ne suffisait pas de créer un fichier : il fallait définir ce qui se passe avant, pendant et après la génération. Cela comprend la création du job, la réception des données, la progression affichée, la gestion d'une erreur possible et la disponibilité du fichier dans l'historique. Dans la Trace 3, en rendant l'export observable, le système devient plus compréhensible pour l'utilisateur et plus simple à diagnostiquer pour l'équipe de développement.