Integrar un ERP sin API: los cuatro caminos

Un ERP sin API se puede integrar. Hay cuatro caminos: usar la API o el servicio web si existe (a veces existe y nadie lo ha activado), acceder a su base de datos, intercambiar ficheros, o hacer que sea tu propio sistema el que envíe los datos cuando la seguridad no admite accesos entrantes. Cuál elegir depende de lo que el sistema ofrece hoy, de quién lo mantiene y de si necesitas solo leer o también escribir.

¿Qué significa de verdad que un ERP no tiene API?

Casi nunca significa que el sistema esté cerrado. Suele significar una de tres cosas:

• Tiene una interfaz, pero no está activada, no está licenciada o nadie en la casa sabe que existe.
• Tiene una interfaz, pero no cubre el dato que necesitas (expone pedidos, pero no vencimientos).
• No tiene interfaz programable, pero sí una base de datos debajo y algún proceso de importación y exportación de ficheros.

El tercer caso es el habitual en AS/400, en aplicaciones COBOL y en ERP a medida. En los tres hay camino. Cambian el coste, el riesgo y quién interviene.

Camino 1: la API o el servicio web, cuando existe

Antes de descartarlo, compruébalo. Hay ERP de mercado antiguos con servicios web SOAP que nadie usa. En AS/400, IBM documenta un servidor de servicios web integrado en IBM i que permite exponer programas RPG y COBOL como servicios REST o SOAP, sin reescribirlos.

Conviene siempre que exista y cubra el dato. Es el único camino en el que el fabricante se compromete con un contrato (qué campos, qué formato, qué errores) y en el que las validaciones del ERP se ejecutan al escribir.

Riesgos: cobertura parcial (la API da casi todo y el resto hay que sacarlo por otro lado), costes de licencia que no estaban en el presupuesto y versiones que cambian con cada actualización.

Camino 2: el acceso a la base de datos

Si el ERP guarda sus datos en SQL Server, Oracle, DB2 o PostgreSQL, se pueden leer con una consulta. Es el camino más directo y, mal usado, el más peligroso.

La regla práctica: leer, sí. Escribir directamente en las tablas, casi nunca. La lógica de negocio vive en los programas, no en las tablas. Un registro insertado a mano se salta numeradores y validaciones, y el error aparece semanas después.

Cómo hacerlo con orden:

• Un usuario de solo lectura, limitado a las tablas o vistas necesarias.
• Vistas pactadas con quien mantiene el sistema. La vista actúa como contrato.
• Consultas incrementales y fuera de las horas de cierre.
• Si hay que escribir, tablas intermedias que el propio ERP importa con su proceso estándar.

Riesgos: dependes de un esquema que nadie te garantiza, y una actualización puede cambiarlo sin avisar. Algunos fabricantes condicionan el soporte a que nadie toque la base de datos: lee antes el contrato de mantenimiento.

Camino 3: el intercambio de ficheros

El sistema exporta un fichero, lo deja en una carpeta o en un servidor SFTP, y el otro lado lo recoge. Es el camino más antiguo y el más universal: la banca lo usa a diario con la Norma 43 y los ficheros SEPA.

Conviene cuando el sistema ya exporta e importa ficheros, cuando el dato no necesita moverse al instante y cuando quieres que cada intercambio deje una pieza auditable.

Riesgos, todos evitables:

• Ficheros a medio escribir. Se evita escribiendo con un nombre temporal y renombrando al terminar.
• Duplicados. El mismo fichero procesado dos veces genera dos pagos. Hace falta un identificador por fichero y por registro.
• Codificación, separadores decimales y signos. Un importe con coma donde se esperaba punto.
• Silencio. Un fichero que no llega no da error. Alguien tiene que esperarlo y avisar si falta.
• Sin confirmación. Dejar el fichero no significa que el destino lo haya aceptado.

Los totales de control (número de registros y suma de importes) resuelven buena parte de estos problemas con muy poco esfuerzo.

Camino 4: que sea tu sistema el que envíe

En muchas empresas, la política de seguridad no admite que un proveedor abra conexiones hacia la red interna. Ni VPN, ni puertos abiertos. Es razonable y no impide integrar: se invierte el sentido.

Es tu sistema el que abre una conexión saliente y envía los datos, con una llamada HTTPS o una subida por SFTP a un punto de recepción externo. Exige algo dentro de tu red capaz de extraer y enviar de forma programada: una tarea del planificador del AS/400 o un script en un servidor interno.

Riesgos:

• La pieza que envía es tuya, y su mantenimiento también.
• Los reintentos ocurren en tu lado. Si el envío falla de madrugada, algo tiene que volver a intentarlo.
• El receptor no puede pedir datos, solo esperarlos. Debe saber qué esperar y cuándo, para detectar el silencio.

¿Cómo se elige entre los cuatro?

Con estas preguntas, por este orden:

• ¿Qué ofrece el sistema hoy, sin desarrollar nada? Empieza por ahí.
• ¿Solo lectura o también escritura? Para leer sirve casi todo. Para escribir, API o ficheros por el proceso de importación del ERP.
• ¿Quién mantiene el sistema? Si lo mantiene una sola persona, su tiempo es el recurso escaso: elige el camino que menos le pida.
• ¿Con qué frecuencia necesitas el dato? En tesorería, una o varias cargas al día cubren la mayoría de los procesos.
• ¿Qué dice seguridad? Si no hay accesos entrantes, el camino 4 es el punto de partida.
• ¿Qué pasa cuando falla? Elige el camino en el que el fallo se ve antes.

Combinar es normal: leer por base de datos y escribir por fichero es un patrón frecuente. Y sea cual sea el camino, exige dos cosas: que procesar dos veces el mismo dato no lo duplique, y que se compruebe que el destino lo ha aceptado.

AS/400, COBOL y ERP a medida: lo que suele funcionar

En AS/400 (IBM i), la base de datos DB2 es accesible por ODBC y JDBC, así que la lectura suele resolverse por el camino 2. Hay que vigilar la codificación EBCDIC, los decimales empaquetados, los nombres de campo crípticos y el reparto por bibliotecas cuando cada sociedad tiene la suya.

En aplicaciones COBOL sobre ficheros indexados no hay base de datos relacional que consultar. El camino es el fichero plano, y la definición de registros del programa sirve de contrato.

En un ERP a medida, la base de datos suele ser accesible y el problema es otro: nadie ha escrito qué significa cada campo. La primera tarea es documentarlo con quien lo conoce, antes de que cambie de puesto.

Dónde encaja Rosetta IA de Arjé Partners

Rosetta IA es la plataforma de integración de Arjé Partners: se conecta por API, por servicio web, por base de datos o por fichero. Para el cuarto camino, el diseño prevé que sea tu sistema el que abra la conexión y envíe; esa opción se valora en el diagnóstico. Lo leído se traduce a un modelo de datos común, se valida antes de salir y se entrega comprobando que el destino lo ha aceptado. Las equivalencias se definen una vez y quedan documentadas y versionadas.

La inteligencia artificial se usa para entender la estructura de un sistema desconocido y proponer equivalencias entre campos, siempre con revisión. Los importes y los ficheros que van al banco se calculan con reglas deterministas.

Arjé Partners ha integrado contabilidades que corren sobre AS/400, leyendo de DB2 por JDBC con el controlador de IBM para esa plataforma. Los otros caminos habituales son ODBC y el intercambio de ficheros, y cuál conviene se decide en el diagnóstico.

Los límites: si un sistema no ofrece ninguno de los cuatro caminos, no hay integración posible (la mayoría de los sistemas antiguos ofrecen al menos uno). Se contrata como servicio, con la implantación de los consultores de Arjé Partners. Y el plazo depende del sistema y del proceso: sale de un diagnóstico inicial.

Preguntas frecuentes

¿Se puede integrar un AS/400 con una plataforma de tesorería en la nube?

Sí, y es un caso que Arjé Partners ya ha resuelto. Lo habitual es leer de DB2 por ODBC o JDBC, o exportar ficheros, y entregar a la plataforma de tesorería por su API o su importación estándar. Si no se admiten accesos entrantes, el AS/400 envía los datos de forma programada.

¿Es seguro dar acceso a la base de datos del ERP?

En lectura, con un usuario limitado a vistas concretas, es una práctica habitual y controlable. La escritura directa en tablas se salta las validaciones del ERP y conviene evitarla.

¿Qué hago si mi política de seguridad no admite conexiones entrantes?

Invertir el flujo. Tu sistema abre una conexión saliente y envía los datos a un punto de recepción. No hay puertos abiertos hacia tu red.