Workflow Step Reference workflow-step-reference

Workflow models consist of a series of steps of various types. According to the type, these steps can be configured and extended with parameters and scripts to provide the functionality and control you require.

Step Properties step-properties

Each step component has a Step Properties dialog that lets you define and edit the required properties.

Step Properties - Common tab step-properties-common-tab

A combination of the following properties are available for most workflow step components, on the Common tab of the properties dialog:

Step Properties - User/Group tab step-properties-user-group-tab

The following properties are available for many workflow step components, on the User/Group tab of the properties dialog:

AND Split and-split

The AND Split creates a split in the workflow, after which both branches will be active. You add workflow steps to each branch as required. This step enables you to introduce multiple processing paths into the workflow. For example, you can allow certain review steps to occur in parallel, so saving time.

AND Split - Configuration and-split-configuration

Container Step container-step

A Container step starts another workflow model that runs as a child workflow.

This Container lets you reuse workflow models to implement common sequences of steps. For example a translation workflow model could be used in multiple editing workflows.

Container Step - Configuration container-step-configuration

To configure the step, edit and use the following tabs:

Goto Step goto-step

The Goto Step allows you to specify the next step in the workflow model to execute, dependent on the result of an ECMAScript:

The Goto Step enables you to implement advanced routing structures in your workflow models. For example, to implement a loop, the Goto Step can be defined to execute a prior step in the workflow, with the script evaluating a loop condition.

Goto Step - Configuration goto-step-configuration

To configure the step, edit and use the following tabs:

Simulating a for Loop simulating-a-for-loop

Simulating a for loop requires that you maintain a count of the number of loop iterations that have occurred:

For example, to implement a workflow that performs an action on several JCR nodes you can use a loop counter as an index for the nodes. To persist the count, store an integer value in the data map of the workflow instance. Use the script of the Goto Step to increment the count as well as to compare the count to the exit criteria.

function check(){
   var count=0;
   var keyname="loopcount"
   try{
      if (workflowData.getMetaDataMap().containsKey(keyname)){
        log.info("goto script: found loopcount key");
        count= parseInt(workflowData.getMetaDataMap().get(keyname))+1;
      }

     workflowData.getMetaDataMap().put(keyname,count);

     }catch(err) {
         log.info(err.message);
         return false;
    }
   if (parseInt(count) <7){
       return true;
   } else {
      return false;
   }
}

OR Split or-split

The OR Split creates a split in the workflow, after which only one branch will be active. This step enables you to introduce conditional processing paths into your workflow. You add workflow steps to each branch as required.

OR Split - Configuration or-split-configuration

Participant Steps and Choosers participant-steps-and-choosers

Participant Step 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.

Although not directly related, user authorization must be considered when assigning an action; the user must have access to the page that is the workflow payload.

Participant Step - Configuration participant-step-configuration

To configure the step, edit and use the following tabs:

Dialog Participant Step 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.

To configure the step, you specify the group or user to assign the work item to, and the path to the dialog.

Dialog Participant Step - Configuration dialog-participant-step-configuration

To configure the step, edit and use the following tabs:

Dialog Participant Step – Creating a dialog dialog-participant-step-creating-a-dialog

To create a dialog:

Dialog Participant Step - Storing Data in the Payload dialog-participant-step-storing-data-in-the-payload

You can store widget data in the workflow payload or in the work item metadata. The format of the name property of the widget node determines where the data is stored.

Dialog Participant Step - Dialog Definition dialog-participant-step-dialog-definition

Dynamic Participant Step dynamic-participant-step

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

To configure the step, you select a Participant Chooser that identifies the participant to assign the work item to, together with a dialog.

Dynamic Participant Step - Configuration dynamic-participant-step-configuration

To configure the step, edit and use the following tabs:

Dynamic Participant Step - Developing the participant chooser dynamic-participant-step-developing-the-participant-chooser

