O Assets não muda de upload para pasta de destino no AEMaaCS
O Assets permanece preso na pasta de upload ou de preparo quando um fluxo de trabalho personalizado falha ao movê-lo para a pasta de destino devido a conflitos de confirmação de repositório. Recrie o fluxo de trabalho para evitar grandes confirmações paralelas e atualizações de metadados divididos em um fluxo de trabalho de pós-processamento separado para resolver o problema.
Descrição description
Ambiente
- ADOBE EXPERIENCE MANAGER AS A CLOUD SERVICE - ASSETS
- Ambiente de autor, implantado pelo Cloud Manager
- Fluxo de trabalho personalizado de movimentação de ativos acionado por um iniciador ou um trabalho agendado
Problema/Sintomas
-
O Assets permanece na pasta de upload ou preparo e não aparece na pasta de destino.
-
Um fluxo de trabalho personalizado de movimentação de ativos é acionado corretamente (por exemplo, por um iniciador semelhante ao cron), mas:
- Demora muito para ser concluída, ou
- Termina com falhas e tentativas repetidas.
-
Nenhum erro é relatado para o próprio iniciador; falhas ocorrem na etapa de movimentação personalizada.
-
Um grande número de instâncias de fluxo de trabalho (por exemplo, mais de 10.000 instâncias em execução) é acumulado para o mesmo modelo de fluxo de trabalho.
-
O log de erros do AEM mostra falhas de commit com conflitos de alteração simultâneos, por exemplo:
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 -
O comportamento pós-processamento (como atualizar títulos de mídia, informações do carregador ou sinalizadores do Dynamic Media) é atrasado ou intermitente porque os ativos não chegam à pasta de destino de forma confiável.
Causa
-
Nas implementações afetadas, a etapa de movimentação de ativos personalizados foi alterada para:
- Colocar muitos ativos em lote em uma única sessão JCR grande e confirmar, e
- Execute essa lógica em paralelo em várias instâncias de fluxo de trabalho (por exemplo, por meio de um iniciador em execução a cada poucos minutos enquanto as execuções anteriores ainda estiverem ativas).
-
Sob carga, esse design leva a:
- Confirmações de ramificação simultâneas em conflito no repositório do Oak (
OakState0002), causando a falha da confirmação e a nova tentativa do trabalho de fluxo de trabalho. - Uma corrida em que o ativo é movido primeiro e os metadados no caminho original são atualizados posteriormente, para que a atualização dos metadados falhe ou seja ignorada.
- Confirmações de ramificação simultâneas em conflito no repositório do Oak (
-
O problema é um problema de contenção no nível do repositório no código de fluxo de trabalho personalizado, não um mau funcionamento do iniciador ou do processamento de ativos integrado do AEM.
Resolução resolution
Para restaurar a movimentação de ativos confiáveis e evitar conflitos de confirmação, siga estas etapas:
- Remova ou reverta qualquer lote de confirmação grande único para que a etapa de movimentação de ativos personalizada não mova e atualize vários ativos em um único
save()oucommit(), e evite designs em que centenas de ativos são movidos em uma transação. - Refatore a etapa de movimentação para que cada ativo, ou um lote muito pequeno, seja movido para o local de destino e confirmado imediatamente (por exemplo, com
session.save()ouresourceResolver.commit()). Verifique também se a etapa é idempotente por ativo e pode lidar com tentativas com segurança, capturando opcionalmenteInvalidItemStateExceptionouPersistenceExceptione implementando tentativas limitadas com registro em log. - Divida a lógica de movimentação e metadados ou pós-processamento em workflows separados, mantendo o fluxo de trabalho de movimentação focado na seleção de ativos válidos e movendo-os da pasta de upload ou preparo para a pasta de destino, e configurando um fluxo de trabalho pós-processamento separado na pasta de destino que atualize os metadados e as propriedades personalizadas (como sinalizadores do Dynamic Media ou campos usados por sistemas downstream) e seja executado por meio do mecanismo de fluxo de trabalho de pós-processamento (início automático) após a conclusão do processamento do ativo.
- Limite a simultaneidade do fluxo de trabalho de movimentação revisando a configuração da fila de trabalhos do tópico de trabalho Sling do fluxo de trabalho, reduzindo o número máximo de trabalhos paralelos, quando possível, e garantindo que o iniciador não inicie novas execuções grandes enquanto as execuções anteriores ainda estiverem ativas ou em repetição.
- Mantenha as instâncias de fluxo de trabalho sob controle configurando a limpeza do fluxo de trabalho (por exemplo, com a configuração
com.adobe.granite.workflow.purge.Scheduler) para que as instâncias concluídas do modelo personalizado sejam removidas regularmente e não sejam acumuladas. - Valide o comportamento após essas alterações carregando um conjunto controlado de testes de ativos na pasta de carregamento ou de preparo, confirmando que os ativos são movidos de forma confiável para a pasta de destino dentro do tempo esperado, que os fluxos de trabalho de pós-processamento na pasta de destino são concluídos com êxito e atualizam os metadados imediatamente, e que os logs não mostram mais conflitos de confirmação frequentes do
OakState0002relacionados à etapa de movimentação personalizada.
Notas:
- Esse problema surge de como os fluxos de trabalho personalizados interagem com o repositório do AEM as a Cloud Service em simultaneidade, não de um mau funcionamento do iniciador ou do processamento de ativos integrado do AEM.
- Ao reprojetar o fluxo de trabalho para confirmar por ativo (ou lote pequeno) e mover atualizações de metadados ou propriedades para um fluxo de trabalho pós-processamento separado na pasta de destino, você reduz a contenção de confirmação, elimina a corrida de movimentação/metadados e restaura a movimentação estável e oportuna de ativos da pasta de upload para a pasta de destino.