Uma chave, um efeito financeiro
Origem e ID externo formam a chave canônica. Mesmo ID e mesmo hash viram duplicidade segura; hash divergente abre conflito sem alterar o evento original.
← Voltar aos projetos
Projeto demonstrativo 04 / 04
Integração financeira resiliente · REST + Apex
Order-to-Cash Resilience
Uma esteira de eventos financeiros que recebe emissão e liquidação, contém duplicidades e conflitos e recupera eventos fora de ordem sem regredir a projeção do boleto.
Projetos demonstrativos, empresas e dados fictícios. Experiências profissionais reais não são publicadas por confidencialidade.
A solução
Do sinal disperso a um comportamento verificável.
A entrada registra um recibo e um evento canônico imutável. O processamento serializa cada boleto, aplica somente a próxima sequência válida e encaminha divergências para uma fila operacional com ações auditadas.
Arquitetura
O caminho principal dos dados
- 01ERP simulado
- 02REST de ingresso
- 03Inbox canônica
- 04Processador por stream
- 05Boleto + exceções
Decisões centrais
Onde a engenharia realmente aparece
Cada boleto possui sua própria fila
Sequência, lease e retry impedem dois workers de avançarem o mesmo boleto ao mesmo tempo ou aplicarem um evento antes do predecessor.
Falha vira trabalho explicável
Órfãos, conflitos e eventos fora de ordem entram numa fila sanitizada, com permissão por ação e trilha de responsável, motivo e tentativa.
Teste uma sequência financeira imperfeita
Os eventos e resultados são fictícios e processados somente nesta página.
Submissões0
Eventos canônicos0
Efeitos no boleto0
Exceções abertas0
Inbox durável
operacionalEventos recebidos
Aguardando o primeiro evento sintético.
Projeção
Sem registroBoleto VET-1042
- Última sequência aplicada
- —
- Estado externo
- —
- Valor
- R$ 18.400
- Origem
- VETRA_ERP_SIM
streampronto para processar
Operação financeira
Exceções
Nenhuma intervenção necessária.
PRONTO
Comece enviando a emissão do boleto.
Por dentro do projeto
Decisões que não cabem numa captura de tela
Modelo de dados
O evento financeiro é imutável e separado do recibo de cada tentativa. Um stream por boleto controla sequência, lease e retry; Boleto__c continua sendo a projeção compatível com a operação existente.
Mapeamentos de cliente externo para Account possuem vigência e estado próprio. Exceções não guardam o payload bruto na interface: exibem somente detalhe sanitizado e a próxima ação segura.
Recuperação e controle
Configurações de runtime mantêm ingresso, processamento e operação desligados por padrão. Retry usa backoff limitado; lease vencido pode ser recuperado pelo sweeper sem liberar processamento concorrente.
Permission Sets e Custom Permissions separam integração, atendimento, vendas, finanças e manutenção técnica. As telas entregam DTOs adequados a cada papel, sem expor registros técnicos para quem precisa apenas do resumo.
O que a demo prova
A demonstração abaixo reproduz localmente quatro momentos: aceitação, reentrega idempotente, evento fora de ordem e recuperação após a chegada do predecessor. Nenhuma org, ERP ou dado real é acessado.
A release técnica passou pelos testes automatizados e pelo ensaio concorrente em uma scratch org descartável. A validação humana final ainda está pendente; por isso o estudo não apresenta a entrega como promovida para uma org persistente.