DocumentaciónKCS de Experience Cloud

Assets no se mueve de la carga a la carpeta de destino en AEMaaCS

Última actualización: 22 de junio de 2026

Assets permanece atascado en la carpeta de carga o ensayo cuando un flujo de trabajo personalizado no puede moverlos a la carpeta de destino debido a conflictos de confirmación del repositorio. Rediseñe el flujo de trabajo para evitar grandes confirmaciones paralelas y divida las actualizaciones de metadatos en un flujo de trabajo posterior al procesamiento independiente para resolver el problema.

Descripción description

Entorno

  • ADOBE EXPERIENCE MANAGER AS A CLOUD SERVICE - ASSETS
  • Entorno de creación, implementado mediante Cloud Manager
  • Flujo de trabajo de movimiento de recursos personalizado activado por un lanzador o un trabajo programado

Problema/Síntomas

  • Assets permanecerá en la carpeta de carga o ensayo y no aparecerá en la carpeta de destino.

  • Un flujo de trabajo de movimiento de recursos personalizado se activa correctamente (por ejemplo, mediante un lanzador de tipo cron), pero:

    • Tarda mucho tiempo en completarse, o
    • Termina con errores y reintentos repetidos.

  • No se notifica ningún error para el propio lanzador; los errores se producen en el paso de movimiento personalizado.

  • Se acumula un gran número de instancias de flujo de trabajo (por ejemplo, más de 10 000 instancias en ejecución) para el mismo modelo de flujo de trabajo.

  • El registro de errores de AEM muestra errores de confirmación con conflictos de cambios simultáneos, por ejemplo:

    code language-none 
    org.apache.sling.api.resource.PersistenceException: Unable to commit changes to session      at com.example.aem.core.workflows.MoveToTarget.execute(MoveToTarget.java:xx)    Caused by: javax.jcr.InvalidItemStateException:      OakState0002: Conflicting concurrent change on branch commits

  • El comportamiento posterior al procesamiento (como la actualización de títulos de medios, información del cargador o indicadores de Dynamic Media) se retrasa o intermitente porque los recursos no llegan a la carpeta de destino de forma fiable.

Causa

  • En las implementaciones afectadas, el paso de mover recursos personalizados se cambió a:

    • El lote de muchos recursos se mueve a una sola sesión JCR grande y se confirma, y
    • Ejecute esta lógica en paralelo en muchas instancias de flujo de trabajo (por ejemplo, mediante un iniciador que se ejecuta cada pocos minutos mientras las ejecuciones anteriores siguen activas).

  • En carga, este diseño conduce a:

    • Se confirma la rama simultánea en conflicto en el repositorio de Oak (OakState0002), lo que provoca que la confirmación falle y se reintente el trabajo de flujo de trabajo.
    • Una carrera en la que el recurso se mueve primero y los metadatos de la ruta original se actualizan más adelante, por lo que la actualización de metadatos falla o se omite.

  • El problema es un problema de contención a nivel de repositorio en el código de flujo de trabajo personalizado, no un mal funcionamiento del lanzador o el procesamiento de recursos integrado de AEM.

Resolución resolution

Para restaurar el movimiento de recursos fiable y evitar conflictos de confirmación, siga estos pasos:

  1. Elimine o revierta cualquier lote de confirmación grande para que el paso de movimiento de recursos personalizado ya no mueva y actualice varios recursos en un único save() o commit(), y evite diseños en los que cientos de recursos se muevan en una transacción.
  2. Refactorice el paso de movimiento para que cada recurso, o un lote muy pequeño, se mueva a la ubicación de destino y se confirme inmediatamente (por ejemplo, con session.save() o resourceResolver.commit()). Asegúrese de que el paso sea idempotente para cada recurso y de que pueda gestionar los reintentos de forma segura, capturando de forma opcional InvalidItemStateException o PersistenceException e implementando reintentos enlazados con el registro.
  3. Divida la lógica de movimiento y metadatos o de procesamiento posterior en flujos de trabajo independientes. Para ello, mantenga el flujo de trabajo de movimiento centrado en la selección de recursos válidos y su desplazamiento de la carpeta de carga o ensayo a la carpeta de destino, y configure un flujo de trabajo de procesamiento posterior independiente en la carpeta de destino que actualice los metadatos y las propiedades personalizadas (como los indicadores de Dynamic Media o los campos utilizados por los sistemas de flujo descendente) y se ejecute mediante el mecanismo de flujo de trabajo de procesamiento posterior (inicio automático) una vez completado el procesamiento del recurso.
  4. Limite la concurrencia para el flujo de trabajo de movimiento revisando la configuración de la cola de trabajos del tema de trabajo de Sling del flujo de trabajo, reduciendo el número máximo de trabajos paralelos siempre que sea posible y asegurándose de que el iniciador no inicie nuevas ejecuciones grandes mientras las anteriores siguen activas o reintentando.
  5. Mantenga las instancias de flujo de trabajo bajo control configurando la depuración de flujo de trabajo (por ejemplo, con la configuración com.adobe.granite.workflow.purge.Scheduler) para que las instancias completadas del modelo personalizado se purguen con regularidad y no se acumulen.
  6. Valide el comportamiento después de estos cambios cargando un conjunto de prueba controlado de recursos en la carpeta de carga o ensayo, confirmando que los recursos se mueven de forma fiable a la carpeta de destino en el tiempo esperado, que los flujos de trabajo posteriores al procesamiento en la carpeta de destino se completan correctamente y actualizan los metadatos rápidamente, y que los registros ya no muestran OakState0002 conflictos de confirmación frecuentes relacionados con el paso de movimiento personalizado.

Notas:

  • Este problema surge de cómo los flujos de trabajo personalizados interactúan con el repositorio de AEM as a Cloud Service en régimen de concurrencia, no de un mal funcionamiento del iniciador o del procesamiento de recursos integrado de AEM.
  • Al rediseñar el flujo de trabajo para que se comprometa por recurso (o lote pequeño) y mover las actualizaciones de propiedades o metadatos a un flujo de trabajo posterior al procesamiento independiente en la carpeta de destino, se reduce la contención de compromiso, se elimina la carrera de mover/metadatos y se restaura el movimiento estable y oportuno de recursos desde la carpeta de carga a la carpeta de destino.
recommendation-more-help
experience-cloud-kcs-help-kbarticles