Talend - Passage de variables entre jobs
Nous allons vous présenter quelques manières pour passer des valeurs / paramètres entre des jobs parents et enfants dans l'ETL Talend. nous utilisons ici Talend Open Studio en version communautaire.
1. Par variables de contexte
1.1 Mise en place du job parent
Nous avons ici un Job parent qui génère des lignes et qui va les passer à un job enfant pour traitement (enfin, affichage par un logger).
Nous commençons par créer notre job parent avec un générateur de lignes et un logger:
Le générateur contient un schema simple avec un id, un nom et une notation.
Nous pouvons éxecuter le job pour s'assurer que les lignes sont bien générées et nous obtenons:
Nous allons ensuite passer les lignes une à une à un job enfant. Pour cela, nous intercalons un tJavaRow définis comme suis
et nous envoyons l'output à un sous-job.
Avant de configurer la tâche RunJob, nous devons déjà créer le sous-job.
1.2 Mise en place du job enfant
Avant de créer le job enfant, nous allons sauvegarder le schema des données que nous transitons dans le job parent.
Pour cela, éditez par exemple le tLogRow du parent et ouvrez le built-in schema, puis sauvegardez le.
Celui-ci sera désormais dans les Generic Schemas dans vos Metadata.
Il faut créer un nouveau job et y ajouter un tFixedFlowInput et un logger.
Nous créeons également un Contexte qui reprend la même définition que le schema précédent (il serait sympa de pouvoir générer le schema à partir du Contexte)
et nous glissons le contexte créé dans le sous-job.
Dans la définition du fixedFlowInput, nous allons redonner le schema enregistré précedemment et fixer les valeurs à celles du contexte.
1.3 Liaison
Nous pouvons revenir au job parent et terminer de parametrer la tâche sous-job. Pour cela, dans les "Context Param", on ajoute ceux défini dans le sous-job et la valeur est celle transmise par le tJavaRow.
Vous pouvez ensuite tester le tout en faisant un Run du parent.
Vous obtenez dans le logger du parent la liste des lignes,
et pour chacune le job enfant affiche (heureusement) les mêmes lignes.
Cette méthode est simple à mettre en oeuvre seulement peut devenir pénible quand il y a trop de paramètres à passer.
2. Par inversion de descendance
L'idée de cette méthode est d'appliquer le traitement du parent dans l'enfant et de remonter les résultats par un tBufferOutput.
En reprenant notre exemple, le générateur est du coup déplacé dans le job enfant et les résultats sont envoyés dans un buffer output.
Le parent devient un appel, en premier, du job enfant et ensuite le traitement des données reçues (ici juste un logger).
Et quand on execute le job parent, on affiche bien les mêmes données dans l'enfant et dans le parent.
3. Par une seule variable de contexte
Un inconvénient de la première méthode est d'avoir une multitude de variables de contexte.
Une alternative est de ne passer qu'une seule variable de contexte de type Object qui contient une List avec l'ensemble des données.
Cependant, il faut tout de même placer les données dans la liste puis les extraire dans le job enfant.
Le parent est le même que dans le premier cas, seulement le code de la tâche tJavaRow devient:
// Les imports sont dans les Advanced Settings
import java.util.List;
import java.util.ArrayList;
// Put the params in an arrayList
List<String> params = new ArrayList<>();
params.add(input_row.id.toString());
params.add(input_row.name);
params.add(input_row.rating.toString());
// Set the data context to the params list
output_row.data = (Object)params;
et le schema devient:
Il n'y plus qu'un seul paramètre de passé au job enfant.
Concernant le Job enfant, celui-ci a toujours le tFixedFlowInput pour récupérer le context
et le passer à un tJavaRow qui est le miroir de celui du parent.
et evidemment, on obtient toujours le même résultat.
