Workflow Best Practices workflow-best-practices

Workflows enable you to automate Adobe Experience Manager (AEM) activities.

They often represent a large amount of the processing that occurs in an AEM environment, so when custom workflow steps are not written according to best practices, or out-of-the-box workflows are not configured to run as efficiently as possible, the system can suffer as a result.

It is therefore highly recommended to plan your workflows implementations carefully.

Configuration configuration

When configuring workflow processes (customized and/or out-of-the-box), there are a few things that should be kept in mind.

Transient Workflows transient-workflows

To optimize high ingestion loads you can define a workflow as transient.

When a workflow is transient the runtime data related to the intermediate worksteps are not persisted in the JCR when they run (the output renditions are persisted of course).

The advantages can include:

Tuning DAM Workflows tuning-dam-workflows

For performance tuning guidelines for DAM workflows, see the AEM Assets Performance Tuning Guide.

Configure the Maximum Number of Concurrent Workflows configure-the-maximum-number-of-concurrent-workflows

AEM can allow multiple workflow threads to run concurrently. By default the number of threads is configured to be half the number of processor cores on the system.

In cases where the workflows being executed are demanding of system resources, this can mean little is left for AEM to use for other tasks, such as rendering the authoring UI. As a result, the system may be sluggish during activities such as bulk image uploading.

To address this issue, Adobe recommends configuring the number of Maximum Parallel Jobs to be between half to three-quarters of the number of processor cores on the system. This should allow enough capacity for the system to stay responsive when processing these workflows.

To configure Maximum Parallel Jobs, you can either:

Additionally, there is a separate configuration for the Granite Workflow External Process Job Queue. This is used for workflow processes that launch external binaries, such as InDesign Server or Image Magick.

Configure Individual Job Queues configure-individual-job-queues

In some cases it is useful to configure individual job queues to control concurrent threads, or other queue options, on an individual job basis. You can add and configure an individual queue from the Web console via the Apache Sling Job Queue Configuration factory. To find the appropriate topic to list, execute your workflow’s model and look for it in the Sling Jobs console; for example, at http://localhost:4502/system/console/slingevent.

Individual job queues can be added for transient workflows as well.

Configure Workflow Purging configure-workflow-purging

In a standard installation AEM provides a maintenance console where daily and weekly maintenance activities can be scheduled and configured; for example, at:

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

By default, the Weekly Maintenance Window has a Workflow Purge task, but this needs to be configured before it will run. To configure workflow purges, a new Adobe Granite Workflow Purge Configuration must be added in the Web console.

For further details on maintenance tasks in AEM, see the Operations Dashboard.

Customization customization

When writing custom workflow processes, there are some things that should be kept in mind.

Locations locations

Definitions of workflow models, launchers, scripts and notifications are held in the repository according to type; i.e. out-of-the-box, custom, amongst others.

Locations - Workflow Models locations-workflow-models

Workflow models are stored in the repository according to type:

Locations - Workflow Launchers locations-workflow-launchers

Workflow launcher definitions are also stored in the repository according to type:

Locations - Workflow Scripts locations-workflow-scripts

Workflow scripts are also stored in the repository according to type:

Locations - Workflow Notifications locations-workflow-notifications

Workflow notifications are also stored in the repository according to type:

Process Sessions process-sessions

As in any custom development, it is always recommended to use a user’s session when possible:

When implementing a workflow process:

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);

Saving a session:

Minimize the Number/Scope of Launchers minimize-the-number-scope-of-launchers

There is one listener that is responsible for all of the workflow launchers that are registered:

Creating too many launchers will cause the evaluation process to run more slowly.

Creating a globbing path at the root of the repository on a single launcher would cause the workflow engine to listen for and evaluate create/modify events to every node in the repository. For this reason, it is recommended to only create launchers that are needed and to make the globbing path as specific as possible.

Due to the impact of these launchers on workflow behavior, it can also be helpful to disable any out-of-the-box launchers that are not in use.

Configuration Enhancements for Launchers configuration-enhancements-for-launchers

The custom launcher configuration has been enhanced to support the following:

Do Not Start Workflows from other Workflows do-not-start-workflows-from-other-workflows

Workflows can carry a significant amount of overhead, both in terms of objects created in memory and nodes tracked in the repository. For this reason, it is better to have a workflow do its processing within itself rather than start additional workflows.

An example of this would be a workflow that implements a business process on a set of content and then activates that content. It is better to create a custom workflow process that activates each of these nodes, rather than starting an Activate Content model for each of the content nodes that needs to be published. This approach will require additional development work, but is more efficient when executed than starting a separate workflow instance for each activation.

Another example would be a workflow that processes a number of nodes, creates a workflow package, then activates said package. Rather than creating the package and then starting a separate workflow with the package as the payload, you can change the payload of your workflow in the step that creates the package and then call the step to activate the package within the same workflow model.

Handler Advance handler-advance

When designing a workflow model you have the option to enable handler advance on your workflow steps. Alternately, you can add code to your workflow step to determine which step should be run next and then execute it.

It is recommened to use handler advance as it delivers better performance.

Workflow Stages workflow-stages

You can define workflow stages, then assign tasks/steps to a specific workflow stage.

This information is used for displaying the progress of a workflow when you click on the Workflow Info tab of a workitem from the Inbox. Existing workflow models can be edited to add stages.

Activate Page Process Step activate-page-process-step

The Activate Page Process step will activate pages for you, but it will not automatically find any referenced DAM assets and activate those as well.

This is something to keep in mind if you plan to use this step as part of a workflow model.

Upgrade Considerations upgrade-considerations

When upgrading your instance:

System Tools system-tools

There are many system tools available to help with monitoring, maintaining, and troubleshooting workflows. All example URLs below use localhost:4502, but should be available on any author instance ( <hostname>:<port>).

Sling Job Handling Console sling-job-handling-console

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

The Sling Job Handling console will show:

Workflow Report Tool workflow-report-tool

The workflow reporting tool is being removed in 6.3 to prevent performance degradation.

Workflow Maintenance Operations MBean workflow-maintenance-operations-mbean

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

The workflow maintenance MBean exposes several useful maintenance routines such as purging completed workflows and retrieving workflow statistics.

Further Information further-information

For further information see: