Na segunda parte desta série, aprofundamos a implementação da camada de inteligência artificial nos workflows de destino. Enquanto a Parte 1 focou na fundação da integração (RFC, plumbing e propagação de erros), aqui o foco é a lógica de agentes: como desenhá-los para não apenas gerar texto, mas produzir artefatos de dados estruturados e rastreáveis.
Para empresas brasileiras com grandes ambientes legados, a transição para integrações baseadas em agentes é um movimento estratégico para reduzir o esforço manual de tratamento de erros. A chave aqui é o determinismo.
1. Design do Loop de Agentes em Logic Apps
Em vez de tratar o LLM como uma "caixa preta" capaz de improvisar, utilizamos uma abordagem estruturada. O, Data Validation Agent atua dentro do workflow de destino, recebendo o payload normalizado do SAP e validando-o contra regras de negócio externas (mantidas no SharePoint para facilitar a gestão).
2. O Contrato de Ferramentas (Tools)
Os tools no Logic Apps não são apenas nomes, são contratos de execução. O agente é restrito a três ferramentas:
- Get validation rules: Busca as regras no SharePoint via parâmetro, permitindo atualização centralizada sem redeploy do workflow.
- Get CSV payload: Define o dataset exato para processamento, criando uma borda clara entre o estado do workflow e o operacional da IA.
- Summarize CSV payload review: O ponto central onde o agente "trabalha". Aqui, forçamos o modelo a entregar três outputs tipados: um sumário HTML (para e-mail), um CSV de
InvalidOrderIds(para processamento lógico) e uma payload CSV filtrada (para remediação).
3. Fases de Análise e Persistência
Após o loop de validação, entramos na fase de análise, utilizando um segundo chamado de modelo. A separação entre validação (estrita e binária) e análise (qualitativa e de tendência) evita que o consumo de tokens pela IA seja desperdiçado em tarefas fora do escopo.
Para a remediação, quando a validação detecta registros inválidos, o workflow utiliza Z_CREATE_ONLINEORDER_IDOC. Isso garante que o erro não seja apenas "esquecido" no e-mail: ele se torna um artefato durable, ou seja, um IDoc no SAP, permitindo que a equipe de TI atue de forma recorrente e auditável.
Considerações para Engenharia
O grande ganho aqui é a reutilização do padrão. Ao definir parâmetros de saída claros e formatados, você converte a "IA generativa" em pipelines de dados imutáveis e determinísticos. Se o seu ambiente SAP exige alta disponibilidade e tempos de resposta consistentes, a aplicação de modelos de IA deve respeitar contratos rígidos de schema, exatamente como faria com um serviço REST ou um barramento de integração tradicional.
Para o time de engenharia, a lição é clara: não tente fazer a IA entender o contexto de ponta a ponta. Trate-a como um componente de processamento dentro de um orquestrador resiliente (como o Azure Logic Apps), garantindo que ela sempre retorne dados que satisfaçam o seu contrato de integração original.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
