Lidar com erros e exceções de fluxo de trabalho no Azure Logic Apps

Aplica-se a: Azure Logic Apps (Consumption + Standard)

A maneira como qualquer arquitetura de integração lida adequadamente com o tempo de inatividade ou problemas causados por sistemas dependentes pode representar um desafio. Para ajudá-lo a criar integrações robustas e resilientes que lidam graciosamente com problemas e falhas, os Aplicativos Lógicos do Azure fornecem uma experiência de primeira classe para lidar com erros e exceções.

Políticas de nova tentativa

Para a exceção mais básica e tratamento de erros, você pode usar a política de repetição se esse recurso existir em um gatilho ou ação, como a ação HTTP. Se o pedido original do acionador ou da ação ultrapassar o tempo limite ou falhar, originando uma resposta 408, 429 ou 5xx, a política de repetição de tentativas especifica que o acionador ou a ação reenvie o pedido de acordo com as definições da política.

Limites da política de repetição de tentativas

Para obter mais informações sobre políticas, configurações, limites e outras opções de repetição, consulte Limites da política de repetição.

Tipos de política de repetição

As operações do conector que suportam políticas de repetição utilizam a política Padrão, a menos que selecione uma política de repetição diferente.

Alterar o tipo de política de repetição no designer

1. No portal do Azure, abra seu recurso de aplicativo lógico.

2. Na barra lateral do recurso, siga estas etapas para abrir o designer de fluxo de trabalho, com base em seu aplicativo lógico:

   • Consumo: em Ferramentas de Desenvolvimento, selecione o designer para abrir seu fluxo de trabalho.

   • Padrão

     1. Em Fluxos de trabalho, selecione Fluxos de trabalho.

     2. Na página Fluxos de trabalho , selecione seu fluxo de trabalho.

     3. Em Ferramentas, selecione o designer para abrir seu fluxo de trabalho.

3. No gatilho ou ação em que você deseja alterar o tipo de política de repetição, siga estas etapas para abrir as configurações:

   1. No designer, selecione a operação.

   2. No painel de informações da operação, selecione Configurações.

   3. Em Rede, em Repetir política, selecione o tipo de política desejado.

Alterar o tipo de política de repetição no editor de visualização de código

1. Confirme se o gatilho ou a ação oferece suporte a políticas de repetição concluindo as etapas anteriores no designer.

2. Abra o fluxo de trabalho do aplicativo lógico no editor de visualização de código.

3. Na definição de gatilho ou ação, adicione o retryPolicy objeto JSON ao objeto do gatilho ou ação inputs . Se nenhum retryPolicy objeto existir, o gatilho ou ação usará a política de default repetição.

   "inputs": {
      <...>,
      "retryPolicy": {
         "type": "<retry-policy-type>",
         // The following properties apply to specific retry policies.
         "count": <retry-attempts>,
         "interval": "<retry-interval>",
         "maximumInterval": "<maximum-interval>",
         "minimumInterval": "<minimum-interval>"
      },
      <...>
   },
   "runAfter": {}
   

   Obrigatório

   Propriedade	valor	Tipo	Descrição
   type	< tipo-de-política-de-tentativa>	Cordão	O tipo de política de repetição a ser usado: default, none, fixed, ou exponential
   count	< repetir-tentativas>	Número inteiro	Para os tipos de política fixed e exponential, o número de tentativas de repetição, com um valor entre 1 e 90. Para obter mais informações, consulte Intervalo fixo e Intervalo exponencial.
   interval	< intervalo de repetição>	Cordão	Para os tipos de política fixed e exponential, o valor do intervalo de repetição deve estar no formato ISO 8601. Para a exponential política, você também pode especificar intervalos máximos e mínimos opcionais. Para obter mais informações, consulte Intervalo fixo e Intervalo exponencial. Consumo: 5 segundos (PT5S) a 1 dia (P1D). Padrão: Para fluxos de trabalho com monitoração de estado, de 5 segundos (PT5S) a 1 dia (P1D). Para fluxos de trabalho sem monitoração de estado, de 1 segundo (PT1S) a 1 minuto (PT1M).

   Opcional

   Propriedade	valor	Tipo	Descrição
   maximumInterval	< intervalo-máximo>	Cordão	Para a política exponential, o maior valor do intervalo selecionado aleatoriamente no formato ISO 8601. O valor padrão é 1 dia (P1D). Para obter mais informações, consulte Intervalo Exponencial.
   minimumInterval	< intervalo-mínimo>	Cordão	Para a política exponential, o menor intervalo do intervalo selecionado aleatoriamente no formato ISO 8601. O valor padrão é 5 segundos (PT5S). Para obter mais informações, consulte Intervalo Exponencial.

