Saltar al contenido
AgenticUltimate by QOON Solicitar una demostración en directo
Automatización · Arquitectura

Flujos: ¿al guardar o mediante planificador?

·Aprox. 15 min de lectura · Interactivo
Resumen
  • Los flujos al guardar se ejecutan en la petición de guardado; a menudo aún faltan relaciones y objetos posteriores.
  • Los flujos del planificador separan interfaz y trabajo, pero necesitan cron, observación e idempotencia.
  • Un mal modelado aparece como correos vacíos, peticiones bloqueadas o acciones duplicadas, no como un error teórico abstracto.

Los flujos de SuiteCRM, históricamente Advanced Open Workflow, permiten acciones condicionales por módulo. En la práctica fallan menos por el motor que por supuestos erróneos sobre el momentoen que los datos están completos y las relaciones establecidas. Este artículo hace tangible la decisión con ayuda de selección, comparación de ciclos y lista de pruebas.

Comprobación interactiva

¿Qué tipo de flujo encaja en su caso?

Dos preguntas y una recomendación. No sustituye las pruebas, pero filtra el error de decisión más frecuente.

Recomendación: flujo al guardar

Adecuado para cálculos o cambios de estado del mismo registro, sin relaciones dependientes ni esperas apreciables.

1. Dos ciclos de vida: síncrono frente a asíncrono

En lugar de definiciones abstractas, veamos el proceso que experimentan realmente el usuario y el sistema:

Tarjeta A · Síncrono

Ciclo de vida al guardar

  1. 1 El usuario pulsa «Guardar»
  2. 2 La petición HTTP sigue activa; el navegador espera
  3. 3 Validación y hooks previos al guardado
  4. 4 Escritura en base de datos (INSERT/UPDATE)
  5. 5 Flujo al guardar: posibles correos, webhooks y más escrituras
  6. 6 Respuesta al navegador
Riesgo: La latencia externa y las cadenas pesadas alargan la petición. En ese momento, las relaciones de subpaneles suelen no estar aún como espera la lógica funcional.
Tarjeta B · Asíncrono

Ciclo de vida del planificador

  1. 1 El usuario guarda y recibe respuesta rápida
  2. 2 La interfaz vuelve a estar disponible
  3. 3 Ejecución diferida: cron/proceso de trabajo
  4. 4 La tarea lee el estado actual de la base de datos, normalmente con relaciones ya presentes
  5. 5 Acciones por lotes sin bloquear la interfaz
  6. 6 Marcar estado o idempotencia
Requisito: Cron funciona de forma fiable, las tareas se supervisan y el flujo admite repeticiones sin duplicados indiscriminados.

2. Ayuda breve para decidir

Pregunta de diseñoMás bien al guardarMás bien planificador
¿El registro relacionado se crea después de guardar?DesfavorableAdecuado
¿El usuario necesita ver un campo o respuesta de inmediato?AdecuadoDiferido
¿API externa con latencia apreciable?Arriesgado dentro de la peticiónMejor
¿Muchos registros o ejecuciones nocturnas?InadecuadoPlanificar con filtros

3. Tres trampas de arquitectura

Trampa 1 · Carrera de relaciones

La ilusión del subpanel

El ID principal puede existir durante el guardado mientras los registros relacionados se escriben en un paso posterior de la transacción o después. Un flujo que espera un contacto del presupuesto no encuentra nada, aunque el usuario acabe de crear la relación en la interfaz. Contramedida: Planificador o segundo paso consciente cuando se garantice la lectura de la relación.

Trampa 2 · Bucle de guardado

El bucle recursivo infinito

El flujo cambia un campo, vuelve a guardar, vuelve a ejecutarse y continúa hasta agotar tiempo o memoria. Es especialmente peligroso si la condición y la escritura afectan al mismo campo. Contramedida: Marca explícita de procesamiento, condiciones que hagan inocua la segunda ejecución y evitar guardados innecesarios en la cadena.

Trampa 3 · Todos los registros

La ejecución sin freno del planificador

Un flujo sin filtros estrictos de fecha y estado puede procesar enormes historiales en cada cron tras años de uso. El sistema parece volverse lento de repente aunque el flujo siempre fuera igual. Contramedida: Criterios de selección estrictos, estado de procesado y supervisión de duración y carga.

4. Preparación para el despliegue: protocolo para marcar

Pasar a producción sin estas cinco pruebas es avanzar a ciegas, independientemente del tipo de desencadenante.

Lista del entorno de pruebas

0–2 marcas: riesgo elevado; no se recomienda desplegar en producción.

La Workflow Engine de AgenticUltimate utiliza modelado visual, simulación y aprobación por versiones para que los flujos no lleguen a producción sin revisión. Elegir entre guardar y planificador sigue siendo una decisión arquitectónica; la simulación no sustituye ninguna de las cinco pruebas.

Workflow Engine ↗

5. Límites del artículo

No hay garantía para cada parche de SuiteCRM ni cada conjunto de hooks propios. Son criterios arquitectónicos basados en fallos habituales; las pruebas en su instancia siguen siendo decisivas.

← Volver a la revista