No auto-start Workflow menu in DAM folder properties in local environment | Community
Skip to main content
M
mstuart2-dxc
October 26, 2022
Solved

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

  • October 26, 2022
  • 1 reply
  • 760 views

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!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by Chandra_Hire

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 (wttech.blog)

 

Hope this helps.

1 reply

Chandra_Hire
Chandra_HireAccepted solution
Level 4
October 27, 2022

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 (wttech.blog)

 

Hope this helps.

    M
    mstuart2-dxcAuthor
    October 31, 2022

    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. 

      Terms & ConditionsAccessibility statement

      Loading footer...