Política de repetição predefinida

As operações do conector que suportam políticas de repetição utilizam a política Padrão, a menos que selecione uma política de repetição diferente. Para a maioria das operações, a política de repetição padrão é uma política de intervalo exponencial que envia até 4 repetições em intervalos exponencialmente crescentes . Esses intervalos são dimensionados em 7,5 segundos, mas são limitados entre 5 e 45 segundos. Várias operações usam uma política de repetição padrão diferente, como uma política de intervalo fixo.

Em sua definição de fluxo de trabalho, a definição de gatilho ou ação não define explicitamente a política padrão, mas o exemplo a seguir mostra como a política de repetição padrão se comporta para a ação HTTP:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "http://myAPIendpoint/api/action",
      "retryPolicy" : {
         "type": "exponential",
         "interval": "PT7S",
         "count": 4,
         "minimumInterval": "PT5S",
         "maximumInterval": "PT1H"
      }
   },
   "runAfter": {}
}

Nenhuma - Sem política de nova tentativa

Para especificar que a ação ou o acionador não volte a tentar pedidos com falha, defina o <retry-policy-type> como none.

Política de repetição de tentativas com intervalo fixo

Para especificar que a ação ou o acionador aguarda o intervalo especificado antes de enviar o pedido seguinte, defina <retry-policy-type> como fixed.

Exemplo

Esta política de repetição tenta obter as últimas notícias mais duas vezes após a primeira solicitação com falha com um atraso de 30 segundos entre cada tentativa:

"Get_latest_news": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "https://mynews.example.com/latest",
      "retryPolicy": {
         "type": "fixed",
         "interval": "PT30S",
         "count": 2
      }
   }
}

Política de repetição com intervalo exponencial

A política de repetição com intervalo exponencial especifica que o accionador ou a ação aguarda um intervalo aleatório antes de enviar o pedido seguinte. Este intervalo aleatório é selecionado a partir de uma faixa de crescimento exponencial. Opcionalmente, pode substituir os intervalos mínimo e máximo predefinidos, especificando os seus próprios intervalos mínimo e máximo, consoante tenha um fluxo de trabalho da aplicação lógica Consumo ou Padrão.

Intervalos de variáveis aleatórias

Para a política de repetição de intervalo exponencial, a tabela a seguir mostra o algoritmo geral que os Aplicativos Lógicos do Azure usam para gerar uma variável aleatória uniforme no intervalo especificado para cada nova tentativa. O intervalo especificado pode ir até ao número de tentativas, inclusive.

Gerenciar o comportamento de "correr atrás"

Ao adicionar ações no designer de fluxo de trabalho, você declara implicitamente a sequência para executar essas ações. Depois de uma ação terminar de ser executada, a ação é marcada com um estado como Êxito, Falha, Ignorada ou Tempo limite excedido. Em outras palavras, a ação antecessora deve primeiro terminar com qualquer um dos estados permitidos antes de a ação sucessora poder ser executada.

Por padrão, uma ação adicionada no designer será executada somente se a ação anterior for concluída com o status Bem-sucedido . Esse comportamento de execução após especifica com precisão a ordem de execução das ações em um fluxo de trabalho.

