Integrações corporativas
A camada que liga sistemas de donos diferentes: ERP, plataformas de terceiro e serviços internos que não foram desenhados para conversar.
O problema
Cada plataforma tem seu vocabulário. O que o ERP chama de documento, o sistema de origem chama de pedido; o que uma plataforma trata como identificador único, a outra trata como texto livre. Integrar não é transportar dado, é traduzir modelo — e decidir o que fazer quando a tradução não é exata.
O que eu construí
- Middleware de tradução entre plataforma de terceiro e domínio interno, isolando a incompatibilidade num lugar só
- ETL de carga entre origens externas e base analítica, com reconciliação e tratamento de reprocesso
- Extração de dado do ERP para os serviços que precisam dele sem falar diretamente com o ERP
- Consulta a fontes externas de dado cadastral e fiscal, com cache e política de falha
- SDK interno para cada integração relevante, para que quem consome não reimplemente o cliente
Decisão que eu defendo
Um middleware por plataforma externa, não um barramento genérico. Barramento único parece economia e vira gargalo: todo time espera a fila do time do barramento, e a incompatibilidade de uma plataforma contamina o modelo comum. Um tradutor dedicado é mais código e menos acoplamento, e quando o terceiro muda a API só um lugar quebra.
Integrações
ERP (SAP) · plataforma de atendimento (Zendesk) · marketing (Emarsys, Oracle Responsys) · CRM (Oracle Service Cloud) · plataformas do fabricante (Apple GSX, DEP, Trade In) · fontes de consulta cadastral e fiscal · Correios
Ver também
Integrações e sistemas distribuídos · Documentação e mapeamento de sistemas · Backend .NET · Dados e persistência