Workflows
What are workflows?
• A workflow is nothing but a way to automate AEM activities by executing some steps in
a specific order to achieve the desired results.
• Each step performs an individual activity such as publishing a page, creating a version of
the page, sending an email message etc.
• For example, the most common activity in AEM is publishing the page from the author
instance to the publish instance. But sometimes we want the approval of the changes
by some reviewers before publishing. This can be easily achieved by implementing
workflows in AEM.
• There are many workflows provided out of the box in AEM. Apart from those, if we
want, we can also define our custom workflows for our specific activities.
Workflow Console
1. Models: Lists the workflow models that are currently available. We can also create, edit
and delete a new workflow here.
2. Instances: This tab shows the details of the currently active workflow. These instances
are also version dependent.
3. Archive: This shows the list of terminated workflows, for whatever reason.
4. Launcher: Allows us to define a workflow to be launched if a specific node has been
updated. Sometimes launchers are used in place of JCR event listeners.
5. Failures: This tab shows the details of the failed workflows along with their error trace
and at which step it failed.
Workflow Steps
• Process Step: It executes an ECMA script or an OSGi service to perform automatic
processing.
• Participant Step: This type of step enables us to assign ownership for a particular action.
The workflow will only proceed when the user has manually acknowledged the step.
This is used when we want someone to take any action on the workflow.
• Dialog Participant Step:
▪ This is used to collect information from the user who is assigned the work item.
▪ The data can be later used in the workflow.
▪ Upon completing the step, the Complete Work Item dialog contains the fields
that you define in your dialog.
▪ The data that is collected in the fields is stored in nodes of the workflow payload.
▪ Subsequent workflow steps can then read the value from the repository.
▪ To configure the step, we specify the group or user to assign the work item to,
and the path to the dialog.
• OR Split: This creates a split in the workflow, after which only one branch will be active
(logical OR operation). This step enables us to introduce conditional processing paths
into your workflow. We add workflow steps to each branch as required.
• AND Split: The AND Split creates a split in the workflow, after which both branches will
be active (logical AND operation). We add workflow steps to each branch as required.
This step enables us to introduce multiple processing paths into the workflow.
• Container Step: A container step starts another workflow model that executes as a child
workflow. This container can allow you to reuse workflow models to implement
common sequences of steps.
• GOTO Step: The Goto Step allows us to specify the next step in the workflow model to
execute, dependent on the result of an ECMAScript:
a) true: The Goto Step completes and the workflow engine executes the specified
step.
b) false: The Goto Step completes and the normal routing logic determines the
next step to execute.
The Goto Step enables us to implement advanced routing structures in our workflow
models.
How to create custom process workflow?
A. Create an OSGi service implementing the interface
com.adobe.granite.workflow.exec.WorkflowProcess
B. Set the property process.label. This is the String value by which our workflow
needs to be listed.
C. Implement the execute(WorkItem, WorkflowSession, MetaDataMap) method
with the implementation code.
How to create custom participant workflow?
A. Create an OSGi service implementing the interface
com.adobe.granite.workflow.exec.ParticipantStepChooser
B. Set the property chooser.label. This is the String value by which our workflow
needs to be listed.
C. Implement the getParticipant(WorkItem, WorkflowSession, MetaDataMap)
method with the implementation code.
The execute() method has three parameters
1. WorkItem: It is the unit that is passed through a Workflow instance of a
WorkflowModel. It contains the - WorkflowData. The instances act on and a
reference to the WorkflowNode that describes the underlying workflow step.
2. WorkflowSession: This class provides all functionality (depending on the users’
rights) for managing WorkflowModels, Workflow instances and their execution.
3. MetaDataMap: A value map for generic access to meta data values.
