Skip to main content


Handle Workflow Events in AEM

Hey everybody, it's been almost three months that I have written a post. This weekend, I finally got some time and a use case which I am going to share with you. We all know workflows play a very important role in the day to day activities of AEM. It is not unheard of that you as a user want to trigger some service/component/scheduler on some of the events in a workflow. To achieve this, it is necessary that we listen to the workflow events in our code and perform our business logic as that event is triggered. In this post, we will see how we can achieve this using an EventHandler (to know how EventHandler works, see this post ). Since AEM has a rich set of APIs, we are fortunate that it has also an API through which we can listen to workflow-related events. Steps: Below are the steps through which we can listen to workflow events -  Step #1 Create an Event Handler (WorkflowEventsHandler, in our case) which implements the org.osgi.service.event.EventHandler interfac
Recent posts

Generate id for AEM components

We all know that when we add an AEM component to a page, it creates the DOM structure on the pages based upon our HTL file. Sometimes we require id attribute to be set in our div for n number of reasons. If we put id attribute in the HTL file itself then it will become static and if in include that component multiple times on the page, the same id will be repeated for all instance; which is not a neat solution. Wouldn't it be nice if we have a mechanism to generate an id randomly and uniquely for each instance of the component on the page? In this post, we are going to do just that. Hence, without further ado, let's get started - Step #1 Create a component that will have the field for unique id. We are making this id editable as well to give more flexibility to the content authors. Below is the cq:dialog.xml file - <?xml version="1.0" encoding="UTF-8"?> <jcr:root xmlns:sling= "" xmlns

Workflows in AEM 05 - Trigger Workflow Programmatically

It is often needed to trigger a workflow programmatically. Hence, in this small post, we will see how we can easily do that. package org. redquark . demo . core . servlets ; import; import java.util.Date; import java.util.HashMap; import java.util.Map; import javax.servlet.Servlet; import; import; import; import; import; import org.osgi.framework.Constants; import org.osgi.service.component.annotations.Component; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import com.adobe.granite.workflow.WorkflowException; import com.adobe.granite.workflow.WorkflowSession; import com.adobe.granite.workflow.exec.WorkflowData; import com.adobe.granite.workflow.model.WorkflowModel; /** * @a

Workflows in AEM 04 - MetaDataMap

Sometimes we are faced with a situation where we need to pass data from one workflow step to the another. AEM's workflow API provides an easy way to achieve this using MetaDataMap . Please note that only primitive data types like Integer, String etc. can be passed from one step to the another. If you have a requirement to pass non-primitive data then use the byte[] array. Caution: If the data to be passed is too large, refrain passing InputStream. Instead, a better approach is to save the data in a JCR node in the step and retrieve it from the JCR node in a later step. A MetaDataMap is the data structure which acts as a value map and allows users to set and get data among the steps. Code example Let's see a code example to demonstrate this concept. Here we will be using two process steps. In the first, we will be passing data and in the second, we will be retrieving it. package org. redquark . demo . core . workflows ; import org.osgi.

Workflows in AEM 03 - Dynamic Participant Step

A participant is a step which enables a user to assign ownership of a task to another user. The workflow will only go further if that user manually acknowledges the step. A simple use case of this workflow is a review step, i.e. if you have made some changes in an AEM page and then you want someone to review it then you can add it to the participant step and that user will get a notification in his/her inbox. Obviously, the reviewer should have access to the page in question. Dynamic Participant Step is similar to the Participant Step with the exception that the user is selected at run time. There might be a use case where you want an item to be assigned to a user who has the lowest number of items to review. The business logic of a Dynamic Participant Step can be written in a class that implements the  Participant Chooser interface. Following is a code example that selects the participant from either "admin" or a user from the "administrators" group based

Workflows in AEM 02 - Process Step

Hi everyone, it's been a long time since I wrote the first part of this blog. In the previous part, we discussed the fundamentals of workflows, their types and applications. Today, we are going to discuss the most widely used Workflow step - the process step. This is generally used when we want our application to execute a certain logic. It executes an ECMA script or an OSGi service to perform automatic processing. A process can be implemented using the following steps - Create an OSGi service implementing the interface com.adobe.granite.workflow.exec.WorkflowProcess . Set the property process.label . This is the String value by which our workflow needs to be listed. Implement the execute(WorkItem, WorkflowSession, MetaDataMap) method with the implementation code. The execute() method has three parameters - 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 t