Azure Data Factory est à la fois un ordonnanceur de traitements, un ETL ou un ELT selon la manière dont on pense les transformations et le chargement dans la destination (« sink » dans le vocable d’ADF). Il est muni d’une fenêtre de monitoring permettant de superviser l’exécution de pipelines au travers de triggers (déclencheurs en bon français). Et il ne sera pas rare (le plus rare possible, on vous le souhaite !) de rencontrer les icônes rouges de l’échec du traitement dans cette fenêtre.

Dans cet article, nous allons explorer différentes méthodes de déclenchement ou relance d’un pipeline Azure Data Factory.

Relancer manuellement

Depuis le monitoring des pipelines, nous disposons de plusieurs boutons comme le bouton « rerun » au niveau de l’exécution globale du trigger.

Lorsqu’il existe une ou plusieurs activités dans le pipeline, il suffit d’aller sur le détail de l’exécution du pipeline pour choisir une des activités (cliquer dessus) et la relancer (« rerun from failed activity »). Ce second mode est particulièrement intéressant lorsqu’une chaîne de traitement a déjà réalisé des étapes importantes et ne nécessite pas d’être reprise depuis le début. Les gains de temps de traitement seront sans doute conséquents.

Ces deux stratégies sont bien sûr manuelles et nécessitent de venir observer la console de supervision. Nous allons maintenant explorer des stratégies plus automatisées.

Démarrage ou relance automatique

Une approche classique de déclenchement des pipelines consiste à définir un jour et une heure de déclenchement. S’il existe des dépendances aux activités, on prendra soin d’inclure différentes activités au sein du même pipeline et de les relier grâce aux différentes sorties disponibles (« add activity on »).

Il existe quatre types de conditions :

• Success
• Failure
• Completion : exécution de l’activité suivante en cas de succès ou d’échec de l’activité
• Skipped : exécution de l’activité suivante uniquement si l’activité n’a pas été exécutée

Ce blog vous permettra de rentrer plus en détails dans le fonctionnement de ces conditions.

Mais certains événements comme la présence d’un fichier, de lignes dans une table ou encore la réponse à une requête HTTP peuvent être des conditions de déclenchement attendues.

Par le paramétrage d’une activité

La manière sans doute la plus simple et basique de relancer une activité consiste à utilise le paramétrage de l’activité elle-même. Pour cela, dans la section General du module :

• Renseigner un nombre maximum de Retry
• Renseigner un intervalle en secondes entre chaque essai

Remarque : le time out par défaut est à 7 jours, il peut être diminuer.

Il faut toutefois anticiper ici un nombre maximum fini de relances, ce que l’on n’est pas forcément en capacité d’anticiper.

A la première exécution avec succès, les retry ne sont bien sûr plus pris en compte.

Les activités de type for each ou execute pipeline ne disposent pas de ce paramétrage.

Avec le composant Until

La documentation du composant Until est disponible sur ce lien et définit son fonctionnement de la sorte :

The Until activity provides the same functionality that a do-until looping structure provides in programming languages. It executes a set of activities in a loop until the condition associated with the activity evaluates to true. You can specify a timeout value for the until activity in Data Factory.

Nous allons créer ainsi le scénario suivant : sur présence d’un fichier testé par le composant Until, nous déclenchons une activité de copie.

Une variable nommée FileExists, de type chaîne de texte (string), est définie au niveau du pipeline.

A l’intérieur du composant Until, nous allons travailler avec deux activités que sont Get Medatada et Wait.

L’activité Get Metadata permet d’obtenir des informations sur un dataset préalablement défini, comme un checksum de type MD5, le nom, le type ou l’existence d’un item.

Le composant suivant Set variable n’est pas indispensable mais il nous permet d’illustrer ici la manière de conserver dans une variable une partie de l’information obtenue par l’activité Get Metadata.

La valeur de la variable est définie de la sorte :

@string(activity('Get Metadata from Source').output.exists)

On utilisera la fenêtre d’ajout de contenu dynamique pour obtenir directement certaines parties de cette expression.

Enfin, une activité Wait est déclenchée pour laisser un laps de temps s’écouler avant de tester à nouveau la présence du fichier.

Le composant If exists permet de ne pas jouer l’activité Wait lorsque le fichier attendu est détecté. Il n’est pas nécessaire de définir la partie True de ce composant.

L’activité Until peut enfin paramétrée à l’aide de l’expression suivante :

@equals(variables(‘FileExists’),’True’)

Voici enfin une démonstration du fonctionnement complet de ce pipeline.