I've customized the Request for Activation Workflow by overlaying libs/../managepublicationwizard and I can publish the Content to Publish environment and it is working as expected(As per my logic). But in the case of Publishing Content to Preview the same customized workflow will be triggering this is not expected behaviour and I want to publish the content to preview directly or whatever is in the OOTB. Is there a way we can keep the OOTB workflow in case of a preview?
Hopefully, someone can give me some suggestions. thanks
Solved! Go to Solution.
Thanks all for the suggestions. I've been checking whether the agenId is a preview or publish if the agenId is a preview it will invoke the OOTB workflow and else it will trigger our customized workflow.
Hi @jerinraj5555 ,
It sounds like you have customized the Request for Activation Workflow by overlaying the managepublicationwizard component in order to add some custom logic for publishing content to the Publish environment. However, this customization is also affecting the behavior of the workflow when publishing to the Preview environment, which is not the desired behavior.
To keep the out-of-the-box (OOTB) workflow when publishing to the Preview environment, you will need to update your customization to exclude the Preview environment. There are a few ways you can do this, depending on your specific requirements:
You can update your custom code to check the environment being published to and only execute your custom logic when publishing to the Publish environment. For example, you can use the env
variable in the workflow process to determine the environment being published to, and only execute your custom logic if env == "publish"
.
Alternatively, you can create a separate workflow process for publishing to the Preview environment that does not include your custom logic. This would allow you to keep the OOTB workflow for the Preview environment while still using your custom logic for the Publish environment.
You can also consider using a different approach to customize the Request for Activation Workflow, such as creating a custom workflow process step or extending the OOTB workflow process using an OSGi bundle. These approaches would allow you to more easily separate your custom logic from the OOTB workflow process, making it easier to maintain and update your customization.
I hope this helps! Let me know if you have any other questions.
Thanks,
Ravi Joshi
Thanks for the reply. Could you please provide some hints or helpful links for the 2nd approach? I mean where I can update the custom workflow path for publishing to the Preview env.
Hi @jerinraj5555 ,
With 2nd approach, you can create a new workflow model in AEM that is specifically for the Preview environment.
Then use workflow launchers to trigger the appropriate workflow model based on the environment. For example, you can create a workflow launcher that is specifically for the Preview environment, and configure it to trigger the OOTB workflow model.
Use workflow conditions to control which workflow model is triggered based on the environment. For example, you can create a workflow condition that checks the environment and only triggers the OOTB workflow model if the environment is Preview.
Reference: https://experienceleague.adobe.com/docs/experience-manager-64/authoring/workflows/workflows.html?lan....
I mean where I can update the custom workflow path for publishing to the Preview env - No need to update any path when you make changes to any OOTB workflow. Once you edit any OOTB workflow model it will move to the "/conf/global/workflow/models" location.
Thanks,
Ravi Joshi
Thanks all for the suggestions. I've been checking whether the agenId is a preview or publish if the agenId is a preview it will invoke the OOTB workflow and else it will trigger our customized workflow.
Views
Likes
Replies