Erreurs et exécution conditionnelle
S’APPLIQUE À : 
Azure Data Factory Azure Synapse Analytics
Conseil
Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !
Chemins conditionnels
Une orchestration Azure Data Factory et Synapse autorise une logique conditionnelle et permet à l’utilisateur d’emprunter différents chemins en fonction des résultats d’une activité précédente. L’utilisation de différents chemins permet aux utilisateurs de créer des pipelines robustes et d’incorporer la gestion des erreurs dans la logique ETL/ELT. Au total, nous autorisons quatre chemins conditionnels :
| Nom | Explication |
|---|---|
| En cas de réussite | (Pass par défaut) Exécutez ce chemin si l’activité actuelle a réussi |
| En cas d’échec | Exécutez ce chemin si l’activité actuelle a échoué |
| Une fois l’opération terminée | Exécutez ce chemin d’accès une fois l’activité en cours terminée, qu’elle ait réussi ou non |
| En cas d’omission | Exécutez ce chemin si l’activité elle-même n’a pas été exécutée |
Vous pouvez ajouter plusieurs branches à la suite d’une activité, à une exception près : le chemin Une fois l’opération terminée ne peut pas coexister avec le chemin En cas de réussite ou En cas d’échec. Pour chaque exécution de pipeline, au maximum un chemin est activé, en fonction du résultat d’exécution de l’activité.
Gestion des erreurs
Mécanisme de gestion des erreurs courantes
Bloc Try-Catch
Dans cette approche, le client définit la logique métier et spécifie uniquement le chemin En cas d’échec pour intercepter toute erreur de l’activité précédente. Cette approche entraîne la réussite du pipeline si le chemin En cas d’échec réussit.
Bloc Do-If-Else
Dans cette approche, le client définit la logique métier et spécifie les chemins En cas d’échec et En cas de réussite. Cette approche entraîne l’échec du pipeline même si le chemin En cas d’échec réussit.
Bloc Do-If-Skip-Else
Dans cette approche, le client définit la logique métier et spécifie les chemins En cas d’échec et En cas de réussite, avec une activité En cas d’omission factice jointe. Cette approche entraîne la réussite du pipeline si le chemin En cas d’échec réussit.
Tableau récapitulatif
| Approche | Définit | Quand l’activité réussit, le pipeline global indique | Quand l’activité échoue, le pipeline global indique |
|---|---|---|---|
| Try-Catch | Chemin En cas d’échec uniquement | Opération réussie | Opération réussie |
| Do-If-Else | Chemin En cas d’échec + chemin En cas de réussite | Succès | Échec |
| Do-If-Skip-Else | Chemin En cas d’échec + chemin En cas de réussite (avec une activité En cas d’omission factice à la fin) | Opération réussie | Opération réussie |
Comment l’échec de pipeline est déterminé
Différents mécanismes de gestion des erreurs conduisent à un état différent pour le pipeline : si certains pipelines échouent, d’autres réussissent. Nous déterminons la réussite et l’échec des pipelines comme ceci :
- Évaluation du résultat de toutes les activités au niveau feuille. Si une activité au niveau feuille a été ignorée, nous évaluons son activité parente à la place.
- Le résultat du pipeline est réussi si et seulement si tous les nœuds évalués réussissent.
En supposant que l’activité En cas d’échec et l’activité En cas d’échec factice réussissent :
Dans l’approche Try-Catch,
- Quand l’activité précédente réussit : le nœud En cas d’échec est ignoré et son nœud parent réussit ; le pipeline global réussit
- Quand l’activité précédente échoue : le nœud En cas d’échec est activé ; le pipeline global réussit
Dans l’approche Do-If-Else,
- Quand l’activité précédente réussit : le nœud En cas de réussite réussit et le nœud En cas d’échec est ignoré (et son nœud parent réussit) ; le pipeline global réussit
- Quand l’activité précédente échoue : le nœud En cas de réussite est ignoré et son nœud parent échoue ; le pipeline global échoue
Dans l’approche Do-If-Skip-Else,
- Quand l’activité précédente réussit : le nœud En cas d’omission factice est ignoré et son nœud parent En cas de réussite réussit ; l’activité de l’autre nœud, En cas d’échec, est ignorée et son nœud parent réussit ; le pipeline global réussit
- Quand l’activité précédente échoue : le nœud En cas d’échec réussit et En cas d’omission factice réussit ; le pipeline global réussit
Exécution conditionnelle
À mesure que nous développons des pipelines plus complexes et résilients, il est parfois nécessaire d’introduire des exécutions conditionnelles dans notre logique : exécuter une certaine activité que si certaines conditions sont remplies. Les cas d’usage sont nombreux, par exemple :
- exécuter une activité de suivi, comme l’envoi d’une notification par e-mail, si les travaux de copie précédents ont réussi
- exécuter une tâche de gestion des erreurs si l’une des activités précédentes a échoué
- passer à l’étape suivante si l’activité elle-même ou son activité de gestion des erreurs correspondante a réussi
- , etc.
Nous expliquons ici certaines logiques courantes et comment les implémenter dans ADF.
Activité unique
Voici quelques modèles courants qui suivent une seule activité. Nous pouvons utiliser ces modèles comme blocs de construction pour mettre au point des flux de travail complexes.
Gestion des erreurs
Le modèle est la logique de condition la plus courante dans ADF. Une activité de gestion des erreurs est définie pour le chemin d’accès « En cas d’échec » et sera appelée en cas d’échec de l’activité principale. Elle doit être incorporée en tant que meilleure pratique pour toutes les étapes stratégiques qui nécessitent des alternatives de secours ou une journalisation.
Étapes de l’effort optimal
Certaines étapes, telles que la journalisation des informations, sont moins critiques et leurs échecs ne devraient pas bloquer l’ensemble du pipeline. Dans ce cas, nous devons adopter les stratégies d’effort optimal en ajoutant les étapes suivantes au chemin « Une fois l’opération terminée » pour débloquer le flux de travail.
and
Les scénarios prioritaires les plus courants sont le « and » conditionnel : continuer le pipeline si et seulement si les activités précédentes réussissent. Par exemple, vous pouvez avoir plusieurs activités de copie qui doivent d’abord réussir avant de passer à l’étape suivante du traitement des données. Dans ADF, le comportement peut être facilement obtenu : déclarer plusieurs dépendances pour l’étape suivante. Graphiquement, cela représente plusieurs lignes qui pointent vers l’activité suivante. Vous pouvez choisir le chemin « En cas de réussite » pour vous assurer que la dépendance a réussi, ou le chemin « Une fois l’opération terminée » pour permettre une exécution optimale.
Ici, l’activité d’attente de suivi ne s’exécute que lorsque les deux activités web ont réussi.
Et ici, l’activité d’attente de suivi s’exécute quand ActivitySucceeded réussit et qu’ActivityFailed a été exécuté. Notez qu’avec le chemin d’accès « En cas de réussite », ActivitySucceed doit réussir, tandis que sur le chemin « Une fois l’opération terminée » ActivityFailed s’exécute dans un effort optimal, c’est-à-dire qu’il peut échouer.
ou
Les deuxièmes scénarios courants sont le « or » conditionnel : exécuter une activité si l’une des dépendances réussit ou échoue. Ici, nous devons utiliser les chemins d’accès « Une fois l’opération terminée » activité if Condition et langage d’expression.
Avant d’approfondir le code, il faut comprendre autre chose. Une fois qu’une activité a été exécutée et terminée, vous pouvez référencer son état avec @activity('ActivityName').Status. Ce peut être « Succès » ou « Échec ». Nous utilisons cette propriété pour générer une logique « or » conditionnelle.
Étape de journalisation de gestion des erreurs partagées
Dans certains cas, vous pouvez appeler une étape de gestion ou de journalisation des erreurs partagées si l’une des activités précédentes a échoué. Vous pouvez créer votre pipeline ainsi :
- exécutez plusieurs activités en parallèle
- ajoutez une condition « if » pour contenir les étapes de gestion des erreurs, dans la branche « True »
- connectez des activités à l’activité de condition à l’aide du chemin « Une fois l’opération terminée »
- expression logique pour les lectures d’activité de condition
@or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded').Status, 'Failed'))
- Remarque : vous aurez besoin du « or » concaténé si vous avez plus de deux activités de dépendance, par exemple,
@or(or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded1').Status, 'Failed')),equals(activity('ActivitySucceeded1').Status, 'Failed'))
Feu vert si une activité a réussi
Lorsque toutes vos activités sont des efforts optimaux, vous pouvez passer à l’étape suivante si l’une des activités précédentes a réussi. Vous pouvez créer votre pipeline ainsi :
- exécutez plusieurs activités en parallèle
- ajoutez une condition « if » pour contenir les étapes suivantes, dans la branche « True »
- connectez des activités à l’activité de condition à l’aide du chemin « Une fois l’opération terminée »
- expression logique pour les lectures d’activité de condition
@or(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
- Remarque : Le graphique ressemble exactement au scénario précédent. La seule différence est le langage d’expression utilisé
Scénarios complexes
Toutes les activités doivent réussir pour continuer
Le modèle est une combinaison de deux choses : conditionnelle et + gestion des erreurs. Le pipeline passe aux étapes suivantes si toutes les activités en cours réussissent, sinon il exécute une étape de journalisation des erreurs partagée. Vous pouvez créer le pipeline ainsi :
- exécutez plusieurs activités en parallèle
- ajoutez une condition « if ». Ajoutez les étapes suivantes dans la branche « True » et ajoutez du code de gestion des erreurs dans la branche « False »
- connectez des activités à l’activité de condition à l’aide du chemin « Une fois l’opération terminée »
- expression logique pour les lectures d’activité de condition
@and(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
Modèles courants
Try-Catch-Proceed
Le modèle équivaut à essayer d’intercepter du bloc dans le codage. Il est possible qu’une activité échoue dans un pipeline. En cas d’échec, le client doit exécuter un travail de gestion des erreurs pour le traiter. Toutefois, l’échec d’activité unique ne doit pas bloquer les activités suivantes dans le pipeline. Par exemple, j’essaie d’exécuter un travail de copie, en déplaçant des fichiers dans le stockage. Toutefois, l’opération peut échouer à mi-parcours. Dans ce cas, je souhaite supprimer les fichiers partiellement copiés et non fiables du compte de stockage (mon étape de gestion des erreurs). Mais je suis d’accord pour poursuivre d’autres activités par la suite.
Pour configurer le modèle :
- Ajoutez la première activité
- Ajoutez la gestion des erreurs au chemin UponFailure
- Ajoutez une deuxième activité, mais ne vous connectez pas à la première activité
- Connectez les chemins UponFailure et UponSkip de l’activité de gestion des erreurs à la deuxième activité
Remarque
Chaque chemin (UponSuccess, UponFailure et UponSkip) peut pointer vers n’importe quelle activité. Plusieurs chemins d’accès peuvent diriger vers la même activité. Par exemple, UponSuccess et UponSkip peuvent pointer vers une activité, alors qu’UponFailure pointe vers une autre.
Le travail de gestion des erreurs s’exécute uniquement en cas d’échec de la première activité. L’activité suivante s’exécute, que la première activité réussisse ou non.
Gestion des erreurs génériques
En règle générale, plusieurs activités s’exécutent séquentiellement dans le pipeline. En cas d’échec, je dois exécuter un travail de gestion des erreurs pour effacer l’état et/ou journaliser l’erreur. Par exemple, j’ai des activités de copie séquentielles dans le pipeline. Si l’une de ces opérations échoue, je dois exécuter un travail de script pour journaliser l’échec du pipeline.
Pour configurer le modèle :
- Générer un pipeline de traitement des données séquentiel
- Ajouter une étape de gestion des erreurs générique à la fin du pipeline
- Connectez des chemins UponFailure et UponSkip de l’activité de gestion des erreurs à la dernière activité
La dernière étape, Gestion des erreurs génériques, s’exécute uniquement en cas d’échec de l’une des activités précédentes. Elle ne s’exécutera pas si elles réussissent toutes.
Vous pouvez ajouter plusieurs activités pour la gestion des erreurs.
