Workflow

Workflows enable you to automate Experience Manager activities. Workflows consist of a series of steps that are executed in a specific order. Each step performs a distinct activity such as activating a page or sending an email message. Workflows can interact with assets in the repository, user accounts, and Experience Manager services. Therefore, workflows can coordinate complicated activities that involve any aspect of Experience Manager

Many useful workflow models are provided with Experience Manager. In addition, any number of custom workflow models, tailored to the specific needs of your project, can be defined using the Workflow console.

Read more

Interview Questions

Note: For more on Workflow watch this video

Workflows enable you to automate Experience Manager activities. Workflows consist of a series of steps that are executed in a specific order. Each step performs a distinct activity such as activating a page or sending an email message. Workflows can interact with assets in the repository, user accounts, and Experience Manager services. Therefore, workflows can coordinate complicated activities that involve any aspect of Experience Manager

The Workflow console is the centralized location for workflow management in AEM. It can be accessed via the Workflows link on the AEM Welcome page (Classic UI), and the Tools section of the touch-optimized UI.

Within the Workflow console, there are several tabs:

  • Models - Lists the workflow models currently available. Here you can create, edit or delete workflow models.
  • Instances - Shows you details of workflow instances which are currently active. These instances are also version dependent.
  • Archive - Enables you to access details of workflow instances which have terminated, for whatever reason.
  • Launcher - Allows you to define a workflow to be launched if a specific node has been updated.
  • Failures - Enables you to monitor and manage failed worklow instances.

To define a process step as an OSGI service component.

  • 1. the OSGI component needs to implement the WorkflowProcess interface with its execute() method.
  • 2. Add the SCR property "process.label" and set the value as you please. This will be the name which your process step is listed as when using the generic Process Step component.
    import org.apache.felix.scr.annotations.Component;
    import org.apache.felix.scr.annotations.Properties;
    import org.apache.felix.scr.annotations.Property;
    import org.apache.felix.scr.annotations.Service;
    import org.osgi.framework.Constants;
    import com.adobe.granite.workflow.WorkflowException;
    import com.adobe.granite.workflow.WorkflowSession;
    import com.adobe.granite.workflow.exec.WorkItem;
    import com.adobe.granite.workflow.exec.WorkflowProcess;
    import com.adobe.granite.workflow.metadata.MetaDataMap;
    @Component
    @Service
    @Properties({
       @Property(name = Constants.SERVICE_DESCRIPTION, value = "An example workflow process implementation."),
       @Property(name = Constants.SERVICE_VENDOR, value = "my vendor"),
       @Property(name = "process.label", value = "My Sample Workflow Process") })
      public class MyProcess implements WorkflowProcess {
      public void execute(WorkItem arg0, WorkflowSession arg1, MetaDataMap arg2 )throws WorkflowException {
      // TODO Auto-generated method stub
      }
    }
    execute method has three parameters :-
    • WorkItem - A WorkItem is the unit that is passed through an Workflow instance of a WorkflowModel. It contains the WorkflowData the instances acts on and a reference to the WorkflowNode that describes the underlying workflow step. A WorkItem can be considered as a token in a petri net that flows through the net during execution. More
    • WorkflowSession - The WorkflowSession class provides all functionality (depending on the users rights) for managing WorkflowModels, Workflow instances and their execution. More
    • MetaDataMap - A value map for generic access to meta data values. More
  • 3. In the CQ Workflow console, add the process step to the workflow using the generic Process Step component.     Mountain View
  • 4. In the edit dialog, go to the Process tab and select your process implementation.(Here My Sample Workflow Process).
       Mountain View
  • 5. If you use arguments in your code set the Process Arguments
  • 6. Save the changes

Check this video:- Create custom AEM workflow step

The Dynamic Participant Step component is similar to Participant Step except the participant is selected automatically at run time.

