Cuando el sistema no tiene API

Pasa en casi todo diagnóstico. Hay un sistema en el centro de la operación —un ERP de hace quince años, un portal de un proveedor, una aplicación de escritorio que alguien compró y el fabricante ya no existe— y no expone forma alguna de conectarse programáticamente.

La conclusión habitual es que ese proceso no se puede automatizar hasta que se reemplace el sistema. Y como reemplazar el sistema es un proyecto de dos años, el proceso sigue haciéndose a mano indefinidamente.

Tres puntos de conexión, en orden de preferencia

1. API. Lo mejor: un contrato explícito, versionado, que el fabricante se compromete a mantener. Si existe y está documentada, se usa.
2. Base de datos. Aceptable con cuidado. Leer es razonablemente seguro; escribir directo salta la lógica de negocio de la aplicación y puede dejar el sistema en un estado que la propia aplicación no entiende.
3. Interfaz. El último recurso, y funciona: el robot opera la pantalla igual que lo haría una persona con teclado y ratón. El proceso avanza igual.

La condición

Automatizar una interfaz tiene un costo que hay que aceptar de entrada: es más frágil. Un cambio de diseño del proveedor, una actualización que mueve un botón, un mensaje nuevo que aparece la primera vez — cualquiera de esos rompe el proceso.

Eso no lo descarta. Lo que exige es que el fallo sea visible. Una automatización silenciosa que dejó de correr es peor que no tenerla: durante semanas todos creen que el proceso está cubierto.

En la práctica significan tres cosas no negociables:

• Reintentos con espera creciente, porque muchos fallos son transitorios.
• Alerta cuando el reintento se agota, dirigida a una persona concreta y no a un buzón.
• Bitácora por ejecución: qué corrió, cuándo, con qué datos y con qué resultado.

Lo que no hacemos

Operar la interfaz de un sistema propio del cliente, o de un proveedor con el que el cliente tiene una relación contractual y permiso para hacerlo, es automatización. Vulnerar un control de seguridad de un tercero para conseguir acceso no lo es, y no lo hacemos — ni lo construimos dentro de nuestros productos.

Cuando un flujo se topa con un control de seguridad legítimo de un tercero, la respuesta correcta es una persona resolviéndolo, no un mecanismo para saltarlo. En nuestros propios productos lo tenemos resuelto exactamente así: el reto llega a una cola interna y alguien lo atiende. El cliente final no se entera, y no se rompió nada de nadie.

La consecuencia práctica

Un ERP sin API no bloquea el proyecto. Cambia el diseño de la solución y cambia el presupuesto de mantenimiento — y las dos cosas conviene decirlas al principio, no descubrirlas a la mitad.