AEM provides several tools and resources for creating worklfow 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.
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 version of the workflow model version that is available when the workflow was started. Edits to the workflow model that occur after the specific instance was started will not be applied to that instance.
The steps performed are those defined by the workflow model at the time the instance is generated.
If the workflow model is changed after this point in time, then the instance will not reflect those changes. Only instances 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:
- Participant (User/Group): These steps generate a work item and assign it to a user or group. A user must complete the work item to advance the workflow.
- Process (Script, Java method call): These steps are executed automatically by the system. An ECMA script or Java class implements the step. Services can be developed to listen to special workflow events and perform tasks according to the business logic.
- Container (Sub Workflow): This type of step starts another workflow model.
- OR Split/Join: Use logic to decide which step to execute next in the workflow.
- AND Split/Join: Allows multiple steps to be executed simultaneously.
All the steps share the following common properties: Autoadvance and Timeout alerts (scriptable).
A WorkflowTransition represents a transition between two WorkflowNodes of a WorkflowModel.
- It defines the link between two consecutive steps.
- It is possible to apply rules.
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.
- It is used to identify the task and is put into the respective inbox.
- A workflow instance can have one or many WorkItems at the same time (depending on the workflow model).
- The WorkItem references the workflow instance.
- In the repository the 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.
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:
- are run often.
- do not need the workflow history.
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:
- The payload type (for example, video) requires external steps for processing; in such cases the runtime history is needed for status confirmation.
- The workflow enters an AND Split; in such cases the runtime history is needed for status confirmation.
- When the transient workflow enters a participant step it changes mode (at runtime) to non-transient; as the task is being passed to a person the history needs to 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.
Typically, workflows are used to process form submissions in AEM. This can be with the Form components available in a standard AEM instance, or with the AEM Forms solution. Workflows are also an integral part of the Translation process.
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.