Processar erros e exceções no Azure Logic Apps
Aplica-se a: Aplicativos Lógicos do Azure (Consumo + Padrão)
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.
Repetir políticas
Para a exceção mais básica e o tratamento de erros, você pode usar a política de repetição quando houver suporte em um gatilho ou ação, como a ação HTTP. Se a solicitação original do gatilho ou ação expirar ou falhar, resultando em uma resposta 408, 429 ou 5xx, a política de repetição especifica que o gatilho ou ação reenvia a solicitação por configurações de política.
Limites da política de repetição
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.
Repetir tipos de política
As operações de conector que suportam políticas de repetição usam a política Padrão, a menos que você selecione uma política de repetição diferente.
| Política de repetição | Description |
|---|---|
| Predefinição | 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. Para obter mais informações, consulte o Tipo de política de repetição padrão. |
| Nenhuma | Não reenvie o pedido. Para obter mais informações, consulte Nenhuma - Nenhuma política de novas tentativas. |
| Intervalo Exponencial | Esta política aguarda um intervalo aleatório, que é selecionado a partir de um intervalo exponencialmente crescente antes de enviar a próxima solicitação. Para obter mais informações, revise o tipo de política de intervalo exponencial. |
| Intervalo fixo | Esta política aguarda o intervalo especificado antes de enviar a próxima solicitação. Para obter mais informações, revise o tipo de política de intervalo fixo. |
Alterar o tipo de política de repetição no designer
No portal do Azure, abra o fluxo de trabalho do aplicativo lógico no designer.
Se você estiver trabalhando em um fluxo de trabalho Consumo ou Padrão, abra as Configurações do gatilho ou da ação.
Consumo: Na forma de ação, abra o menu de reticências (...) e selecione Configurações.
Padrão: no designer, selecione a ação. No painel de detalhes, selecione Configurações.
Se o gatilho ou ação oferecer suporte a políticas de repetição, em Política de Repetição, selecione o tipo de política desejado.
Alterar o tipo de política de repetição no editor de visualização de código
Se necessário, confirme se o gatilho ou a ação oferece suporte a políticas de repetição concluindo as etapas anteriores no designer.
Abra o fluxo de trabalho do aplicativo lógico no editor de visualização de código.
Na definição de gatilho ou ação, adicione o
retryPolicyobjeto JSON ao objeto desse gatilho ou açãoinputs. Caso contrário, se nenhumretryPolicyobjeto existir, o gatilho ou ação usará adefaultpolítica de 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
Property valor Tipo Description type<retry-policy-type> String O tipo de política de repetição a ser usado: default,none,fixed, ouexponentialcount<novas tentativas-tentativas> Número inteiro Para fixedeexponentialtipos de política, o número de tentativas de repetição, que é um valor de 1 a 90. Para obter mais informações, consulte Intervalo fixo e Intervalo exponencial.interval<intervalo de repetição> String Para fixedeexponentialtipos de política, o valor do intervalo de repetição no formato ISO 8601. Para aexponentialpolí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
Property valor Tipo Description maximumInterval<intervalo-máximo> String Para a exponentialpolítica, o maior intervalo para o 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> String Para a exponentialpolítica, o menor intervalo para o 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 de conector que suportam políticas de repetição usam a política Padrão, a menos que você 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": {}
}
Nenhum - Nenhuma política de repetição
Para especificar que a ação ou o gatilho não repete solicitações com falha, defina o <retry-policy-type> como none.
Política de repetição de intervalo fixo
Para especificar que a ação ou gatilho aguarda o intervalo especificado antes de enviar a próxima solicitação, 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 de intervalos exponenciais
A política de repetição de intervalo exponencial especifica que o gatilho ou ação aguarda um intervalo aleatório antes de enviar a próxima solicitação. Este intervalo aleatório é selecionado a partir de uma faixa de crescimento exponencial. Opcionalmente, você pode substituir os intervalos mínimo e máximo padrão especificando seus próprios intervalos mínimos e máximos, com base no fato de você ter um fluxo de trabalho de aplicativo lógico Consumo ou Padrão.
| Nome | Limite de consumo | Limite padrão | Notas |
|---|---|---|---|
| Atraso máximo | Padrão: 1 dia | Padrão: 1 hora | Para alterar o limite padrão em um fluxo de trabalho de aplicativo lógico de consumo, use o parâmetro de política de repetição. Para alterar o limite padrão em um fluxo de trabalho de aplicativo lógico padrão, revise Editar configurações de host e aplicativo para aplicativos lógicos em Aplicativos Lógicos do Azure de locatário único. |
| Atraso mínimo | Padrão: 5 seg | Padrão: 5 seg | Para alterar o limite padrão em um fluxo de trabalho de aplicativo lógico de consumo, use o parâmetro de política de repetição. Para alterar o limite padrão em um fluxo de trabalho de aplicativo lógico padrão, revise Editar configurações de host e aplicativo para aplicativos lógicos em Aplicativos Lógicos do Azure de locatário único. |
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 ser até e incluindo o número de tentativas.
| Número de repetição | Intervalo mínimo | Intervalo máximo |
|---|---|---|
| 1 | max(0, <intervalo-mínimo>) | min (intervalo, <intervalo-máximo>) |
| 2 | max (intervalo, <intervalo-mínimo>) | min (2 * intervalo, <intervalo> máximo) |
| 3 | max(2 * intervalo, <intervalo-mínimo>) | min (4 * intervalo, <intervalo> máximo) |
| 4 | max (4 * intervalo, <intervalo> mínimo) | min (8 * intervalo, <intervalo> máximo) |
| .... | .... | .... |
Gerenciar o comportamento de "correr atrás"
Ao adicionar ações no designer de fluxo de trabalho, você declara implicitamente a ordem a ser usada para executar essas ações. Depois que uma ação termina de ser executada, essa ação é marcada com um status como Êxito, Falha, Ignorado ou Tempo Limite. Por padrão, uma ação adicionada no designer é executada somente depois que o predecessor é concluído com o status Bem-sucedido . Na definição subjacente de uma ação, a runAfter propriedade especifica que a ação predecessora que deve ser concluída primeiro e os status permitidos para essa ação predecessora antes que a ação sucessora possa ser executada.
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 mecanismo determina o status de toda a execução avaliando todos os status da ramificação. 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 status do antecessor é Succeeded, Failed, Skipped, Timedout ou todos esses status.
Por exemplo, para executar a ação Enviar um email do Office 365 Outlook após a ação Adicionar uma linha a uma tabela predecessora do Excel Online estiver marcada como Falha, em vez de Êxito, altere o comportamento "executar após" usando o designer ou o editor de exibição de código.
Nota
No designer, a configuração "executar após" não se aplica à ação que se segue imediatamente ao gatilho, pois o gatilho deve ser executado com êxito antes que a primeira ação possa ser executada.
Alterar o comportamento "executar após" no designer
No portal do Azure, abra o fluxo de trabalho do aplicativo lógico no designer.
No designer, selecione a forma de ação. No painel de detalhes, selecione Executar após.
O painel Executar Depois mostra a ação predecessora para a ação selecionada no momento.
Expanda o nó de ação antecessor para visualizar todos os status "executar depois".
Por padrão, o status "executar após" é definido como bem-sucedido. Portanto, a ação predecessora deve ser executada com êxito antes que a ação selecionada atualmente possa ser executada.
Altere o comportamento "executar após" para o status desejado. Certifique-se de selecionar uma opção antes de desmarcar a opção padrão. Você sempre tem que ter pelo menos uma opção selecionada.
O exemplo a seguir seleciona falhou.
Para especificar que a ação atual é executada se a ação predecessora estiver marcada como Falha, Ignorada ou Tempo Limite, selecione os outros status.
Para exigir que mais de uma ação predecessora seja executada, cada uma com seus próprios status "executar após", expanda a lista Selecionar ações . Selecione as ações predecessoras desejadas e especifique os status necessários de "execução após".
Quando estiver pronto, selecione Concluído.
Alterar o comportamento "executar após" no editor de visualização de código
No portal do Azure, abra o fluxo de trabalho do aplicativo lógico no editor de exibição de código.
Na definição JSON da ação, edite a
runAfterpropriedade, que tem a seguinte sintaxe:"<action-name>": { "inputs": { "<action-specific-inputs>" }, "runAfter": { "<preceding-action>": [ "Succeeded" ] }, "type": "<action-type>" }Neste exemplo, altere a
runAfterpropriedade deSucceededFailedpara :"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" }Para especificar que a ação é executada se a ação predecessora estiver marcada como
Failed,SkippedouTimedOut, 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 em um escopo com falha e executar ações que manipulam esses erros, você pode usar a configuração "executar após" que Escopo 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.
Obtenha contexto e resultados para falhas
Embora a deteção de falhas de um escopo seja útil, você também pode querer mais contexto para ajudá-lo a aprender as ações com falha exatas, além de quaisquer erros ou códigos de status. A result() função retorna os resultados das ações de nível superior em uma ação com escopo. 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.
Nota
A result() função retorna os resultados somente das ações de nível superior e não de ações aninhadas mais profundas, como ações de alternância ou condição.
Para obter contexto sobre as ações que falharam em um escopo, você pode usar a @result() expressão com o nome do escopo e a configuração "executar após". Para filtrar a matriz retornada para ações com status Falha, você pode adicionar a ação Filtrar matriz. Para executar uma ação para uma ação com falha retornada, pegue a matriz filtrada retornada e use um Para cada loop.
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. Segue-se o exemplo de 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:
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')A condição para Filter Array é qualquer
@result()item que tenha um status igual aFailed. 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.Execute uma
For_eachação de loop nas saídas de matriz filtradas. 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_eachloop serão executadas apenas uma vez. Várias ações com falha causam uma ação por falha.Envie um HTTP POST no corpo de resposta do
For_eachitem, que é a@item()['outputs']['body']expressão.A
@result()forma do item é a mesma que a@actions()forma e pode ser analisada da mesma maneira.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 @result() item, mostrando o name, bodye clientTrackingId as propriedades 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. Você também pode incluir outras propriedades úteis da resposta, \@result() conforme descrito anteriormente.
Configurar logs 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 o Azure 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 logs do Azure Monitor e coletar dados de diagnóstico para Aplicativos Lógicos do Azure.