Configuration des nouveaux essais de demandes dans le cloud

Si une demande est limitée par un fournisseur dans le cloud pendant la découverte, la configuration des nouvelles tentatives des demandes dans le cloud fournit une méthode personnalisable pour relancer les demandes. Schémas de découverte 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 Découverte et les administrateurs cloud peuvent accéder à la configuration des nouvelles tentatives de demande à l’adresse suivante : Tous > Découverte > Configuration des nouveaux essais 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

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

Temporisation exponentielle

Pour l'exemple de configuration suivant :

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

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).

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

Pour l'exemple de configuration suivant :

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

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.

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

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