Erros e execução condicional
APLICA-SE A: 
Azure Data Factory Azure Synapse Analytics
Gorjeta
Experimente o Data Factory no Microsoft Fabric, uma solução de análise tudo-em-um para empresas. O Microsoft Fabric abrange tudo, desde a movimentação de dados até ciência de dados, análises em tempo real, business intelligence e relatórios. Saiba como iniciar uma nova avaliação gratuitamente!
Caminhos condicionais
A orquestração do Azure Data Factory e do Synapse Pipeline permite a lógica condicional e permite que o usuário siga um caminho diferente com base nos resultados de uma atividade anterior. O uso de caminhos diferentes permite que os usuários criem pipelines robustos e incorpora o tratamento de erros na lógica ETL/ELT. No total, permitimos quatro caminhos condicionais,
| Nome | Explicação |
|---|---|
| Após Êxito | (Passe padrão) Execute este caminho se a atividade atual for bem-sucedida |
| Após Falha | Execute este caminho se a atividade atual falhar |
| Após Conclusão | Execute este caminho após a conclusão da atividade atual, independentemente de ter sido bem-sucedida ou não |
| Após o Skip | Execute esse caminho se a atividade em si não tiver sido executada |
Você pode adicionar várias ramificações após uma atividade, com uma exceção: o caminho Após a conclusão não pode coexistir com o caminho Após o sucesso ou Após a falha . Para cada execução de pipeline, no máximo um caminho é ativado, com base no resultado da execução da atividade.
Processamento de Erros
Mecanismo comum de tratamento de erros
Experimente o bloco Catch
Nessa abordagem, o cliente define a lógica de negócios e define apenas o caminho Upon Failure para detetar qualquer erro da atividade anterior. Essa abordagem renderiza o pipeline com êxito, se o caminho Upon Failure for bem-sucedido.
Bloquear Do If Else
Nessa abordagem, o cliente define a lógica de negócios e define os caminhos Upon Failure e Upon Success . Essa abordagem processa falhas de pipeline, mesmo se o caminho Upon Failure for bem-sucedido.
Do If Skip Else bloco
Nessa abordagem, o cliente define a lógica de negócios e define o caminho Upon Failure e Upon Success, com uma atividade fictícia Upon Skipped anexada. Essa abordagem renderiza o pipeline com êxito, se o caminho Upon Failure for bem-sucedido.
Quadro-resumo
| Abordagem | Define | Quando a atividade é bem-sucedida, o pipeline geral é exibido | Quando a atividade falha, o pipeline geral mostra |
|---|---|---|---|
| Try-Catch | Somente no caminho de falha | Com êxito | Com êxito |
| Do-If-Else | Caminho do Fracasso + Caminho do Sucesso | Com êxito | Falha |
| Do-If-Skip-Else | Caminho do Fracasso + Caminho do Sucesso (com um Dummy Upon Skip no final) | Com êxito | Com êxito |
Como a falha do pipeline é determinada
Diferentes mecanismos de tratamento de erros levam a um status diferente para o pipeline: enquanto alguns pipelines falham, outros são bem-sucedidos. Determinamos o sucesso e as falhas do pipeline da seguinte forma:
- Avalie o resultado de todas as atividades de licenças. Se uma atividade foliar foi ignorada, avaliamos sua atividade pai
- O resultado do pipeline é bem-sucedido se e somente se todos os nós avaliados forem bem-sucedidos
Assumindo que a atividade Upon Failure e a atividade Dummy Upon Failure são bem-sucedidas,
Na abordagem Try-Catch ,
- Quando a atividade anterior é bem-sucedida: o nó Upon Failure é ignorado e o nó pai é bem-sucedido;
- Quando a atividade anterior falha: o nó Upon Failure é acionado; o pipeline geral é bem-sucedido
Na abordagem Do-If-Else ,
- Quando a atividade anterior é bem-sucedida: o nó Upon Success é bem-sucedido e o nó Upon Failure é ignorado (e seu nó pai é bem-sucedido);
- Quando a atividade anterior falha: o nó Upon Success é ignorado e o nó pai falha;
Na abordagem Do-If-Skip-Else ,
- Quando a atividade anterior é bem-sucedida: o nó Dummy Upon Skip é ignorado e seu nó pai Upon Success é bem-sucedido, a outra atividade do nó, Upon Failure, é ignorada e seu nó pai é bem-sucedido
- Quando a atividade anterior falha: o nó Upon Failure é bem-sucedido e o Dummy Upon Skip é bem-sucedido;
Execução condicional
À medida que desenvolvemos pipelines mais complicados e resilientes, às vezes é necessário introduzir execuções condicionais em nossa lógica: executar uma determinada atividade somente se certas condições forem atendidas. Os casos de uso são muitos, por exemplo:
- executar uma atividade de acompanhamento, como enviar uma notificação por e-mail, se trabalhos de cópia anteriores forem bem-sucedidos
- Executar um trabalho de tratamento de erros, se alguma das atividades anteriores falhar
- Prossiga para a próxima etapa se a atividade em si ou sua atividade de tratamento de erros correspondente for bem-sucedida
- etc.
Aqui explicamos algumas lógicas comuns e como implementá-las no ADF.
Atividade única
Aqui estão alguns padrões comuns após uma única atividade. Podemos usar esses padrões como blocos de construção para construir fluxos de trabalho complicados.
Processamento de erros
O padrão é a lógica de condição mais comum no ADF. Uma atividade de tratamento de erros é definida para o caminho "Upon Failure" e será invocada se a atividade principal falhar. Deve ser incorporado como prática recomendada para todas as etapas de missão crítica que necessitem de alternativas alternativas de recurso ou registro.
Melhores passos de esforço
Certas etapas, como o registro em log informativo, são menos críticas, e suas falhas não devem bloquear todo o pipeline. Nesses casos, devemos adotar as melhores estratégias de esforço: adicionar os próximos passos ao caminho "Após a conclusão", para desbloquear o fluxo de trabalho.
And
O primeiro e mais comum cenários são condicionais "e": continuar o pipeline se e somente se as atividades anteriores forem bem-sucedidas. Por exemplo, você pode ter várias atividades de cópia que precisam ser bem-sucedidas primeiro antes de passar para o próximo estágio de processamento de dados. No ADF, o comportamento pode ser alcançado facilmente: declarar várias dependências para a próxima etapa. Graficamente, isso significa várias linhas apontando para a próxima atividade. Você pode escolher o caminho "Após o sucesso" para garantir que a dependência tenha sido bem-sucedida ou o caminho "Após a conclusão" para permitir a melhor execução do esforço.
Aqui, a atividade de espera de acompanhamento só será executada quando ambas as atividades da Web forem bem-sucedidas.
E aqui, a atividade de espera de acompanhamento é executada quando ActivitySucceeded passa e ActivityFailed é concluído. Observe que, com o caminho "Upon Success", ActivitySucceeded , tem que ser bem-sucedido, enquanto ActivityFailed no caminho "Upon Completion" é executado com o melhor esforço, ou seja, pode falhar.
Ou
Os segundos cenários comuns são condicionais "ou": execute uma atividade se qualquer uma das dependências for bem-sucedida ou falhar. Aqui precisamos usar os caminhos "Após a conclusão", a atividade If Condition e a linguagem de expressão.
Antes de nos aprofundarmos no código, precisamos entender mais uma coisa. Depois que uma atividade for executada e concluída, você poderá fazer referência ao seu status com @activity('ActivityName'). Estado. É "Succeeded"_ ou "Failed". Usamos esta propriedade para construir condicional ou lógica.
Etapa de registro de tratamento de erros compartilhados
Em alguns casos, convém invocar uma etapa de tratamento de erros ou registro em log compartilhada, se alguma das atividades anteriores falhar. Você pode construir seu pipeline assim:
- executar várias atividades em paralelo
- adicionar uma condição if para conter as etapas de tratamento de erros, na ramificação True
- conectar atividades à atividade de condição usando o caminho "Após a conclusão"
- expressão lógica para leituras de atividade de condição
@or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded').Status, 'Failed'))
- Nota: você precisa concatenado ou se você tiver mais de duas atividades de dependência, por exemplo,
@or(or(equals(activity('ActivityFailed').Status, 'Failed'), equals(activity('ActivitySucceeded1').Status, 'Failed')),equals(activity('ActivitySucceeded1').Status, 'Failed'))
Luz verde se alguma atividade for bem-sucedida
Quando todas as suas atividades forem o melhor esforço, você pode querer prosseguir para a próxima etapa se alguma das atividades anteriores tiver sido bem-sucedida. Você pode construir seu pipeline assim:
- executar várias atividades em paralelo
- adicionar uma condição if para conter as próximas etapas, na ramificação True
- conectar atividades à atividade de condição usando o caminho "Após a conclusão"
- expressão lógica para leituras de atividade de condição
@or(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
- Nota: o gráfico se parece exatamente com o cenário anterior. A única diferença é a linguagem de expressão utilizada
Cenários complexos
Todas as atividades precisam ser bem-sucedidas para prosseguir
O padrão é uma combinação de dois: manipulação de erros condicionais e +. O pipeline prossegue para as próximas etapas se todas as atividades em andamento forem bem-sucedidas, ou então ele executa uma etapa de log de erros compartilhados. Você pode construir o pipeline assim:
- executar várias atividades em paralelo
- Adicione uma condição if. Adicione as próximas etapas na ramificação True e adicione o código de tratamento de erros na ramificação False
- conectar atividades à atividade de condição usando o caminho "Após a conclusão"
- expressão lógica para leituras de atividade de condição
@and(equals(activity('ActivityFailed').Status, 'Succeeded'), equals(activity('ActivitySucceeded').Status, 'Succeeded'))
Padrões comuns
Try-Catch-Proceed
O padrão é equivalente a tentar catch block na codificação. Uma atividade pode falhar em um pipeline. Quando falha, o cliente precisa executar um trabalho de tratamento de erros para lidar com isso. No entanto, a falha de atividade única não deve bloquear as próximas atividades no pipeline. Por exemplo, tento executar um trabalho de cópia, movendo arquivos para o armazenamento. No entanto, pode falhar a meio do caminho. E, nesse caso, quero excluir os arquivos parcialmente copiados e não confiáveis da conta de armazenamento (minha etapa de tratamento de erros). Mas não tenho problema em prosseguir com outras atividades depois.
Para configurar o padrão:
- Adicionar primeira atividade
- Adicionar tratamento de erros ao caminho UponFailure
- Adicionar segunda atividade, mas não se conectar à primeira atividade
- Conecte os caminhos UponFailure e UponSkip da atividade de tratamento de erros à segunda atividade
Nota
Cada caminho (UponSuccess, UponFailure e UponSkip) pode apontar para qualquer atividade. Vários caminhos podem apontar para a mesma atividade. Por exemplo, UponSuccess e UponSkip podem apontar para uma atividade, enquanto UponFailure aponta para uma diferente.
O trabalho de Tratamento de Erros é executado somente quando a Primeira Atividade falha. A próxima atividade será executada independentemente de a primeira atividade ser bem-sucedida ou não.
Tratamento genérico de erros
Comumente, temos várias atividades em execução sequencialmente no pipeline. Se algum falhar, preciso executar um trabalho de tratamento de erros para limpar o estado e/ou registrar o erro. Por exemplo, tenho atividades de cópia sequencial no pipeline. Se algum deles falhar, preciso executar um trabalho de script para registrar a falha do pipeline.
Para configurar o padrão:
- Crie um pipeline de processamento de dados sequencial
- Adicionar etapa genérica de tratamento de erros ao final do pipeline
- Conecte os caminhos UponFailure e UponSkip da última atividade à atividade de tratamento de erros
A última etapa, Tratamento Genérico de Erros, só será executada se alguma das atividades anteriores falhar. Não correrá se todos tiverem sucesso.
Você pode adicionar várias atividades para tratamento de erros.
