Procesos largos y confiables: por qué orquestamos flujos documentales con un motor de workflows

Cuando un documento llega a Loony, nuestra plataforma de inteligencia documental, no se procesa en un solo paso. Se divide en secciones, se lee su texto, se aplica OCR cuando hace falta, se clasifica, se extraen sus datos, se integra a un archivero y se dispara la revisión del expediente completo. Algunos pasos tardan segundos; otros, minutos; otros esperan a que una persona suba un documento o revise un resultado, y eso puede tomar días. En este artículo explicamos por qué orquestamos todo esto con un motor de workflows y no con colas y reintentos construidos a mano.

El problema con las colas y los reintentos hechos a mano

La forma más común de procesar documentos en segundo plano es conocida: un servicio recibe el archivo, publica un mensaje en una cola, un proceso trabajador lo toma y va actualizando un estatus en la base de datos: en cola, procesando, procesado, error. Nosotros mismos construimos sistemas así, y funcionan bien mientras el proceso es corto y lineal.

Los problemas aparecen cuando el proceso crece:

• El estado queda repartido. Parte vive en la cola, parte en la base de datos y parte en la memoria del trabajador. Si el trabajador se reinicia a mitad del proceso, reconstruir en qué paso iba requiere código adicional.
• Los reintentos son peligrosos. Volver a ejecutar un paso puede significar pagar dos veces un OCR o una extracción, o escribir dos veces el mismo resultado.
• Los tiempos de espera se vuelven artesanales. Cada paso necesita su propio límite de tiempo y su propia forma de detectar que algo se quedó atorado.
• Nadie sabe bien dónde está cada caso. Responder «¿en qué va este expediente?» obliga a revisar bitácoras de varios servicios.
• Cada flujo nuevo reinventa lo anterior. Lo que se resolvió para un proceso hay que volver a resolverlo para el siguiente.

Qué nos da un motor de workflows

En un motor de workflows, el flujo se describe como una secuencia de pasos, y cada paso que toca el mundo exterior (almacenamiento, OCR, un modelo de lenguaje, una base de datos) es una unidad separada. El motor guarda el historial de cada ejecución. Si un trabajador se detiene, otro retoma el flujo exactamente donde se quedó, sin perder lo ya hecho.

Sobre esa base resolvemos de forma uniforme lo que antes se resolvía caso por caso:

1. Reintentos con política por paso. Los errores de red se reintentan con espera creciente; los errores permanentes, como un archivo faltante o una configuración inválida, fallan de inmediato. Los pasos obligatorios detienen la ejecución y los opcionales se registran sin detenerla.
2. Idempotencia. Los pasos que cuestan dinero, como el OCR o la extracción, están diseñados para no volver a enviarse en un reintento, y las escrituras se identifican por su destino: si el resultado ya existe, el paso no lo repite.
3. Tiempos de espera y señales de vida. Las tareas largas reportan su avance periódicamente; si dejan de hacerlo, el motor lo sabe y actúa.
4. Capacidad sin reintentos ciegos. Cuando un proveedor de OCR o de modelos no tiene espacio, el trabajo no se lanza para fallar y reintentarse: espera su turno en una fila ordenada y visible, y se ejecuta solo cuando hay lugar.
5. Visibilidad. Cada ejecución tiene su historial, y cada sección de un documento grande aparece por separado, de modo que puede volver a ejecutarse sola. En la interfaz, un documento muestra si está procesando, en revisión o en fila, y en qué posición.

Pasos humanos dentro del mismo flujo

Lo que más valoramos de este modelo es que una espera humana es un paso más del proceso, no una excepción que vive fuera del sistema.

• Revisión de resultados. La revisión de un expediente produce un dictamen: aprobado, rechazado o, cuando el resultado cae en una banda intermedia, revisar. En ese caso una persona acepta o rechaza, desde la interfaz o por API, y su decisión queda registrada con fecha y autor.
• Documentos solicitados. Un archivero puede pedir un documento que no estaba previsto. Esa solicitud queda pendiente esperando a una persona, no a un servidor; cuando el documento llega, la revisión de completitud se actualiza sola.
• Cargas simultáneas. Si se suben diez documentos a la vez a un mismo archivero, se generan diez versiones, pero la revisión del expediente no corre diez veces: termina la pasada en curso y corre una más sobre la versión más reciente.

Para el motor, esperar una semana a una persona no cuesta nada y no se pierde si se reinician los servidores.

Decisiones que lo mantienen sostenible

Un motor de workflows no ordena el sistema por sí solo. Estas reglas son las que, en nuestra experiencia, lo hacen manejable:

• Pocos flujos, mucha configuración. Tenemos dos flujos genéricos, uno para documentos y otro para archiveros, que interpretan una configuración versionada. Una capacidad nueva es una nueva entrada de catálogo, no un flujo nuevo.
• Referencias en el flujo, contenido en el almacenamiento. El motor solo ve identificadores y referencias, nunca el texto de los documentos. Eso mantiene la confidencialidad y el historial ligero.
• La configuración se fija al inicio. Cada ejecución registra las versiones que usó y no las vuelve a leer a mitad del proceso.
• Resultados que no se sobrescriben. Volver a procesar agrega una nueva versión junto a la anterior; nada se borra.

Un motor de workflows no elimina la complejidad de un proceso largo; la concentra en un solo lugar, donde se puede ver, probar y auditar.

También tiene costos: el código de los flujos debe ser determinista, el equipo necesita aprender un modelo distinto y hay una pieza más de infraestructura que operar. Para procesos que duran minutos o días, involucran a personas y deben dejar evidencia, nos parece un intercambio claramente favorable.

¿Tienes procesos documentales largos que necesitan ser confiables? Escríbenos.