Is it possible to trigger a workflow launcher with an event, or have it wait for another workflow to finish?

[peter-g]

Hi,

I have a workflow that I want to run on any assets created in a specific DAM folder, lets call it "data-folder".

I need this workflow to run after DamUpdateAsset.

I would prefer to do this without modifying the DamUpdateAsset model.

I need to do this with an AEM workflow launcher, and not an EventListener.

I've tried a few things but have not been able to trigger properly, once DamUpdateAsset finishes. Below are the things I've tried:

1) Setting the launcher to Node modified on data-folder, and condition dam:assetState == processed. This triggers my workflow multiple times, including on file delete. (bad)

2) Setting the launcher to Node created on data-folder. This triggers my workflow once, but it fails because DamUpdateAsset is still running. (bad) Perhaps there is a way to add a wait to the launcher? 

3) I tried appending my workflow to the end of DamUpdateAsset but the payload given to it becomes the "original" rendition, and I'd rather not have to jump up to the parent programatically. Also, this requires modifying or copying DamUpdateAsset, and changing the way AEM is set up OOTB. 

Any help here is appreciated. This seems like a simple issue but I'm not experienced with AEM enough to know what conditions to set.

Thanks!

[arunpatidar]

try with similar to below, we had a similar requirement to work on images after assets processed.

conditions="[jcr:content/renditions/original/jcr:content/jcr:mimeType==image/.*]"

nodetype="dam:Asset"

eventType="{Long}1"

[SameerBhalerao · Accepted solution]

Hi Peter,

This is not a simple use case as you've wrote in your question.

For me, this kind of sequentiality can be achieved only if you invoke the required workflow as a part of sub workflow or by writing a custom step at the end of DamUpdateWorkflow. 

Workflow Launcher have only 3 types of events available that too "jcr node events" and not sling ones so creating them would be difficult with a lot of trial and error and possibility multiple times invocation.

I think you should revisit decision not to write a sling event listener. It is much cleaner for your use case and you can listen to DAM_UPDATE_ASSET_WORKFLOW_COMPLETED event which is sent at the end of DamUpdateWorkflow and have a lot of power with programmatic filter and event topics to choose from for right time invocation and also payload path manipulation. This event listener can be backed up with good logging to allow comprehensive debugging.   

Hope this helps!