Trex Pi
Se fornece um grande retalhista ou grupo automóvel na Europa, usa EDI. Não porque alguém ame a sintaxe do EDIFACT, mas porque a parte com o departamento de compras maior escolhe o formato, e o formato deles foi estandardizado em 1988. Esperar que ofereçam uma API REST não é uma estratégia.
Como é, na realidade, uma configuração de EDI moderna
O truque é tratar o EDI como um dialeto de transporte, não como uma arquitetura. Dentro da integração, tudo é um objeto simples e bem tipado de encomenda/expedição/fatura; o EDIFACT e o X12 existem apenas na periferia, em tradutores que são aborrecidos, versionados e exaustivamente testados com ficheiros de exemplo gravados.
Essa separação compensa de três formas:
- Integrar um novo parceiro comercial significa um novo perfil de tradutor - versão da mensagem, particularidades dos segmentos, o uso criativo que fazem dos campos de texto livre - e não nova lógica de negócio.
- Os testes são reproduzíveis. Cada ficheiro de parceiro alguma vez recebido serve de exemplo de teste gravado. Quando um tradutor muda, voltamos a correr cinco anos de tráfego através dele e comparamos o resultado.
- O ERP com 20 anos e a loja online recém-criada veem o mesmo objeto de encomenda, pelo que as encomendas EDI e as encomendas API fluem através de um único pipeline com um único conjunto de regras.
As partes pouco glamorosas que fazem a diferença
As confirmações (acknowledgements) são metade do protocolo. Um parceiro que não recebe a sua mensagem CONTRL dentro da janela de tempo assumirá que a encomenda desapareceu e telefonará à sua equipa comercial. Monitorize a latência das confirmações da mesma forma que monitoriza o uptime - é a métrica que o funcionário de compras do seu cliente realmente sente.
O EDI não é dívida técnica. É infraestrutura - como a bitola da via férrea. Não é através da modernização que nos livramos dele; constroem-se adaptadores limpos e deixa-se que continue a fazer aquilo que tem feito de forma fiável há quatro décadas.