Workflows Transient en AEM: cómo reduje casi a la mitad una sincronización con un PIM

Hace unos meses se planteaba un reto en un mantenimiento para un cliente: mejorar la eficiencia de una sincronización de datos entre un PIM y nodos en AEM. La sincronización afectaba a una cantidad de nodos demasiado grande, los tiempos se disparaban, y había que hacer algo. Investigando alternativas encontré los workflows transient que, hasta la fecha, no había usado — y acabaron siendo la pieza clave de la solución. En este artículo cuento qué son, por qué son más eficientes, cómo activarlos y qué resultados obtuve en un caso real.

El caso de uso: sincronizar un PIM con AEM

Un PIM (Product Information Management) es el sistema maestro de la información de producto: nombres, descripciones, atributos, categorías, referencias... En este proyecto, esa información debía sincronizarse periódicamente hacia AEM, donde cada producto se materializaba en nodos del repositorio JCR.

El problema era la escala. Cada ejecución de la sincronización procesaba un volumen enorme de nodos, y cada nodo pasaba por un workflow de AEM que orquestaba los pasos del proceso. Con ese volumen, dos costes se hacían insostenibles:

1. El tiempo total del proceso, que crecía con cada ampliación del catálogo.
2. El consumo de recursos de la instancia mientras la sincronización estaba en marcha, afectando al rendimiento general.

Qué hace lento a un workflow "normal"

Para entender la solución hay que entender primero de dónde viene el coste. Cuando lanzas un workflow estándar en AEM, el motor de workflows persiste en el repositorio JCR todo el estado de la ejecución: se crea una instancia del workflow bajo /var/workflow/instances, y en ella se van guardando el historial de pasos, los metadatos, el estado de cada transición...

Eso tiene sentido cuando necesitas trazabilidad: puedes ver el workflow en la consola de instancias, consultar en qué paso está, ver el histórico completo o reanudarlo si algo falla.

Pero tiene un precio: cada ejecución genera escrituras en el JCR. Y cuando no hablas de un workflow puntual sino de decenas de miles de ejecuciones en una sincronización masiva, ese overhead se multiplica:

• Miles de nodos de instancia creados, modificados y (eventualmente) purgados.
• Presión sobre el repositorio: más escrituras, más crecimiento del segment store, más trabajo para las tareas de mantenimiento y compactación.
• Tiempo añadido en cada ejecución individual que, sumado, domina el tiempo total del proceso.

Para una sincronización PIM → AEM, toda esa trazabilidad persistida no aportaba valor: lo que importaba era el resultado (los nodos actualizados), no el histórico de cada mini-ejecución.

La solución: transient workflows

Un transient workflow es exactamente el mismo workflow, con una diferencia fundamental: no guarda datos de la ejecución en el repositorio JCR. La instancia del workflow vive solo en memoria mientras se ejecuta; no se crean nodos bajo /var/workflow/instances, no hay historial persistido, no hay nada que purgar después.

Al eliminar esas escrituras, cada ejecución es más ligera y el repositorio deja de recibir el bombardeo de escrituras de estado. En procesos masivos, la diferencia se nota de forma directa en los tiempos.

Cómo se activa

Activarlo es sorprendentemente sencillo: en el editor de modelos de workflow, dentro de las propiedades del modelo, marca la casilla "Transient Workflow". A partir de ahí, todas las ejecuciones de ese modelo serán transient. No hay que cambiar el código de los process steps: los mismos WorkflowProcess funcionan igual.

Qué pierdes a cambio

No es gratis, claro. Al no persistir estado, renuncias a varias cosas:

• No hay visibilidad en la consola de instancias: no puedes ver el workflow "en curso" ni su histórico una vez terminado.
• No hay reanudación tras fallo: si la instancia de AEM se cae a mitad de ejecución, el workflow no se recupera — simplemente no existe registro de él. Tu proceso debe ser idempotente o reejecutable.
• Sin pasos de participante: los workflows con intervención humana (aprobaciones, tareas) no pueden ser transient, porque necesitan persistir el estado mientras esperan.

Para la sincronización PIM ninguna de estas renuncias era un problema: el proceso era completamente automático, idempotente por diseño (cada ejecución dejaba los nodos en el estado que dictaba el PIM) y su monitorización se hacía por logs, no por la consola de workflows.

Los resultados

El cambio a transient workflows, por sí solo, redujo hasta un 10% los tiempos del proceso. Solo con marcar una casilla — probablemente el ratio esfuerzo/beneficio más alto de todo el mantenimiento.

Pero no me quedé ahí. Aproveché para revisar el código del proceso y corregir varios puntos de uso excesivo de memoria: acumulación innecesaria de objetos durante la iteración de nodos, sesiones y recursos que se mantenían abiertos más de lo necesario, y saves demasiado frecuentes (o demasiado infrecuentes) contra el repositorio.

Sumando las correcciones de código y los transient workflows, el resultado final fue una reducción de los tiempos de casi un 40-50% respecto al proceso original.

Conclusión

Los transient workflows son una de esas funcionalidades de AEM que pasan desapercibidas hasta que las necesitas: llevan años en la plataforma, se activan con una casilla y, en el escenario adecuado — procesos masivos, automáticos y reejecutables —, ofrecen una mejora de rendimiento inmediata al eliminar la persistencia de estado en el JCR.

La otra lección del proyecto es igual de importante: las mejoras grandes rara vez vienen de un único cambio. El 10% de los transient workflows se convirtió en un 40-50% al combinarlo con optimizaciones de memoria en el código. Rendimiento en AEM casi siempre significa eso: sumar mejoras en capas distintas.

Si te toca pelearte con una sincronización masiva en AEM y aún no conocías los transient workflows, muy recomendado probarlos 😋