Esta página foi útil?
Seus comentários sobre este conteúdo são importantes. Queremos saber sua opinião.
Comentários adicionais?
1500 caracteres restantes
Diretrizes para repetição de ACS

Diretrizes para repetição de ACS

Publicado: janeiro de 2013

Atualizado: julho de 2015

Aplica-se a: Azure

O Access Control do Active Directory do Microsoft Azure (também conhecido como Access Control Service ou ACS) presta suporte a inúmeros pontos de extremidade de emissão e gerenciamento de token para os quais os clientes podem enviar solicitações de token. Este tópico define as diretrizes para implementação da lógica de repetição quando as solicitações de token falham.

As falhas de solicitação de token que retornam códigos de erro HTTP 500 normalmente respondem a repetições. Em alguns cenários, o cliente é um aplicativo ou um serviço que faz solicitações automatizadas ao ACS. Em outros cenários, como no caso da federação baseada na Web, que usa o protocolo WS-Federation, o cliente é um navegador e o usuário final deve repetir a operação manualmente. Este tópico aborda os cenários de tratamento de erros nos quais o cliente é um aplicativo ou um serviço.

Esses cenários incluem:

As diretrizes a seguir explicam como implementar a lógica de repetição nos cenários de tratamento de erros.

A lógica de repetição é altamente recomendável quando o ACS retorna erros HTTP 500. A lista a seguir inclui cenários de erros HTTP 500 típicos.

  • Erro HTTP 500 - Erro interno do servidor

  • Erro HTTP 502 - Gateway incorreto

  • Erro HTTP 503 - Serviço indisponível

  • Erro HTTP 504 – Tempo limite do gateway

Embora códigos HTTP individuais possam ser enumerados na lógica de repetição, é suficiente invocar a lógica de repetição se algum erro HTTP 500 for exibido.

A lógica de repetição deve ser acionada por códigos de erro HTTP, como HTTP 504 (Tempo limite do servidor externo), e não por códigos de erro do ACS, como ACS90005. Os códigos de erro do ACS são informativos e estão sujeitos a alteração.

Normalmente, a lógica de repetição não é recomendável quando códigos de erro HTTP 400 são retornados. Um código de resposta de erro HTTP 400 do ACS indica que a solicitação é inválida e precisa ser analisada. Uma exceção é o código de erro 429 ("Excesso de solicitações"), que indica que o namespace excedeu o limite da taxa de solicitação de token por um longo período. No caso de erros 429, as repetições com um temporizador de retirada podem resolver a lista de pendências imediatas da solicitação de token até o administrador ter tempo de verificar e analisar a distribuição de carga de trabalho do namespace. Para obter mais informações, consulte Limitações do serviço ACS.

Quando um cliente recebe um erro HTTP 500, ele deve aguardar por um determinado período de tempo antes de repetir a solicitação. Para obter melhores resultados, é recomendável que esse período aumente a cada repetição subsequente. Essa abordagem permite que os erros transitórios sejam rapidamente solucionados e que, ao mesmo tempo, otimize a taxa de solicitação para erros transitórios da rede ou do servidor que demoram mais para serem solucionados.

Por exemplo, use um temporizador de retirada exponencial no qual o atraso antes da repetição aumente exponencialmente a cada instância. Por exemplo, Repetição 1: 1 segundo, Repetição 2: 2 segundos, Repetição 3: 4 segundos, e assim por diante.

Ajuste o número de repetições e o intervalo entre cada uma de acordo com a necessidade de sua experiência de usuário. Entretanto, é recomendável até cinco repetições por período de cinco minutos. As falhas causadas por um tempo limite são mais demoradas de solucionar.

Ao realizar operações de criação ou exclusão com o Serviço de Gerenciamento ACS, como a criação de um novo aplicativo de terceira parte confiável ou exclusão de uma regra, a lógica de repetição deve consultar se o item existe antes de realizar a operação. Em algumas circunstâncias, como a de uma falha transitória da rede ocorrida durante a entrega da resposta do servidor, uma operação de criação ou exclusão pode eficaz quando o cliente obtém uma resposta de erro.

Se uma operação de criação for repetida sem a verificação da existência do item, itens duplicados poderão ser criados. Além disso, o sistema pode retornar um erro HTTP 400 se o item for único.

Se uma operação de exclusão for repetida sem a verificação da existência do item, o sistema poderá retornar um erro HTTP 400 quando não conseguir encontrar o item.

Consulte também

Contribuições da comunidade

ADICIONAR
Mostrar:
© 2015 Microsoft