Déclencheurs, erreurs et logs dans Talend : OnSubjobOk, tLogCatcher et Log4j2

Sous-job ou composant : deux familles de déclencheurs

Sur le canevas, deux sortes de liens relient les composants. Les liens de données (Row) transportent des lignes d’un composant à l’autre. Les déclencheurs (Trigger) ne transportent rien : ils fixent l’ordre d’exécution.

Un sous-job est un groupe de composants reliés par des liens de données. Studio l’entoure d’un cadre coloré, qu’on peut masquer depuis la barre d’outils. Les déclencheurs se distinguent par leur point de départ :

• OnSubjobOk et OnSubjobError attendent la fin du sous-job entier. Ils partent toujours du premier composant du sous-job ;
• OnComponentOk et OnComponentError partent d’un composant précis, dès que celui-ci a terminé ;
• Run If part lui aussi d’un composant, mais ne se déclenche que si une expression Java est vraie.

OnSubjobOk part du premier composant et attend tout le sous-job ; Run If part d’un composant précis et teste une condition.

L’expression d’un Run If lit souvent une variable système du composant, comme le nombre de lignes écrites :

((Integer)globalMap.get("tFileOutputDelimited_1_NB_LINE")) > 0

Ici, le mail ne part que si le fichier de sortie a reçu au moins une ligne. Nous détaillons ces variables dans l’article sur les contextes et les variables.

Une gestion d’erreurs commune à tous les jobs

Pour Dale Anderson, la gestion des erreurs est le terrain où une bonne pratique rapporte le plus, parce qu’elle se réutilise dans presque tous les jobs d’un projet. Son modèle repose sur deux éléments.

Le premier est un joblet de journalisation, inclus dans chaque job. Il contient un tLogCatcher, qui capte les exceptions Java ainsi que les messages de tWarn et tDie. Il les met en forme, puis les écrit dans une table ou un fichier. Ce joblet n’a ni entrée ni sortie : il veille en arrière-plan.

Le second est un jeu de codes retour défini une fois pour toutes. tDie et tWarn acceptent un code ; le job parent le lit après chaque tRunJob dans la variable CHILD_RETURN_CODE, et décide de la suite : continuer, relancer, alerter.

Le joblet capte, met en forme et journalise ; les codes retour disent au parent quoi faire.

La grille de codes de notre schéma n’est qu’un exemple. L’important est d’en avoir une, consignée dans le guide de développement, et que tous les jobs la respectent.

Log4j2 : un niveau de log par environnement

Studio intègre le framework de journalisation Apache Log4j, et tous les composants s’en servent. Dale Anderson conseillait de l’activer et d’adapter le niveau de détail à l’environnement :

• INFO en développement et en test, pour suivre le déroulement ;
• WARN en recette ;
• ERROR en production, pour ne garder que l’essentiel.

Les messages d’un niveau plus grave sont toujours inclus : un job réglé sur WARN journalise aussi les erreurs. Dans Talend Studio 8, Log4j se règle dans les paramètres du projet (Project Settings), rubrique Log4j. La configuration XML y est commune à tous les jobs, ce qui garantit des messages au même format.

Statistiques et logs d’exécution

Au-delà des messages, Studio peut collecter des données d’exécution grâce à trois composants :

• tStatCatcher enregistre le début, la fin, la durée et le statut de chaque job et composant ;
• tLogCatcher collecte les exceptions et les messages de tWarn et tDie ;
• tFlowMeterCatcher relève les volumes mesurés par les tFlowMeter.

Plutôt que de les poser dans chaque job, on peut les activer pour tout le projet dans Project Settings › Job Settings › Stats & Logs. Les données sont écrites dans la console, dans des fichiers ou dans une base. Stockées en base, elles se prêtent à des requêtes SQL, par exemple pour alerter quand un code retour dépasse un seuil.

Les points de reprise

Pour un job long en plusieurs étapes critiques, tout relancer après une erreur coûte cher. Studio permet de poser des points de reprise (recovery checkpoints) sur les déclencheurs OnSubjobOk et OnSubjobError. En cas d’échec, l’administrateur relance le job à partir du dernier point de reprise franchi, depuis la page Error Recovery Management de Talend Administration Center.

Cette fonction est liée à Talend Administration Center et ne se règle que dans un projet distant. Nous ne l’avons pas trouvée dans Talend Management Console. Sur Qlik Talend Cloud, nous conseillons plutôt de découper le traitement en jobs enfants qu’on peut relancer séparément.

Ce qui a changé depuis 2016

• Log4j est passé en version 2. Il est activé par défaut dans un nouveau projet ; un projet importé d’une version 7.2 ou antérieure reste en Log4j 1, déprécié, jusqu’à ce qu’on change de version dans les paramètres du projet.
• L’Activity Monitoring Console n’est plus une application web de Talend Administration Center depuis Talend 8.0. Elle subsiste comme module optionnel de Studio, et les données de Stats & Logs restent exploitables.
• Talend LogServer, le serveur de logs centralisé, est déprécié depuis Talend 8.0. Son retrait de Talend Administration Center était annoncé pour juin 2026 ; une pile ELK se met en place séparément.

À retenir

• Deux familles de déclencheurs. OnSubjob attend tout le sous-job, OnComponent un seul composant.
• OnSubjob part du premier composant. C’est lui qui représente le sous-job.
• Run If teste une condition Java. Souvent une variable système comme NB_LINE.
• Un joblet de log partout. tLogCatcher capte, un tDBOutput journalise.
• Des codes retour communs. Le parent les lit dans CHILD_RETURN_CODE et décide de la suite.
• Un niveau Log4j2 par environnement. INFO en test, WARN en recette, ERROR en production.

Essayer dans Talend Studio

Pour observer l’ordre d’exécution des déclencheurs :

1. Créez un job avec un tRowGenerator (cinq lignes) relié à un tLogRow : c’est le sous-job 1.
2. Ajoutez un tJava qui affiche System.out.println("Sous-job 2");, relié depuis le tRowGenerator par OnSubjobOk.
3. Ajoutez un second tJava qui affiche System.out.println("Après le tLogRow");, relié depuis le tLogRow par OnComponentOk.
4. Exécutez : le message du second tJava apparaît dès la fin du tLogRow, celui du premier à la fin du sous-job.
5. Remplacez le second lien par un Run If avec l’expression ((Integer)globalMap.get("tLogRow_1_NB_LINE")) > 3 : le message n’apparaît que si plus de trois lignes ont été affichées.

Sources

• Dale Anderson, Talend Job Design Patterns and Best Practices, partie 1 et partie 3, Talend (version archivée).
• Aide Qlik Talend : configurer Log4j, Stats & Logs, points de reprise sur les déclencheurs et éléments dépréciés et retirés de Talend 8.0.

Tout le mérite du contenu original revient à Dale Anderson ; l’adaptation à Talend Studio 8 et ses éventuelles erreurs sont de HeyData. Cet article fait partie de notre série sur les bonnes pratiques de conception de jobs Talend : découvrir la série.