You are reading the Adobe Experience Manager 5.6.1 version of Workflow Step Reference.
This documentation is also available for the following versions:
AEM 5.6 CQ 5.5
Workflow Steps
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.
Common Step Properties
The following properties are available for most workflow step components, on the Common tab of the properties dialog:
Title
The title for the step.
Description
A description of the step.
Timeout
The period after which the step will be "timed out". You can select between Off, Immediate, 1h, 6h, 12h, 24h.
Timeout Handler
The handler which will control the workflow when the step times out; for example com.day.cq.workflow.timeout.autoadvance.AutoAdvancer.
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.
The following properties are available:
User/Group
A drop down selection box will allow you to navigate and select a user or group.
If you assign the step to a specific user, then only this user can take action on the step.
If you assign the step to an entire group, then when the workflow reaches this step all users in this group will have the action in their Workflow Inbox.
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.
Note: The workflow initiator is always notified when:
The workflow is completed (finished).
The workflow is aborted (terminated).
Note
Some properties need to be configured to enable email notifications. You can also customize the email template or add an email template for a new language.See Configuring Email Notification to configure email notifications in AEM.
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 indicate the user or group to assign the step, and the path to the dialog.
Creating the dialog
Dialogs for Dialog Participant Steps are similar to dialogs that you create for authoring components. Dialogs have the following node structure:
dialog
|- items
|- widget0
|- widget1
|- ...
The following table contains descriptions of the nodes:
Node name
jcr:PrimaryType
Description
dialog
cq:Dialog
The root node of the dialog. The node must have a String property named xtype of value dialog.
items
cq:WidgetCollection
The child node of the dialog node.
field_name
cq:Widget
One or more UI widgets that appear in the dialog. These nodes can use any valid JCR name. Each node must have the following properties:
xtype: A String value that determines the type of widget. For information, see the Widget API reference.
name: A String value that represents the path of the node that stores the widget data.
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.
Store Data with the Payload
To store widget data as a property of the workflow payload, use the following format for the value of the name property of the cq:Widget node:
./jcr:content/nodename
The data is stored in the nodename property of the payload node. If the node does not contain that property, the property is created.
When stored with the payload, subsequent uses of the dialog with the same payload overwrites the value of the property.
Store Data with the Work Item
To store widget data as a property of the work item metadata, use the following format for the value of the name property:
nodename
The data is stored in the nodename property of the work item metadata. The data is preserved if the dialog subsequently used with the same payload.
Example dialog
The following XML code represents a dialog that stores a String value in the watchEmail node of the payload content. The title node represents the textfield widget:
In addition to the same properties of the Participant Step, the Dialog Participant Step includes the Dialog Path property. The value of the Dialog Path property is the path to the cq:Dialog node of you dialog.
The dialog of the previous example is contained in a component named EmailWatch that is stored in the /etc/workflows/dialogs node. The following value is used for the Dialog Path property:
/etc/workflow/dialogs/EmailWatch/dialog
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, and the path to the form.
Create a form for use with a Form Participant Step as normal. However, forms for Form Participant Steps must have the following configurations:
The Start of Form component must have the Action Type property set to Edit Workflow Controlled Resource(s).
The Start of Form component must have a value for the the Form Identifier property.
The form components must have the Element Name property set to the path of the node where the field data is stored. The path must locate a node in the workflow payload content. The value uses the following format:
./jcr:content/path_to_node
The form must include a Submit to Workflow(s) component. You do not configure any properties of the component.
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.
For information about creating forms, see Developing Forms. For information about available form components, see the Forms section of the Default Components page.
Configuring the Form Participant Step
In addition to the same properties of the Participant Step, the Form Participant Step includes the Form Path property. Set the value of the Form Path property to the path of the page that contains the form.
Dynamic Participant Step
The Dynamic Participant Step component is similar to Participant Step except 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.
You create the participant chooser. Therefore, you can use any selection logic or criteria. For example, your participant chooser can select the user that has the fewest work items of all the other users in a group. You can create any number of participant choosers to use with different instances of the Dynamic Participant Step component in your workflow models.
Developing the participant chooser
Create an OSGi service or an ECMA script that selects a user to assign the work item.
ECMA script
Scripts must include a function named getParticipant that returns a user ID as a String value. Store the script in the /etc/workflow/scripts folder, or a subfolder.
A sample script is installed that selects the workflow initiator as the participant. The /etc/workflow/scripts/initiator-participant-chooser.ecma script is very simple:
function getParticipant() {
return workItem.getWorkflow().getInitiator();
}
Tip: The Workflow Initiator Participant Chooser component extends the Dynamic Participant Step and uses this script as the step implementation.
SERVICE_PROPERTY_LABEL field: Use this field to specify the name of the participant chooser. The name appears in a list of available participant choosers in the Dynamic Participant Step properties.
getParticipant method: Returns the user ID as a String value.
To make your implementation available to Dynamic Participant Step components, add your Java class to an OSGi bundle that exports the service, and deploy the bundle to the AEM server.
Tip: Random Participant Chooser is a sample service that selects a random user (com.day.cq.workflow.impl.process.RandomParticipantChooser). The Random Participant Chooser step component sample extends the Dynamic Participant Step and uses this service as the step implementation.
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 initator-participant-chooser.ecma script 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.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 implementation of a dynamic participant chooser."),
@Property(name = ParticipantStepChooser.SERVICE_PROPERTY_LABEL, value = "Workflow Initiator Participant Chooser") })
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 Workflow Initiator Participant Chooser item 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.2012 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
Create Task Step
The Create Task step creates a Task Management task and assigns it to a user.
Task
Basic task properties. These properties are also available when manually creating tasks.
Project: Select the Task Management project to contain the task.
Name: The name of the task that appears in the Task Management page and the Inbox.
Assign To: The user who is assigned the task.
Task Priority: (Optional) The relative priority of the task.
Description: (Optional) The Description of the task that appears in the Task Management page and the Inbox.
Hours: (Optional) The number of hours after task creation until the task is due for completion.
Days: (Optional) The number of days after task creation until the task is due for completion. Note: The task due date is calculated from the sum of the Hours and Days property values. When you specify no value for both Hours and Days, no due date is calculated for the task.
Content
Content Source: The content to associate with the task. Select one of the following values:
Use Workflow Payload: The task uses the workflow payload as the content.
Specify Payload: The task uses the content that you specify for the task. The path that you specify must resolve to a resource at run time.
Routing
Actions: Completion options that are presented to the user upon completing the task. The selected action determines the subsequent route to follow.
Click Add item and type a name for the action. The name and order of the actions appear in the Complete Task dialog as they appear in the properties dialog.
Advanced Settings
Pre-Create Task Script: The path of an ECMA script to run before the task is created.
Using Task Actions for Routing
When a user selects an action when completing a task, the Workflow engine stores the action name in the data map of the workfow instance. You can reference the selected action name in the logic of OR Split steps to select the next step to execute.
In the data map of the workflow instance, the selected action name is associated with the lastTaskAction key. In an ECMA script, the following code returns the value:
When using the last task action that is saved, design your workflow model so that no more than one task is awaiting completion at one time. In this way, you ensure that the value for the lastTaskAction key was populated by the expected task.
The following script example script can be used to determine whether the selected action for the last completed task was Accept.
function check(){
var action = workitem.getWorkflow().getWorkflowData().getMetaDataMap().get("lastTaskAction","");
return action === "Accept";
}
Process Step
A process step executes an ECMA script or calls an OSGi service to perform automatic processing.
Process
The process implementation to execute. Use the drop-down menu to select the ECMA script or OSGi service that are available:
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.
Random Participant Chooser
The Random Participant Chooser step is a Participant step that assigns the generated work item to a user that is randomly selected from a list. You specify the list of users as a step argument:
Open the component properties dialog and click the Arguments tab.
To add a user to the list, click Add Item and type the path to the user node or the user ID.
The order of the users does not affect the likelihood of being assigned a work item.
When you have added all users to the list, click OK.
Workflow Initiator Participant Chooser
The Workflow Initiator Participant Chooser step is a Participant step that assigns the generated work item to the user who started the workflow. There are no properties to configure other than the common properties.
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. For example a translation workflow model could be used in multiple editing workflows.
The following properties are available:
Sub Workflow
Select the workflow to start.
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.
Right-click the branch and select Edit to specify the number of branches you need. Add workflow steps to either branch as required.
OR Split
Create a split in the workflow, whereby only one branch is active. This allows you to introduce conditional processing paths into your workflow.
Selecting this adds two branches to the workflow. You add workflow steps to each branch as requried.
Right-click the branch and select Edit to specify the number of branches that the split contains. You also specify the script that contains the logic that determines whether a branch is followed.
The script of each branch is evaluated one at a time. The branch number determines the order in which they are evaluated.
The first script that evaluates to true is executed.
If no script evaluates to true, then the default branch is followed
Script Path
The path to a file that contains the script.
Script
Add the script in the box.
Default Route
The default branch is followed when no script is defined for any branches in the split, or neither are fulfilled. You can specify only one branch as the default.
Note
Script Path and Script options can not be used at the same time.
Goto Step
The Goto step specifies the next step in the workflow model to execute, depending on the result of an ECMA script:
Script returns true: The Goto step completes and the workflow engine executes the specified step.
Script returns false: The Goto step completes and the normal routing logic determines the next step to execute.
The Goto step enables you to implement advanced routing structures in your workflow models. For example, to implement a loop, the Goto step executes a previous step in the workflow and the script evaluates a looping condition.
In addition to the common properties, the following properties are available on the Process tab of the edit dialog:
The Step To Go To: Select the step to execute.
Script Path: The path to the ECMA script that determines whether to execute the Goto step.
Script: The ECMA script that determines whether to execute the Goto step.
Specify a value for either the Script Path or the Script property. If you specify values for both properties, the step uses the Script Path.
Simulating a for Loop
Simulating a for loop requires that you maintain a count of the number of loop iterations that have occurred:
The count typically represents an index of items that are acted on in the workflow.
The count is evaluated as the exit criteria of the loop.
For example, a workflow performs an action on several JCR nodes. The loop counter is used 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; }
AEM provides several process steps that administrators typically use for creating workflow models. Custom process steps can also be added for tasks not covered by the built-in steps (see Creating Workflow Models).
Below is a list of all the process steps that AEM provides. For each process step, the following charactersitics are described:
Java class or ECMAScript path: Process steps are defined either by a Java class or an ECMAscript. For the Java class processes, the fully qualified class name is provided. For the ECMAscript processes the path to the script is provided.
Payload: The payload is the entity upon which a workflow instance acts. The payload is selected impicitly by the context within which a workflow instance is started. For example, if a workflow is applied to an AEM page P then P is passed from step to step as the workflow advances with each step optionally acting upon P in some way. In the most common case the payload is a JCR Node in the repository (for example an AEM Page or Asset). A JCR Node payload is passed as a string that is either a JCR path or a JCR identifier (UUID). In some cases the payload may be a JCR property (passed as a JCR path), a URL, a binary object or a generic Java object. Individual process steps that do act on the payload will usually expect a payload of a certain type, or act differently depending on the payload type. For each process described below, the expected payload type, if any, is described.
Arguments: Some workflow processes accept arguments, which the administrator specifies when setting up the workflow step. Arguments are entered as a single string in the Process Arguments property in the Properties pane of the workflow editor (see image above). For each process described below, the format of the argument string is described in a simple EBNF grammar. For example,
args := name '::' value [',' name '::' value]*
name := /* A string */
value := /* A string */
indicates that the argument string consists of one or more comma-delimited pairs, where each pair consists of a name (which is a string) and a value, seperated by a double colon.
Timeout: The administrator can set a timeout after which the workflow step is no longer operational. Some workflow processes respect the timeout, while for others it does not apply and is ignored.
Workflow Control Processes
The following processes do not perform any actions on content. They serve to control the behavior of the workflow itself.
AutoAdvancer
This process automatically advances the workflow to the next step. If there is more than one possible next step (for example, if there is an OR split) then this process will advance the workflow along the default route, if one has been specified, otherwise the workflow will not be advanced.
Timeout: Process times out after set length of time.
AbsoluteTimeAutoAdvancer
This process behaves identically to AutoAdvancer, above, except that it times out after a given time and date, instead of after a given length of time.
Timeout: Process times out when set time and date is reached.
ProcessAssembler
This process executes multiple sub-processes sequentially in a single workflow step. To use the ProcessAssembler, create a single step of this type in your workflow and set its arguments to indicate the names and arguments of the sub-processes you wish to execute.
This is a null process that returns false on the check() method.
ECMAScript path: /etc/workflow/scripts/noop.ecma
Payload: None.
Arguments: None.
Timeout: Ignored.
urlcaller
This is a simple workflow process that calls the given URL. Typically the URL will be a reference to a JSP (or other servlet equivalent) that performs a simple task. This process should be used only during development and demonstrations and not in a production environment. The arguments specify the URL, login and password.
The following processes perform WCM-related tasks.
ActivatePageProcess
This process activates the payload. The process first checks access control. In case the session starting the process is lacking the privilege to replicate, a “request for activation” workflow event is sent out. Listeners to this event may then handle this situation.
This process enables confirmation of subscription requests, meaning that if a user sends a form requesting a subscription ot a newsletter, this subscription will be stored. Another process may then start a workflow to confirm that the subscription is valid. This can be used, for example, to send a a confirmation email to a user to ensure that the recipient intended to subscribe to the newsletter.
This process deactivates the payload. The process first checks access control. In case the session starting the process is lacking the privilege to replicate, a “request for deactivation” workflow event is sent out. Listeners to this event may then handle this situation.
Replicate As Participant: Select this option to perform the reverse replication using the context of the most recent participant of the workflow. If no participant is found from the steps that executed previously in the workflow instance, the context of the admin user is used. When this option is not selected, the context of the admin user is used.
Timeout: Ignored
Versioning Processes
The following process performs a version-related task.
CreateVersionProcess
Creates a new version of the workflow payload (AEM page or DAM asset).
Payload: A JCR path or UUID that refers to a page or DAM asset.
Arguments: None.
Timeout: Respected.
DAM Processes
The following processes perform DAM-related tasks.
AssetSetLastModifiedProcess
This process updates the last modified properties of an asset using the current date and time (for date properties) and the current user (for 'modified by' properties). The properties affected are the standard JCR properties jcr:lastModified and jcr:lastModifiedBy as well as the related Dublin Core properties (prefix dc) in the metadata. Additional properties can be updated by specifying them in the arguments.
If this argument is used with a payload of an asset at /x/y/myasset then,
The DATE property at /x/y/myasset/mydata/mylastmodified will be updated. to the current date and time.
The STRING property at /x/y/myasset/mydata/mylastmodifiedby will be updated to the user name of the current user.
This process can be used, for example, to update the asset node when renditions are added.
Timeout: Respected.
CommandLineProcess
This process that calls a command-line program using the payload asset as input. Each output file produced becomes an additional rendition of the payload asset. One or more permitted mimetypes must be specified, restricing the operation to assets of those types. Optionally, thumbnails of the specified sizes can be produced from the payload asset.
the process will call /bin/convert, pass it the full path of the asset being processed (temporarily dumped to disk), and create thumbnails of size 140x100 and 48x48 based on the output created. This will only happen for assets having the application/postscript mimetype, others are ignored.
The process arguments can contain multiple mime: and tn: arguments, but only one cmd: argument. The cmd: argument and at least one mime: argument are required.
Payload:The JCR path of a dam:Asset or a node within the subtree of a dam:Asset.
Arguments: None.
Timeout: Respected.
CreateThumbnailProcess
This process will create one or more thumbnails for the payload asset. The Thumbnail generation is delegated to the appropriate AssetHandler. The thumbnails dimensions are given as the process arguments
Payload: The JCR path of a dam:Asset or a node within the subtree of a dam:Asset.
Arguments:
args := arg [',' arg]*
arg := '[' width ':' height [':' center] ']'
width := /* Width of the thumbnail in pixels */
height := /* Height of the thumbnail in pixels */
center := 'true' | 'false' /* A boolean specifying whether to center the image. The default is 'true' */
Each argument specifies the width and height (in pixels) of the thumbnail, and optionally whether to center the image or not.
If the center flag is false, then the aspect ratio of the original asset is always respected such that the resulting thumbnail will have at most the dimension specified.
If the center flag is true, then the thumbnail image will have exactly the size given by the configuraiton. If the resized image is smaller it will be centred within the thumbnail.
Timeout: Respected.
CreateWebEnabledImageProcess
This process creates a web-enabled representation from the payload asset. The format of the web-enabled image is specified by the arguments passed to the process. The process is memory aware: Image creation is deferred or cancelled if the memory requirements cannot be sattisfied within a fixed number of attempts.
Would result in the process converting the payload asset to a 400 by 300 image/jpg of 90% quality unless
the payload asset was of type application/pdf or image/tiff, in which case the asset is skipped and no result is produced, or
the payload asset is of type image/gif, image/png or image/x-png, in which case the resulting image is simply a scaled copy of the payload image (no type conversion required).
Timeout: Respected.
DeleteAssetProcess
Deletes the asset in the /content/dam subtree when its corresponding asset in /var/dam is deleted.
Payload:The JCR path of a dam:Asset or a node within the subtree of a dam:Asset.
Arguments: None.
Timeout: Respected.
DeleteDamAssetProcess
This process acts when it detects the deletion of an asset from below the source root. It checks for a corresponding asset below the destination root and, if it exists, deletes it. Correspondence in this context is based on matching relative paths below the two roots.
Payload:The JCR path of a dam:Asset or a node within the subtree of a dam:Asset.
Arguments:
args := source ',' dest
source := /* Absolute path of the source root. The path must end with an "/" character */
dest := /* Absolute path of the destination root. The path must end with an "/" character */
For example, the following parameters:
/content/dam/,/var/dam/
will cause the process to weatch for deletes under /content/dam/ and, when one happens, delete the corresponding node under /var/dam/.
Timeout: Respected.
ExtractMetadataProcess
Reads the metadata of the payload asset and and stores it along with the asset (in a node called metadata below the jcr:content node of the dam:Asset).
Payload:The JCR path of a dam:Asset or a node within the subtree of a dam:Asset.
Arguments: None.
Timeout: Respected.
Create Video Storyboard
Creates a storyboard for the workflow payload, which is a video asset. The storyboard consists of a series of JPG images that are created from key frames of the video. You specify the number and size of images to create. The images are equal-spaced in the video timeline, starting at the time that you specify. Optionally, you can use specific key frames.
The storyboard images are stored below the asset node in the repository. A film strip of the merged key frames are also stored as a rendition of the video asset.
The asset must have one of the following mime types:
Frame Count: The number of storyboard image frames to create.
Start: The position in the timeline of the first frame to use as a storyboard frame, in seconds.
Maximum Width: The maximum width of the storyboard frames, in pixels. The aspect ratio of the video frame is preserved.
Maximum Height: The maximum height of the storyboard frames, in pixels. The aspect ratio of the video frame is preserved.
Upscale: Select this option to increase the size of the video frame if either the height or width is smaller than the value of the Maximum Height or Maximum Width properties, repsectively.
Frames: (Optional) Use this property to specify the specific video frames to use for the storyboard. Add an item for each frame to include in the format hh:mm:ss, or in seconds. If specified, the value of this property overrides the Frame Count and Start properties.
Timeout: Respected
Create Video Thumbnails
Creates thumbnail images from a key frame of a video asset. The thumbnails are PNG files, stored as renditions of the asset. Use the step properties to specify the keyframe to use, and the configuration of one or more thumbnail images to create from the keyframe.
The asset must have one of the following mime types:
Start: The position in the timeline of the first key frame to extract, in seconds.
Count: The number of images to extract from the keyframes.
Index: The index number (0-based) that identifies the extracted keyframe image to use to create the thumbnails. If the value of Index is greater than the number of extracted images, the last image is used.
Index Thumbnails: Configures the thumbnail renditions. Add an item to configure each rendition of the index thumbnail to generate. Specify the thumbnail width, height, and how to center the image. Use the format width:height:center.
width: The width of the image, in pixels.
height: The height of the image, in pixels.
center: If the source image is smaller than the width or height, specify true to use a border to frame the original image. Specify false to scale the source image to the sepcified width and height.
The rendition name is prefixed with cq5dam, followed by the width and height, followed by margin if center is true, followed by the file name extension. For example, the name of the rendition for 20:20:true is cq5dam.20.20.margin.png. The name of the rendition for 20:20:false is cq5dam:20:20:png.
Payload: The JCR path of a dam:Asset or a node within the subtree of a dam:Asset.
Arguments: None.
Timeout: Respected.
Resize Image
This process resizes the payload asset according to the specified geometry. The result is added as a rendition. The new rendition's name is built according the following rule:
It will be prefixed with cq5dam.resized. If a rendition name argument is given, this will be appended, if not then the image dimensions will be appended. Finally, the extension png is appended. For example:
args := size [',' name]
/* The size parameter is required. The name parameter is optional */
size := numpixels | dimensions
numpixels := number '@'
/* The size of the rendition in terms of the total number of pixels */
dimensions := reldim | absdim
reldim := width '%' 'x' height '%'
/* The size of the rendition as a percentage of the original image in both width and height */
absdim := width 'x' height op
/* Specifies the size of the rendition in width and height in pixels with 'op' indicating how to imterpret those dimensions */
op := shrink | grow | minimal | force
shrink := '<'
/* Resizes the original image so that it has at most the the dimensions specified. Only downscales if the original image is larger than the given dimensions. Keeps the aspect ratio. */
grow := '>'
/* Resizes the original image so that it has at most the the dimensions specified. Only upscales if the original image is smaller than the given dimensions. Keeps the aspect ratio. */
minimal := '^'
/* Resizes the original image so that it has at least the the dimension specified. Keeps the aspect ratio */
force := '!'
/* Resizes the original image so that it has the exact dimensions specified */
name := /* Name that the created rendition should be appended with. If missing, Defaults to the the dimenisions specified with the argument 'size' */
width := /* a positive integer */
height := /* a positive integer */
For example, the following parameters will result in a rendition exactly 300 by 300 pixels with a name appended with the string "myrendition":
300x300!,myrendition
Resize Image To Area
This process resizes the payload asset to the specified area in pixels. The aspect ratio of the payload asset does not change.
The result is added to the repository as a rendition. The name of the new rendition is built according the following rule:
The name is prefixed with cq5dam.resized. If a rendition name property is specified, the value is appended, otherwise the value of the Area property is appended. The extension for the asset's mime type is appended. For example:
Rendition Name: The text to append to the rendition name.
Area: The area of the resized image, in pixels.
Scene7
Uploads the workflow payload to Adobe Scene7. The step requires a valid Scene7 account configuration. (See Configuring Scene7 integration).
At runtime, this step does not attempt to upload to Scene7 and logs a warning if the Cloud Services Scene7 account configuration cannot be found, or if any of the account properties are not configured. The step logs an error message if an error occurs during the upload.
Configuration: The name of a Cloud Services configuration for Scene7.
Timeout: Ignored
SyncAssetProcess
Copies an asset from /var/dam to the corresponding position in /content/dam. This process either creates a new asset or replaces the original rendition of an existing asset.
The mode cleanup removes the nodes in /content/dam subtree that have no counterpart in the /var/dam subtree.
The mode sync starts, for each new node N of type nt:file in var/dam, a workflow of the model specified by the wfModelId argument and N's path as payload.
will start a workflow of type syncmodel for each new nt:file in /var/dam.
Timeout: Respected.
SyncVarProcess
Writes modifications done to the subtree at content/dam into var/dam. The process is only executed if started with a mode argument, the payload exists and is currently not involved in a workflow
Video Profiles: Add an item and select the video profile to use. A transcoded rendition is created for each video profile that is specified.
Timeout: Respected.
Test&Target Offer
Publishes a Test&Target offer that is created in AEM to the Adobe Test&Target server. The workflow payload is the Test&Target offer. The step requires a valid Test&Target account configuration. (See Creating a Test&Target Configuration).
At runtime, this step does not attempt to publish the offer and logs a warning if the Cloud Services Test&Target account configuration cannot be found, or if any of the account properties are not configured. The step logs an error message if an error occurs during publishing.
Configuration: The name of a Cloud Services configuration for Test&Target.
Timeout: Ignored
Unarchiver
Extracts ZIP files that are stored in the repository. Archived contents can replace previously unarchived files, or stored in a new folder. You can also limit the number of files per folder, the total number of folders, and the total amount of data that is unarchived.
Payload: An asset in the repository that is a file with the .zip extension, and the application/zip mime type.
Arguments:
Disable Extraction: Select this option to prevent the unarchiving of the payload. This option is not selected by default.
Remove Original: Select this option to delete the ZIP file from the repository after unarchiving. This option os not selected by default.
Update Mode: The unarchiving behavior for preserving existing files and conserving storage space. Select one of the following options:
Replace the existing folder with the contents of the archive: (Default) The folder in the repository is removed, and all of the archive contents are extracted. This option conserves the most space in the data store.
Update the existing folder only replacing files contained in: Archive contents are extracted only if they differ from existing assets (SHA-1 digest comparison), or do not already exist in the repository.
Create a new numbered folder to extract the archive to: A new folder is created where the files are extracted. This option preserves all previously-extracted files.
File Number Limit: The maximum number of files that can be extracted from an archive. If the archive contains a greater number of files, an error is thrown and no files are extracted. The default value is 10000.
Per Directory File Number Limit: The maximum number of files that a folder in the archive can contain. If any folder contains a greater number of files, an error is thrown and no files are extracted. The default value is 100.
Size Limit: The maximum number of bytes of uncompressed files that an archive can contain. If the archive uncompressed contents exceed this limit, an error is thrown and no files are extracted. The default value is 104857600 (100 Mb).
Save Threshold: The number of files to extract and temporarily store in internal server memory before saving to the repository. Decrease this value if out of memory errors occur during unarchiving. The default value is 1024.
Timeout: Respected
Collaboration Processes
The following processes are related the collaboration (social communities) features of AEM.
BlogSearchPingProcess
Pings search engines to notify them that there is a new post to a blog.
A process step that sets the approved property of a node to true or false. This step is used to approve user-generated comments. If the node does not have an approved property, the property is created.
Approve: Select this option to set the value of the payload's approved property to true. When unselected, the approved property is set to false.
Timeout: Respected
Approve Comment Step
This step creates a work item for a participant. This step extends the Participant step, however the workflow payload is a user-generated comment.
Payload: A JCR path that resolves to a node that has a sling:resourceType of collab/commons/components/comments/comment.
Arguments: The step arguments are the same as those of the Participant step.
Timeout: Respected
CheckSpamProcess
Checks if a comment should be considered spam. Posts without an IP or from localhost are considered non-spam. Other posts are sent to the Akismet service for analysis. If an entry is considered spam, the process marks the resource with the propety isSpam.
Payload: A JCR path to a node with resource type collab/blog/components/trackbacks or collab/commons/components/comments/comment.
Arguments: None.
Timeout: Respected.
CalendarSubscriptionProcess
Handles the subscription of a calendar to an event. If executed with the unsubscribe as argument, the calendar in the payload will be unsubscribed, in any other cases it will be subscribed.
Arguments: optional: unsubscribe, to unsubscribe the payload calendar.
Timeout: Respected.
Flush (Replicate) Page
Calls a Dispatcher Flush replication agent to invalidate a page in the Dispatcher cache. For information about replication between publish and author instances, see Replication Agents.
Agent Name: The name of the replication agent to use.
Timeout: Respected
Forum Subscription
Subscribes or unsubscribes a user for a forum topic. The user is obtained from the work item metadata. This process step is used in conjunction with the User State Toggle feature.
Subscribe: Select this option to subscribe the user to the payload topic.
Unsubscribe: Select this option to unsubscribe the user from the payload topic.
Timeout: Respected.
Send Email
Sends an email message that is based on a template. You can provide the template as a property value, or specify the path to a template that is stored in the repository.
The message template must follow the Internet Message Format that the Engineering Internet Task Force (EITF) defines. The template text is comprised of header fields (such as to, from, and subject) and the message body. The text in a header field and any part of the body can be static or dynamic. To insert text at runtime, use variables that reference a property of the workflow payload (a JCR node) or a property of the workflow:
${payload.propertyname}
${workflowproperty}
The following workflow properties are available:
data.startComment: The comment provided for the workflow instance.
data.workflowTitle: The title of the workflow.
initiator.familyName: The family name property of the initiatior's user profile.
initiator.home: The path to the node in the repository for the initiator user.
initiator.id: The user id of the initiator.
initiator.jcr:mixinTypes: The JCR mixin types of the initiator's user profile node.
initiator.jcr:primaryType: The JCR primary type of the initiator's user profile node.
initiator.name: The name of the workflow initiator.
initiator.sling.resourceType: The path to the component that provides the implementation for the user profile.
instance.data.startComment: The comment provided for the workflow instance.
instance.data.workflowTitle: The title provided for the workflow instance.
instance.id: The path of the node that stores the workflow instance.
instance.state: The state of the workflow instance.
item.id: The id of the step instance.
item.node.data.PROCESS: The name of the class that implements the Send Email step component.
item.node.data.PROCESS_AUTO_ADVANCE: A boolean value that indicates whether the workflow automatically advances to the next step.
item.node.data.template: The template literal value.
For example, the following template includes values for the email, name, userid, and password properties of the node that is used as the workflow payload:
From: GeoMetrixx Outdoors <webadmin@geometrixxoutdoors.com>
To: ${payload.email}
Subject: Your new Geometrixx Outdoors user account
Dear ${payload.name},
Here are the details about your new user account at http://www.geometrixxoutdoors.com/.
You login name is: ${payload.userid}.
Your password is: ${payload.password}.
Regards,
Geometrixx Outdoors
Another strategy for including dynamic text is to create the template at runtime:
Specify the path to the template in the Send Email properties (the Email Template Path argument).
In a previous step of the workflow, create the template text and save the template as a node at the pre-defined path.
Arguments: Specify a value for one of the followng arguments:
Email Template Path: The path to the template in the repository.
Email Template: The template (literal value)
Timeout: Not applicable.
Your comments are welcome!
Did you notice a way we could improve the documentation on this page? Is something unclear or insufficiently explained? Please leave your comments below and we will make the appropriate changes. Comments that have been addressed, by improving the documentation accordingly, will then be removed.
COMMENTS
By
Florian Salihovic - 5:06 PM on Mar 25, 2013
Reply
So, apparently the Dialog Participant Step doesn't work properly when triggered from the sidekick? Is that true or is there some trick to it?
http://forums.adobe.com/message/4492149?tstart=0#4492149