Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La plupart des activités de pipeline dans Data Factory prennent en charge les essais automatisés. Lorsqu’une activité échoue à cause d’une erreur transitoire (une API limitée, une courte interruption de service ou une dépendance de claquements), vous pouvez la configurer pour qu’elle réessaie automatiquement un nombre déterminé de fois avant de marquer l’activité comme échouée.
Vous pouvez aussi contrôler combien de temps l’activité attend entre les tentatives, et définir le nombre de réessayages et attendre individuellement pour chaque activité, afin d’ajuster précisément le comportement des réessays dans votre flux de travail.
Configurez les paramètres de réévaluation dans une activité
Pour configurer le comportement de nouvelle tentative pour une activité :
Sélectionnez l’activité dans la zone de dessin du pipeline.
Dans l’onglet Général du volet propriétés, cochez la case Activer les nouvelles tentatives pour activer la fonctionnalité de nouvelle tentative.
Définissez le champ Nouvelle tentative sur le nombre de nouvelles tentatives. Entrez une valeur comprise entre 1 et 1 000. La valeur par défaut est 1.
Dans le type d’intervalle de tentative, sélectionnez Délai fixe ou croissant pour contrôler le calcul du temps d’attente entre les tentatives. Ensuite, définissez les champs d’intervalles pour le type choisi. Voir intervalles de répétition pour plus de détails.
Si vous le souhaitez, configurez les conditions de nouvelle tentative (préversion) pour contrôler le moment où les nouvelles tentatives se produisent en fonction de critères d’erreur spécifiques.
Intervalles de réessai
L’intervalle de réessai contrôle combien de temps une activité attend entre les tentatives. Utilisez Fixed pour des échecs courts et prévisibles. Utilisez Délai croissant pour des coupures plus longues. Il met en place un ralentissement exponentiel, où le temps d’attente augmente à chaque tentative, donnant progressivement aux services en amont plus de temps pour récupérer.
Le paramètre de type intervalle de tentative détermine l’approche à utiliser.
| Catégorie | Behavior |
|---|---|
| Corrigé (par défaut) | Il attend le même nombre de secondes entre chaque tentative. |
| Augmentation du retard | Utilise un retour exponentiel : chaque tentative attend un intervalle aléatoire à partir d’une plage qui croît de façon exponentielle, jusqu’à un maximum configurable. |
Résolution
Lorsque vous sélectionnez Corrigé, l’activité attend le même nombre de secondes entre chaque tentative de réessayage. Utilisez ce type lorsque les pannes sont brèves et prévisibles.
Réglez l’intervalle de réessai (seconde) au nombre de secondes d’attente. La valeur par défaut est 30 secondes.
Retard croissant
Lorsque vous sélectionnez Délai croissant, le temps d’attente augmente de façon exponentielle entre les tentatives, un schéma appelé reculement exponentiel. Ce schéma donne progressivement plus de temps de récupération aux services en amont, réduit la charge répétée sur les systèmes en difficulté, et permet aux pipelines de se régénérer d’eux-mêmes après des coupures plus longues sans intervention manuelle.
Le moteur de retentatives sélectionne un intervalle aléatoire dans une plage à croissance exponentielle avant chaque tentative :
| Réessayer | Portée minimale | Portée maximale |
|---|---|---|
| 1 | max(0, intervalle min) | min(intervalle, intervalle max) |
| 2 | max(intervalle, intervalle min) | min(2 × intervalle, intervalle maximal) |
| 3 | max(2 × intervalle, intervalle minimum) | min(4 × intervalle, intervalle maximal) |
| 4 | max( intervalle × 4, intervalle minimum) | min(8 × intervalle, intervalle maximal) |
| … | … | … |
La portée double à chaque tentative jusqu’à ce que la limite supérieure atteigne l’intervalle maximal de réessayage, après quoi toutes les tentatives restantes attendent ce maximum. La sélection aléatoire dans chaque plage réduit la probabilité que des tentatives concurrentes de pipeline entrent en collision sur le même système en amont au même moment.
Deux champs sont disponibles lorsque l’option Retard croissant est sélectionnée :
| Champ | Description | Default |
|---|---|---|
| Intervalle de réessai (sec) | L’intervalle de départ. Définit la base de la plage de recul. | 30 secondes |
| Intervalle maximal de tentative (sec) | La limite supérieure de l’intervalle d’attente. Les nouvelles tentatives ne dépassent jamais cette durée. | 3600 secondes |
Note
Les champs d’intervalles de réessai ne prennent pas en charge les expressions dynamiques. Les valeurs doivent être des entiers statiques.
Configurer les conditions de nouvelle tentative (version préliminaire)
Par défaut, une activité réessaye en cas d’échec. Utilisez des conditions de réessai pour spécifier quelles erreurs déclenchent une rétentative. Cette approche vous aide à éviter de gaspiller des tentatives sur des erreurs qui ne se résolvent pas, comme les échecs d’authentification.
Pour ajouter une condition de nouvelle tentative :
- Dans la section Conditions de nouvelle tentative (préversion), sélectionnez le + bouton pour ajouter une nouvelle ligne de condition.
- Choisissez un champ à évaluer :
- Message d’erreur : contenu texte du message d’erreur.
- Type de défaillance : La catégorie de défaillance, telle que l’erreur utilisateur ou l’erreur système.
- Code d’erreur : Le code d’erreur spécifique retourné, comme 429 pour la limitation de vitesse.
- Sélectionnez un opérateur pour définir le type de correspondance, comme Contains.
- Entrez une valeur à comparer.
- Utilisez la colonne And/Or pour combiner plusieurs conditions. Sélectionnez Et pour exiger que toutes les conditions soient remplies, ou Ou pour réessayer si au moins une condition est remplie.
Par exemple, pour réessayer uniquement sur les erreurs de limitation de débit, ajoutez une condition avec le champ défini sur Error code, l’opérateur défini sur Containset la valeur définie sur 429.
Important
L’intervalle entre les tentatives s’applique avant que la condition ne soit évaluée. Par exemple, si vous définissez un délai de nouvelle tentative d’une heure et que la condition de nouvelle tentative n’est pas satisfaite, le pipeline attend tout de même une heure complète avant de passer à l’activité suivante ou de mettre fin à son exécution.
Tip
Lorsque vous ne spécifiez pas de conditions de nouvelle tentative, l’activité est relancée après chaque échec. Ajoutez des conditions pour être plus sélectives sur les erreurs qui déclenchent des nouvelles tentatives.
Limitations connues des nouvelles tentatives
- Prise en charge des activités : les tentatives conditionnelles sont prises en charge pour des types d’activités spécifiques, notamment Copie de données, Notebook, Flux de données et les activités de procédure stockée.
- Propriétés d’erreur : les conditions de nouvelle tentative peuvent correspondre au code d’erreur, au message d’erreur et au type d’échec. Tous les champs d’erreur spécifiques au connecteur ne sont pas disponibles pour la correspondance.