> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Motor de orquestração > Coordene as verificações e as aprovações em torno de uma transação, com um registro por etapa do que rodou e do que retornou. 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 *** 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. 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. O módulo Flowker. Operadores criam e editam workflows, configuram provedores, e monitoram execuções. 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 *** ```mermaid theme={null} flowchart LR Trigger["Gatilho
sua chamada de webhook ou um agendamento"] Flow["Flowker
um grafo de nós e arestas"] Yours["Seus serviços
KYC, AML, score de fraude"] Tracer["Tracer
allow, deny, ou review"] Midaz["Ledger Midaz
registra a transação"] Console["Console
módulo Flowker"] AM["Access Manager
emite os tokens"] Trigger -->|"inicia uma execução"| Flow Flow -->|"conector HTTP genérico"| Yours Flow -->|"provedor nativo tracer"| Tracer Flow -->|"provedor nativo ledger"| Midaz Console -->|"lê workflows e execuções"| Flow AM -.->|"bearer token, execute em webhooks"| Trigger classDef lerian fill:#fff8e1,stroke:#f4b400,color:#333; classDef yours fill:#e8f0fe,stroke:#4285f4,color:#333; classDef ext fill:#f1f3f4,stroke:#9aa0a6,color:#333; class Flow,Tracer,Midaz,Console,AM lerian; class Trigger,Yours yours; ``` 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 *** | Peça | Fonte de verdade para | Fala com | Você mantém | | ---------------- | ---------------------------------------------------------------------------------- | --------------------------------------------------------- | --------------------------------------------------------------------------------- | | Flowker | definições de workflow, execuções, configurações de provedor, o registro de schema | os seus serviços, o Tracer, o Midaz | a lógica de fluxo em um só lugar | | Tracer | a decisão allow, deny, ou review | um nó executor que o chama | as suas regras e limites de gastos | | Midaz | a transação que ele registra | um nó executor que o chama | o seu ledger. O Flowker não garante que todo lançamento passou pelas verificações | | Access Manager | quem pode executar um gatilho de webhook | o Flowker, em cada rota protegida | os seus usuários e as suas aplicações machine-to-machine | | Console | o registro de execução que um operador lê | o módulo Flowker | um único login para operadores | | Os seus serviços | KYC, AML, score de fraude, aprovações | o conector HTTP genérico, sobre os hosts que você permite | os seus fornecedores e os seus contratos | ## Adote uma peça de cada vez *** 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. 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. 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. 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 *** Leia o que a plataforma coordena, e os registros que ela mantém de cada execução. Configure o Flowker e rode o seu primeiro workflow de ponta a ponta. Aprenda workflows, nós, arestas, o catálogo, configurações de provedor, e execuções.