설명서

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 플래그 업데이트)이 지연되거나 간헐적으로 발생합니다.

원인

  • 영향을 받는 구현에서 사용자 지정 에셋 이동 단계가 다음과 같이 변경되었습니다.

    • 많은 에셋을 일괄 처리하여 하나의 큰 JCR 세션 및 커밋으로
    • 많은 워크플로우 인스턴스에서 이 논리를 동시에 실행합니다(예: 이전 실행이 아직 활성 상태인 동안 몇 분마다 실행되는 런처를 통해).

  • 로드 중 이 설계는 다음으로 이어집니다.

    • Oak 저장소(OakState0002)에서 동시 분기 커밋이 충돌하여 커밋이 실패하고 워크플로우 작업이 다시 시도됩니다.
    • 에셋이 먼저 이동되고 원래 경로의 메타데이터가 나중에 업데이트되어 메타데이터 업데이트가 실패하거나 건너뛴 경합.

  • 문제는 런처 또는 AEM의 기본 제공 에셋 처리의 오작동이 아닌 사용자 지정 워크플로 코드의 저장소 수준 경쟁 문제입니다.

해결 방법 resolution

안정적인 자산 이동을 복원하고 커밋 충돌을 방지하려면 다음 단계를 따르십시오.

  1. 사용자 지정 자산 이동 단계가 더 이상 단일 save() 또는 commit()에서 여러 자산을 이동 및 업데이트하지 않도록 단일 큰 커밋 일괄 처리를 제거하거나 되돌리고, 한 트랜잭션에서 수백 개의 자산을 이동하는 디자인을 방지하십시오.
  2. 이동 단계를 리팩터링하여 각 자산 또는 매우 작은 배치가 대상 위치로 이동되고 즉시 커밋되도록 하고(예: session.save() 또는 resourceResolver.commit() 사용), 단계가 자산별로 idempotent이고 다시 시도를 안전하게 처리할 수 있도록 하며, 선택적으로 InvalidItemStateException 또는 PersistenceException을(를) catch하고 로깅을 통해 제한된 다시 시도를 구현합니다.
  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