Orquestrador de Processos — motor de processos de negócio distribuídos, reativo e auditável. Solicitar demonstração →
Início/Produtos/Orquestrador de Processos
Motor reativo · tolerante a falhas · multi-tenant

O motor que executa seus processos de negócio.

Desenhe um processo como um grafo de nós —tarefas, decisões, integrações, esperas— e o Orquestrador de Processos o executa passo a passo, mantendo a rastreabilidade e reagindo às falhas conforme as regras que você declara no próprio diagrama.

studio / processos / pedido-provisionamento · v3 IN_PROGRESS
▶Início
startCOMPLETED
⇄Validar (API)
action · crawlerCOMPLETED
◷Aguardar pagamento
wait · eventoWAITING · ttl 120s
◆Valor > 1000€?
gatewayNEXT
☷Revisão humana
task · caixa de tarefas—
■Fim
end—
!Avisar operação
exception →handled
// Para que serve

Processos que hoje vivem em e-mails, planilhas e scripts dispersos.

O Orquestrador de Processos os transforma em fluxos executáveis, coordenados e auditáveis.

⚙

Automatize fluxos

Trabalho que hoje vai por e-mail, Excel ou scripts soltos, executado de forma confiável e repetível.

⇄

Coordene sistemas

CRMs, ERPs e APIs SaaS orquestrados sem código de cola entre eles.

◷

Aguarde o mundo real

Uma assinatura, um pagamento confirmado, um evento IoT — o fluxo é retomado sozinho quando ele chega.

▤

Audite tudo

Cada passo fica registrado com quem, quando e por quê. Rastreabilidade completa.

↺

Recupere-se de erros

Retentativas automáticas, conectores de exception e TTL — sem perder trabalho.

// Modelo de execução

Quatro entidades. Se você entender isso, tudo se encaixa.

Do desenho que você faz no Studio a cada passo concreto que o motor executa e registra.

DESENHO
ProcessDefinition

O processo que você desenha: nós, conectores, propriedades. Sem estado de execução. Versionado e imutável ao publicar.

→
EXECUÇÃO
ProcessInstance

Uma execução concreta de uma versão. Tem contexto, estado e tempos. Milhares podem rodar ao mesmo tempo, independentes.

→
CURSOR
TokenInstance

O cursor que avança pelo grafo. Divide-se em um fork paralelo e se reúne em um join. Seu estado agrega o da instância.

→
PASSO
NodeInstance

A execução de um nó por um token, com inputs, outputs e tempos. O que você vê no viewer ao inspecionar uma instância.

Motor reativo: o engine não bloqueia threads esperando. O estado vive no banco de dados; as threads são efêmeras — uma única instância sustenta dezenas de milhares de processos em espera ao mesmo tempo.
// Tipos de nó

As primitivas que você realmente precisa em produção.

Um modelo próprio, mais simples que BPMN 2.0 e ao mesmo tempo mais explícito em erros e tempos.

▶start

Inicia a instância. Executa uma única vez.

→ COMPLETED
☷task

Tarefa humana. Cria uma entrada na caixa de tarefas e aguarda que alguém a conclua.

WAITING → COMPLETED
⇄action

Integração externa (HTTP/JDBC/FTP/SaaS). Delega ao crawler.

WAITING → COMPLETED · ERROR_HANDLED
◷wait

Aguarda um evento do mundo real ou um tempo determinado.

WAITING / SCHEDULED → COMPLETED
◆gateway

Decisão, fork ou join. Avalia condições e ramifica o token.

→ COMPLETED
{}script

Executa uma expressão inline para transformar variáveis do contexto.

→ COMPLETED
↻loop

Itera sobre uma coleção até esgotá-la.

→ COMPLETED
■end

Marca um fim e encerra o token.

→ COMPLETED
// Tolerância a erros

O erro não é algo a evitar. É outro ramo do diagrama.

Quando algo falha, o estado fica registrado e o motor busca o ramo de recuperação que você declarou. Nada se perde.

connection
Caminho feliz

Por padrão: é seguido quando o nó termina com sucesso.

exception
Algo falhou

Exceção não tratada ou estado ERROR. O nó fica handled e o token continua por este ramo.

maxRetries
Retentativas esgotadas

Apenas para action: o número máximo de tentativas foi atingido. Envia, por exemplo, para uma fila de revisão humana.

expired
A paciência acabou

Para wait e action: o TTL do nó expirou e o fluxo segue por uma rota alternativa.

"Qualquer falha recuperável deve estar modelada explicitamente no desenho."

