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.
When configuring workflow processes (customized and/or out-of-the-box), there are a few things that should be kept in mind.
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:
- A reduction in the workflow processing time; of upto 10%.
- Significantly reduce repository growth.
- No more CRUD workflows are required to purge.
- In addition, it reduces the number of TAR files to compact.
If your business dictates that you persist/archive workflow runtime data for audit purposes, do not enable this feature.
For performance tuning guidelines for DAM workflows, see the AEM Assets Performance Tuning Guide.
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:
- Configure the OSGi Configuration from the AEM Web console; for Queue: Granite Workflow Queue (an Apache Sling Job Queue Configuration).
- 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.
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.
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.
For further details on maintenance tasks in AEM, see the Operations Dashboard.
It is not recommended to edit any of the out-of-the-box workflows as you would (potentially) have to re-apply the edits after applying any form of update (e.g upgrade, service pack, feature pack, hot-fix amongst others).
It is recommended to either clone and modify the workflow model or, for specific scenarios, to use overlays; for example, see Example: Customized Request for Activation.
It is not recommended to edit any of the out-of-the-box workflow launchers as you would (potentially) have to re-apply the edits after applying any form of update (e.g upgrade, service pack, feature pack, hot-fix amongst others).
It is recommended to clone and modify the workflow launcher.
The following path is meant for out-of-the-box workflows:
Do not place any of your custom workflow models in this folder, as they may be overwritten at upgrade or when installing hot-fixes, cumulative fix packs or service packs.
As in any custom development, it is always recommended to use a user’s session when possible:
- for best adherence to security guidelines
- to allow the system to manage opening and closing the session
When implementing a workflow process:
- A workflow session will be provided and should be used unless there is a compelling reason not to.
- You should not acquire a new JCR session from within a process step in a workflow; you should use the workflow session provided by the Process Step API.
- New sessions should not be created from workflow steps as this causes inconsistencies in the state(s) together with possible concurrency issues in the workflow engine.
Saving a session:
- 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 not necessary as the workflow engine saves the session automatically once the workflow has finished executing.
- By eliminating unnecessary saves, you can reduce overhead and thus make the workflows more efficient.
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.
The custom launcher configuration has been enhanced to support the following:
- Have multiple conditions "AND"ed together.
- Have OR conditions within a single condition.
- Disable/enable launchers based on whether a feature flag is enabled or disabled.
- Support regex in launcher conditions.
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.
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.
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.
When upgrading your instance:
- make sure that any custom workflow models are backed up before an instance is upgraded.
- confirm that none of your custom workflows are stored under the location /etc/workflow/models/projects
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>).
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.
The workflow maintenance MBean exposes several useful maintenance routines such as purging completed workflows and retrieving workflow statistics.