Adobe AEM Workflows - Is It Possible to Modify Payload via EMCAScript

Question

I am working on creating an AEM Workflow. One of the steps in this workflow is a Process that calls an EMCAScript file which renames the Asset if it has spaces:

var workflowData = workItem.getWorkflowData();
var pType = workflowData.getPayloadType();
if (workflowData.getPayloadType() == "JCR_PATH") {
    var path = workflowData.getPayload().toString();
    var parentPath = path.replace('/jcr:content/renditions/original', '');
    if (workflowSession.getSession().itemExists(parentPath)) { 
        var replaceChars = new RegExp(" ", "g");

        var node = workflowSession.getSession().getItem(parentPath);
        var name = node.getPath();
        var newName = name.replace(replaceChars, "_");
        log.warn('Name : ' + name + ". New Name: " + newName);
        if(name != newName) {
        log.warn(newName);
         workflowSession.getSession().move(name, newName);
        node.save();
        }
    } else {
        log.warn("Item does not exist: " + path);
    }
}

The logic works as expected - the file is renamed. Other steps in the workflow seem to complete correctly as well; i.e. the thumbnail seems to be properly extracted.

However, the asset itself is "stuck" in the processing state. When I look at the failure details for the job, I see the following:

com.adobe.granite.workflow.WorkflowException: Process execution resulted in an error
    at com.adobe.granite.workflow.core.job.HandlerBase.executeProcess(HandlerBase.java:201)
    at com.adobe.granite.workflow.core.job.JobHandler.process(JobHandler.java:260)
    at org.apache.sling.event.impl.jobs.JobConsumerManager$JobConsumerWrapper.process(JobConsumerManager.java:502)
    at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.startJob(JobQueueImpl.java:293)
    at org.apache.sling.event.impl.jobs.queues.JobQueueImpl.access$100(JobQueueImpl.java:60)
    at org.apache.sling.event.impl.jobs.queues.JobQueueImpl$1.run(JobQueueImpl.java:229)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: com.adobe.granite.workflow.WorkflowException: Failed to execute process
    at com.day.cq.workflow.compatibility.CQWorkflowProcessRunner.execute(CQWorkflowProcessRunner.java:108)
    at com.adobe.granite.workflow.core.job.HandlerBase.executeProcess(HandlerBase.java:191)
    ... 8 more
Caused by: com.day.cq.workflow.WorkflowException: execute: cannot process video, asset [{/content/dam/this file name has spaces.jpg/jcr:content/renditions/original}] in payload doesn't exist for workflow [{VolatileWorkItem_node2_var_workflow_instances_server0_2023-02-17_update_asset_58}].
    at com.day.cq.dam.video.AbstractFFMpegProcess.execute(AbstractFFMpegProcess.java:75)
    at com.day.cq.workflow.compatibility.CQWorkflowProcessRunner.execute(CQWorkflowProcessRunner.java:93)
    ... 9 more

I understand the error: the Workflow cannot find the original file since it has been moved/renamed. However, what I don't understand is why I am receiving that error from the "FFmpeg thumbnails" step when it is before the step (Process near the bottom) that does the renaming.

Is it possible to update the payload (Jcr Path) so that all steps in the Workflow see the updated name? I am using Adobe AEM 6.5.10.

Answer 1

I have a "hacky" way of changing a payload path of a running workflow.

I prefaced with "hacky" way because it is not documented and would require you to have an extra task step in your workflow.

The gist of it is:

1. Save the value of the new file name of your payload somewhere
2. After the step wherein the payload was renamed, create a Task step.
3. In the task "Pre create task script" have a script that essentially gets the value of the new file name, and set it to the content path of the task:

task.setContentPath(newFileName);

4. Task needs to be completed and after the task is completed, your payload would have adjusted to the new location.