No designer, você pode alterar o comportamento padrão "executar após" de uma ação editando a configuração Executar após da ação. Essa configuração está disponível somente em ações subsequentes que seguem a primeira ação em um fluxo de trabalho. A primeira ação em um fluxo de trabalho sempre é executada depois que o gatilho é executado com êxito. Portanto, a configuração Executar depois não está disponível e não se aplica à primeira ação.

Na definição JSON subjacente de uma ação, a configuração Executar depois é a mesma que a runAfter propriedade. Esta propriedade especifica uma ou mais ações predecessoras que devem primeiro terminar com os status permitidos específicos antes que a ação sucessora possa ser executada. A runAfter propriedade é um objeto JSON que fornece flexibilidade permitindo que você especifique todas as ações predecessoras que devem ser concluídas antes que a ação sucessora seja executada. Este objeto também define uma matriz de status aceitáveis.

Por exemplo, para que uma ação seja executada após a ação A ser bem-sucedida e também depois que a ação B for bem-sucedida ou falhar quando você estiver trabalhando na definição JSON de uma ação, configure a seguinte runAfter propriedade:

{
   // Other parts in action definition
   "runAfter": {
      "Action A": ["Succeeded"],
      "Action B": ["Succeeded", "Failed"]
    }
}

Comportamento "Executar após" para tratamento de erros

Quando uma ação gera um erro ou exceção não tratada, a ação é marcada como Falha e qualquer ação sucessora é marcada como Ignorada. Se esse comportamento acontecer para uma ação que tenha ramificações paralelas, o mecanismo de Aplicativos Lógicos do Azure seguirá as outras ramificações para determinar seus status de conclusão. Por exemplo, se uma ramificação terminar com uma ação ignorada , o status de conclusão dessa ramificação será baseado no status antecessor dessa ação ignorada. Após a conclusão da execução do fluxo de trabalho, o motor determina o estado global da execução avaliando os estados de todos os ramos. Se qualquer ramificação terminar em falha, toda a execução do fluxo de trabalho será marcada como Falha.

Para garantir que uma ação ainda possa ser executada apesar do status de seu antecessor, você pode alterar o comportamento "executar após" de uma ação para lidar com os status malsucedidos do predecessor. Dessa forma, a ação é executada quando o estado do antecessor é Succeeded, Failed, Skipped, TimedOut ou todos estes estados.

Por exemplo, para executar a ação do Office 365 Outlook Enviar um e-mail depois de a ação precedente do Excel Online Adicionar uma linha a uma tabela estar marcada como Falha, em vez de Êxito, altere o comportamento "executar após" utilizando o estruturador ou o editor da vista de código.

Alterar o comportamento "executar após" no designer

1. No portal do Azure, abra seu recurso de aplicativo lógico.

2. Na barra lateral do recurso, siga estas etapas para abrir o designer de fluxo de trabalho, com base em seu aplicativo lógico:

   • Consumo: em Ferramentas de Desenvolvimento, selecione o designer para abrir seu fluxo de trabalho.

   • Padrão

     1. Na barra lateral do recurso, em Fluxos de trabalho, selecione Fluxos de trabalho.

     2. Na página Fluxos de trabalho , selecione seu fluxo de trabalho.

     3. Em Ferramentas, selecione o designer para abrir seu fluxo de trabalho.

3. No gatilho ou ação em que você deseja alterar o comportamento "executar depois", siga estas etapas para abrir as configurações da operação:

   1. No designer, selecione a operação.

   2. No painel de informações da operação, selecione Configurações.

      A seção Executar após contém uma lista Selecionar ações , que mostra as operações predecessoras disponíveis para a operação selecionada no momento, por exemplo:

      

   3. Na lista Selecionar ações , expanda a operação predecessora atual, que é HTTP neste exemplo:

      

      Por padrão, o status "executar após" é definido como É bem-sucedido. Esse valor significa que a operação predecessora deve ser concluída com êxito antes que a ação atual possa ser executada.

      

