Pular para o conteúdo principal

Editor no-code de pipelines

O painel web (/dashboard/pipelines) permite que administradores montem e ajustem os pipelines da engine sem código e acompanhem as execuções. Decisão em ADR-022 (E-6.4). Requer a permissão pipeline:read (edição/execução usam pipeline:write/pipeline:run na API).

Lista de pipelines​

Tabela por trigger/key com nº de nós, versão e estado. Ações:

  • Novo pipeline — informe nome, trigger e key; o pipeline nasce com um nó start e abre direto no editor. O trigger é um campo livre (não uma lista fechada), com sugestões clicáveis montadas a partir dos gatilhos do SFA (order.pre, order.post, webhook.received), dos webhooks de entrada cadastrados (webhook.<eventType>) e dos gatilhos já usados por outros pipelines. Também valem event.<Tipo> (qualquer evento de domínio, inclusive os emitidos por outro pipeline no nó emit-event) e nomes próprios combinados com o sistema externo — ex.: erp.order.created. Ver a convenção em engine. Escolha com cuidado: o trigger é imutável depois de criado.
  • Habilitar/Desabilitar — clique no selo de estado (só pipelines habilitados rodam no trigger).
  • Excluir — remove o pipeline e seu histórico de execuções.

Editor​

O editor (/dashboard/pipelines/[id]) tem quatro áreas:

  1. Configurações — nome, descrição, habilitado. O trigger e a key são imutáveis após a criação (o histórico preserva a versão usada).
  2. Nós — cada nó tem id, type (dos tipos conhecidos), name, política onError (abort/continue/branch) e a configuração em campos tipados: o editor mostra só os parâmetros válidos do tipo do nó (ex.: validate tem um construtor de condições; transform uma lista de definições; http-request método/URL/headers/body). A config gerada é correta por construção — o usuário não sai do escopo do handler.
  3. Arestas — ligam nós numa frase legível: "se o nó [X] tiver o status [sucesso/erro/…] vá para o nó [Z]". As opções de status vêm do nó de origem: um if oferece se sim / senão, um switch oferece os casos que você nomeou + padrão. Um preview do grafo (read-only) mostra o fluxo resultante.

Nós que ramificam (if / switch)​

O cartão de um if ou switch no canvas tem uma porta por saída, nomeada e colorida — se sim (verde) / senão (âmbar) no if; um caso por linha (violeta) + padrão (cinza) no switch. Arraste a bolinha da saída até o próximo passo: a aresta já nasce com aquele rótulo, sem precisar abrir a lista de arestas para corrigir depois. O cartão cresce conforme o número de casos, e a cor da linha no canvas é a da saída de onde ela sai.

No switch, a ordem dos casos importa (vence o primeiro que casar) — use as setas ↑↓ do formulário para reordenar. Nomes repetidos são sinalizados: duas saídas com o mesmo rótulo deixariam a aresta ambígua. 4. Salvar — grava a definição; cada alteração incrementa a versão. Erros de estrutura (validateDefinition: tipo desconhecido, aresta órfã, sem nó inicial…) aparecem em toast.

Predicados de validate com composição aninhada (not, all+any combinados) que o construtor simples não representa caem num campo JSON avançado só para aquele predicado — o resto continua em campos tipados.

Testar​

O painel Testar roda a versão persistida (salve antes) com um input de amostra (JSON) via POST /pipelines/:id/test e mostra o trace por step: status, branch seguido, duração, erro e a saída/logs de cada nó. Motivos de rejeição (ex.: validate que aborta) aparecem destacados.

Histórico de execução​

Lista as execuções recentes (GET /pipelines/:id/executions) com o mesmo trace expansível por step — a fonte das métricas de desempenho exigidas pelo escopo. Inclui as execuções reais disparadas por order.pre/order.post/webhook.received, não só os testes.

Exemplo de uso​

  1. Crie um pipeline order.pre chamado "Valor mínimo".
  2. Adicione um nó validate com config: 
    { "conditions": { "field": "order.totalAmount", "op": "gte", "value": 100 },
      "message": "Pedido abaixo do mínimo de R$100" }
  3. Ligue start → (validate) e salve.
  4. Em Testar, rode com { "order": { "totalAmount": 80 } } → o trace mostra o validate falhando e o motivo. Com 120, passa.
  5. Habilite o pipeline: a partir daí todo POST /orders da organização passa por ele.