Documentation AEM as a Cloud Service User Guide

Administering Workflow Instances administering-workflow-instances

Last update: Thu Feb 22 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Topics:
Administering

CREATED FOR:

Admin

The workflow console provides several tools for administering workflow instances to ensure that they are executing as expected.

A range of consoles are available for administering your workflows. Use the global navigation to open the Tools pane, then select Workflow:

Models: Manage workflow definitions
Instances: View and manage running workflow instances
Launchers: Manage how workflows are to be launched
Archive: View history of workflows that completed successfully
Failures: View history of workflows that completed with errors
Auto-Assign: Configure Auto-Assigning workflows to templates

Monitoring the Status of Workflow Instances monitoring-the-status-of-workflow-instances

Using Navigation select Tools, then Workflow.
Select Instances to display the list of running workflow instances currently in progress.
On the top rail, in the right corner, the workflow instances show Running workflows, Status, and Details.
Running workflows shows the number of running workflows, and their status. for example, in the given images, shown are the number of Running workflows and the Status of AEM instance:
- Status: Healthy
- Status: Unhealthy

For Status details of workflow instances, click Details, to show the number of running workflows instances, completed workflow instances, aborted workflow instances, failed workflow instances, and so forth. for example, below are the given images that show Status details with:

Status details: Healthy
Status details: Unhealthy

note note
NOTE
To maintain workflow instance healthy, follow best practices at regular purging of workflow instances or workflow best practices.

Search Workflow Instances search-workflow-instances

Using Navigation select Tools, then Workflow.
Select Instances to display the list of workflow instances currently in progress. On the top rail, in the left corner, select Filters. Alternatively, you can use the keystrokes alt+1. The following dialog is displayed:
In the Filter dialog, select the workflow search criteria. You can search based on these inputs:
- Payload path: Select a specific path
- Workflow model: Select a workflow model
- Assignee: Select a workflow Assignee
- Type: Task, Workflow item or Workflow Failure
- Task Status: Active, Complete, or Terminated
- Where I Am: Owner AND Assignee, Owner only, Assignee only
- Start Date: Start date before or after a specified date
- End Date: End date before or after a specified date
- Due Date: Due date before or after a specified date
- Updated Date: Updated date before or after a specified date

Suspending, Resuming, and Terminating a Workflow Instance suspending-resuming-and-terminating-a-workflow-instance

Using Navigation select Tools, then Workflow.
Select Instances to display the list of workflow instances currently in progress.

Select a specific item, then use Terminate, Suspend, or Resume, as appropriate; confirmation, and/or further details are required:

wf-97-1

note note
NOTE
To terminate or abort a workflow, it must be in a state of waiting for user intervention, such as in a Participant Step. Attempting to abort a workflow that is currently executing jobs (active threads that are under execution) may not produce the expected results.

Viewing Archived Workflows viewing-archived-workflows

Using Navigation select Tools, then Workflow.

Select Archive to display the list of workflow instances that completed successfully.

archived-instances

note note
NOTE
The abort status is considered as a successful termination as it occurs as a result of user action; for example:
use of the Terminate action when a page, that is subject to a workflow, is (force) deleted, then the workflow is terminated.

Select a specific item, then Open History to see more details:

Fixing Workflow Instance Failures fixing-workflow-instance-failures

When a workflow fails, AEM provides the Failures console to allow you to investigate and take appropriate action once the original cause has been handled:

Failure Details
Opens a window to show the Failure Message, **Step, and Failure Stack.
Open History
Shows details of the workflow history.
Retry Step Executes the Script Step component instance again. Use the Retry Step command after you have fixed the cause of the original error. For example, retry the step after you fix a bug in the script that the Process Step executes.
Terminate Terminate the workflow if the error has caused an irreconcilable situation for the workflow. For example, the workflow can rely on environmental conditions such as information in the repository that are no longer valid for the workflow instance.
Terminate and Retry similar to Terminate except that a new workflow instance is started using the original payload, title, and description.

To investigate failures, then resume or terminate the workflow afterwards, use the following steps:

Using Navigation select Tools, then Workflow.
Select Failures to display the list of workflow instances that did not complete successfully.
Select a specific item, then the appropriate action:

workflow-failure

Regular Purging of Workflow Instances regular-purging-of-workflow-instances

Minimizing the number of workflow instances increases the performance of the workflow engine, so you can regularly purge completed or running workflow instances from the repository.