You create the participant chooser. Therefore, you can use any selection logic or criteria. For example, your participant chooser can select the user (within a group) that has the fewest work items. You can create any number of participant choosers to use with different instances of the Dynamic Participant Step component in your workflow models.

Create an OSGi service or an ECMAScript that selects a user to assign the work item to.

Dynamic Participant Step - Example Participant Chooser Service dynamic-participant-step-example-participant-chooser-service

The following Java class implements the ParticipantStepChooser interface. The class returns the name of the participant who initiated the workflow. The code uses the same logic that the sample script ( initator-participant-chooser.ecma) uses.

The @Property annotation sets the value of the SERVICE_PROPERTY_LABEL field to Workflow Initiator Participant Chooser.

package com.adobe.example;

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 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.ParticipantStepChooser;
import com.adobe.granite.workflow.exec.WorkItem;
import com.adobe.granite.workflow.metadata.MetaDataMap;

@Component
@Service
@Properties({
        @Property(name = Constants.SERVICE_DESCRIPTION, value = "An example implementation of a dynamic participant chooser."),
        @Property(name = ParticipantStepChooser.SERVICE_PROPERTY_LABEL, value = "Workflow Initiator Participant Chooser (service)") })
public class InitiatorParticipantChooser implements ParticipantStepChooser {

 private Logger logger = LoggerFactory.getLogger(this.getClass());

 public String getParticipant(WorkItem arg0, WorkflowSession arg1,
   MetaDataMap arg2) throws WorkflowException {

  String initiator = arg0.getWorkflow().getInitiator();
  logger.info("Assigning Dynamic Participant Step work item to {}",initiator);

  return initiator;
 }
}

In the Dynamic Participant Step properties dialog, the Participant Chooser list includes the item Workflow Initiator Participant Chooser (script), which represents this service.

``When the workflow model is started, the log indicates the ID of the user who initiated the workflow and who is assigned the work item. In this example, the admin user started the workflow.

13.09.2015 15:48:53.037 *INFO* [10.176.129.223 [1347565733037] POST /etc/workflow/instances HTTP/1.1] com.adobe.example.InitiatorParticipantChooser Assigning Dynamic Participant Step work item to admin

Form Participant Step form-participant-step

The Form Participant Step presents a form when the work item is opened. When the user fills and submits the form, the field data is stored in the nodes of the workflow payload.

To configure the step, you specify the group or user to assign the work item to, and the path to the form.

Form Participant Step - Configuration form-participant-step-configuration

To configure the step, edit and use the following tabs:

Form Participant Step - Creating the form form-participant-step-creating-the-form

Create a form for use with a Form Participant Step as normal. However, forms for a Form Participant Step must have the following configurations:

The requirements of your workflow determine where you should store field data. For example, field data can be used to configure the properties of page content. The following value of an Element Name property stores field data as the value of the redirectTarget property of the jcr:content node:

./jcr:content/redirectTarget

In the following example, the field data is used as the content of a Text component on the payload page:

./jcr:content/par/text_3/text

``The first example can be used for any page that the cq:Page component renders. The second example can only be used when the payload page includes a Text component that has an ID of text_3.

The form can be located anywhere in the repository, however workflow users must be authorized to read the form.

Random Participant Chooser random-participant-chooser

The Random Participant Chooser step is a participant chooser that assigns the generated work item to a user that is randomly selected from a list.

Random Participant Chooser - Configuration random-participant-chooser-configuration

To configure the step, edit and use the following tabs:

Workflow Initiator Participant Chooser workflow-initiator-participant-chooser

The Workflow Initiator Participant Chooser step is a participant chooser that assigns the generated work item to the user who started the workflow. There are no properties to configure other than the Common properties.

Workflow Initiator Participant Chooser - Configuration workflow-initiator-participant-chooser-configuration

To configure the step, edit using the following tabs:

Process Step process-step

A Process Step runs an ECMAScript or calls an OSGi service to perform automatic processing.

Process Step - Configuration process-step-configuration

To configure the step, edit and use the following tabs: