Esta documentación está archivada y no tiene mantenimiento.

Instrucciones para reintento de ACS

Publicada: enero de 2013

Actualizado: julio de 2015

Se aplica a: Azure

Active Directory Access Control de Microsoft Azure (también conocido como Access Control Service o ACS) admite numerosos extremos de administración y emisión de tokens 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.

Los errores de solicitud de token que devuelven errores de HTTP 500 suelen resolverse con los reintentos. En determinados escenarios, el cliente es una aplicación o un servicio que realiza solicitudes automatizadas al 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 estos escenarios se incluyen los siguientes:

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

Se recomienda usar la lógica de reintento cuando ACS devuelve errores del tipo 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 no válida

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

La lógica de reintento debe activarse con los errores del tipo HTTP como, por ejemplo, el error HTTP 504 (tiempo de espera del servidor agotado) y no por los códigos de error de ACS como, por ejemplo, ACS90005. Los códigos de error de ACS son solo informativos y están sujetos a cambios.

Normalmente, la lógica de reintento no se recomienda en caso de errores HTTP 400. Un código de respuesta a errores HTTP 400 de ACS indica que la solicitud no es válida y 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, vea Lmitaciones del servicio ACS.

Cuando un cliente recibe un error HTTP 500, este debe esperar un periodo determinado antes de volver a intentar la solicitud. Para obtener los mejores resultados, se recomienda incrementar dicho periodo con cada reintento. Este enfoque permite resolver rápidamente los errores transitorios a la vez que optimiza la tasa de resolución de solicitudes de problemas de servidor o de red transitorios.

Por ejemplo, puede usar un temporizador de trabajo pendiente exponencial cuando el retraso aumente de forma exponencial con cada instancia como, por ejemplo, en el 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 según los requisitos de experiencia del usuario. Sin embargo, se recomienda ajustar hasta cinco reintentos durante un periodo de cinco minutos. Los errores obtenidos por agotamiento del tiempo de espera tardan más en resolverse.

Al realizar operaciones de creación o eliminación con el Servicio de administración de ACS como, por ejemplo, la creación de una nueva aplicación de usuario de confianza o la eliminación de una regla, la lógica de reintento deberá consultar si el elemento existe antes de realizar la operación. En algunas circunstancias como, por ejemplo, en caso de un error de red transitorio que se produzca durante la entrega de la respuesta del servidor, la operación de creación o eliminación podrá 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.

Vea también

Mostrar: