Réessayer
S’APPLIQUE À : Tous les niveaux de Gestion des API
La stratégie retry
exécute ses stratégies enfants une fois, puis retente leur exécution jusqu’à ce que la condition
de la nouvelle tentative devienne false
ou que le count
de nouvelles tentatives soit épuisé.
Notes
Définissez les éléments enfants et de stratégie dans l’ordre fourni dans l’instruction de stratégie. En savoir plus sur comment définir ou modifier des stratégies du service Gestion des API.
Instruction de la stratégie
<retry
condition="Boolean expression or literal"
count="number of retry attempts"
interval="retry interval in seconds"
max-interval="maximum retry interval in seconds"
delta="retry interval delta in seconds"
first-fast-retry="boolean expression or literal">
<!-- One or more child policies. No restrictions. -->
</retry>
Attributs
Attribut | Description | Obligatoire | Default |
---|---|---|---|
condition | Propriété booléenne. Spécifie si les nouvelles tentatives doivent être arrêtées (false ) ou poursuivies (true ). Les expressions de stratégie sont autorisées. |
Oui | N/A |
count | Nombre positif compris entre 1 et 50 spécifiant le nombre de nouvelles tentatives à tenter. Les expressions de stratégie sont autorisées. | Oui | N/A |
interval | Nombre positif en secondes spécifiant le délai d’attente entre les tentatives. Les expressions de stratégie sont autorisées. | Oui | N/A |
max-interval | Nombre positif en secondes spécifiant le délai d’attente maximal entre les tentatives. Il est utilisé pour implémenter un algorithme de nouvelles tentatives exponentiel. Les expressions de stratégie sont autorisées. | Non | N/A |
delta | Nombre positif en secondes spécifiant l’incrément du délai d’attente. Il est utilisé pour implémenter les algorithmes de nouvelles tentatives linéaires et exponentiels. Les expressions de stratégie sont autorisées. | Non | N/A |
first-fast-retry | Propriété booléenne. S’il a la valeur true , la première des nouvelles tentatives est effectuée immédiatement. Les expressions de stratégie sont autorisées. |
Non | false |
Temps d’attente des nouvelles tentatives
Lorsque seul
interval
est spécifié, les nouvelles tentatives sont effectuées à intervallesinterval
.Lorsque seuls
interval
etdelta
sont spécifiés, un algorithme de relance par intervalle linéaire est utilisé. Le temps d’attente entre les nouvelles tentatives augmente selon la formule suivante :interval + (count - 1)*delta
Lorsque
interval
,max-interval
etdelta
sont spécifiés, un algorithme de nouvelle tentative par intervalle exponentiel est appliqué. Le temps d’attente entre les nouvelles tentatives augmente de façon exponentielle en fonction de la formule suivante :interval + (2^(count - 1)) * random(delta * 0.8, delta * 1.2)
, jusqu’à un intervalle maximal défini parmax-interval
.Par exemple, quand
interval
etdelta
sont tous les deux définis sur 10 secondes etmax-interval
est de 100 secondes, le temps d’attente approximatif entre les nouvelles tentatives augmente comme suit : 10 secondes, 20 secondes, 40 secondes, 80 secondes, avec 100 secondes d’attente utilisée pour les nouvelles tentatives restantes.
Éléments
La stratégie retry
peut contenir n’importe quelle autre stratégie sous forme d’élément enfant.
Utilisation
- Sections de la stratégie : inbound, outbound, backend, on-error
- Étendues de la stratégie : global, espace de travail, produit, API, opération
- Passerelles : classiques, v2, consommation, auto-hébergées, espace de travail
Exemples
Transfert de demande avec nouvelle tentative exponentielle
Dans l’exemple suivant, le transfert de la demande est retenté jusqu’à dix fois suivant un algorithme de nouvelles tentatives exponentiel. Étant donné que first-fast-retry
est false
, toutes les tentatives de nouvelle tentative sont soumises à une augmentation exponentielle des temps d’attente des nouvelles tentatives (dans cet exemple, environ 10 secondes, 20 secondes, 40 secondes, ...), jusqu’à une attente maximale de max-interval
.
<retry
condition="@(context.Response.StatusCode == 500)"
count="10"
interval="10"
max-interval="100"
delta="10"
first-fast-retry="false">
<forward-request buffer-request-body="true" />
</retry>
Envoyer la demande en cas d’échec de la demande initiale
Dans l’exemple suivant, l’envoi d’une requête à une URL autre que le back-end défini est retenté jusqu’à trois fois si la connexion expire/est supprimée ou si la requête entraîne une erreur côté serveur. first-fast-retry
ayant la valeur true, la première nouvelle tentative est exécutée immédiatement lors de l’échec de la requête initiale. Notez que send-request
doit affecter la valeur true à ignore-error
pour que response-variable-name
soit Null en cas d’erreur.
<retry
condition="@(context.Variables["response"] == null || ((IResponse)context.Variables["response"]).StatusCode >= 500)"
count="3"
interval="1"
first-fast-retry="true">
<send-request
mode="new"
response-variable-name="response"
timeout="3"
ignore-error="true">
<set-url>https://api.contoso.com/products/5</set-url>
<set-method>GET</set-method>
</send-request>
</retry>
Stratégies connexes
Contenu connexe
Pour plus d’informations sur l’utilisation des stratégies, consultez :
- Tutoriel : Transformer et protéger votre API
- Référence de stratégie pour obtenir la liste complète des instructions et des paramètres de stratégie
- Expressions de stratégie
- Définir ou modifier des stratégies
- Réutilisation de configurations de stratégie
- Référentiel d’extrait de stratégie
- Kit de ressources des stratégies Gestion des API Azure
- Créer des stratégies à l’aide de Microsoft Copilot dans Azure