Dokumentation

Assets går inte från överföring till målmapp i AEMaaCS

Last update: Wed May 27 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Assets fastnar fortfarande i överförings- eller mellanlagringsmappen när ett anpassat arbetsflöde inte kan flytta dem till målmappen på grund av konflikter vid databasimplementering. Utforma om arbetsflödet för att undvika stora parallella implementeringar och dela metadatauppdateringar i ett separat arbetsflöde för efterbearbetning för att lösa problemet.

Beskrivning description

Miljö

  • ADOBE EXPERIENCE MANAGER AS A CLOUD SERVICE - ASSETS
  • Designmiljö, distribuerad via Cloud Manager
  • Anpassat arbetsflöde för flyttning av resurser som utlöses av ett startjobb eller schemalagt jobb

Problem/symtom

  • Assets finns kvar i överförings- eller mellanlagringsmappen och visas inte i målmappen.

  • Ett anpassat arbetsflöde för att flytta resurser aktiveras korrekt (t.ex. av en cron-lik startare) men:

    • tar lång tid att slutföra, eller
    • Slutar med upprepade fel och försök.

  • Inga fel rapporteras för själva startprogrammet. fel inträffar i det anpassade flyttsteget.

  • Ett stort antal arbetsflödesinstanser (till exempel 10 000+ instanser som körs) ackumuleras för samma arbetsflödesmodell.

  • I AEM-felloggen visas implementeringsfel med samtidiga ändringskonflikter, till exempel:

    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

  • Efterbehandlingsbeteendet (t.ex. uppdatering av medietitlar, uppladdningsinformation eller flaggor för dynamiska media) är fördröjt eller intermittent eftersom resurserna inte når målmappen på ett tillförlitligt sätt.

Orsak

  • I de implementeringar som påverkas ändrades steget för att flytta resurser till:

    • Gruppera många resurser i en enda stor JCR-session och spara, och
    • Kör den här logiken parallellt i många arbetsflödesinstanser (till exempel via en startfunktion som körs några minuter medan tidigare körningar fortfarande är aktiva).

  • Under laddning leder den här designen till:

    • Konflikt vid samtidig allokering av grenar i Oak-databasen (OakState0002), vilket gör att implementeringen misslyckas och arbetsflödesjobbet provas igen.
    • En takt där resursen flyttas först och metadata i den ursprungliga sökvägen uppdateras senare, så att metadatauppdateringen misslyckas eller hoppas över.

  • Problemet är ett problem på databasnivå med anpassad arbetsflödeskod, inte en felfunktion i startprogrammet eller AEM inbyggda resursbearbetning.

Upplösning resolution

Så här återställer du pålitlig resursrörelse och förhindrar implementeringskonflikter:

  1. Ta bort eller återställ en enda stor implementeringsgrupp så att det anpassade flyttsteget inte längre flyttar och uppdaterar flera resurser i en enda save() eller commit(), och undvik designer där hundratals resurser flyttas i en transaktion.
  2. Återfyll flyttningssteget så att varje resurs, eller en mycket liten grupp, flyttas till målplatsen och verkställs omedelbart (till exempel med session.save() eller resourceResolver.commit()) och se till att steget är idempotent per resurs och kan hantera återförsök på ett säkert sätt, och eventuellt fånga InvalidItemStateException eller PersistenceException och implementera avgränsade återförsök med loggning.
  3. Dela upp flytt- och metadatainformation eller efterbearbetningslogik i separata arbetsflöden genom att låta flyttarbetsflödet fokusera på att välja giltiga resurser och flytta dem från överförings- eller mellanlagringsmappen till målmappen, och konfigurera ett separat efterbearbetningsarbetsflöde i målmappen som uppdaterar metadata och anpassade egenskaper (t.ex. Dynamiska medieflaggar eller fält som används av system längre fram i kedjan) och körs via arbetsflödesmekanismen för efterbearbetning (autostart) när resursbearbetningen har slutförts.
  4. Begränsa samtidighet för flyttningsarbetsflödet genom att granska jobbkökonfigurationen för arbetsflödets Sling-jobbämne, minska det maximala antalet parallella jobb där det är möjligt och se till att startprogrammet inte startar nya stora körningar medan tidigare körningar fortfarande är aktiva eller försöker igen.
  5. Håll arbetsflödesinstanser under kontroll genom att konfigurera rensning av arbetsflöde (till exempel med konfigurationen com.adobe.granite.workflow.purge.Scheduler) så att slutförda instanser av den anpassade modellen rensas regelbundet och inte ackumuleras.
  6. Validera beteendet efter dessa ändringar genom att överföra en kontrollerad testuppsättning med resurser till överförings- eller mellanlagringsmappen, vilket bekräftar att resurserna flyttas tillförlitligt till målmappen inom den förväntade tiden, att efterbehandlingsarbetsflödena i målmappen slutförs och metadata uppdateras snabbt och att OakState0002 implementeringskonflikter som är relaterade till det anpassade flyttsteget inte längre visas i loggarna.

Anteckningar:

  • Problemet beror på hur anpassade arbetsflöden samverkar med AEM as a Cloud Service-databasen samtidigt, inte på en felfunktion i startprogrammet eller AEM inbyggda materialbearbetning.
  • Genom att ändra arbetsflödet så att det implementeras per resurs (eller en liten grupp) och flytta metadata- eller egenskapsuppdateringar till ett separat arbetsflöde för efterbearbetning i målmappen, minskar du implementeringskonflikterna, eliminerar flytt/metadataflödet och återställer stabila rörelser i rätt tid för resurser från överföringsmappen till målmappen.
recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f