Boas práticas para tratamento de erros em pipelines
Entenda como implementar um tratamento de erros eficiente no seu pipeline e aumentar a confiabilidade das integrações.
Atualizado
Isto foi útil?
Entenda como implementar um tratamento de erros eficiente no seu pipeline e aumentar a confiabilidade das integrações.
Atualizado
Isto foi útil?
O tratamento adequado de erros é essencial para garantir a estabilidade, previsibilidade e confiabilidade das integrações construídas na Digibee Integration Platform. Sem uma gestão eficaz de falhas, os pipelines podem apresentar comportamentos inesperados, dificultando a manutenção e impactando processos críticos. Neste artigo, exploramos boas práticas para lidar com erros de forma eficiente.
Essa opção está disponível nas configurações da maioria dos conectores da Plataforma. Quando ativada, a execução do pipeline é interrompida. Em conectores que utilizam , uma exceção é enviada para o fluxo do OnException.
O está presente em alguns conectores com subfluxos, como , e , e desempenha um papel importante na captura de falhas controladas. Ele permite centralizar o tratamento de erros em um ponto do pipeline, facilitando ajustes posteriores, análises e até novas inclusões no fluxo de erro, evitando a repetição da lógica ao longo do pipeline.
O OnException de conectores de loop, como o For Each, não interrompe a execução do loop. Isso permite compilar ou unificar todas as exceções que ocorrerem durante sua execução, possibilitando o tratamento após o término do loop. Mais informações estão disponíveis na .
Uma prática recomendada é armazenar um resumo dos erros na memória do pipeline para exibição posterior, utilizando a cápsula Add item to session (array). Essa cápsula insere os registros em um array chamado resultList, que pode ser recuperado posteriormente.
É necessário incluir um objeto JSON no payload para adicionar corretamente um item ao array:
O timeout do trigger deve ser maior do que a soma dos timeouts de todos os conectores externos. Isso garante que o pipeline tenha tempo suficiente para tratar possíveis falhas antes de ser encerrado.
Se os conectores externos tiverem timeouts longos e o trigger tiver um valor inferior, o pipeline poderá ser finalizado antes da conclusão das requisições, gerando inconsistências e dificultando a identificação de erros.
Calcule a soma dos timeouts dos conectores externos e adicione uma margem de segurança ao timeout do trigger.
Evite valores excessivamente altos, pois isso pode comprometer o desempenho da plataforma.
Considere os processos internos do pipeline, como transformações e tratamento de erros, ao definir o timeout do trigger.
Monitore regularmente o tempo de execução dos conectores e ajuste os timeouts conforme necessário.
Considere as seguintes práticas:
Ativar a opção Fail On Error nos conectores que acessam o Object Store, para capturar falhas automaticamente.
Monitorar acessos simultâneos ao Object Store, evitando sobrecarga e falhas por concorrência.
Se um pipeline realiza leitura no Object Store para, em seguida, atualizar os dados, um erro pode ocorrer caso outro processo modifique ou remova esses dados antes da atualização. Para mitigar esse risco, recomenda-se:
Verificar os dados após a leitura, garantindo que ainda estão disponíveis.
Essas práticas ajudam a minimizar falhas e aumentam a confiabilidade nas interações com o Object Store.
Recomendação: Para garantir que o Retry continue suas tentativas até atingir o limite configurado, evite usar o conector Throw Error no OnException. Assim, o pipeline poderá seguir com as execuções restantes antes de falhar completamente.
Por exemplo, com dois servidores e timeout de 30 segundos:
A primeira tentativa utilizará 30 segundos para conectar-se ao primeiro servidor.
Caso falhe, o conector tentará o segundo servidor, aplicando novamente 30 segundos.
O gerenciamento de conexões deve estar alinhado às necessidades do fluxo de integração. Configurações inadequadas podem resultar em:
Excesso de conexões abertas, afetando o desempenho do banco e do pipeline.
Uso desnecessário de recursos, comprometendo a escalabilidade e a estabilidade.
Revisar e ajustar os parâmetros de conexão pode melhorar o desempenho do pipeline e reduzir o impacto no banco de dados. Os principais parâmetros incluem:
Pool Size By Actual Consumers – Define o tamanho do pool com base no número de consumidores reais.
Exclusive DB Pool – Indica se o pipeline terá um pool exclusivo.
Custom Pool – Permite definir um pool personalizado.
Keep Connection – Mantém a conexão ativa entre execuções, o que pode impactar o uso de recursos.
Para fluxos com alto volume de operações, revisar essas configurações é essencial para garantir performance e evitar sobrecarga.
A gestão adequada de erros na Digibee Integration Platform é essencial para garantir a estabilidade e a eficiência das integrações. Como vimos ao longo do artigo, é importante:
Configurar corretamente os conectores Fail On Error e OnException.
Entender os comportamentos específicos dos conectores Retry e DB V2.
Definir timeouts apropriados para conectores externos, alinhando-os com o trigger.
Adotar validações em fluxos concorrentes com Object Store, evitando inconsistências.
A aplicação dessas boas práticas torna o pipeline mais resiliente, facilitando a detecção e resolução de problemas. Além disso, recomenda-se revisar periodicamente as configurações e estratégias de tratamento de erros, acompanhando a evolução dos processos de integração.
Com uma abordagem estruturada, é possível garantir que as soluções desenvolvidas na Digibee sejam robustas, confiáveis e escaláveis.
Caso a cápsula não esteja disponível, também é possível realizar essa ação diretamente no pipeline utilizando outros conectores, como o e :
Essa abordagem deve ser usada com cautela, pois o consumo de memória aumenta conforme os registros são adicionados ao array. Em casos de grandes volumes de iteração, recomenda-se utilizar o com o parâmetro Isolated ativado, por ser uma alternativa mais adequada.
Ao configurar um pipeline, é fundamental considerar o tempo limite (timeout) dos conectores de conexão externa (, , , ) em relação ao timeout definido no trigger.
Por exemplo, se um pipeline tiver três conectores , cada um com timeout de 30 segundos, o tempo total de execução pode chegar a 90 segundos. Caso o trigger esteja configurado com um timeout inferior a esse valor, o pipeline será encerrado antes que os conectores finalizem suas execuções.
Quando um pipeline realiza múltiplas operações CRUD (Create, Read, Update, Delete) em uma coleção do , especialmente de forma simultânea entre diferentes fluxos, é fundamental seguir boas práticas para evitar inconsistências e falhas inesperadas.
Implementar validações após cada operação, usando os conectores ou , para garantir que os dados foram corretamente manipulados.
Utilizar o conector para validar a presença dos dados esperados.
Aplicar o conector para definir rotas alternativas caso os dados tenham sido alterados ou removidos.
O conector Retry possui regras próprias para o tratamento de erros, descritas . É importante compreender o comportamento dos blocos OnProcess e OnException no contexto do Retry.
Se o OnProcess contém um conector ou está com o parâmetro Fail On Error ativado, e se o OnException também inclui um Throw Error, o Retry encerrará imediatamente suas tentativas, mesmo que ainda haja execuções pendentes.
Quando a string de conexão do conector inclui dois ou mais servidores, o timeout definido no campo Custom Connection Properties é aplicado individualmente a cada servidor.