4. Para alterar o comportamento "executar após" para os estados pretendidos, selecione esses estados.

   O exemplo a seguir seleciona Has failed.

   

5. Para especificar que a operação atual é executada somente quando a ação predecessora é concluída com o status Falhou, Foi ignorado ou Atingiu o tempo limite , selecione esses status e limpe o status padrão, por exemplo:

   

   Nota

   Antes de limpar o status padrão, certifique-se de selecionar outro status primeiro. Você sempre deve ter pelo menos um status selecionado.

6. Para exigir que várias operações predecessoras sejam executadas e concluídas, cada uma com seus próprios status de "execução após", siga estas etapas:

   1. Abra a lista Selecionar ações e selecione as operações predecessoras desejadas.

   2. Selecione os status "run after" para cada operação.

   

7. Quando terminar, feche o painel de informações da operação.

Alterar o comportamento "executar após" no editor de visualização de código

1. Na barra lateral do recurso, siga estas etapas para abrir o editor de visualização de código, com base em seu aplicativo lógico:

   • Consumo: Em Ferramentas de Desenvolvimento, selecione a visualização de código para abrir seu fluxo de trabalho no editor JSON.

   • Padrão

     1. Em Fluxos de trabalho, selecione Fluxos de trabalho.

     2. Na página Fluxos de trabalho , selecione seu fluxo de trabalho.

     3. Em Ferramentas, selecione a visualização de código para abrir seu fluxo de trabalho no editor JSON.

2. Na definição JSON da ação, edite a runAfter propriedade, que tem a seguinte sintaxe:

   "<action-name>": {
      "inputs": {
         "<action-specific-inputs>"
      },
      "runAfter": {
         "<preceding-action>": [
            "Succeeded"
         ]
      },
      "type": "<action-type>"
   }
   

3. Neste exemplo, altere a propriedade runAfter de Succeeded para Failed:

   "Send_an_email_(V2)": {
      "inputs": {
         "body": {
            "Body": "<p>Failed to add row to table: @{body('Add_a_row_into_a_table')?['Terms']}</p>",
            "Subject": "Add row to table failed: @{body('Add_a_row_into_a_table')?['Terms']}",
            "To": "Sophia.Owen@fabrikam.com"
         },
         "host": {
            "connection": {
               "name": "@parameters('$connections')['office365']['connectionId']"
            }
         },
         "method": "post",
         "path": "/v2/Mail"
      },
      "runAfter": {
         "Add_a_row_into_a_table": [
            "Failed"
         ]
      },
      "type": "ApiConnection"
   }
   

4. Para especificar que a ação é executada se a ação predecessora estiver marcada como Failed, Skipped ou TimedOut, adicione os outros status:

   "runAfter": {
      "Add_a_row_into_a_table": [
         "Failed", "Skipped", "TimedOut"
      ]
   },
   

Avaliar ações com escopos e seus resultados

Semelhante à execução de etapas após ações individuais com a configuração "executar após", você pode agrupar ações dentro de um escopo. Você pode usar escopos quando quiser agrupar logicamente ações, avaliar o status agregado do escopo e executar ações com base nesse status. Depois que todas as ações em um escopo terminam de ser executadas, o escopo em si recebe seu próprio status.

Para verificar o status de um escopo, você pode usar os mesmos critérios usados para verificar o status de execução de um fluxo de trabalho, como Êxito, Falha e assim por diante.

Por padrão, quando todas as ações do escopo são bem-sucedidas, o status do escopo é marcado como Bem-sucedido. Se a ação final em um escopo estiver marcada como Falha ou Anulada, o status do escopo será marcado como Falha.

Para detetar exceções num âmbito Com falha e executar ações que tratam esses erros, pode utilizar a definição "executar após" para esse âmbito Com falha. Dessa forma, se alguma ação no escopo falhar e você usar a configuração "executar após" para esse escopo, poderá criar uma única ação para detetar falhas.

Para limites de escopos, consulte Limites e configuração.

Configurar um escopo com "executar após" para tratamento de exceções

1. No portal do Azure, abra o recurso e o fluxo de trabalho da aplicação lógica no Designer.

   Seu fluxo de trabalho já deve ter um gatilho que inicia o fluxo de trabalho.

2. No designer, siga estas etapas genéricas para adicionar uma ação de controle chamada Escopo ao seu fluxo de trabalho.

3. Na ação Escopo, siga estas etapas genéricas para adicionar ações a serem executadas, por exemplo:

   

   A lista a seguir mostra alguns exemplos de ações que você pode incluir dentro de uma ação de escopo :

   • Obtenha dados de uma API.
   • Processar os dados.
   • Salve os dados em um banco de dados.

4. Agora defina as regras de "executar depois" para executar as ações no âmbito.

   1. No estruturador, selecione o título Scope. Quando o painel de informações do escopo abrir, selecione Configurações.

   2. Se você tiver mais de uma ação anterior no fluxo de trabalho, na lista Selecionar ações , selecione a ação após a qual deseja executar as ações com escopo.

   3. Para a ação selecionada, selecione todos os estados da ação que podem executar as ações no âmbito definido.

      Em outras palavras, qualquer um dos status escolhidos que resultam da ação selecionada faz com que as ações no escopo sejam executadas.

      No exemplo seguinte, as ações com escopo são executadas depois de a ação HTTP ser concluída com qualquer um dos estados selecionados:

      

Obtenha o contexto e os resultados em caso de falhas

Embora seja útil detetar falhas num âmbito, também poderá querer mais contexto para perceber exatamente quais foram as ações que falharam, além de quaisquer erros ou códigos de estado. A result() função devolve os resultados das ações de nível superior numa ação delimitada por âmbito. Essa função aceita o nome do escopo como um único parâmetro e retorna uma matriz com os resultados dessas ações de nível superior. Esses objetos de ação têm os mesmos atributos que os atributos retornados actions() pela função, como a hora de início, a hora de término, o status, as entradas, as IDs de correlação e as saídas da ação.

Para obter contexto sobre as ações que falharam num escopo, pode usar a expressão @result() com o nome do escopo e a definição "run after". Para filtrar a matriz devolvida e ficar apenas com as ações que têm o estado Falhou, pode adicionar a ação Filtrar matriz. Para executar uma ação sobre uma ação com falha devolvida, obtenha a lista filtrada devolvida e utilize um ciclo Para cada.

O exemplo JSON a seguir envia uma solicitação HTTP POST com o corpo de resposta para todas as ações que falharam dentro da ação de escopo chamada My_Scope. Após o exemplo, segue-se uma explicação detalhada.

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": "@result('My_Scope')",
      "where": "@equals(item()['status'], 'Failed')"
   },
   "runAfter": {
      "My_Scope": [
         "Failed"
      ]
    }
},
"For_each": {
   "type": "foreach",
   "actions": {
      "Log_exception": {
         "type": "Http",
         "inputs": {
            "method": "POST",
            "body": "@item()['outputs']['body']",
            "headers": {
               "x-failed-action-name": "@item()['name']",
               "x-failed-tracking-id": "@item()['clientTrackingId']"
            },
            "uri": "http://requestb.in/"
         },
         "runAfter": {}
      }
   },
   "foreach": "@body('Filter_array')",
   "runAfter": {
      "Filter_array": [
         "Succeeded"
      ]
   }
}

As etapas a seguir descrevem o que acontece neste exemplo:

1. Para obter o resultado de todas as ações dentro My_Scope, a ação Matriz de Filtros usa esta expressão de filtro: @result('My_Scope')