Se você modelar, o fluxo se recupera sozinho. Caso contrário, o token fica em erro aguardando intervenção manual — e o operador sempre pode reprocessar qualquer nó a partir do Studio. Uma rede de segurança (DLQ) recolhe o que não é nem interpretável.

ERROR_HANDLED MAX_RETRIES_HANDLED TTL_EXPIRED_HANDLED ERROR TTL_EXPIRED
// TTL e cancelamento

Um limite de paciência por nó.

O TTL não é um timeout para matar trabalhos longos: é a forma de escapar de esperas que ficaram no limbo. Ao expirar, o motor cancela automaticamente o trabalho em andamento.

1
action(ttl=120s)O token entra e fica aguardando o crawler. Registra-se expires_at = now + 120s.
2
watchdog @ 30sA cada 30s busca subscrições expiradas. Detecta que o evento não chegou a tempo.
3
cancel.actionPublica um cancelamento: o job do crawler passa a CANCELLED e deixa de ser retentado.
4
expireFromWaitO token segue o ramo expired se existir; caso contrário, fica em TTL_EXPIRED.
Chamada de API em sistema rápido60–300 s
Espera de resposta humana (e-mail)≈ 1 dia
Evento pouco frequente (mensal)≈ 30 dias
Ação crítica que não pode travarnunca sem TTL

// o TTL conta tempo de parede; max_attempts conta tentativas. São independentes e se combinam.

// Arquitetura

Não um app monolítico: serviços que cooperam por mensageria.

Isolamento de falhas, escalabilidade independente e a linguagem adequada a cada problema. Se o componente que chama um ERP cai, o motor segue e os trabalhos são retentados quando ele volta.

engine Java · Spring

Executa processos: recebe eventos, move tokens, decide ramos e persiste estado.

process-manager repositório

Definições versionadas. Multi-tenant. Apenas o engine lê daqui.

crawler Quarkus · Camel

Executa integrações externas (HTTP/JDBC/FTP) sob demanda do engine.

studio TypeScript · Lit

Desenhar processos, monitorar instâncias e gerenciar tarefas, na web.

⟷   barramento de mensagens · SQS / ElasticMQ — filas FIFO por correlationKey   ⟷
watcher Node.js

Acorda tokens adormecidos por tempo (esperas do tipo "aguardar 2 dias").

listener em design

Recebe webhooks externos e os traduz em eventos para o engine.

db PostgreSQL

Estado durável compartilhado. A verdade do sistema vive aqui.

garantia at-least-once

Entrega ponta a ponta com handlers idempotentes. Efeito equivalente a exactly-once.

// Operar com confiança

Publicar nunca quebra o que já está rodando.

// Versionamento e publicação

Versões imutáveis

Apenas uma versão fica ativa por processo. As instâncias vivas continuam executando a versão com que iniciaram — mudar o grafo em andamento seria uma garantia quebrada.

v1ARCHIVED — histórica, apenas para suas instâncias
v2ARCHIVED — instâncias que a iniciaram continuam nela
v3ACTIVE — a que inicia novas instâncias
// Segurança e auditoria

Bearer JWT sobre OAuth2 / OIDC

Autenticação padrão com provedores de identidade intercambiáveis e isolamento por organização no repositório de processos.

Multi-tenant

Cada organização vê apenas seus processos, pastas e datasources. Isolamento por organization_id.

Identidade intercambiável

Amazon Cognito ou ZITADEL (auto-hospedado), conforme o ambiente.

Rastreabilidade por design

Cada transição de estado fica registrada com tempos, tentativas e erros.

// Low-code, com critério

Visual para 95% do trabalho. Code-light onde faz diferença.

O fluxo é desenhado em um editor visual sem programar o motor. A integração com um sistema novo é modelada uma vez e depois reutilizada.

PERFIL · ANALISTA

Designer de processos

Arrasta, conecta e configura propriedades. Modela o fluxo e os ramos de erro sem escrever código.

100% visual
PERFIL · TI

Integrador

Define um conector YAML (Camel) para cada novo sistema externo. Uma vez por sistema, não por processo.

code-light · 1 YAML/sistema
PERFIL · PLATAFORMA

Desenvolvedor

Estende o engine via plugins (políticas de erro, validação, observação) apenas em casos avançados.

code · casos raros
// Vamos conversar

Ponha seus processos para funcionar.

Mostramos o Orquestrador de Processos com um processo real do seu negócio — e como a consultoria da Wattyo o leva à produção.