AEM provides several tools and resources for creating workflow models, developing workflow steps, and for programmatically interacting with workflows.
Workflows enable you to automate processes for managing resources and publishing content in your AEM environment. Workflows are comprised of a series of steps, with each step accomplishing a discrete task. You can use logic and runtime data to make decisions as to when a process can continue and select the next step from one of multiple possible steps.
For example, business processes for creating and publishing web pages include approval and sign-off tasks by various participants. These processes can be modeled using AEM workflows and applied to specific content.
Key aspects are covered below, while the following pages cover further details:
For information about:
A WorkflowModel
represents a definition (model) of a workflow. It is made of WorkflowNodes
and WorkflowTransitions
. The transitions connect the nodes and define the flow. The Model has always a start node and an end node.
Workflow models are versioned. When you run a workflow instance it will use (and keep) the runtime model of the workflow (as available at the time the workflow was started).
A runtime model is generated when Sync is triggered in the workflow model editor.
Edits to the workflow model that occur, and/or runtime models that are generated, after the specific instance was started will not be applied to that instance.
The steps performed are those as defined by the runtime model; this is generated at the time the Sync action is triggered in the workflow model editor.
If the workflow model is changed after this point in time (without Sync being triggered), then the runtime instance will not reflect those changes. Only runtime models generated after the update will reflect the changes. The exceptions are the underlying ECMA scripts, which are held only once so changes to these are taken.
Each step accomplishes a discrete task. There are different types of workflow steps:
All the steps share the following common properties: Autoadvance
and Timeout
alerts (scriptable).
A WorkflowTransition
represents a transition between two WorkflowNodes
of a WorkflowModel
.
A WorkItem
is the unit that is passed through an Workflow
instance of a WorkflowModel
. It contains the WorkflowData
that the instance acts on and a reference to the WorkflowNode
that describes the underlying workflow step.
WorkItems
at the same time (depending on the workflow model).WorkItem
references the workflow instance.WorkItem
is stored below the workflow instance.References the resource that has to be advanced through a workflow.
The payload implementation references a resource in the repository (by path, UUID or URL) or by a serialized java object. Referencing a resource in the repository is very flexible and in conjunction with sling very productive; for example the referenced node could be rendered as a form.
Is created when starting a new workflow (by choosing the respective workflow model and defining the payload) and ends when the end node is processed.
The following actions are possible on a workflow instance:
Completed and terminated instances are archived.
Each user account has its own workflow inbox in which the assigned WorkItems
are accessible.
The WorkItems
are assigned to either the user account directly or to the group to which they belongs.
There are various types of workflow as indicated in the Workflow Models console:
Default
These are the out-of-the-box workflows included in a standard AEM instance.
Custom workflows (no indicator in the console)
These are workflows that have been created as new, or from out-of-the-box workflows that have been overlaid with customizations.
Legacy
Workflows created in a prior version of AEM. These can be retained during an upgrade, or exported as a workflow package from the prior version, then imported into the new version.
Standard workflows save runtime (history) information during their execution. You can also define a workflow model as Transient to avoid such history being persisted. This is used for performance tuning as it saves/avoids the time/resources used for persisting the information.
Transient workflows can be used for any workflows that:
Transient workflows were introduced for loading a large number of assets, where the asset information is important, but not the workflow runtime history.
See Creating a Transient Workflow for further details.
When a workflow model has been flagged as Transient, there are a few scenarios when the runtime information will still be persisted:
Within a transient workflow you should not use a Goto Step.
This is as the Goto Step creates a sling job to continue the workflow at the goto
point. This defeats the purpose of making the workflow transient and generates an error in the log file.
To make decisions in a transient workflow you can use the OR Split.
See Best Practices for Assets for further information about how Transient Workflows impact Asset performance.
Activating Multi Resource Support for your workflow model means that a single workflow instance will be started even when you select multiple resources; these will be attached as a package.
If Multi Resource Support is not activated for your workflow model and multiple resources are selected, then an individual workflow instance will be started for each resource.
See Configuring a Workflow for Multi Resource Support for further details.
Workflow Stages help visualize the progress of a workflow when handling tasks. They can be used to provide an overview of how far the workflow is through processing, as when the workflow is run, the user can view the progress described by Stage (as opposed to individual step).
As the individual step names can be specific and technical, the stage names can be defined to provide a conceptual view of the workflow progress.
For example, for a workflow with six steps and four stages:
Step Name | Stage (assigned to the step) |
---|---|
Step 1 | Create |
Step 2 | Create |
Step 3 | Review |
Step 4 | Approve |
Step 5 | Complete |
Step 6 | Complete |
When the workflow is run, the user can view the progress according to the Stage names (instead of the step names). The workflow progress will be displayed in the WORKFLOW INFO tab of the task details window of the workitem listed in the Inbox.
Typically, workflows are used to process form submissions in AEM. This can be with the core components form components available in a standard AEM instance, or with the AEM Forms solution.
When creating a new form, the form submission can be easily associated with a workflow model; for example to store the content in a particular location of the repository or to notify a user about the form submission and its content.
Workflows are also an integral part of the Translation process.