---
sourceDocument: Gestion des opérations IT Xanadu
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/xanadu/it-operations-management

 Release :

    - xanadu

ft:locale :

    - fr-FR

ft:publication_title :

    - Gestion des opérations IT Xanadu

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Configurer les nouvelles tentatives de demandes dans le cloud

# Configurer les nouvelles tentatives de demandes dans le cloud {#ariaid-title1}

* Rversion finale: Xanadu
* 
* Mis à jour 1 août 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes de lecture

Si une demande est limitée par un fournisseur dans le cloud pendant la détection, la configuration des nouvelles tentatives de demande dans le cloud fournit une méthode personnalisable pour relancer les demandes. Modèles de détection et de mappage des services inclut une configuration de nouvelle tentative pour AWS et Azure. Vous pouvez personnaliser la configuration incluse ou créer la vôtre.
Les administrateurs Discovery et les administrateurs cloud peuvent accéder à la configuration des nouveaux essais de demande à l'adresse suivante : ToutDécouverteConfigurer les nouvelles tentatives de demandes dans le cloud. Vous pouvez créer une configuration pour chaque fournisseur.  
Lorsqu'une demande est limitée, le cadre de travail des nouvelles tentatives utilise la configuration des nouvelles tentatives définie pour que le fournisseur gère les nouvelles tentatives avant de renvoyer la réponse finale aux classes ApiCommand :

* AwsApiCommand
* AzureApiCommand
{#cloud-request-retry-configuration__ul_vnx_nb1_b5b}

Les configurations des nouvelles tentatives sont synchronisées avec les Serveurs MID à l'aide de la propriété du Serveur MID, mid.cloud.discovery.retry.configuration.  
Les stratégies de nouvelle tentative sont les suivantes :

* Temporisation exponentielle
* Temporisation de l'en-tête de la réponse
* Temporisation personnalisée
{#cloud-request-retry-configuration__ul_ipy_1h1_b5b}

## Temporisation exponentielle {#cloud-request-retry-configuration__section_lgs_2h1_b5b}

Pour l'exemple de configuration suivant :{#cloud-request-retry-configuration__table_chm_xw1_b5b__entry__2}

| Paramètre | Valeur |
|-|-|
| Nombre max de nouveaux essais | 3 |
| Codes de réponses | 429 |
| Retard de base, en ms | 1 000 |
| Délai maximal, en ms | 10 000 |
| Délai supplémentaire, en ms | 1 500 |
[ ]

{#cloud-request-retry-configuration__table_chm_xw1_b5b}  
La stratégie de nouvelle tentative de temporisation exponentielle fonctionne comme suit :

* 1ère nouvelle tentative : le multiplicateur de temporisation est sélectionné aléatoirement entre 0 et 1. La valeur maximale du délai est de 400 ms (400 \* 1).
* 2e tentative : le multiplicateur de temporisation est sélectionné aléatoirement entre 0 et 3. La valeur maximale du délai est de 1 200 ms (400 \* 3).
* 3e tentative : le multiplicateur de temporisation est sélectionné aléatoirement entre 0 et 7. La valeur maximale du délai est de 2 800 ms (400 \* 7).
{#cloud-request-retry-configuration__ul_rwr_fx1_b5b}

Lors des nouvelles tentatives ultérieures, si le délai dépasse 10 000 (le délai maximal), la valeur 10 000 est utilisée comme délai initial.

Une fois le délai initial généré, il est ajouté au délai. La fenêtre de gigue est définie par le champ Délai supplémentaire, en ms. Le système sélectionne une valeur aléatoire comprise entre 0 et 1 500, et l'ajoute au délai initial.

Si le délai initial est de 500, le délai final (avec gigue) peut être une valeur comprise entre 500 et 2 000 ms.

## Temporisation de l'en-tête de la réponse {#cloud-request-retry-configuration__section_ffr_2y1_b5b}

Pour l'exemple de configuration suivant :{#cloud-request-retry-configuration__table_a4m_gy1_b5b__entry__2}

| Paramètre | Valeur |
|-|-|
| Nombre max de nouveaux essais | 3 |
| Codes de réponses | 429 |
| En-tête de la réponse | Nouvelle tentative après |
| Unité de délai de l'en-tête de réponse | Secondes |
| Délai supplémentaire, en ms | 1 500 |
[ ]

{#cloud-request-retry-configuration__table_a4m_gy1_b5b}  
La stratégie de temporisation de l'en-tête de réponse fonctionne comme suit :

* Récupérez la valeur de l'en-tête Retry-After auprès de la réponse du serveur.
* Convertissez le paramètre Retry-After en millisecondes en multipliant par 1 000.
{#cloud-request-retry-configuration__ul_e14_sy1_b5b}

Une fois le délai initial généré, il est ajouté au délai. La fenêtre de gigue est définie par le champ Délai supplémentaire, en ms. Le système sélectionne une valeur aléatoire comprise entre 0 et 1 500, et l'ajoute au délai initial.

Si le délai initial est de 2 000, le délai final (avec gigue) peut être une valeur comprise entre 2 000 et 3 500 ms.

## Temporisation personnalisée {#cloud-request-retry-configuration__section_ipx_byx_f5b}

Avec une stratégie de nouvelle tentative de temporisation personnalisée, vous définissez le nombre maximal de nouvelles tentatives et les codes de réponse et créez votre propre include de script MID qui définit la façon dont les demandes sont retentées à l'aide de la getDelay() fonction. Pour plus d'informations, consultez Includes de script.