Configure Adobe Granite Workflow Purge Configuration to purge workflow instances according to their age and status. You can also purge workflow instances of all models or of a specific model.

You can also create multiple configurations of the service to purge workflow instances that satisfy different criteria. For example, create a configuration that purges the instances of a particular workflow model when they are running for much longer than the expected time. Create another configuration that purges all completed workflows after some days to minimize the size of the repository.

To configure the service, you can configure the OSGi Configuration Files see OSGi configuration files. The following table describes the properties that you need for either method.

NOTE

For adding the configuration to the repository, the service PID is:
com.adobe.granite.workflow.purge.Scheduler
Because the service is a factory service, the name of the sling:OsgiConfig node requires an identifier suffix, for example:
com.adobe.granite.workflow.purge.Scheduler-myidentifier

Property Name (Web Console)

OSGi Property Name

Description

Job Name

scheduledpurge.name

A descriptive name for the scheduled purge.

Workflow Status

scheduledpurge.workflowStatus

The status of the workflow instances to purge. The following values are valid:

COMPLETED: Completed workflow instances are purged.
RUNNING: Running workflow instances are purged.

Models To Purge

scheduledpurge.modelIds

The ID of the workflow models to purge. The ID is the path to the model node, for example:
/conf/global/settings/workflow/models/dam/update_asset/jcr:content/model
Specify no value to purge instances of all workflow models.

To specify multiple models, click the + button in the Web Console.

Workflow Age

scheduledpurge.daysold

The age of the workflow instances to purge, in days.

Setting the Maximum Size of the Inbox setting-the-maximum-size-of-the-inbox

You can set the maximum size of the inbox by configuring the Adobe Granite Workflow Service, see add an OSGi configuration to the repository. The following table describes the property that you configure.

NOTE

For adding the configuration to the repository, the service PID is:
com.adobe.granite.workflow.core.WorkflowSessionFactory.

Property Name (Web Console)

OSGi Property Name

Max Inbox Query Size

granite.workflow.inboxQuerySize

Using Workflow variables for customer owned datastores using-workflow-variables-customer-datastore

Data processed by workflows is stored in the Adobe provided storage (JCR). This data can be sensitive in nature. You may want to save all the user-defined metadata/data in your own managed storage instead of Adobe provided storage. These sections describe how to set up these variables for external storage.

Set the model to use external storage of metadata set-model-for-external-storage

At the level of workflow model, a flag is provided to indicate that the model (and its runtime instances) has external storage of metadata. Workflow variables will not be persisted in JCR for the workflow instances of the models marked for external storage.

The property userMetadataPersistenceEnabled is stored on the jcr:content node of the workflow model. This flag is persisted in workflow metadata as cq:userMetaDataCustomPersistenceEnabled.

The illustration below shows how to set the flag on a workflow.

workflow-externalize-config

APIs for metadata in external storage apis-for-metadata-external-storage

To store the variables externally you must implement the APIs that the workflow exposes.

UserMetaDataPersistenceContext

The following samples show you how to use the API.


@ProviderType
public interface UserMetaDataPersistenceContext {

    /**
     * Gets the workflow for persistence
     * @return workflow
     */
    Workflow getWorkflow();

    /**
     * Gets the workflow id for persistence
     * @return workflowId
     */
    String getWorkflowId();

    /**
     * Gets the user metadata persistence id
     * @return userDataId
     */
    String getUserDataId();
}

UserMetaDataPersistenceProvider

/**
 * This provider can be implemented to store the user defined workflow-data metadata in a custom storage location
 */
@ConsumerType
public interface UserMetaDataPersistenceProvider {

   /**
    * Retrieves the metadata using a unique identifier
    * @param userMetaDataPersistenceContext
    * @param metaDataMap of user defined workflow data metaData
    * @throws WorkflowException
    */
   void get(UserMetaDataPersistenceContext userMetaDataPersistenceContext, MetaDataMap metaDataMap) throws WorkflowException;

   /**
    * Stores the given metadata to the custom storage location
    * @param userMetaDataPersistenceContext
    * @param metaDataMap metadata map
    * @return the unique identifier that can be used to retrieve metadata. If null is returned, then workflowId is used.
    * @throws WorkflowException
    */
   String put(UserMetaDataPersistenceContext userMetaDataPersistenceContext, MetaDataMap metaDataMap) throws WorkflowException;

}

recommendation-more-help

fbcff2a9-b6fe-4574-b04a-21e75df764ab