Práticas recomendadas de workflow

Última atualização: 15 de julho de 2024

Aplica-se a:
Experience Manager 6.5

Tópicos:
Desenvolvimento

Criado para:

Desenvolvedor

Os workflows permitem automatizar as atividades do Adobe Experience Manager (AEM).

Geralmente representam uma grande quantidade do processamento que ocorre em um ambiente AEM, de modo que, quando as etapas personalizadas do fluxo de trabalho não são gravadas de acordo com as práticas recomendadas ou os fluxos de trabalho prontos para uso não são configurados para serem executados da maneira mais eficiente possível, o sistema pode sofrer como resultado.

Portanto, é altamente recomendável planejar as implementações dos workflows com cuidado.

Configuração

Ao configurar processos de fluxo de trabalho (personalizados e/ou prontos para uso), há algumas coisas que devem ser lembradas.

Workflows transitórios

Para otimizar altas cargas de assimilação, você pode definir um fluxo de trabalho como transitório.

Quando um workflow é transitório, os dados de tempo de execução relacionados às etapas de trabalho intermediárias não são mantidos no JCR quando executados (as representações de saída são mantidas).

As vantagens podem incluir:

Uma redução no tempo de processamento do fluxo de trabalho de até 10%.
Reduzir significativamente o crescimento do repositório.
Não são necessários mais workflows CRUD para limpar.
Além disso, reduz o número de arquivos TAR para compactar.

CUIDADO

Se sua empresa determinar que você mantenha/arquive os dados de tempo de execução do fluxo de trabalho para fins de auditoria, não ative esse recurso.

Ajuste de fluxos de trabalho do DAM

Para obter diretrizes de ajuste de desempenho para fluxos de trabalho do DAM, consulte o Guia de Ajuste de Desempenho do AEM Assets.

Configurar o número máximo de workflows simultâneos

O AEM pode permitir que vários threads de fluxo de trabalho sejam executados simultaneamente. Por padrão, o número de processos é configurado para ser a metade do número de núcleos de processador no sistema.

Nos casos em que os workflows que estão sendo executados exigem recursos do sistema, isso pode significar que pouco resta para o AEM usar para outras tarefas, como renderizar a interface do usuário de criação. Como resultado, o sistema pode ficar lento durante atividades como carregamento de imagens em massa.

Para resolver esse problema, a Adobe recomenda configurar o número de Máximo de Trabalhos Paralelos para que fique entre a metade e três quartos do número de núcleos de processador no sistema. Isso deve permitir capacidade suficiente para que o sistema permaneça responsivo ao processar esses workflows.

Para configurar o Máximo de Trabalhos Paralelos, você pode:

Configure a Configuração OSGi no console da Web AEM; para Fila: Fila de Fluxo de Trabalho Granite (uma Configuração de Fila de Trabalho Apache Sling).
Configure a fila com a opção Trabalhos do Sling do console da Web AEM; para Configuração da fila de trabalhos: Fila de fluxos de trabalho do Granite, em http://localhost:4502/system/console/slingevent.

Além disso, há uma configuração separada para a Fila de trabalhos do processo externo do fluxo de trabalho do Granite. Isso é usado para processos de fluxo de trabalho que iniciam binários externos, como InDesign Server ou Image Magick.

Configurar Filas de Trabalhos Individuais

Em alguns casos, é útil configurar filas de jobs individuais para controlar threads simultâneas ou outras opções de fila, com base em jobs individuais. Você pode adicionar e configurar uma fila individual no console da Web por meio da fábrica Apache Sling Job Queue Configuration. Para encontrar o tópico apropriado para listar, execute o modelo do seu fluxo de trabalho e procure-o no console Trabalhos do Sling; por exemplo, em http://localhost:4502/system/console/slingevent.

Filas de trabalhos individuais também podem ser adicionadas para fluxos de trabalho transitórios.

Configurar a limpeza de fluxo de trabalho

Em uma instalação padrão, o AEM fornece um console de manutenção em que as atividades de manutenção diárias e semanais podem ser programadas e configuradas; por exemplo, em:

http://localhost:4502/libs/granite/operations/content/maintenance.html

Por padrão, a Janela de Manutenção Semanal tem uma tarefa Limpeza de Fluxo de Trabalho, mas ela precisa ser configurada para ser executada. Para configurar as remoções de fluxo de trabalho, uma nova Configuração de remoção de fluxo de trabalho do Adobe Granite deve ser adicionada ao console da Web.

Para obter mais detalhes sobre tarefas de manutenção no AEM, consulte o Painel de Operações.

Personalização

Ao escrever processos de fluxo de trabalho personalizados, há algumas coisas que devem ser lembradas.

Localizações

As definições de modelos de fluxo de trabalho, iniciadores, scripts e notificações são mantidas no repositório de acordo com o tipo; ou seja, prontas para uso, personalizadas, entre outras.

OBSERVAÇÃO

Consulte também Reestruturação do repositório no AEM 6.5.

Locais - Modelos de fluxo de trabalho

Os modelos de fluxo de trabalho são armazenados no repositório de acordo com o tipo:

Os designs de workflow prontos para uso são mantidos no seguinte caminho:

/libs/settings/workflow/models/
CUIDADO
Não:
coloque qualquer um dos modelos de fluxo de trabalho personalizados nesta pasta

editar qualquer item em /libs
Como qualquer alteração pode ser substituída na atualização ou ao instalar hot fixes, cumulative fix packs ou service packs.
Os designs personalizados de fluxo de trabalho são mantidos em:
/conf/global/settings/workflow/models/...
Os designs do fluxo de trabalho de tempo de execução (prontos para uso e personalizados) são mantidos no seguinte caminho:

/var/workflow/models/
Os designs de fluxo de trabalho herdados (tempo de design e tempo de execução) são mantidos no seguinte caminho:

/etc/workflow/models/

NOTE
Se esses designs forem editados usando a interface do usuário AEM, os detalhes serão copiados para os novos locais.

Locais - Iniciadores de fluxo de trabalho

As definições do iniciador de fluxo de trabalho também são armazenadas no repositório de acordo com o tipo:

Os iniciadores de fluxos de trabalho prontos para uso são mantidos no seguinte caminho:

/libs/settings/workflow/launcher/
CAUTION
Não:
coloque qualquer um dos iniciadores de fluxo de trabalho personalizados nesta pasta

editar qualquer item em /libs
Como qualquer alteração pode ser substituída na atualização ou ao instalar hot fixes, cumulative fix packs ou service packs.
Os iniciadores de fluxo de trabalho personalizados são mantidos em:
/conf/global/settings/workflow/launcher/...
Os iniciadores de fluxos de trabalho herdados são mantidos no seguinte caminho:

/etc/workflow/launcher/

NOTE
Se essas definições forem editadas usando a interface do usuário AEM, os detalhes serão copiados para os novos locais.

Locais - Scripts de fluxo de trabalho

Os scripts de fluxo de trabalho também são armazenados no repositório de acordo com o tipo:

Os scripts de workflow prontos para uso são mantidos no seguinte caminho:

/libs/workflow/scripts/
CAUTION
Não:
coloque qualquer um dos scripts de fluxo de trabalho personalizados nesta pasta

editar qualquer item em /libs
Como qualquer alteração pode ser substituída na atualização ou ao instalar hot fixes, cumulative fix packs ou service packs.
Os scripts de fluxo de trabalho personalizados são mantidos em:
/apps/workflow/scripts/...
Os scripts de workflow herdados são mantidos no seguinte caminho:

/etc/workflow/scripts/

Locais - Notificações de fluxo de trabalho

As notificações de fluxo de trabalho também são armazenadas no repositório de acordo com o tipo:

As definições de notificação de workflow prontas para uso são mantidas no seguinte caminho:

/libs/settings/workflow/notification/
CAUTION
Não:
colocar qualquer uma das definições de notificação de fluxo de trabalho personalizadas nesta pasta

