Ön a következő verzió súgóját látja::

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

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

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:

  • 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: OffImmediate, 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
  • Handler Advance 
    Select this option to automatically advance the workflow to the next step after execution. If not selected, the implementation script must handle workflow advancement.

Step Properties - User/Group tab

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

  • 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.
    • See Participating in Workflows for more information.
  • 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.

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

To configure the split:

  • Edit and use the following tabs:

    • Common
      • Branches: Select the number of branches required; 2, 3, 4 or 5.
  • Add workflow steps to the branches as required.

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.

chlimage_1

Container Step - Configuration

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

  • Common
  • Container
    • Sub Workflow: Select the workflow to start.

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:

  • true: The Goto Step completes and the workflow engine executes the specified step.
  • 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 can be defined to execute a prior step in the workflow, with the script evaluating a loop condition.

Goto Step - Configuration

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

  • Common
  • Process
    • The step to go to.: Select the step to execute.
    • Script Path: The path to the ECMAScript that determines whether to execute the Goto Step.
    • Script: The ECMAScript that determines whether to execute the Goto Step.

Figyelmeztetés:

Specify either the Script Path or Script. Both options cannot be used at the same time. 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, 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

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

To configure the split:

  • Edit and use the following tabs:

    • Common
      • Branches: Select the number of branches required; 2, 3, 4 or 5.
    • Branch <x>
      • 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.

    Megjegyzés:

    There is a separate tab for each branch:

    • 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.

    Figyelmeztetés:

    Specify either the Script Path or Script. Both options cannot be used at the same time. If you specify values for both properties, the step uses the Script Path.

  • Add workflow steps to the branches as required.

Participant Steps and Choosers

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

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

Megjegyzés:

The workflow initiator is always notified when:

  • The workflow is completed (finished).
  • The workflow is aborted (terminated).

Megjegyzés:

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 specify the group or user to assign the work item to, and the path to the dialog.

Dialog Participant Step - Configuration

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

Dialog Participant Step - Creating a dialog

To create a dialog you need to create the dialog:

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.

  • 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 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.

Dialog Participant Step - Touch-Optimized UI

  1. Dialog Structure

    Dialogs for Dialog Participant Steps are similar to dialogs that you create for authoring components. They are stored under:

    /etc/workflow/dialogs

    Dialogs for the touch-optimized UI have the following node structure:

    newComponent (cq:Component)
      |- cq:dialog (nt:unstructured)
        |- content 
          |- layout 
            |- items 
              |- column 
                |- items 
                  |- component0
                  |- component1
                  |- ...

    Megjegyzés:

    For further information see Creating and Configuring a Dialog for the touch-optimized UI.

  2. Dialog Path Property

    The Dialog Participant Step has the Dialog Path property (together with the properties of a Participant Step). The value of the Dialog Path property is the path to the dialog node of your dialog.

    For example, the dialog is contained in a component named EmailWatch that is stored in the /etc/workflows/dialogs node. For the touch-optimized UI the following value is used for the Dialog Path property:

    /etc/workflow/dialogs/EmailWatch/cq:dialog

    chlimage_1
  3. Example Dialog Definition

    The following XML code snippet represents a dialog that stores a String value in the watchEmail node of the payload content. The title node represents the TextField component:

    jcr:primaryType="nt:unstructured" 
        jcr:title="Watcher Email Address Dialog" 
        sling:resourceType="cq/gui/components/authoring/dialog">
        <content jcr:primaryType="nt:unstructured"
            sling:resourceType="granite/ui/components/foundation/container">
            <layout jcr:primaryType="nt:unstructured" 
                margin="false" 
                sling:resourceType="granite/ui/components/foundation/layouts/fixedcolumns"
            />
            <items jcr:primaryType="nt:unstructured">
                <column jcr:primaryType="nt:unstructured"
                    sling:resourceType="granite/ui/components/foundation/container">
                    <items jcr:primaryType="nt:unstructured">
                        <title jcr:primaryType="nt:unstructured" 
                            fieldLabel="Notification Email Address" 
                            name="./jcr:content/watchEmails"
                            sling:resourceType="granite/ui/components/foundation/form/textfield"
                        />
                    </items>
                </column>
            </items>
        </content>
    </cq:dialog>

    This example will, in the case of the touch-optimized UI, result in a dialog such as:

    chlimage_1

Dialog Participant Step - Classic UI

  1. Dialog Structure

    Dialogs for Dialog Participant Steps are similar to dialogs that you create for authoring components. They are stored under:

    /etc/workflows/dialogs

    Dialogs for the classic UI have the following node structure:

    newComponent
      |- 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. 

    Megjegyzés:

    For further information see Creating and Configuring a Dialog for the classic UI.

  2. Dialog Path Property

    The Dialog Participant Step has the Dialog Path property (together with the properties of a Participant Step). The value of the Dialog Path property is the path to the dialog node of your dialog.

    For example, the dialog is contained in a component named EmailWatch that is stored in the /etc/workflows/dialogs node. For the classic UI the following value is used for the Dialog Path property:

    /etc/workflow/dialogs/EmailWatch/dialog

    chlimage_1
  3. Example Dialog Definition

    The following XML code snippet represents a dialog that stores a String value in the watchEmail node of the payload content. The title node represents the textfield widget:

    jcr:primaryType="cq:Dialog" 
        title="Watcher Email Address Dialog" 
        xtype="dialog">
        <items 
            jcr:primaryType="cq:WidgetCollection">
            <title 
                jcr:primaryType="cq:Widget" 
                fieldLabel="Notification Email Address" 
                name="./jcr:content/watchEmails" 
                xtype="textfield"
            />
        </items>
    </dialog>

    This example will, in the case of the classic UI, result in a dialog such as:

    chlimage_1

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

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

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.

  • ECMAscript

    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 included in a standard AEM instance:

    /etc/workflow/scripts/initiator-participant-chooser.ecma

    This script selects the workflow initiator as the participant:

    function getParticipant() {
        return workItem.getWorkflow().getInitiator();
    }

    Megjegyzés:

    The Workflow Initiator Participant Chooser component extends the Dynamic Participant Step and uses this script as the step implementation. 

  • OSGi service

    Services must implement the com.day.cq.workflow.exec.ParticipantStepChooser interface. The interface defines the following members:

    • 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 the dynamically resolved Principal id as a String value.

    Figyelmeztetés:

    The getParticipant method returns the the dynamically resolved Principal id. This can be either a group id or user id.

    However, a group id can only be used for a Participant Step, when a list of participants is returned. For a Dynamic Participant Step an empty list is returned and this cannot be used for delegation.

    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.

    Megjegyzés:

    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.

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") })
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.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

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

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

Megjegyzés:

The Collecting data using forms and workflows tutorial walks you through the creation of a workflow that uses the Form Participant Step and the related forms.

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 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 Workflow Submit Button(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.

Megjegyzés:

For information about creating forms, see Developing Forms. For information about available form components, see the Forms section of Components for Page Authoring.

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. 

chlimage_1

Random Participant Chooser - Configuration

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

  • Common
  • Arguments
    • Participants: Specifies the list of users available for selection. To add a user to the list, click Add Item and type the home path of the user node or the user ID. The order of the users does not affect the likelihood of being assigned a work item.

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

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

  • Common
  • Arguments
    • No arguments available.

Process Step

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

chlimage_1

Process Step - Configuration

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

Forms Workflow Steps

Forms workflow steps are in addition to default workflow steps. These steps allow you rapidly build adaptive forms based Forms-centric workflow on OSGi. These workflows can be used for basic review and approvals, internal and across the firewall simpler business processes, to start document services, integrate with Adobe Sign signature workflow, and similar operations. You require AEM Forms add-on to use these steps in a workflow.

By default, AEM Forms steps are not visible in sidekick. You can select the Forms Workflow option from the design mode tool of sidekick to enable these steps. For more information, see Forms-centric workflow on OSGi.  

Assign task step

The assign task component creates a task and assigns it to a user or group. Along with assigning the task, use the component to specify the adaptive form or non-interactive PDF for the task. The adaptive form is required to accept input from users and non-interactive PDF or a read-only adaptive form is used for review only workflows.

You can also use the component to control the behavior of the task. For example, creating an automatic document of record, assign the task to a specific user or group, the path of the submitted data, the path of data to be pre-populated, and default actions. The Assign Task step has the following properties:

  • Title: Title of the task. The title is displayed in AEM Inbox.
  • Description: Explanation of the operations being performed in the task. This information is useful for other process developers when you are working in a shared development environment. This description is also displayed in AEM Inbox.
  • Thumbnail Path: Path of the task thumbnail. If no path is specified, for an adaptive form default thumbnail is displayed and for Document of Record, a default icon is displayed.
  • Workflow Stage: A workflow can have multiple stages. These stages are displayed in the AEM Inbox. You can define these stages in the properties of the model (Sidekick > Page > Page Properties > Stages).
  • Priority: Selected priority is displayed in the AEM Inbox. The available options are High, Medium, and Low. The default value is Medium.
  • Due Date: Specify the number of days or hours, after which the task is marked overdue. If you select Off, then the task is never marked overdue. You can also specify a time-out handler to perform specific tasks after the task is overdue.
  • Days: The number of days before which the task is to be completed. The number of days are counted after the task is assigned to a user. If a task is not complete and crosses the number of days specifies in the Days field, then, if selected, a timeout handler is triggered after the due date.
  • Hours: The number of hours before which the task is to be completed. The number of hours are counted after the task is assigned to a user. If a task is not complete and crosses the number of hours specifies in the Hours field, then, if selected, a timeout handler is triggered after the due hours.
  • Time-out after Due Date: Select the option to enable the Timeout Handler selection field.
  • Timeout Handler: Select the script to be executed when the assign task step crosses the due date. Scripts placed in the CRX-repository at [apps]/fd/dashboard/scripts/timeoutHandler are available for selection. The specified path does not exist in crx-repository. An administrator creates the path before using it.
  • Highlight the action and comment from the last task in Task Details: Select the option to display the last action was taken and comment received on the task details section of a task.
  • Type: Choose the type of document to be filled when the workflow is started. You can choose an adaptive form, read-only adaptive form, or a non-interactive PDF document.
  • Adaptive Form Path: Specify the path of the adaptive form. The field is available when you choose an adaptive form or read-only adaptive form in the Type field.
  • PDF Path: Specify the path of a non-interactive PDF document. The field is available when you choose a non-interactive PDF document in the Type field. The path is always relative to the payload. For example, [Payload_Directory]/Workflow/PDF/credit-card.pdf. The path does not exist in crx-repository. An administrator creates the path before using it. You require a Document of Record option enabled or form template based adaptive forms for using the PDF Path option.
  • For completed task, render the adaptive form as: When a task is marked complete, you can render the adaptive form as a read-only adaptive form or a PDF document. You require a Document of Record option enabled or form template based adaptive forms for rendering the adaptive form as Document of Record.
  • Information to be pre-populated: The following fields listed below serve as inputs to the task:
    • Data File Path: Path of input data file (.json or .xml). The path is always relative to the payload. For example, the file contains the data submitted for the form through an AEM Inbox application. An example path is [Payload_Directory]/workflow/data.
    • Attachment Path: Attachments available at the location are attached to the form associated with the task. The path is always relative to the payload. An example path is [Payload_Directory]/attachments/
  • Submitted information: The following fields listed below serve as output locations to the task:
    • Data File Path: Path of data file (.json or .xml). The data file contains information submitted through the associated form. The path is always relative to the payload. For example, [Payload_Directory]/Workflow/data, where data is a file.
    • Attachment Path: Path to save the form attachments provide in a task.
    • Document of Record Path: Path to save a Document of Record file. For example, [Payload_Directory]/DocumentofRecord/credit-card.pdf. The Document of Record is not generated if the path field is left empty. The path is always relative to the payload.
  • Assign options: Specify the method to assign the task to a user. You can dynamically assign the task to a user or a group using the Participant Chooser script or assign the task to a specific AEM user or group.
  • Participant Chooser: The option is available when the Dynamically to a user or group option is selected in the Assign options field. You can use an ECMAScript or a service to dynamically select a user or a group. For more information, see Dynamically assign a workflow to the users and Creating a custom Adobe Experience Manager Dynamic Participant step.
  • User or Group: The task is assigned to selected user or group. The option is available when the To a specific user or group option is selected in the Assign options field. It lists all the users and groups available in underlying AEM instance.
  • Notify Assignee by Email: Select the option to send email notifications to the assignee. These notifications are sent when a task is assigned to a user. Before using the option, enable the notifications from AEM Web Console. For step-by-step instructions, see configure email notifications for the assign task step
  • HTML Email Template: Select email template for the notification email. To edit a template, modify the file located at /libs/fd/dashboard/templates/email/htmlEmailTemplate.txt in crx-repository.
  • Allow Delegation To: AEM Inbox provides an option to the logged in user to delegate the assigned workflow to another user. You are allowed to delegate within the same group or to the workflow user of another group. If the task is assigned to a single user and the allow delegation to members of the assignee group option is selected, then it is not possible to delegate the task to another user or group.
  • Default Actions: Out of the box, Submit, Save, and Reset actions are available. All the default actions are enabled, by default. You can deselect an option to disable an action for the workflow.
  • Route Variable: Name of the route variable. The route variable captures custom actions that a user selects in AEM Inbox.
  • Routes: A task can branch to different routes. When selected in AEM Inbox, the route returns a value and the workflow branches based on the selected route.
  • Title:  Specify the title for the route. It is displayed in AEM Inbox.
  • Coral Icon: Specify HTML attribute of a coral icon. Adobe CorelUI library provides a vast set of touch-first icons. You can choose and use an icon for the route. It is displayed along with the title in AEM Inbox.
  • Allow assignee to add comment: Select the option to enable comments for the task. An assignee can add the comments from within AEM Inbox at the time of task submission.
  • Allow assignee to add attachment(s) to the task: Select the option to enable attachments for the task. An assignee can add the attachments from within AEM Inbox at the time of task submission.
  • Output path of task attachments: Specify the location of attachment folder. The location is relative to the payload.
  • Use custom metadata: Select the option to enable the custom metadata field. Custom metadata is used in email templates.
  • Custom Metadata: Select a custom metadata for the email templates. The custom metadata is available in crx-repository at apps/fd/dashboard/scripts/metadataScripts. The specified path does not exist in crx-repository. An administrator creates the path before using it. You can also use a service for the custom metadata. You can also extend the interface WorkitemUserMetadataService to provide custom metadata.
  • Show Data from Previous Steps: Select the option to enable assignees to view previous assignees, action already taken on the task, comments added to the task, and document of record of the completed task, if available.  
  • Show Data from Subsequent Steps: A task can be assigned to more users after the current assignee. Select the option to enable the current assignee to view the action take and comments added to task by subsequent assignees. It also allows the current assignee to view a document of record of the completed task, if available.
  • Visibility of data type: By default, an assignee can view a Document of Record, assignees, action taken, and comments that previous and subsequent assignees have added. Use the visibility of data type option to limit the type of data visible to the assignees.

Generate Document of Record

When a form is filled or submitted, you can keep a record of the form, in print or in document format. This is referred to as a Document of Record (DoR). You can use the Generate Document of record step to create a (read-only/interactive) PDF version of an adaptive form. The PDF version contains information filled-in to the form along with the layout of the adaptive form.

The Document of Record step has the following properties:

Adaptive Path: Specifies path of the adaptive form for which the document of record is being generated.

Input Data Path: Path of the input data for the adaptive form. You can keep the data at a location relative to the payload, at payload location, or specify an absolute path of the data. The input data is merged with the adaptive form to create a document of record.

Generated Document of Record Path: Specify the location to keep a document of record file. You can choose to overwrite the payload folder or place document of record at a location within the payload directory.

Locale: Specify the language of the document of record.

Sign Document step

The Sign Document step enables you to use Adobe Sign to sign documents.  The Sign Document step has the following properties:

  • Agreement Name: Specify the title of the agreement. The agreement name becomes part of the subject and body text of the email sent to the signers.
  • Locale: Specify the language for the email and verification options.
  • Adobe Sign Cloud Configuration: Choose an Adobe Sign Cloud Configuration. If you have not configured Adobe Sign for AEM Forms, see Integrate Adobe Sign with AEM Forms.   
  • Document to be Signed: You can choose a document from a location relative to the payload, use payload as the document, or specify an absolute path of the document.
  • Days Until Deadline: A document is marked due (passed deadline) after there is no activity on the task for the number of days specifies in the Days Until Deadline field. The number of days are counted after the documented is assigned to a user for signing.
  • Reminder Email Frequency: You can send a reminder email at daily or weekly interval. The week is counted from the day the documented is assigned to a user for signing.
  • Signature Process: You can choose to sign a document in a sequential or a parallel order. In sequential order, one signer receives the document at a time for signing. After the first signer completes signing the document, then the document is sent to the second signer, and so on. In parallel order, multiple signers can sign a document at a time.
  • Redirection URL: Specify a redirection URL. After the document is signed, you can redirect the assignee to a URL. Usually, this URL contains a thank you message or further instructions.
  • Workflow Stage: A workflow can have multiple stages. These stages are displayed in the AEM Inbox. You can define these stages in the properties of the model (Sidekick > Page > Page Properties > Stages).
  • Select Signers: Specify the method to choose signers for the document. You can dynamically assign the workflow to a user or a group or manually add details of a signer.
  • Script or service to select signers: The option is available only if the Dynamically option is selected in the Select Signers field. You can specify an ECMAScript or a service to choose signers and verification options for a document.
  • Signer Details: The option is available only if the Manually option is selected in the Select Signers field. Specify email address and choose an optional verification mechanism. Before selecting a 2-step verification mechanism, ensure that the corresponding verification option is enabled for the configured Adobe Sign account.
  • Status Variable: An Adobe Sign enabled document stores signing status of the document in a variable. Specify the name of the status variable (adobeSignStatus). A status variable of an instance is available in CRXDE at  /etc/workflow/instances/<server>/<date-time>/<instance of workflow model>/workItems/<node>/metaData contains status of a variable.
  • Signed Document Path: Specify the location to keep signed documents. You can choose to overwrite the payload file or place the signed document at a location within the payload directory.

Document Services Steps

AEM Document Services are a set of services for creating, assembling, and securing PDF Documents. AEM Forms provides a seperate AEM Workflow step for each document service:

Apply Document Time Stamp

Add time stamp to a document. You provide document details such as input document path, input document name, location to store exported data. You may choose to overwrite existing payload file or choose a different file name to store data in a different file under payload folder.

Convert to image

Converts a PDF document to an image file. Supported image formats are JPEG, JPEG2000, PNG, and TIFF. The following information applies to conversions to TIFF images:

  • A multi-page TIFF file is generated.
  • Some annotations are not included in TIFF images. Annotations that require Acrobat to generate their appearance are not included.

Convert to PDF/A

Converts a PDF document to PDF/A format using the options provided. The PDF/A version of Portable Document Format (PDF) is specialized for archiving and long-term preservation of documents.

Convert to PS

Convert PDF documents to PostScript. When converting to PostScript, you can use the conversion operation to specify the source document and whether to convert to PostScript level 2 or 3. The PDF document you convert to a PostScript file must be non-interactive.

Create PDF from specified type

Generate a PDF document from an input file. The input document can be relative to the payload, have an absolute path, or can be payload itself. 

Create PDF from URL/HTML/ZIP

Generates a PDF document from supplied URL, HTML, and ZIP file.

Export Data

Exports data from a PDF forms or XDP file. It requires you to enter the file path of Input Document and the Export Data Format. The options for Export Data Format are Auto, XDP and XmlData.

Export PDF to specified type

Converts a PDF document to a selected format.

Generate Non-Interactive PDF

Generate a Non-Interactive PDF. It provides various customization options. 

Import Data

Merges form data into a PDF form. You can import form data into a PDF form.

Invoke DDX

Executes the DDX file on the specified map of input documents and returns the manipulated PDF documents.

Optimize PDF

Optimizes PDF files by reducing their size. The result of this conversion is PDF files that may be smaller than their original versions. This operation also converts PDF documents to the PDF version specified in the optimization parameters.

Optimization settings specify how files are optimized. Here are example settings:

  • Target PDF version

  • Discarding objects such as JavaScript actions and embedded page thumbnails

  • Discarding user data such as comments and file attachments

  • Discarding invalid or unused settings

  • Compressing uncompressed data or using more efficient compression algorithms

  • Removing embedded fonts

  • Setting transparency values

Render PDF Form

Renders a form created in Form Designer (XDP) to a PDF form.

Secure Document

Encrypt, Sign, and certify a document. AEM Forms supports both password based and certificate base encryption. You can also choose between various algorithms for signing documents. For example, SHA-256 and SH-512. You can also use the workflow step to reader extend PDF documents. The workflow step provides option to enable barcode decoding, digital signatures, import and export of PDF data, and other options.  

Send to Printer

Send a document directly to a printer. It supports the following printing access mechanisms:

  • Direct accessible printer: A printer that is installed on the same computer is called a direct accessible printer, and the computer is named printer host. This type of printer can be a local printer that is connected to the computer directly.
  • Indirect accessible printer: The printer that is installed on a print server is accessed from other computers. Technologies such as the common UNIX® printing system (CUPS) and the Line Printer Daemon (LPD) protocol are available to connect to a network printer. To access an indirect accessible printer, specify the print server’s IP or host name. Using this mechanism, you can send a document to an LPD URI when the network has an LPD running. The mechanism lets you route the document to any printer that is connected to the network that has an LPD running.

Ez a munka a Creative Commons Nevezd meg!-Ne add el!-Így add tovább! 3.0 Unported licenc alatt lett közzétéve.  A Twitter™ és Facebook közzétételeket a Creative Commons jogi feltételei nem szabályozzák.

Jogi közlemények   |   Online adatvédelmi nyilatkozat