AEM provides several tools and resources for creating worklfow models, developing workflow steps, and for programmatically interacting with workflows.
Developing and Extending 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, and each step accomplishes a discrete task. Use logic and runtime data to make decisions when a process can continue using 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 workflow is made of steps. Automated steps, also called process steps, can be defined by using either an ECMA script or a service (a Java class in a bundle). Rules for OR split can be defined with ECMA scripts. Services can be developed to listen to special workflow events and perform tasks according to the business logic. The Java API, the main workflow objects and the REST API are described. The last section explains how to change the workflow specific log level to efficiently debug the code.
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. Running Workflow Instances keep the initial workflow model version that is set when the workflow is started.
There are different types of workflow steps:
- Participant (User/Group): These types of steps generate a work item and assigns it to a user or group. A user must complete the work item to advance the workflow.
- Process (Script, Java method call): This type of step is executed automatically by the system. An ECMA script or Java class implements the step.
- Container (Sub Workflow): This step starts another workflow model.
- OR Split/Join: Uses logic to decide which step to execute next in the workflow.
- AND Split/Join: Executes multiple steps simultaneously.
All the steps share the following common properties: Autoadvance and Timeout alerts (scriptable).
Is the "there is a task identifier" 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 either a path or an UUID) or a resource by a 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 logged in user has its own workflow inbox in which the assigned WorkItems are accessible.
The WorkItems are assigned either to the user itself or to the group to which he belongs.
Workflows are at the center of how form submissions in AEM are typically processed. 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.