Skip to main content
Operações financeiras envolvem múltiplas etapas, aprovações e verificações externas. Quando você escreve lógica personalizada para cada fluxo, as mesmas regras se espalham pelos seus serviços, e erros, atrasos e lacunas de compliance aparecem. O Flowker mantém essa lógica em um só lugar. Você define o processo uma vez como um grafo de nós e arestas, e o Flowker o executa da mesma forma todas as vezes. O seu fornecedor de antifraude, o seu serviço de KYC, o Tracer, e o ledger Midaz são nós nesse grafo. O campo stepResults contém uma entrada para cada nó executor, condicional ou de ação executado, em ordem. As entradas registram status e duração, podem incluir saída, e as etapas com falha podem incluir errorMessage. Nós de gatilho não criam registro de etapa.

​
O que você recebe

Flowker

A plataforma de orquestração de workflows. Ela coordena as etapas em torno de uma transação: verificações antifraude, chamadas para sistemas externos de aprovação, roteamento de pagamentos e onboarding de clientes.

Midaz e Tracer como provedores

O catálogo registra o Midaz como o provedor ledger e o Tracer como o provedor tracer, ambos sintetizados a partir das suas especificações OpenAPI. Um nó de workflow chama as operações deles.

Console

O módulo Flowker. Operadores criam e editam workflows, configuram provedores, e monitoram execuções.

Access Manager

Com PLUGIN_AUTH_ENABLED=true, toda chamada a um gatilho de webhook exige um bearer token, e quem chama precisa da permissão execute no recurso webhooks.

​
Como as peças se encaixam

  1. Uma chamada de webhook ou um agendamento inicia uma execução. Apenas um workflow ativo registra cada combinação de caminho e método.
  2. Nós executores chamam os seus serviços através de configurações de provedor.
  3. Um nó condicional avalia a sua condição e retorna um resultado nomeado. O Flowker segue a aresta de saída que carrega esse nome.
  4. Um nó tracer pede uma decisão ao Tracer. Um nó ledger chama o Midaz. Os dois provedores aparecem quando o registro de schema nativo está configurado e a síntese é bem-sucedida.
  5. O campo stepResults contém uma entrada para cada nó executor, condicional ou de ação executado, em ordem. As entradas registram status e duração, podem incluir saída, e as etapas com falha podem incluir errorMessage. Nós de gatilho não criam registro de etapa.
  6. Operadores leem a execução no módulo Flowker do Console.
O Flowker tenta novamente uma chamada de executor que falha por um erro transitório. Por padrão, ele não tenta novamente um POST nem um PATCH. Um circuit breaker protege cada provedor. Ele abre depois de 20 falhas consecutivas, espera 30 segundos, e então permite uma requisição para testar o serviço. O Flowker orquestra as verificações que vêm antes de uma etapa de lançamento no ledger. Ele não fiscaliza a fronteira no próprio ledger. A sua integração de ledger deve garantir que nenhum outro caminho lance sem as verificações exigidas.

​
O que cada peça possui

​
Adote uma peça de cada vez

1

Comece com os seus próprios serviços

Crie uma configuração de provedor para cada instância de serviço que você chama. Ela guarda a URL base, as credenciais, e os hosts públicos que a conexão pode alcançar. O conector HTTP genérico rejeita uma lista allowedHosts vazia.
2

Adicione os provedores nativos

Defina MIDAZ_BASE_URL e TRACER_BASE_URL no deploy. Um OPENAPI_NATIVE_PROVIDERS vazio torna todo provedor nativo elegível para síntese. Uma lista não vazia restringe a elegibilidade aos ids que você nomear.
3

Coloque o acesso a webhooks sob o Access Manager

Com PLUGIN_AUTH_ENABLED=true, toda requisição a um caminho de webhook precisa de um bearer token, e quem chama precisa de execute em webhooks. Conceda essa permissão a uma identidade machine-to-machine para cada sistema que você deixa chamar os seus webhooks.
4

Habilite o módulo do Console e exporte telemetria

Habilite o módulo Flowker no Console, onde os operadores leem workflows e execuções. Defina ENABLE_TELEMETRY=true e um endpoint OTLP para exportar telemetria para o seu próprio coletor.

​
Traga o seu

  • Qualquer ledger. O Flowker chama o Midaz ou outro ledger através de uma configuração de provedor. Ele não exige nenhum ledger específico.
  • Os seus fornecedores de KYC, AML e antifraude. O conector HTTP genérico os chama sobre os hosts públicos que você lista na conexão.
  • A sua própria API. Faça upload do documento OpenAPI dela para o registro de schema. Aponte uma configuração de provedor para esse documento. Um nó então chama uma operação da sua API.
  • Os seus gatilhos. Você registra um caminho de webhook, ou define uma cadência cron com o fuso horário que você nomear.
  • O seu backend de observabilidade. Quando você habilita a telemetria, o Flowker emite dados OpenTelemetry das suas operações HTTP e de serviço para o coletor que você roda.

​
Um exemplo prático

O catálogo traz um template que valida uma transação através do Tracer e a cria no Midaz quando o Tracer aprova. Este exemplo adiciona uma verificação de KYC na frente desse par.
  1. O seu serviço de pagamento envia a requisição para o caminho de webhook que o workflow registra.
  2. Um nó executor chama o seu serviço de KYC através da configuração de provedor dele.
  3. Um nó condicional lê o resultado do KYC e encaminha uma verificação com falha para um caminho de rejeição.
  4. Um nó executor envia o payload para o Tracer através do provedor tracer.
  5. Quando o Tracer aprova a transação, um nó ledger a cria no Midaz.
  6. O webhook responde ao seu serviço no modo de resposta que você escolheu. O padrão retorna um recibo 202, e sync espera pelo resultado.

​
Comece aqui

O que é o Flowker?

Leia o que a plataforma coordena, e os registros que ela mantém de cada execução.

Primeiros passos com o Flowker

Configure o Flowker e rode o seu primeiro workflow de ponta a ponta.

Conceitos principais

Aprenda workflows, nós, arestas, o catálogo, configurações de provedor, e execuções.