Integrar SAP Business One sin romper el ERP

Hay una forma de integrar SAP Business One que funciona perfectamente el primer día y le cuesta el soporte del ERP el día que llega un parche: escribir directamente en las tablas de la base de datos.

Es tentadora porque es la más rápida. La base está ahí, las tablas se pueden leer, un INSERT es un INSERT. Y durante unas semanas todo va bien.

Este artículo es sobre por qué no, y sobre qué hacer en su lugar.

Por qué escribir en las tablas rompe cosas que no se ven

SAP Business One no es una base de datos con pantallas encima. Cuando usted crea un documento desde la interfaz, el sistema no escribe una fila: aplica reglas de negocio, actualiza saldos, mueve numeración de series, dispara asientos contables, valida contra el maestro de artículos y toca varias tablas relacionadas dentro de una misma transacción.

Un INSERT directo salta todo eso. El registro aparece —se ve en las consultas, se ve en los reportes— pero el estado del sistema queda inconsistente de una forma que nadie detecta hasta el cierre, cuando el inventario no cuadra con la contabilidad y no hay manera de reconstruir por qué.

A eso se suma lo obvio: la escritura directa en la base no está soportada por SAP. Si abre un caso de soporte con datos escritos así, la conversación termina ahí. Y el esquema interno cambia entre versiones, de modo que su integración es también una apuesta a que nunca actualizarán el ERP.

Leer de las tablas es otra conversación, y en la práctica es común y razonable para reportería. Es la escritura lo que no tiene defensa.

Los dos caminos soportados, y qué elige cada uno por usted

Service Layer es la interfaz REST de SAP Business One, basada en OData. Habla HTTP y JSON, se consume desde cualquier lenguaje y desde cualquier sistema operativo, y es la opción por defecto para prácticamente todo lo nuevo. Su limitación es que no todos los objetos ni todas las operaciones del ERP están expuestos con la misma profundidad, así que hay casos —sobre todo en operaciones poco frecuentes o muy específicas de la versión— en los que se queda corto.

DI API es la interfaz de componentes de SAP. Cubre más superficie del ERP y es la de mayor recorrido histórico, pero le impone su modelo de ejecución: es Windows, y su aplicación tiene que vivir donde ese componente pueda correr. Si su sistema es una aplicación web en Linux o un servicio en contenedor, DI API deja de ser una decisión técnica y pasa a ser una decisión de infraestructura.

La regla práctica: Service Layer por defecto, DI API cuando Service Layer no llegue, y en ese caso aislado detrás de un servicio propio para que el resto de su arquitectura no herede la restricción de plataforma.

Conviene verificar contra la versión concreta que tenga instalada el cliente qué cubre cada interfaz, porque eso ha ido cambiando entre versiones y una lista memorizada envejece mal.

Nada llama a SAP de forma síncrona

Este es el patrón que más problemas evita y el que más se omite.

La tentación es que cuando el usuario pulsa «guardar» en su aplicación, esta llame a SAP, espere la respuesta y muestre el resultado. Es simple y es correcto mientras SAP esté disponible y rápido.

Deja de serlo el día del cierre, cuando el ERP está saturado; el día del mantenimiento programado; y el día que la red entre los dos servidores tiene un mal minuto. En todos esos casos su usuario recibe un error que no puede resolver, por una operación que sí era válida.

La alternativa es una cola. Su aplicación registra el hecho en su propia base, encola el mensaje para SAP y responde al usuario de inmediato. Un trabajador consume la cola contra el ERP, en orden, con reintentos. Si SAP no está, los mensajes esperan. Cuando vuelve, se procesan.

Dos cosas que esto exige y sin las cuales la cola es peor que no tenerla:

Idempotencia. Un reintento no puede crear el documento dos veces. Cada mensaje lleva una clave propia, y antes de crear se comprueba si esa clave ya produjo un documento. Sin esto, el primer corte de red le duplica facturas.

Una bandeja de fallidos que alguien mire. Los mensajes que agotan sus reintentos tienen que quedar visibles, con su error y con una forma de reprocesarlos. Una cola que descarta en silencio es una forma elegante de perder datos.

Quién es dueño de cada dato

La pregunta que hay que responder antes de escribir código, y por escrito: para cada entidad compartida —artículos, socios de negocio, centros de costo, listas de precios— cuál de los dos sistemas manda y en qué dirección viaja el dato.

Si nadie lo decide, lo que pasa es predecible: los dos lados escriben, a los tres meses hay dos catálogos que difieren en algunos registros, y la discusión sobre cuál rige llega cuando ya se facturó con el equivocado.

Lo habitual y sensato es que los maestros los mande SAP y el sistema propio los consuma. Cuando el flujo tiene que ser bidireccional —porque la operación crea socios de negocio en campo, por ejemplo— hace falta una regla explícita de resolución de conflictos, y «gana el último que escribió» no es una regla: es la ausencia de una.

El criterio de éxito

No es que la integración funcione. Es que una actualización de SAP no la rompa.

De ahí sale todo lo anterior. Trabajar contra interfaces con contrato estable en vez del esquema interno, porque el esquema cambia entre versiones y el contrato no. Aislar la dependencia de plataforma en un solo punto. No asumir que el ERP está disponible.

Y la parte que no es de diseño sino de disciplina: toda integración se prueba contra una copia antes de tocar el sistema vivo. Un ambiente de pruebas con datos representativos no es un lujo del proyecto, es la única forma de comprobar que el criterio de éxito se cumple. Si el acceso a ese ambiente no se puede conseguir —porque el proveedor actual del ERP no colabora, que pasa—, esa es una conversación que conviene tener antes de firmar y no en el mes cuatro.