Pour chaque ligne
Traite les lignes une par une, plusieurs en parallèle. Chaque ligne est exécutée par la suite du flux dans un processus dédié.
| Entrées | in (Lignes) |
| Sorties | out (Données) |
| Paramètre | Défaut | Description |
|---|---|---|
max_parallel | 4 | Nombre de lignes traitées simultanément. |
max_rows | 0 | Garde-fou. 0 = pas de limite. |
stop_on_error | false | Arrêter à la première ligne en erreur. |
timeout_seconds | 600 | Durée maximale par ligne. 0 = sans limite. |
Le corps de boucle est une sous-pipeline
Poser la brick crée une sous-pipeline dédiée, liée à elle. C'est cette sous-pipeline qui est rejouée une fois par ligne, dans un processus dédié.
Elle s'écrit comme n'importe quel flux : elle commence par une source. La
ligne courante ne l'alimente pas en données, elle la paramètre —
${var.item.file_name} désigne le fichier à lire, ${var.item.id} la clé à
requêter.
Lister fichiers → Pour chaque ligne → (suite du flux principal)
┌─ Corps de Pour chaque ligne ──────────────┐
│ Source fichier ${var.item.file_name} │
│ ↓ │
│ Traitement │
└───────────────────────────────────────────┘
La sortie laisse passer les données
out porte les données reçues, complètes : ce qui suit la boucle continue
de travailler sur les mêmes lignes. Trois colonnes disent ce qu'est devenue
chacune :
| Colonne | Contenu |
|---|---|
loop_status | success, fail, ou skipped si la boucle s'est arrêtée avant. |
loop_duration | Durée du traitement de la ligne, en secondes. |
loop_error | Cause de l'échec, vide en cas de succès. |
Un Lignes en aval avec
loop_status == "fail" isole ce qui reste à reprendre.
Lire la ligne courante
La ligne arrive comme donnée sur le corps de boucle, et ses champs sont
aussi lisibles dans n'importe quel paramètre de brick via
${var.item.COLONNE} — pratique pour désigner un fichier à lire, une table, une
URL.
Voir les processus
Le bouton Processus, en bas à gauche du canvas, apparaît dès qu'un flux
contient une boucle. Il marque les bricks déportées d'un liseré et d'une
pastille de profondeur — P1, P2 — et affiche le nombre de processus au
maximum.
Les boucles imbriquées se multiplient : une boucle à 4 contenant une boucle à 3 compte 12 processus. L'indicateur fait ce calcul.
Pourquoi un processus par ligne
Les bricks d'un flux sont des instances uniques. Les faire tourner en parallèle dans le même processus reviendrait à ce que deux itérations écrivent dans les mêmes objets. Un processus par ligne écarte le problème par construction, et le parallélisme est réel.
Le prix est un démarrage d'environ 0,2 seconde par ligne, et surtout une réouverture des connexions à chaque ligne. La boucle vaut donc pour du travail lourd — un appel OCR, un appel d'API, un traitement long — et non pour du calcul léger, où le coût par ligne dépasserait le gain.
Les bricks IA parallélisent déjà leurs appels sur les lignes qu'elles reçoivent. Dans une boucle parallèle, les deux se multiplient : quatre lignes simultanées et quatre appels par ligne font seize appels en vol.
Les bricks du corps de boucle restent inertes dans le processus principal : c'est normal, elles tournent ailleurs. Le moteur en est informé et ne les signale pas comme non exécutées.