Arguments

Some workflow processes accept arguments that 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. For each process described below, the format of the argument string is described in a simple EBNF grammar. For example, the following 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:

    args := name '::' value [',' name '::' value]*
    name := /* A string */
    value := /* A string */

Timeout

After this timeout period the workflow step is no longer operational. Some workflow processes respect the timeout, while for others it does not apply and is ignored.

Permissions

The session passed to the WorkflowProcess is backed by the service user for the workflow process service, which has the following permissions at the root of the repository:

  • jcr:read
  • rep:write
  • jcr:versionManagement
  • jcr:lockManagement
  • crx:replicate

If that set of permissions is not sufficient for your WorkflowProcess implementation, then it must use a session with the required permissions.

The recommended way to do this is to use a service user created with the necessary, but minimal, subset of permissions required.

CAUTION
If you are upgrading from a version prior to AEM 6.2 you might need to update your implementation.
In previous versions, the admin session was passed to the WorkflowProcess implementations and could then had full access to the repository without having to define specific ACLs.
The permissions are now defined as above (Permissions). As is the recommended method for updating your implementation.
A short term solution is also available for backward-compatibility purposes when code changes are not feasible:
  • Using the Web Console ( /system/console/configMgr locate the Adobe Granite Workflow Configuration Service

  • enable the Workflow Process Legacy Mode

This will revert to the old behaviour of providing an admin session to the WorkflowProcess implementation and provide unrestricted access to the entirety of the repository once again.

Workflow Control Processes

The following processes do not perform any actions on content. They serve to control the behavior of the workflow itself.

AbsoluteTimeAutoAdvancer (Absolute Time Auto Advancer)

The AbsoluteTimeAutoAdvancer (Absolute Time Auto Advancer) process behaves identically to AutoAdvancer, except that it times out at a given time and date, instead of after a given length of time.

  • Java Class: com.adobe.granite.workflow.console.timeout.autoadvance.AbsoluteTimeAutoAdvancer
  • Payload: None.
  • Arguments: None.
  • Timeout: Process times out when the set time and date is reached.

AutoAdvancer (Auto Advancer)

The AutoAdvancer 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.

  • Java Class: com.adobe.granite.workflow.console.timeout.autoadvance.AutoAdvancer

  • Payload: None.

  • Arguments: None.

  • Timeout: Process times out after set length of time.