No auto-start Workflow menu in DAM folder properties in local environment

[mstuart2-dxc]

Hi. My colleagues and I notice that, in our local SDK installations, there is no Auto-start Workflow menu under the Assets Processing tab in a DAM folder's properties. We do see this in all our remote environments (dev/staging/prod).  I'm trying to setup the creation of a DAM folder and a workflow model, and the assignment of the model to the folder, in our codebase. But I have to deploy to development to test. Is this a thing that does not work when using the SDK locally? Thanks!

[Chandra_Hire · Accepted solution]

Hi @mstuart2-dxc,

We know that, AEMaaCS Assets and AEM DAM On-Premises uses different architecture for assets processing and storage. AEMaaCS Assets directly uploads assets to binary storage and uses cloud-native microservices for processing.

For a situation, where additional processing of assets is required that cannot be achieved using the processing profiles, additional post-processing workflows can be added to the configuration. Post-processing lets you add completely customized processing on top of the configurable processing using asset microservices.

Post-processing workflows, or Auto-start workflow, if configured, are automatically executed by Experience Manager after the microservices processing finishes. These cloud-native asset microservices are not available on local sdk. Hence, the post processing workflows are not available on local aem sdk. If we need to extend the workflow, need to test it on AEMaaCS runtime environment (Please refer 'Develop and test asset microservices' section of Notable changes in Adobe Experience Manager Assets as a Cloud Service | Adobe Experience Manager)

AEM as a Cloud Service SDK is not exact copy of the actual runtime that's running in the cloud. 

You may try this workaround for generating renditions on local SDK -  Handling AEM as a Cloud Service renditions in local development | Wunderman Thompson Technology (wtt...

Hope this helps.

[mstuart2-dxc]

Thanks for verifying that this is not something we can test in the SDK. I did find that the code work properly in our development environment.