Controlo de Concorrência em Loops Aninhados no Azure Logic Apps (Consumption)

Público-Alvo

O público-alvo deste artigo são Programadores de Azure Logic Apps e Arquitetos de Integração, que estão a utilizar ativamente Azure Logic Apps para automação de workflows e tarefas de integração. Deverão considerar este artigo relevante, pois fornece insights sobre como lidar com loops aninhados de forma eficiente e superar as limitações na execução paralela destes loops aninhados.

Contexto

O Azure Logic Apps é uma poderosa plataforma de automação de workflows que permite criar, agendar e gerir fluxos de trabalho para integrar vários serviços e aplicações. Um cenário comum na automação de workflows é a necessidade de iterar sobre matrizes ou coleções aninhadas, geralmente alcançada utilizando loops aninhados.

No entanto, quando se trata de execução paralela, as iterações em loops aninhados são sempre executadas sequencialmente, não em paralelo. (2)

Isso pode causar gargalos durante a execução, especialmente quando parte do fluxo de trabalho envolve enriquecimento de dados, validações e/ou tratamento de exceções.

As imagens a seguir destacam que o recurso "Controlo de Concorrência" está disponível apenas no nível do loop pai.

A ideia para superar essa limitação é dividir a solução em duas logic apps se estiver a utilizar o modelo Logic App (Consumption).

Cenário de Prova de Conceito

Vamos supor que um sistema local produza lotes de arquivos XML contendo informações sobre a sua carteira de clientes, que precisam ser ingeridos por uma Logic App, passar por procedimentos de enriquecimento de dados e, em seguida, serem digeridos para o Salesforce.

No entanto, as informações contidas nesses arquivos não são suficientes para serem persistidas no Salesforce. Portanto, algums procedimentos adicionais são necessários para enriquecer os dados antes de submetê-los para o Salesforce. Por exemplo:

• Obter os detalhes das contas através de endpoint externo.
• Obter os detalhes dos produtos através de outro endpoint.

Além do enriquecimento de dados, numa solução mais robusta e orientada para empresas, pode ser necessário desacoplar alguns desses workflows, ou talvez implementar uma abordagem de tratamento de erros utilizando o componente de escopo para realizar as seguintes tarefas:

• Compor um log de erro bem formatado como ficheiro blob, e/ou enviar um e-mail para a equipa de suporte.
• Reverter procedimentos anteriores para garantir a consistência dos dados.
• Chamar uma ação personalizada no caso de erros inesperados.

Resultado do Caso de Teste - Abordagem Sequêncial

Para os casos de teste, três arquivos XML foram fornecidos, cada um contendo 500 nós (ou Contas), e seguem o esquema delineado abaixo.

A Logic App (Consumption) named 'logic-pocsequential-dev-001' was created for the first test case scenario (sequential).

Levando em consideração a limitação de 900 chamadas e um período de renovação de 60 segundos imposto pelo Salesforce (3), execução total levou aproximadamente 10 minutos para concluir.

Resultado do Caso de Teste - Abordagem Paralela

Todas as contas criadas no caso de teste anterior foram removidas do Salesforce.

Foram criadas duas instâncias de Logic Apps (Consumption) para alcançar esse objetivo (logic-pocparalleldev-001 e -002). Os mesmos 3 arquivos XML foram fornecidos para este caso de teste.

A lógica de upsert do Salesforce foi então movida para a instância "-002", então, em vez do processamento ser realizado no loop pai, a matriz de todas as contas no arquivo atual é passada no corpo da solicitação para a instância do Logic App "-002".

Seguindo esta abordagem, a execução total foi concluída em cerca de 2 minutos, para os mesmos 1500 registos.

Conclusão

Para este cenário específico, os Programadores podem considerar mesclar os arquivos XML antes de processá-los para evitar esta limitação do loop aninhado. Embora esta possa ser uma opção justa ao lidar com um pequeno conjunto de arquivos, pode tornar-se um pouco mais complexa quando precisa registar e relatar falhas especificando qual o nó que falhou em cada arquivo XML.

Alternativamente, os Programadores podem optar por mudar para o gatilho SFTP "Quando um arquivo é adicionado ou atualizado" e aproveitar o recurso "splitOn" se o momento exato que esses ficheiros devam ser processados não forem necessários ou especificados.

No entanto, o objetivo desta PoC é enfatizar a importância do processamento paralelo e da lógica desacoplada na implementação de workflows. Essas abordagens são consideradas melhores práticas em design de sistema devido à sua capacidade de melhorar o desempenho, escalabilidade e manutenibilidade. O processamento paralelo permite que as tarefas sejam executadas simultaneamente, reduzindo o tempo de processamento e melhorando a eficiência. A lógica desacoplada divide sistemas complexos em módulos independentes, promovendo a modularidade e a facilidade de manutenção. Juntos, permitem que os sistemas lidem com cargas de trabalho crescentes, adaptem-se à mudança e mantenham altos níveis de confiabilidade.

por Maxwell Francisco, Azure Developer na Luza