editar qualquer item em /libs
Como qualquer alteração pode ser substituída na atualização ou ao instalar hot fixes, cumulative fix packs ou service packs.
As definições de notificação de workflow personalizadas são mantidas em:
/conf/global/settings/workflow/notification/...
NOTE
Se quiser substituir um texto de notificação de workflow, crie um caminho sobreposto em:
/conf/global/settings/workflow/notification/<path-under-libs>
As definições de notificação de workflow herdadas são mantidas no seguinte caminho:

/etc/workflow/notification/

Sessões de Processo

Como em qualquer desenvolvimento personalizado, é sempre recomendável usar a sessão de um usuário quando possível:

para melhor adesão às diretrizes de segurança
para permitir que o sistema gerencie a abertura e o fechamento da sessão

Ao implementar um processo de workflow:

Uma sessão de fluxo de trabalho será fornecida e deverá ser usada, a menos que haja um motivo convincente para não ser fornecida.
Novas sessões não devem ser criadas a partir de etapas do fluxo de trabalho, pois isso causa inconsistências no(s) estado(s), juntamente com possíveis problemas de simultaneidade no mecanismo do fluxo de trabalho.
Você não deve adquirir uma nova sessão JCR de dentro de uma etapa do processo em um fluxo de trabalho; você deve adaptar a sessão do fluxo de trabalho fornecida pela API de etapas do processo a uma sessão jcr. Por exemplo:

public void execute(WorkItem item, WorkflowSession workflowSession, MetaDataMap args) throws WorkflowException {
        // to obtain a jcr session:
        javax.jcr.Session jcrSession = workflowSession.adaptTo(javax.jcr.Session.class);

        // to obtain a sling resource resolver:
        org.apache.sling.api.resource.ResourceResolver slingResourceResolver = workflowSession.adaptTo(org.apache.sling.api.resource.ResourceResolver.class);

Salvando uma sessão:

Em um processo de fluxo de trabalho, se o WorkflowSession estiver sendo usado para modificar o repositório, não salve explicitamente a sessão. O fluxo de trabalho salvará a sessão quando ela for concluída.
Session.Save não deve ser chamado de dentro de uma etapa do fluxo de trabalho:
- é recomendável adaptar a sessão jcr do fluxo de trabalho; então, save não é necessário, pois o mecanismo de fluxo de trabalho salva a sessão automaticamente após a conclusão da execução do fluxo de trabalho.
- não é recomendável que uma etapa do processo crie sua própria sessão jcr.
Ao eliminar salvamentos desnecessários, você pode reduzir a sobrecarga e, assim, tornar os workflows mais eficientes.

CAUTION

Se, apesar das recomendações aqui, você criar sua própria sessão jcr, ela deverá ser salva.

Minimizar o número/escopo de iniciadores

Há um ouvinte responsável por todos os iniciadores de fluxo de trabalho registrados:

Ele ouvirá as alterações em todos os caminhos especificados nas propriedades de recurso de curinga dos outros inicializadores.
Quando um evento é despachado, o mecanismo de fluxo de trabalho avaliará cada iniciador para determinar se ele deve ser executado.

Criar muitos inicializadores fará com que o processo de avaliação seja executado mais lentamente.

Criar um caminho de recurso de curinga na raiz do repositório em um único iniciador faria com que o mecanismo de fluxo de trabalho ouvisse e avaliasse a criação/modificação de eventos em cada nó no repositório. Por isso, é recomendável criar apenas os iniciadores necessários e tornar o caminho de recurso de curinga o mais específico possível.

Devido ao impacto desses inicializadores no comportamento do fluxo de trabalho, também pode ser útil desativar os inicializadores predefinidos que não estão em uso.

Aprimoramentos de configuração para iniciadores

A configuração personalizada do inicializador foi aprimorada para oferecer suporte ao seguinte:

Ter várias condições "AND" juntas.
Têm condições OR em uma única condição.
Desabilitar/habilitar inicializadores com base no fato de um sinalizador de recurso estar habilitado ou desabilitado.
Suporte a regex nas condições do iniciador.

Não iniciar workflows a partir de outros workflows

Os workflows podem transportar uma quantidade significativa de sobrecarga, tanto em termos de objetos criados na memória quanto de nós rastreados no repositório. Por esse motivo, é melhor ter um workflow fazendo seu processamento dentro de si mesmo do que iniciar workflows adicionais.

Um exemplo disso seria um fluxo de trabalho que implementa um processo de negócios em um conjunto de conteúdo e, em seguida, ativa esse conteúdo. É melhor criar um processo de fluxo de trabalho personalizado que ative cada um desses nós, em vez de iniciar um modelo Ativar conteúdo para cada um dos nós de conteúdo que precisam ser publicados. Essa abordagem exigirá trabalho de desenvolvimento adicional, mas é mais eficiente ao ser executada do que iniciar uma instância de fluxo de trabalho separada para cada ativação.

Outro exemplo seria um fluxo de trabalho que processa vários nós, cria um pacote de fluxo de trabalho e ativa esse pacote. Em vez de criar o pacote e iniciar um fluxo de trabalho separado com o pacote como a carga, você pode alterar a carga do fluxo de trabalho na etapa que cria o pacote e chamar a etapa para ativar o pacote no mesmo modelo de fluxo de trabalho.

Avanço do manipulador

Ao criar um modelo de fluxo de trabalho, você tem a opção de ativar o avanço do manipulador nas etapas do fluxo de trabalho. Como alternativa, você pode adicionar o código à etapa do fluxo de trabalho para determinar qual etapa deve ser executada em seguida e, em seguida, executá-la.

É recomendável usar o avanço do manipulador, pois ele oferece melhor desempenho.

Estágios do fluxo de trabalho

Você pode definir estágios de fluxo de trabalho e atribuir tarefas/etapas a um estágio de fluxo de trabalho específico.

Essas informações são usadas para exibir o progresso de um fluxo de trabalho quando você clica na guia Informações do Fluxo de Trabalho de um item de trabalho da Caixa de Entrada. Os modelos de fluxo de trabalho existentes podem ser editados para adicionar estágios.

Etapa do processo de ativação da página

A etapa Ativar processo de página ativará as páginas para você, mas não encontrará automaticamente nenhum ativo DAM referenciado e os ativará também.

Isso é algo para ter em mente se você planeja usar essa etapa como parte de um modelo de fluxo de trabalho.

Considerações sobre atualização

Ao atualizar sua instância:

verifique se foi feito backup de todos os modelos de fluxo de trabalho personalizados antes de atualizar uma instância.
confirme se nenhum dos seus fluxos de trabalho personalizados está armazenado no local:
- /libs/settings/workflow/models/projects

NOTE

Consulte também Reestruturação do repositório no AEM 6.5.

Ferramentas do sistema

Há muitas ferramentas de sistema disponíveis para ajudar no monitoramento, manutenção e solução de problemas de workflows. Todos os URLs de exemplo abaixo usam localhost:4502, mas devem estar disponíveis em qualquer instância de autor ( <hostname>:<port>).

Console de manuseio de trabalhos do Sling

http://localhost:4502/system/console/slingevent

O console Manuseio de trabalhos do Sling mostrará:

Estatísticas do estado dos trabalhos no sistema desde a última reinicialização.
Ele também mostrará as configurações para todas as filas de trabalhos e fornecerá um atalho para editá-las no gerenciador de configurações.

Ferramenta Relatório de fluxo de trabalho

A ferramenta de relatório de fluxo de trabalho está sendo removida na versão 6.3 para evitar a degradação do desempenho.

MBean de operações de manutenção do workflow

http://localhost:4502/system/console/jmx/com.adobe.granite.workflow:type=Maintenance

O MBean de manutenção do workflow expõe várias rotinas de manutenção úteis, como limpeza de workflows concluídos e recuperação de estatísticas de workflow.

Informações adicionais

Para obter mais informações, consulte:

recommendation-more-help