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.

Tuning DAM 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.

Configure the queue can from the Sling Jobs option of the AEM Web console; for Job Queue Configuration: Granite Workflow Queue, at http://localhost:4502/system/console/slingevent.

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

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

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

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.

Inside a workflow process, if the WorkflowSession is being used to modify the repository then do not explicitly save the session - the workflow will save the session when it completes.

Session.Save should not be called from within a workflow step:

it is recommended to adapt the workflow jcr session; then save is not necessary as the workflow engine saves the session automatically once the workflow has finished executing.

it is not recommended for a process step to create its own jcr session.

By eliminating unnecessary saves, you can reduce overhead and thus make the workflows more efficient.

Attenzione:

If, despite the recommendations here, you do create your own jcr session, then it will need to be saved.

Minimize the Number/Scope of Launchers

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

It will listen for changes at all of the paths specified in the globbing properties of the other launchers.

When an event is dispatched, the workflow engine will then evaluate each launcher to determine if it should run.

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

Disable/enable launchers based on whether a feature flag is enabled or disabled.

Support regex in launcher conditions.

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

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

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

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

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

The Sling Job Handling console will show:

Statistics on the state of jobs in the system since the last restart.

It will also show the configurations for all job queues and provide a shortcut to editing them in the configuration manager.

Workflow Report Tool

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