El sistema de despachos que construyeron a medida funcionaba bien. El problema era el viernes en la tarde: alguien exportaba un Excel desde el ERP, otra persona lo cruzaba con los pedidos de la tienda web y una tercera subía la nómina de pagos al portal del banco. Un viernes se subió dos veces el mismo archivo y se pagó dos veces a 14 proveedores.
La integración de sistemas es lo que evita ese viernes. Cuando tu software a medida conversa directamente con el ERP, el e-commerce y el banco, los datos pasan de un lado a otro sin que nadie los copie, y los errores aparecen en un registro en vez de aparecer en la cartola. "Lo conectamos por API" es el comienzo de la conversación. Después hay que elegir un patrón para cada flujo, averiguar qué entrega el proveedor del otro sistema y acordar qué pasa cuando algo falla, porque en algún momento va a fallar.
Los ejemplos que siguen sirven para cualquier ERP. Al final hay un caso concreto con SAP Business One y con JD Edwards sobre AS/400.
Cuatro formas de integrar sistemas
Casi todas las integraciones empresariales caen en uno de estos cuatro patrones. Lo normal es que un mismo proyecto use dos o tres.
| Patrón | Cómo funciona | Cuándo conviene | Qué cuidar |
|---|---|---|---|
| API REST (consulta directa) | Tu software llama al otro sistema y espera la respuesta | Consultar stock o precio en el momento, crear un pedido | Tiempos de respuesta, límites de llamadas, qué hacer si el otro sistema no responde |
| Webhooks | El otro sistema avisa a tu software cuando pasa algo | Un pago aprobado, un pedido nuevo en la tienda | Validar que el aviso es auténtico, recibir el mismo aviso dos veces sin duplicar |
| Colas de mensajes | Los mensajes quedan en una cola intermedia y se procesan cuando el destino puede | Volúmenes altos, sistemas que se caen o tienen ventanas de mantención | Mensajes que fallan una y otra vez, orden de procesamiento |
| Archivos programados | Se genera un archivo (CSV, TXT, XML) y otro proceso lo recoge a una hora fija | Sistemas antiguos sin API, nóminas bancarias, cargas nocturnas | Archivos repetidos o incompletos, quién revisa si el proceso no corrió |
Un archivo nocturno bien controlado es más confiable que una API mal diseñada. La pregunta útil es cuán frescos necesitas los datos. Si el vendedor tiene que ver el stock real mientras cotiza, necesitas una consulta en línea. Si contabilidad revisa las ventas al día siguiente, una carga nocturna alcanza y es más fácil de mantener.
Qué pedirle al proveedor del otro sistema
Antes de estimar, consigue estas respuestas por escrito. Ahorran semanas.
- Documentación de la API, idealmente en formato OpenAPI, y un ambiente de pruebas con datos ficticios.
- El método de autenticación. Lo habitual en integraciones entre servidores es OAuth 2.0 con el flujo de credenciales de cliente (RFC 6749) o una llave de API. Pregunta cómo se rotan las credenciales y quién puede emitirlas.
- Límites de uso: cuántas llamadas por minuto acepta y qué responde cuando los superas. El estándar es el código HTTP 429, a veces con una cabecera que indica cuánto esperar (RFC 6585).
- Si ofrece webhooks, cómo firma los avisos y si los reintenta cuando tu sistema no responde.
- Un contacto técnico. Un correo genérico de soporte no sirve cuando la integración está detenida.
Con los bancos chilenos hay un matiz. El Sistema de Finanzas Abiertas de la Ley Fintec va a estandarizar APIs de información y de iniciación de pagos, pero la CMF postergó su entrada en vigor hasta julio de 2027. Mientras tanto, cada banco tiene su propio canal para empresas (API, formato de archivo para nóminas u otro). Pregunta a tu ejecutivo qué ofrece antes de diseñar nada.
Autenticación y datos en tránsito
Trata la integración como un usuario más, con sus propias reglas.
- Crea una cuenta técnica exclusiva para cada integración, con los permisos mínimos. Si solo crea pedidos, que no pueda anular facturas.
- Guarda las credenciales en un almacén de secretos, nunca en el código ni en un archivo de configuración dentro del repositorio.
- Usa HTTPS siempre, también dentro de la red interna.
- En los webhooks, valida la firma de cada aviso antes de procesarlo. Si el emisor no firma, al menos restringe desde qué direcciones aceptas llamadas.
Si por la integración pasan datos de personas (clientes, trabajadores, proveedores persona natural), considera la Ley 21.719. Su entrada en vigencia sigue fijada para el 1 de diciembre de 2026; el proyecto que la posterga al 15 de octubre de 2027 ya pasó por el Senado, pero sigue en trámite en la Cámara. Para una integración, lo práctico es enviar solo los campos que el otro sistema necesita y dejar registro de qué datos salieron, hacia dónde y cuándo.
Manejo de errores: decide antes qué pasa cuando falla
Una integración que nadie diseñó para fallar termina con alguien revisándola a mano todas las mañanas. Estas reglas conviene acordarlas desde el diseño:
- Reintentos con espera creciente. Si el ERP no responde, espera unos segundos y prueba de nuevo; después espera más. Reintentar de inmediato y sin límite empeora la caída.
- Operaciones idempotentes. Enviar dos veces el mismo pedido o el mismo pago no debe crear dos registros. Se resuelve con un identificador único por operación que el sistema destino revisa antes de crear algo. Esto es lo que habría evitado el pago doble del ejemplo inicial.
- Una bandeja de errores. Los mensajes que fallan varias veces tienen que quedar en un lugar visible, con el motivo, para que una persona los revise y los reenvíe. Si se pierden en un log que nadie lee, te vas a enterar por un cliente.
- Validación en la entrada. Rechaza temprano el RUT mal formado o el producto inexistente, con un mensaje que diga qué campo falló.
Monitoreo: saber que algo falló antes que el cliente
Si nadie monitorea la integración, el primer aviso de una falla suele ser el reclamo de un cliente. Lo mínimo que debería existir:
- Un registro de cada operación, con hora, resultado y un identificador para rastrearla de punta a punta.
- Alertas cuando la tasa de errores sube o cuando un proceso programado no corrió a su hora. Este segundo caso se olvida seguido: el archivo nocturno que no llegó no genera ningún error, simplemente no está.
- Un tablero simple con lo que pasó hoy: cuántos pedidos entraron, cuántos fallaron y cuántos están pendientes.
Caso: SAP Business One y JD Edwards sobre AS/400
En SAP Business One, la vía moderna para integrar es el Service Layer. Según la guía oficial de SAP, es una API basada en HTTP y OData que expone los objetos de negocio de SAP Business One (socios de negocio, artículos, pedidos, facturas) y funciona sobre SAP HANA y también sobre Microsoft SQL Server desde la versión 10.0 PL01. Para un e-commerce, eso permite crear el pedido de venta en el ERP y consultar stock por bodega sin tocar la base de datos. Si estás evaluando qué conviene integrar y qué conviene desarrollar aparte, lo vimos en cuándo desarrollar a medida sobre SAP Business One.
Con JD Edwards sobre AS/400 (hoy IBM i) la gente suele asumir que no hay cómo integrarse. Sí lo hay. IBM i incluye un servidor de servicios web integrado que permite publicar programas ILE, por ejemplo en RPG, como servicios web que otro sistema puede llamar. En muchas empresas la combinación que funciona es mixta: servicios web para consultas en línea (stock, estado de un pedido) y archivos programados para cargas grandes, como el maestro de productos. Si tu JDE necesita mantención antes de integrarse, revisa cómo mantener JD Edwards en AS/400 sin migrar.
En los dos casos, la recomendación es la misma: no escribir directo en las tablas del ERP. Pasar por la capa que el fabricante ofrece mantiene las validaciones del sistema y evita sorpresas en la próxima actualización.
Preguntas frecuentes
¿Cuánto toma una integración de sistemas?
Depende sobre todo de la calidad de la documentación y del ambiente de pruebas del otro sistema. Una integración con una API bien documentada puede estar lista en pocas semanas; una con un sistema antiguo sin API suele tomar más, porque primero hay que definir cómo exponer los datos.
¿Es mejor una API o una carga de archivos?
Si necesitas el dato al instante, una API. Si basta con tenerlo al día siguiente y el volumen es grande, un archivo programado bien controlado suele ser más simple de operar.
¿Quién mantiene la integración después de la puesta en marcha?
Conviene definirlo en el contrato. Las APIs cambian de versión, las credenciales vencen y los sistemas se actualizan. Sin un responsable, la integración se degrada sin que nadie lo note.
Conecta tus sistemas sin el Excel del viernes
En Disrupsoft desarrollamos integraciones a medida entre tus sistemas, plataformas de terceros e interfaces propias, con APIs seguras, SSO/MFA y automatización con Power Automate. Partimos analizando tus sistemas y procesos actuales para elegir el patrón adecuado en cada caso. Si quieres dejar de mover datos a mano, conversemos sobre la integración de tus sistemas.