To define a dynamic participate step as an OSGI service component.

  • 1. the OSGI component needs to implement the ParticipantStepChooser interface with its getParticipant() method.
  • 2. Add the SCR property "chooser.label" and set the value as you please. This will be the name which your Participant chooser is listed as when using the Dynamic Participant Step component.
    import org.apache.felix.scr.annotations.Component;
    import org.apache.felix.scr.annotations.Properties;
    import org.apache.felix.scr.annotations.Property;
    import org.apache.felix.scr.annotations.Service;
    import org.osgi.framework.Constants;
    import com.day.cq.workflow.WorkflowException;
    import com.day.cq.workflow.WorkflowSession;
    import com.day.cq.workflow.exec.ParticipantStepChooser;
    import com.day.cq.workflow.exec.WorkItem;
    import com.day.cq.workflow.metadata.MetaDataMap;
    @Component
    @Service
    @Properties({
        @Property(name = Constants.SERVICE_DESCRIPTION, value = "An example of a dynamic participant chooser."),
        @Property(name = ParticipantStepChooser.SERVICE_PROPERTY_LABEL, value = "My participate step") })
      public class InitiatorParticipantChooser implements ParticipantStepChooser {
        public String getParticipant(WorkItem arg0, WorkflowSession arg1,MetaDataMap arg2) throws WorkflowException {
          return "admin";
    }
    }
  • 3. In the CQ Workflow console, add the participant step to the workflow using the dynamic particpant Step component.
    participant step
  • 4. In the edit dialog, go to the Participant chooser tab and select your Participant chooser implementation.
    participant step
  • 5. If you use arguments in your code set the Arguments
  • 6. Save the changes

Workflow models consist of a series of steps of various types which can be extended with scripts to provide the functionality and control you require.

  • PROCESS STEP - It executes an ECMA script or calls an OSGi service to perform automatic processing.

       process step
    Process
    The process implementation to execute. Use the drop-down menu to select the ECMA script or OSGi service that are available
    Handler Advance
    Select this option to automatically advance the workflow to the next step after execution. If no selected, the implementation script must handle workflow advancement.
    Arguments
    Arguments to be passed to the process.
  • PARTICIPANT STEP - It enables you to assign ownership for a particular action. The workflow will only proceed when the user has manually acknowledged the step. This is used when you want someone to take an action on the workflow; for example, a review step.

       participant step

  • User/group
    A drop down selection box will allow you to navigate and select a user or group.
    Email
    You can notify participant(s) by sending them an email when the workflow reaches the step.
    If set to On, an email will be sent to the user defined by the property User/Group or to each member of the group if a group is defined.
  • CONTAINER STEP - A container step starts another workflow model that executes as a child workflow.

       Container step

  • Sub Workflow
    Select the workflow to start. more
  • OR SPLIT - It creates a split in the workflow, whereby only one branch is active. This allows you to introduce conditional processing paths into our workflow. more
  • AND SPLIT - An AND Split creates a split in the workflow; both branches will be active. This component enables you to introduce multiple processing paths into the workflow. For example you can allow certain review steps to occur in parallel, saving time. more
  • GOTO STEP - The Goto step specifies the next step in the workflow model to execute, depending on the result of an ECMA script. more

AEM has some inbuilt workflow. Example

  • DAM MetaData Writeback - This workflow manages XMP write-back to the original binary and sets the last modified date in jcr.

    If you want the feature to propagate metadata changes to select renditions of the asset, add the name of the renditions to the XMP Writeback Process workflow step of DAM Metadata WriteBack workflow. By default, this step is configured with the original rendition. more

  • Approve for Adobe Campaign - Workflow handling the edition, review and approval of a newsletter to be sent using Adobe Campaign.
  • Dam update asset - By default, upon image upload to CQ’s Digital Asset Management, a “DAM Update Asset” workflow would be triggered and one of the many processes inside the workflow is to generate a web rendition of the uploaded image. And the default setting of CQ’s Image API is to always render the web-enabled version of the uploaded image. This combination helps to limit the size and the quality of the image displayed thus reducing the page load time.

Other than this AEM has inbuilt workflow - Download Asset, Dam parse word document, etc

PARTICIPANT STEP - A participant step enables you to assign ownership for a particular action. The workflow will only proceed when the user has manually acknowledged the step. This is used when you want someone to take an action on the workflow; for example, a review step. more

DIALOG PARTICIPANT STEP - Use a Dialog Participant Step to collect information from the user who is assigned the work item. This step is useful for collecting small amounts of data that is used later 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. more

We have two built-in workflow groups.

  • workflow-editors - Group that is allowed to create and modify workflow models.
  • workflow-users - A user participating in a workflow must be member of group workflow-users. This gives him or her full access to: /etc/workflow/instances so that he or she can update the workflow instance.

Procedure to trigger a workflow programmatically.

  • Create a workflow session

    WorkflowSession wfSession = workflowService.getWorkflowSession(session);
  • Get the workflow model

    WorkflowModel wfModel = wfSession.getModel(model); # your workfllow model name
  • Get the workflow data.

    WorkflowData wfData = wfSession.newWorkflowData("JCR_PATH", path);
  • Run the Workflow.

    wfSession.startWorkflow(wfModel, wfData);
