Dokumentation

Assets wird in AEMaaCS nicht vom Upload- in den Zielordner verschoben

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

Assets bleibt im Upload- oder Staging-Ordner hängen, wenn ein benutzerdefinierter Workflow sie aufgrund von Repository-Commit-Konflikten nicht in den Zielordner verschieben kann. Entwerfen Sie den Workflow neu, um große parallele Commits zu vermeiden und Metadatenaktualisierungen in einen separaten Nachbearbeitungs-Workflow zu unterteilen, um das Problem zu beheben.

Beschreibung description

Umgebung

  • ADOBE EXPERIENCE MANAGER AS A CLOUD SERVICE - ASSETS
  • Autorenumgebung, bereitgestellt über Cloud Manager
  • Benutzerdefinierter Workflow zum Verschieben von Assets, der durch einen Starter oder einen geplanten Auftrag ausgelöst wird

Problem/Symptome

  • Assets verbleibt im Upload- oder Staging-Ordner und wird nicht im Zielordner angezeigt.

  • Ein benutzerdefinierter Workflow zum Verschieben von Assets wird korrekt ausgelöst (z. B. durch einen cron-ähnlichen Starter), aber:

    • Dauert sehr lange, bis der Vorgang abgeschlossen ist, oder
    • Endet mit wiederholten Fehlern und erneuten Zustellversuchen.

  • Für den Starter selbst werden keine Fehler gemeldet. Im benutzerdefinierten Verschiebungsschritt treten Fehler auf.

  • Eine große Anzahl von Workflow-Instanzen (z. B. über 10.000 laufende Instanzen) wird für dasselbe Workflow-Modell gesammelt.

  • Das AEM-Fehlerprotokoll zeigt Commit-Fehler mit gleichzeitigen Änderungskonflikten an, z. B.:

    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

  • Das Nachbearbeitungsverhalten (z. B. beim Aktualisieren von Medientiteln, Uploader-Informationen oder Dynamic Media-Flags) wird verzögert oder unregelmäßig ausgeführt, da Assets den Zielordner nicht zuverlässig erreichen.

Ursache

  • In den betroffenen Implementierungen wurde der benutzerdefinierte Schritt zum Verschieben von Assets wie folgt geändert:

    • Viele Batch-Assets werden in eine einzelne große JCR-Sitzung verschoben und übertragen, und
    • Führen Sie diese Logik parallel auf vielen Workflow-Instanzen aus (z. B. über einen Launcher, der alle paar Minuten ausgeführt wird, während vorherige Ausführungen noch aktiv sind).

  • Unter Last führt dieser Entwurf zu:

    • Widersprüchliche gleichzeitige Verzweigungen im Oak-Repository (OakState0002), was dazu führt, dass der Commit fehlschlägt und der Workflow-Auftrag erneut versucht wird.
    • Ein Rennen, bei dem das Asset zuerst verschoben und Metadaten im ursprünglichen Pfad später aktualisiert werden, sodass die Metadatenaktualisierung fehlschlägt oder übersprungen wird.

  • Das Problem ist ein Streitpunkt auf Repository-Ebene im benutzerdefinierten Workflow-Code, keine Fehlfunktion des Starters oder der integrierten Asset-Verarbeitung von AEM.

Lösung resolution

Gehen Sie wie folgt vor, um eine zuverlässige Asset-Verschiebung wiederherzustellen und Commit-Konflikte zu vermeiden:

  1. Entfernen oder setzen Sie einen einzelnen Batch mit umfangreichen Commits zurück, sodass mit dem benutzerdefinierten Schritt zum Verschieben von Assets nicht mehr mehrere Assets in einem save() oder commit() verschoben und aktualisiert werden, und vermeiden Sie Designs, bei denen Hunderte von Assets in einer Transaktion verschoben werden.
  2. Gestalten Sie den Schritt zum Verschieben so um, dass jedes Asset oder ein sehr kleiner Batch an den Zielspeicherort verschoben und sofort übertragen wird (z. B. mit session.save() oder resourceResolver.commit()), und stellen Sie sicher, dass der Schritt pro Asset idempotent ist und Wiederholungsversuche sicher verarbeiten kann, indem Sie optional InvalidItemStateException oder PersistenceException erfassen und gebundene Wiederholungsversuche mit Protokollierung implementieren.
  3. Teilen Sie die Logik zum Verschieben und Metadaten bzw. die Nachbearbeitungslogik in separate Workflows auf, indem Sie den Workflow zum Verschieben darauf konzentrieren, gültige Assets auszuwählen und sie aus dem Upload- oder Staging-Ordner in den Zielordner zu verschieben, und einen separaten Nachbearbeitungs-Workflow für den Zielordner konfigurieren, der Metadaten und benutzerdefinierte Eigenschaften aktualisiert (z. B. Dynamic Media-Flags oder Felder, die von nachgelagerten Systemen verwendet werden) und über den Workflow-Mechanismus für die Nachbearbeitung (automatischer Start) ausgeführt wird, nachdem die Asset-Verarbeitung abgeschlossen ist.
  4. Schränken Sie die gleichzeitige Ausführung des Verschiebe-Workflows ein, indem Sie die Konfiguration der Auftragswarteschlange für das Sling-Auftragsthema des Workflows überprüfen, die maximale Anzahl paralleler Aufträge nach Möglichkeit reduzieren und sicherstellen, dass der Starter keine neuen großen Ausführungen startet, während frühere Ausführungen noch aktiv sind oder es erneut versuchen.
  5. Halten Sie Workflow-Instanzen unter Kontrolle, indem Sie die Workflow-Bereinigung konfigurieren (z. B. mit der com.adobe.granite.workflow.purge.Scheduler-Konfiguration), sodass abgeschlossene Instanzen des benutzerdefinierten Modells regelmäßig bereinigt werden und sich nicht sammeln.
  6. Validieren Sie das Verhalten nach diesen Änderungen, indem Sie einen kontrollierten Testsatz von Assets in den Upload- oder Staging-Ordner hochladen und bestätigen, dass Assets innerhalb der erwarteten Zeit zuverlässig in den Zielordner verschoben werden, dass Nachbearbeitungs-Workflows im Zielordner erfolgreich abgeschlossen werden und Metadaten sofort aktualisiert werden und dass Protokolle im Zusammenhang mit dem benutzerdefinierten Verschiebungsschritt keine häufigen OakState0002 mehr anzeigen.

Hinweise:

  • Dieses Problem resultiert aus der Interaktion benutzerdefinierter Workflows mit dem AEM as a Cloud Service-Repository bei gleichzeitiger Ausführung und nicht aus einer Fehlfunktion des Starters oder der integrierten Asset-Verarbeitung von AEM.
  • Indem Sie den Workflow so umgestalten, dass er pro Asset (oder kleinem Batch) einen Commit ausführt, und Metadaten- oder Eigenschaftsaktualisierungen in einen separaten Nachbearbeitungs-Workflow im Zielordner verschieben, reduzieren Sie den Commit-Konflikt, eliminieren den Race-Vorgang mit Metadaten und stellen eine stabile, zeitgerechte Verschiebung von Assets aus dem Upload-Ordner in den Zielordner wieder her.
recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f