2. A condição para Filter Array é qualquer @result() item que tenha um status igual a Failed. Essa condição filtra a matriz que tem todos os resultados da ação de My_Scope para uma matriz com apenas os resultados da ação com falha.

3. Efetue uma For_each ação de ciclo nas saídas da array filtrada. Esta etapa executa uma ação para cada resultado de ação com falha que foi filtrado anteriormente.

   Se uma única ação no escopo falhar, as ações no For_each loop serão executadas apenas uma vez. Múltiplas falhas de ação causam uma ação por cada falha.

4. Envie um pedido HTTP POST ao corpo da resposta do item For_each, que é a expressão @item()['outputs']['body'].

   A @result() forma do item é a mesma que a @actions() forma e pode ser analisada da mesma maneira.

5. Inclua dois cabeçalhos personalizados com o nome da ação com falha (@item()['name']) e o ID de acompanhamento do cliente de execução com falha (@item()['clientTrackingId']).

Para referência, aqui está um exemplo de um único elemento @result(), mostrando as propriedades name, body e clientTrackingId que são analisadas no exemplo anterior. Fora de uma For_each ação, @result() retorna uma matriz desses objetos.

{
   "name": "Example_Action_That_Failed",
   "inputs": {
      "uri": "https://myfailedaction.azurewebsites.net",
      "method": "POST"
   },
   "outputs": {
      "statusCode": 404,
      "headers": {
         "Date": "Thu, 11 Aug 2016 03:18:18 GMT",
         "Server": "Microsoft-IIS/8.0",
         "X-Powered-By": "ASP.NET",
         "Content-Length": "68",
         "Content-Type": "application/json"
      },
      "body": {
         "code": "ResourceNotFound",
         "message": "/docs/folder-name/resource-name does not exist"
      }
   },
   "startTime": "2016-08-11T03:18:19.7755341Z",
   "endTime": "2016-08-11T03:18:20.2598835Z",
   "trackingId": "bdd82e28-ba2c-4160-a700-e3a8f1a38e22",
   "clientTrackingId": "08587307213861835591296330354",
   "code": "NotFound",
   "status": "Failed"
}

Para executar diferentes padrões de tratamento de exceções, você pode usar as expressões descritas anteriormente neste artigo. Você pode optar por executar uma única ação de tratamento de exceção fora do escopo que aceita toda a matriz filtrada de falhas e remover a For_each ação. Também pode incluir outras propriedades úteis da resposta \@result(), conforme descrito anteriormente.

Configurar os registos do Azure Monitor

Os padrões anteriores são maneiras úteis de lidar com erros e exceções que acontecem dentro de uma execução. No entanto, você também pode identificar e responder a erros que acontecem independentemente da execução. Para avaliar os status da execução, você pode monitorar os logs e as métricas de suas execuções ou publicá-las em qualquer ferramenta de monitoramento de sua preferência.

Por exemplo, o Azure Monitor fornece uma maneira simplificada de enviar todos os eventos de fluxo de trabalho, incluindo todos os status de execução e ação, para um destino. Você pode configurar alertas para métricas e limites específicos no Azure Monitor. Você também pode enviar eventos de fluxo de trabalho para um espaço de trabalho do Log Analytics ou uma conta de armazenamento do Azure. Ou, você pode transmitir todos os eventos por meio dos Hubs de Eventos do Azure para oAzure Stream Analytics. No Stream Analytics, você pode escrever consultas em tempo real com base em quaisquer anomalias, médias ou falhas dos logs de diagnóstico. Você pode usar o Stream Analytics para enviar informações para outras fontes de dados, como filas, tópicos, SQL, Azure Cosmos DB ou Power BI.

Para obter mais informações, consulte Configurar os registos do Azure Monitor e recolher dados de diagnóstico para o Azure Logic Apps.

Conteúdo relacionado

• Exemplos e cenários de Aplicativos Lógicos do Azure