Here is Full Code.

 @Component
 @Service
 @Properties({
   @Property(name = "sling.servlet.paths", value = "/bin/programmaticallyrunworklow"),
   @Property(name = "sling.servlet.methods", value = "GET")
 })
 public class ProgrammaticallyRunWorklow extends SlingSafeMethodsServlet {
   static private final Logger log = LoggerFactory.getLogger(this.class);

   @Reference
   private WorkflowService workflowService;

   @Override
   protected void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) throws IOException {
    ResourceResolver resourceResolver = request.getResourceResolver();
    Session session = resourceResolver.adaptTo(Session.class);

    /* Get Parameters
     * @param path = path you want to run the workflow on
    * @param model = workflow model name you want to run. Typically found in /etc/workflow/models
    */
    RequestParameterMap params = request.getRequestParameterMap();
    String path = "/content/mypath";
    String model = "myworkflowmodel";
    // Create a workflow session
    WorkflowSession wfSession = workflowService.getWorkflowSession(session);
    try {
      // Get the workflow model
      WorkflowModel wfModel = wfSession.getModel(model);
      // Get the workflow data
      // The first param in the newWorkflowData method is the payloadType. Just a fancy name to let it know what type of workflow it is working with.
      WorkflowData wfData = wfSession.newWorkflowData("JCR_PATH", path);
      // Run the Workflow.
      wfSession.startWorkflow(wfModel, wfData);
    } catch (WorkflowException ex) {
      response.getWriter().write("failed");
      log.error("Error starting workflow.", ex);
    }
      response.getWriter().write("success");
    }
  }
https://helpx.adobe.com/experience-manager/using/invoking-experience-manager-workflows-using.html

We can pass values between two workflow steps in workitem

  • Set the value into first workflow step using code.
    workItem.getWorkflowData().getMetaDataMap().put("firstStepMessage", "Hello second step");
  • Get the value into Secod workflow step using code.
    workItem.getWorkflowData().getMetaDataMap().get("firstStepMessage", String.class);

Here is the full code of First workflow step

import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Properties;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;
import org.osgi.framework.Constants;
import com.adobe.granite.workflow.WorkflowException;
import com.adobe.granite.workflow.WorkflowSession;
import com.adobe.granite.workflow.exec.WorkItem;
import com.adobe.granite.workflow.exec.WorkflowProcess;
import com.adobe.granite.workflow.metadata.MetaDataMap;
 @Component(label = "First workflowstep", description = "First workflowstep ", immediate = true, metatype = true)
 @Service
 @Properties({
   @Property(name = Constants.SERVICE_DESCRIPTION, value = "Passing value between two workflow step"),
   @Property(name="process.label", value="First Workflow Step")})
 public class FirstWorkflowStep implements WorkflowProcess{

   @Override
   public void execute(WorkItem workItem, WorkflowSession workflowSession, MetaDataMap metaDataMap) throws WorkflowException {


    /** Set value in workitem **/
    workItem.getWorkflowData().getMetaDataMap().put("firstStepMessage", "Hello second step");
  }

 }

Here is the full code of Second workflow step

import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Properties;
import org.apache.felix.scr.annotations.Property;
import org.apache.felix.scr.annotations.Service;
import org.osgi.framework.Constants;
import com.adobe.granite.workflow.WorkflowException;
import com.adobe.granite.workflow.WorkflowSession;
import com.adobe.granite.workflow.exec.WorkItem;
import com.adobe.granite.workflow.exec.WorkflowProcess;
import com.adobe.granite.workflow.metadata.MetaDataMap;
 @Component(label = "Second workflowstep", description = "Second Step workflowstep ", immediate = true, metatype = true)
 @Service
 @Properties({
   @Property(name = Constants.SERVICE_DESCRIPTION, value = "Passing value between two workflow step"),
   @Property(name="process.label", value="Second Workflow Step")})
 public class SecondWorkflowStep implements WorkflowProcess {
   @Override
   public void execute(WorkItem workItem, WorkflowSession workflowSession, MetaDataMap metaDataMap) throws WorkflowException {
    /** get value from Workitem **/
    String firstStepMessage = workItem.getWorkflowData().getMetaDataMap().get("firstStepMessage", String.class);

  }

 }