Trex Pi
Si abasteces a una gran cadena minorista o a un grupo automotriz en Europa, trabajas con EDI. No porque a nadie le encante la sintaxis de EDIFACT, sino porque la parte con el departamento de compras más grande elige el formato, y su formato se estandarizó en 1988. Esperar a que ofrezcan una API REST no es una estrategia.
Cómo es realmente una configuración de EDI moderna
El truco es tratar el EDI como un dialecto de transporte, no como una arquitectura. Dentro de la integración, todo es un objeto de pedido/expedición/factura sencillo y bien tipado; EDIFACT y X12 existen solo en el extremo, en traductores que son aburridos, versionados y probados exhaustivamente con archivos de ejemplo grabados.
Esa separación da sus frutos de tres maneras:
- Incorporar un nuevo socio comercial significa un nuevo perfil de traductor - versión del mensaje, particularidades de los segmentos, su uso creativo de los campos de texto libre - no nueva lógica de negocio.
- Las pruebas son reproducibles. Cada archivo recibido de un socio a lo largo de los años sirve como ejemplo de prueba grabado. Cuando un traductor cambia, volvemos a ejecutar cinco años de tráfico a través de él y comparamos la salida.
- El ERP de 20 años de antigüedad y la tienda online recién estrenada ven el mismo objeto de pedido, de modo que los pedidos por EDI y los pedidos por API fluyen a través de un único pipeline con un único conjunto de reglas.
Las partes poco vistosas que importan
Los acuses de recibo son la mitad del protocolo. Un socio que no recibe su mensaje CONTRL dentro de su ventana asumirá que el pedido desapareció y llamará a tu equipo de ventas. Monitoriza la latencia de los acuses de recibo igual que monitorizas el uptime - es la métrica que realmente experimenta el administrativo de compras de tu cliente.
El EDI no es deuda técnica. Es infraestructura - como el ancho de vía. No te libras de él a base de modernización; se construyen adaptadores limpios y se le deja seguir haciendo lo que ha hecho de forma fiable durante cuatro décadas.