ドキュメント

AssetsがAEMaaCSのアップロードからターゲットフォルダーに移動しない

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

リポジトリのコミットの競合により、カスタムワークフローがターゲットフォルダーへの移動に失敗した場合、Assetsはアップロードフォルダーまたはステージングフォルダー内で停止したままになります。 ワークフローを再設計して、大規模な並列コミットを回避し、メタデータの更新を別の後処理ワークフローに分割して問題を解決します。

説明 description

環境

  • ADOBE EXPERIENCE MANAGER AS A CLOUD SERVICE - ASSETS
  • Cloud Managerを介してデプロイされたオーサー環境
  • ランチャーまたはスケジュールされたジョブによってトリガーされるカスタムアセット移動ワークフロー

問題/症状

  • Assetsはアップロードフォルダーまたはステージングフォルダーに残り、ターゲットフォルダーには表示されません。

  • カスタムのアセット移動ワークフローが正しくトリガーされます（例えば、クローンのようなランチャーによって）。ただし、次のようになります。

    • 完了するのに非常に長い時間がかかります。または
    • 繰り返し失敗および再試行で終了します。

  • ランチャー自体にエラーは報告されません。カスタム移動手順でエラーが発生します。

  • 同じワークフローモデルに対して、多数のワークフローインスタンス（例えば、10,000以上の実行中のインスタンス）が蓄積されます。

  • AEMのエラーログには、次の例のように、同時変更の競合を伴うコミットの失敗が表示されます。

    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

  • アセットがターゲットフォルダーに確実に到達しないため、後処理動作（メディアタイトル、アップローダー情報、Dynamic Media フラグの更新など）が遅延または断続的になります。

原因

  • 影響を受ける実装では、カスタムアセットの移動ステップが次のように変更されました。

    • 多数のアセットを1つの大きなJCR セッションにバッチで移動し、コミットし、および
    • 多くのワークフローインスタンス間で、このロジックを並行して実行します（例えば、以前の実行がまだアクティブである間、数分ごとに実行されるランチャーを介して）。

  • loadでは、このデザインは次のようになります。

    • Oak リポジトリ （OakState0002）で同時ブランチ コミットが競合しているため、コミットが失敗し、ワークフロージョブが再試行されます。
    • アセットが最初に移動され、元のパスのメタデータが後で更新されるため、メタデータの更新が失敗するか、スキップされます。

  • この問題は、カスタムワークフローコードのリポジトレベルの競合の問題であり、ランチャーやAEMの組み込みアセット処理の誤動作ではありません。

解決策 resolution

信頼性の高いアセットの移動を復元し、コミットの競合を防ぐには、次の手順に従います。

  1. 単一の大規模なコミットのバッチ処理を削除または元に戻して、カスタム アセットの移動ステップが1つのsave()またはcommit()で複数のアセットを移動および更新しなくなり、1つのトランザクションで数百のアセットが移動されるデザインを回避します。
  2. 各アセット、または非常に小さなバッチがターゲットの場所に移動され、すぐにコミットされるように移動ステップをリファクタリングし（例：session.save()またはresourceResolver.commit()）、ステップがアセットごとに同じ権限を持ち、再試行を安全に処理できることを確認します。オプションでInvalidItemStateExceptionまたはPersistenceExceptionを取得し、ログで境界のある再試行を実装します。
  3. 有効なアセットを選択してアップロードまたはステージングフォルダーからターゲットフォルダーに移動する作業ワークフローを維持し、メタデータとカスタムプロパティ（Dynamic Media フラグやダウンストリームシステムで使用されるフィールドなど）を更新し、アセット処理が完了した後に後処理（自動開始）ワークフローメカニズムを介して実行するターゲットフォルダーに個別の後処理ワークフローを設定することで、移動とメタデータまたは後処理ロジックを個別に分割します。
  4. ワークフローのSling ジョブトピックのジョブキュー設定を確認し、可能な場合は並列ジョブの最大数を減らし、以前の実行がまだアクティブまたは再試行している間にランチャーが新しい大規模な実行を開始しないようにすることで、移動ワークフローの同時実行を制限します。
  5. （例えば、com.adobe.granite.workflow.purge.Scheduler設定で）ワークフローのパージを設定することで、ワークフローインスタンスを制御し、完了したカスタムモデルのインスタンスが定期的にパージされ、蓄積されないようにします。
  6. これらの変更の後に動作を検証するには、制御されたアセットのテストセットをアップロードまたはステージングフォルダーにアップロードし、アセットが予想される時間内にターゲットフォルダーに確実に移動すること、ターゲットフォルダー内の後処理ワークフローが正常に完了し、メタデータを迅速に更新すること、カスタム移動手順に関連する頻繁なOakState0002 コミット競合がログに表示されなくなったことを確認します。

注意：

  • この問題は、ランチャーの誤動作やAEMの組み込みアセット処理ではなく、カスタムワークフローが同時実行時にAEM as a Cloud Service リポジトリとどのように相互作用するかに起因します。
  • アセット（または小規模なバッチ）ごとにコミットするワークフローを再設計し、メタデータまたはプロパティの更新をターゲットフォルダー内の個別の後処理ワークフローに移動することで、コミット競合を減らし、移動/メタデータレースを排除し、アップロードフォルダーからターゲットフォルダーへのアセットの安定したタイムリーな移動を復元します。
recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f