Compartir a través de

Instrucciones para reintento de ACS

  • Artículo

Actualizado: 6 de julio de 2015

Se aplica a: Azure

Microsoft Azure Active Directory Access Control (también conocido como servicio de Access Control o ACS) admite una serie de puntos de conexión de emisión y administración de tokens diferentes a los que los clientes pueden enviar solicitudes de token. Este tema proporciona instrucciones de implementación de sistemas de lógica de reintento en caso de error en las solicitudes de token.

Escenarios de administración de errores

Los errores de solicitud de token que devuelven errores de HTTP 500 suelen resolverse con los reintentos. En algunos escenarios, el cliente es una aplicación o servicio que realiza solicitudes automatizadas a ACS. En otros escenarios como, por ejemplo, la federación basada en web que usa el protocolo WS-Federation, el cliente es un explorador web y el usuario final debe reintentar la operación de forma manual. Este tema abarca los distintos escenarios de control de errores en los que el cliente es un servicio o una aplicación.

Entre los escenarios se incluyen los siguientes:

Instrucciones de reintento

Las instrucciones siguientes explican cómo implementar una lógica de reintento en los escenarios de administración de errores.

Guía n.º 1: Implementación de la lógica de reintento basada en respuestas de error de la serie HTTP 500

Se recomienda encarecidamente la lógica de reintento cuando ACS devuelve errores de la serie HTTP 500. La lista siguiente muestra ejemplos de los errores del tipo HTTP 500 más habituales.

  • Error HTTP 500: error interno del servidor

  • Error HTTP 502: puerta de enlace incorrecta

  • Error HTTP 503: servicio no disponible

  • Error HTTP 504: tiempo de espera agotado para la puerta de enlace

Aunque los códigos HTTP pueden enumerarse en la lógica de reintento, basta con invocar la lógica de reintento si se obtiene algún error del tipo HTTP 500.

Los códigos de error HTTP deben desencadenar la lógica de reintento, como HTTP 504 (tiempo de espera del servidor externo) y no mediante códigos de error de ACS, como ACS90005. Los códigos de error de ACS son informativos y están sujetos a cambios.

Normalmente, no se recomienda utilizar la lógica de reintento cuando se devuelven códigos de error de la serie HTTP 400. Un código de respuesta de error de la serie HTTP 400 de ACS significa que la solicitud no es válida y que debe revisarse. Una excepción es el código de error 429 ("Demasiadas solicitudes"), lo que indica que el espacio de nombres superó el límite de tasa de solicitud de tokens durante un periodo extendido. Para los errores 429, el uso de reintentos con temporizador de trabajo pendiente puede resolver el trabajo pendiente de la solicitud del token inmediata hasta que el administrador tenga tiempo de revisar la distribución de cargas de trabajo del espacio de nombres. Para obtener más información, consulte Limitaciones del servicio ACS.

Guía n.º 2: Los reintentos deben usar un temporizador de retroceso para un control de flujo óptimo

Cuando un cliente recibe un error HTTP 500, este debe esperar un periodo determinado antes de volver a intentar la solicitud. Para obtener mejores resultados, se recomienda que este periodo sea mayor en cada reintento. Gracias a este enfoque, podemos solucionar rápidamente los errores transitorios y optimizar al mismo tiempo la frecuencia de solicitudes de los problemas de servidor o de red transitorios que tardan más tiempo en resolverse.

Por ejemplo, utilice un temporizador de retroceso exponencial donde el retraso antes del reintento aumente exponencialmente con cada instancia, como reintento 1: 1 segundo; reintento 2: 2 segundos; reintento 3: 4 segundos, y así sucesivamente.

Ajuste el número de reintentos y el tiempo entre cada uno de ellos según los requisitos de experiencia del usuario. Sin embargo, se recomienda hasta cinco reintentos durante un periodo de cinco minutos. Los errores derivados de un tiempo de espera agotado tardan más en solucionarse.

Guía n.º 3: Compruebe que el elemento no existe antes de intentar crearlo o eliminarlo

Al realizar operaciones de creación o eliminación con el servicio de administración de ACS, como crear una nueva aplicación de usuario de confianza o eliminar una regla, la lógica de reintento debe consultar si el elemento existe antes de realizar la operación. En algunas circunstancias, como un error de red transitorio que se produce al entregar la respuesta del servidor, una operación de creación o eliminación puede realizarse correctamente incluso cuando el cliente obtiene una respuesta de error.

Si se reintenta una operación de creación sin comprobar que el elemento existe, es posible que se creen elementos duplicados. Asimismo, el sistema puede devolver un error HTTP 400 si este debe ser único.

Si se reintenta una operación de eliminación sin comprobar la existencia del elemento, el sistema puede devolver un error HTTP 400 cuando no encuentre dicho elemento.

Consulte también

Conceptos

Códigos de error de ACS
Lmitaciones del servicio ACS
Servicio de administración de ACS
Cómo: Solicitar un token de ACS a través del protocolo WRAP de OAuth
Ejemplo de código: Autenticación de certificados de OAuth 2.0
Índice de directrices de ACS