Contextes, variables et routines dans Talend : ne rien coder en dur

Un groupe de contextes, une valeur par environnement

Une variable de contexte est un paramètre du job, lu à l’exécution sous la forme context.nom. On peut la créer dans le job lui-même (Built-In) ou dans un groupe de contextes du référentiel. Dale Anderson recommande nettement la seconde option : le groupe se réutilise dans tous les jobs, et même dans d’autres projets s’il est placé dans un projet de référence.

Dans ce groupe, on crée un contexte par environnement : DEV, TEST, PROD, et au besoin bac à sable et recette. Chacun porte ses propres valeurs pour les mêmes variables. L’auteur conseille de supprimer le contexte « Default » créé par Studio et de faire de DEV le contexte par défaut : on évite ainsi qu’un job lancé sans précaution vise la production.

Le job lit context.db_host ; l’environnement choisi, ou un fichier chargé au démarrage, en fournit la valeur.

Une astuce de l’auteur : ajouter une variable SysENVTYPE qui contient le nom de l’environnement. Le job peut alors adapter son comportement par une simple condition, par exemple n’envoyer d’alerte qu’en production :

if ("PROD".equals(context.SysENVTYPE)) {
    // envoyer l'alerte
}

Charger les contextes au démarrage

Les valeurs d’un groupe de contextes sont embarquées dans le job au moment du build. Pour les gérer en dehors du job, dans un fichier ou une table, Talend propose deux moyens.

Le composant tContextLoad lit des paires clé-valeur et remplace les valeurs des variables du job. Placé dans un tPreJob, il initialise le job avant tout traitement. Son option Die on error arrête le job si une variable attendue manque, ce qui évite de travailler avec une configuration incomplète. Le composant inverse, tContextDump, écrit les valeurs courantes dans un fichier ou une table.

Le chargement implicite fait la même chose sans composant. Il se règle dans Project Settings › Job Settings › Implicit Context Load : on choisit un fichier ou une table, le séparateur, et le niveau de message (avertissement, erreur ou info) quand une variable est chargée sans exister dans le contexte, ou l’inverse. On peut l’appliquer à tous les nouveaux jobs, ou le cocher job par job.

Cette séparation a aussi un intérêt de sécurité : les identifiants de production restent dans un fichier ou une table protégés, pas dans le job.

globalMap : passer une valeur d’un sous-job à l’autre

Les contextes portent la configuration. Pour une valeur calculée pendant l’exécution, on utilise globalMap, une table clé-valeur partagée par tout le job.

Le composant tSetGlobalVar y range une valeur ; on la relit plus loin avec globalMap.get("clé"), converti dans le bon type. L’exemple de Dale Anderson est un chargement incrémental. Un premier sous-job lit la date de la dernière mise à jour (MAX(date)) et la range dans globalMap. Un second sous-job l’utilise dans la clause WHERE de sa requête pour ne lire que les nouveautés.

Le premier sous-job range la date ; le second la relit dans sa requête.

La requête du second tDBInput s’écrit ainsi. La date est remise au format attendu par la base avec TalendDate.formatDate(), car globalMap.get() renvoie un objet Java :

"SELECT * FROM ventes WHERE updated_at > '"
    + TalendDate.formatDate("yyyy-MM-dd HH:mm:ss", (java.util.Date) globalMap.get("LAST_DATE"))
    + "'"

L’ordre compte : la valeur n’existe dans globalMap qu’une fois le premier sous-job terminé. D’où le lien OnSubjobOk entre les deux.

Les variables système des composants

Studio range aussi dans globalMap des variables système, alimentées par les composants eux-mêmes et disponibles dès que le composant a terminé. Le nom se compose du nom unique du composant et de la variable :

• NB_LINE, NB_LINE_OK, NB_LINE_REJECT : les lignes traitées, acceptées et rejetées ;
• NB_LINE_INSERTED, NB_LINE_UPDATED, NB_LINE_DELETED : les lignes écrites par un composant de sortie ;
• ERROR_MESSAGE, DIE_MESSAGE, WARN_MESSAGE : le dernier message d’erreur ;
• CHILD_RETURN_CODE, DIE_CODE, WARN_CODE : les codes retour.

Integer lignes = (Integer) globalMap.get("tDBOutput_1_NB_LINE_INSERTED");

L’onglet Outline de Studio liste les variables disponibles pour chaque composant du job : c’est le moyen le plus sûr d’en trouver le nom exact.

Les routines : du Java réutilisable

Quand aucun composant ne fait l’affaire, on peut écrire du Java dans un tJava ou un tJavaRow. Si le même code revient dans plusieurs jobs, mieux vaut en faire une routine : une classe Java du référentiel, dont les méthodes s’appellent partout, dans un tMap, un tJava ou une expression.

Talend fournit des routines système que tout le monde utilise sans y penser, comme TalendDate.getCurrentDate(), Numeric.sequence("s1", 1, 1) ou Relational.ISNULL(valeur). Les routines utilisateur se créent sous Code › Routines. Une routine générique, bien nommée et commentée, est l’un des meilleurs investissements d’un projet. Dale Anderson rappelle que le commentaire de chaque méthode apparaît comme aide quand on la sélectionne dans l’éditeur d’expressions : il mérite d’être soigné.

package routines;

public class rt_dates {
    /**
     * Premier jour du mois de la date donnée.
     * {talendTypes} Date
     * {Category} rt_dates
     * {example} premierJourDuMois(new java.util.Date())
     */
    public static java.util.Date premierJourDuMois(java.util.Date d) {
        if (d == null) return null;
        java.util.Calendar c = java.util.Calendar.getInstance();
        c.setTime(d);
        c.set(java.util.Calendar.DAY_OF_MONTH, 1);
        return c.getTime();
    }
}

Ce qui a changé depuis 2016

• Le chargement implicite des contextes se règle toujours dans les paramètres du projet. Avec un Remote Engine, le fichier de contexte doit être présent sur le serveur du moteur.
• Studio 8 distingue les routines globales, partagées par tout le projet, des jars de routines personnalisés (Custom Routine Jars). Ceux-ci regroupent des routines et leurs dépendances, et chaque job déclare ceux qu’il utilise. Les dépendances sont plus explicites et les conflits de bibliothèques plus rares.

À retenir

• Rien en dur. Serveurs, chemins et identifiants passent par des contextes.
• Des groupes de contextes partagés. Un contexte par environnement, DEV par défaut, plus de « Default ».
• Une variable d’environnement. SysENVTYPE permet d’adapter le job à l’exécution.
• Des valeurs externes. tContextLoad ou le chargement implicite lisent fichier ou table au démarrage.
• globalMap pour le calculé. tSetGlobalVar range, globalMap.get relit après un OnSubjobOk.
• Des routines commentées. Le commentaire devient l’aide de l’éditeur d’expressions.

Essayer dans Talend Studio

Pour voir un contexte remplacé au démarrage :

1. Dans le référentiel, créez un groupe de contextes ctx_demo avec une variable message de type String, et deux contextes : DEV (« Bonjour DEV ») et PROD (« Bonjour PROD »).
2. Créez un job, onglet Contexts, et importez le groupe ctx_demo.
3. Ajoutez un tJava : System.out.println(context.message);. Exécutez avec DEV, puis avec PROD.
4. Créez un fichier contexte.txt contenant la ligne message;Bonjour fichier.
5. Ajoutez un tPreJob relié à un tFileInputDelimited (séparateur ;, schéma key, value), lui-même relié à un tContextLoad. Exécutez : le tJava affiche désormais « Bonjour fichier ».

Sources

• Dale Anderson, Talend Job Design Patterns and Best Practices, partie 2, partie 3 et partie 4, Talend (version archivée).
• Aide Qlik Talend : Context settings, Job Settings, Managing user routines et Creating custom routine jars.

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.