Cette documentation est archivée et n’est pas conservée.

Instructions relatives aux nouvelles tentatives pour ACS

Publication: janvier 2013

Mis à jour: juillet 2015

S'applique à: Azure

Microsoft Azure Active Directory Access Control (également appelé Access Control Service ou ACS) prend en charge plusieurs points de terminaison de gestion et d'émission de jetons auxquels les clients peuvent envoyer une demande de jetons. Cette rubrique fournit des instructions pour l'implémentation d'une logique de nouvelle tentative en cas d'échec de demande de jetons.

Les échecs de demande de jetons qui retournent des codes d'erreur de série HTTP 500 répondent généralement aux nouvelles tentatives. Dans certains scénarios, le client est une application ou un service qui effectue des demandes automatisées à ACS. Dans d'autres scénarios, tels que la fédération web qui utilise le protocole WS-Federation, le client est un navigateur web et l'utilisateur final doit effectuer une nouvelle tentative manuellement. Cette rubrique traite de scénarios de gestion des erreurs dans lesquels le client est une application ou un service.

Il s'agit des scénarios suivants :

Les instructions suivantes expliquent comment implémenter une logique de nouvelle tentative dans les scénarios de gestion des erreurs.

Il est vivement recommandé d'implémenter une logique de nouvelle tentative quand ACS retourne des erreurs de la série HTTP 500. La liste suivante comprend des exemples d'erreurs de la série HTTP 500.

  • Erreur HTTP 500 - Erreur interne du serveur

  • Erreur HTTP 502 - Passerelle incorrecte

  • Erreur HTTP 503 - Service non disponible

  • Erreur HTTP 504 - Expiration du délai pour la passerelle

Bien que chaque code HTTP puisse être énuméré dans la logique de nouvelle tentative, il suffit d'appeler la logique de nouvelle tentative si une erreur de la série HTTP 500 est retournée.

La logique de nouvelle tentative doit être déclenchée par des codes d'erreur HTTP, tels que HTTP 504 (Expiration du délai pour le serveur externe), et non par des codes d'erreur ACS, tels qu'ACS90005. Les codes d'erreur ACS sont fournis à titre d'information et sujets à modification.

En général, il est déconseillé de faire appel à une logique de nouvelle tentative quand des codes d'erreur de la série HTTP 400 sont retournés. Un code de réponse d'erreur HTTP de la série 400 renvoyé par ACS signifie que la demande n'est pas valide et doit être révisée. Le code d'erreur 429 (« Trop de demandes ») est une exception : il indique que l'espace de noms a dépassé la limite du nombre de demandes de jetons pendant une période prolongée. Pour les erreurs 429, les nouvelles tentatives avec un minuteur d'interruption peuvent résoudre le backlog de demandes de jetons immédiat jusqu'à ce que l'administrateur ait le temps d'examiner et de corriger la distribution des charges de travail de l'espace de noms. Pour plus d'informations, consultez Limitations du service ACS.

Quand un client reçoit une erreur de la série HTTP 500, il doit patienter pendant un laps de temps spécifié avant d'effectuer une nouvelle tentative. Pour de meilleurs résultats, nous vous recommandons d'augmenter ce délai à chaque nouvelle tentative ultérieure. Cette approche permet de résoudre rapidement les erreurs temporaires tout en optimisant le taux de demande pour les problèmes réseau ou de serveur temporaires dont la résolution est plus longue.

Par exemple, vous pouvez utiliser un minuteur d'interruption exponentiel avec lequel le délai avant une nouvelle tentative augmente de manière exponentielle à chaque instance (Nouvelle tentative 1 : 1 seconde, Nouvelle tentative 2 : 2 secondes, Nouvelle tentative 3 : 4 secondes, et ainsi de suite).

Ajustez le nombre de nouvelles tentatives et le délai entre chaque nouvelle tentative en fonction des exigences de votre expérience utilisateur. Nous recommandons de spécifier jusqu'à cinq nouvelles tentatives pour un délai de cinq minutes. La résolution des défaillances dues à un dépassement du délai d'expiration prend davantage de temps.

Lors de l'exécution d'opérations de création ou de suppression avec le service de gestion ACS, par exemple lors de la création d'une application de partie de confiance ou de la suppression d'une règle, la logique de nouvelle tentative doit interroger si l'élément existe avant d'effectuer l'opération. Dans certaines circonstances, par exemple en cas de défaillance réseau temporaire lors de la remise de la réponse du serveur, une opération de création ou de suppression peut réussir même quand le client obtient une réponse d'erreur.

Si vous effectuez une nouvelle tentative d'opération de création sans vérifier l'existence de l'élément, vous risquez de créer des doublons. De plus, le système peut renvoyer une erreur HTTP 400 si l'élément doit être unique.

Si vous effectuez une nouvelle tentative d'opération de suppression sans vérifier l'existence de l'élément, le système risque de retourner une erreur HTTP 400 quand il ne trouve pas l'élément.

Voir aussi

Afficher: