Cómo se monta una capa REST encima de Informix / Multibase sin tocar el ERP

• Por qué no tocar el ERP
• Arquitectura típica que desplegamos
• Cómo se conecta a Informix desde un PHP/Laravel moderno
• Diseño de los endpoints: orientación al caso de uso, no al esquema
• Autenticación: tokens cortos, ámbitos estrictos
• Auditoría: cada hit a la API queda registrado
• Errores que ya hemos pagado y no vas a tener que pagar tú
• ¿Cuánto cuesta y cuánto tarda?

Cuando llegamos a un cliente con CGestion en producción —típicamente sobre Informix Dynamic Server o Multibase— la conversación suele empezar así: “queremos una app móvil para los técnicos”, “el banco nos pide enviar las remesas firmadas digitalmente”, “el cliente final nos exige un portal de pedidos online”.

Detrás de las tres frases hay la misma necesidad: exponer al exterior parte de lo que ya está en el ERP, pero sin tocar el ERP. Esto se resuelve montando una capa REST intermedia. En este artículo contamos cómo lo hacemos y, sobre todo, qué decisiones nos ha costado varios años aprender que no se pueden saltar.

Por qué no tocar el ERP

CGestion lleva 25-30 años funcionando en muchas empresas españolas. La lógica de negocio (gestión de obra, costes, partidas, contabilidad) está pulida por décadas de casos reales. Reescribirla es caro, es arriesgado y es innecesario.

La regla que aplicamos en GPInfor: si la lógica funciona, no se toca. Lo que se moderniza es el envoltorio: la presentación, los canales de entrada y las integraciones con el exterior.

Una capa REST bien diseñada actúa como fachada: el ERP sigue siendo la fuente única de verdad y la capa REST traduce sus tablas y sus procedimientos en endpoints HTTP modernos para que móviles, portales y otros sistemas hablen con él sin saber que por debajo hay un Informix de los noventa.

Arquitectura típica que desplegamos

[ móvil / portal / banco ]
         │ HTTPS / JSON
         ▼
  [ API REST Laravel ]  ◄─── tokens, rate limit, auditoría
         │ ODBC / TDS / nativo
         ▼
  [ Informix / Multibase ]   ◄─── el ERP intacto
         │
         ▼
  [ base de datos histórica ]

Lo importante: la capa REST no replica datos. Lee y escribe contra el mismo Informix/Multibase que usa CGestion. Esto evita el viejo problema del cache inconsistente entre dos sistemas que se piensan sincronizados pero no lo están.

Cómo se conecta a Informix desde un PHP/Laravel moderno

Hay tres caminos posibles. Los hemos usado los tres y cada uno tiene sus tradeoffs:

1. Driver nativo PDO_INFORMIX. Compila contra el cliente Informix (CSDK) y expone PDO estándar. Es lo más rápido y lo que recomendamos cuando se controla el host de la API. Requiere instalar el cliente Informix en el servidor donde corre PHP, lo cual no siempre es trivial en entornos Plesk/cPanel compartidos.

2. ODBC. Más portable, funciona contra Informix y contra Multibase con el mismo código. Pierde un 10-15% de rendimiento frente al nativo, pero gana en mantenibilidad. Es nuestra opción por defecto para clientes que tienen Multibase: el driver Multibase ODBC se firma con sus claves, se instala como driver del sistema y Laravel lo usa vía odbc: connection.

3. Bridge HTTP. En empresas donde no se puede tocar el server del ERP, montamos un microservicio mínimo (Go o Python) que vive en la misma máquina que el motor, expone REST autenticado solo accesible desde la red interna, y la API Laravel le hace consultas. Es más complejo de mantener pero permite separar despliegues.

Diseño de los endpoints: orientación al caso de uso, no al esquema

Un error frecuente cuando se hace una capa REST sobre un ERP heredado es exponer las tablas. Hacer GET /api/v1/obras_partidas devuelve filas crudas con campos crípticos heredados de los noventa: cd_obr, tp_par, imp_ce… No sirve a nadie y obliga al cliente a aprenderse el modelo interno.

Nuestro diseño es siempre orientado al caso de uso del consumidor:

El consumidor (la PWA de obra, el portal del cliente, el banco) habla en su lenguaje. Por debajo, la capa REST sabe que un parte-diario se desglosa en N inserts en cuatro tablas distintas del CGestion, y todas dentro de la misma transacción.

Autenticación: tokens cortos, ámbitos estrictos

CGestion no tiene OAuth ni JWT. Lo añadimos en la capa REST con tokens firmados (HMAC SHA-256) emitidos por la propia API. Cada token lleva:

• Subject: usuario del ERP al que se mapea para auditoría
• Scopes: qué endpoints puede tocar (partes:write, obras:read…)
• Caducidad: 15-60 minutos. Refresh aparte.
• Origen: opcional, restringir por IP cuando el cliente lo permite.

Lo importante: el token nunca sale del backend. El móvil habla con nuestra API, no con Informix directamente.

Auditoría: cada hit a la API queda registrado

Cuando se modifica algo en CGestion vía la capa REST, queremos saber quién, cuándo y qué. Para eso registramos en una tabla aparte (api_audit_log en MariaDB, fuera del ERP) cada llamada que escriba:

• timestamp UTC
• token subject (usuario)
• método + endpoint
• hash del payload (no el payload entero, por RGPD)
• código de respuesta
• entidades creadas o modificadas

Esto es innegociable en sectores regulados (cooperativas con subvenciones PAC, constructoras con obra pública). Cuando un día la inspección o el auditor te pide “¿quién metió este parte el 14 de mayo?“, no quieres tener que reconstruirlo desde tail de logs.

Errores que ya hemos pagado y no vas a tener que pagar tú

• Permisos a nivel de aplicación, no a nivel de BD. Si das al usuario ODBC permisos de UPDATE sobre todas las tablas y luego filtras “por código” en la capa REST, mañana un bug y se cae el ERP entero. Limita por usuario de BD lo que sea posible.

• No paralelizar contra Informix sin medir. Informix Dynamic Server escala bien, Multibase mucho menos. Algunos endpoints de consulta que parecen idempotentes desencadenan locks largos. Test de carga antes de exponer.

• Cuidado con DECIMAL(precisión). Informix permite escalas enormes, JSON no. Si devuelves imp_ce como float JS se va a llevar el redondeo bancario al traste. Devuélvelo como string con dos decimales y deja al cliente que decida.

• Versionado en la URL desde el día uno. /api/v1/.... El día que necesites cambiar el contrato, el cliente que aún no se ha actualizado sigue funcionando contra /v1.

¿Cuánto cuesta y cuánto tarda?

Un proyecto típico de capa REST sobre CGestion con 4-8 endpoints (obras, partes, fichaje, consulta de cobros) son 3-5 semanas desde kickoff hasta producción, incluida la documentación OpenAPI y un par de iteraciones con el cliente final que consumirá la API.

Si el cliente quiere ya además la PWA móvil que la consume, sumar otras 4-8 semanas dependiendo del alcance.

Para conocer si el caso concreto del lector encaja en este planteamiento, lo más rápido es una llamada de 20 minutos: nos cuentas qué motor tienes (Informix vs Multibase), qué quieres exponer y para quién, y te decimos si tiene sentido y qué horquilla manejar.

Pedir esa llamada técnica →