Persisting Workflow Changes in a Project

Hi Dave,

I dont think you have to do all of these. You can just update the OOTB workflow and include that as part of your project package as you do for all custom workflows or content. So when you deploy these packages on any instance should go with the changes workflow.

Regards,

Lokesh

Scott, I disagree.  This isn't a custom addition to CQ, it's a modification of an OOTB piece.  In the case of components and templates, we don't have to worry about an AEM upgrade or hotfix wiping out our changes, since the extensions live under /apps, which a hotfix shouldn't touch.  The workflows differ because they are under /etc, which doesn't have a corresponding overlay directory.

In any case, we've now copied the entire update_asset workflow into our project.  Unfortunately, every install of the project results in an increment to the version number, which is now growing very quickly (20 versions in the last half hour, locally).  Since this increments with every install (even though there are no changes), and because the number of installs may differ between environments (local, dev, test, stage, production, etc), the version information is now useless.  Is it possible to specify the version number?

<model jcr:primaryType="cq:WorkflowModel" jcr:isCheckedOut="{Boolean}false" sling:resourceType="cq/workflow/components/model" description="This workflow manages the update of assets" title="DAM Update Asset"> [...] </model>

[img]dam_workflow.png[/img]

I've tried to include the jcr:uuid and jcr:baseVersion properties, with the hope that making these values static would prevent the version increments.  This did not work, nor did adding the cq:lastModified and cq:lastModifiedBy properties.
If I set jcr:isCheckedOut="{Boolean}true", versions do not get created, and the version appears as "jcr:rootVersion" in the Workflow console.  This mitigates the auto-increment, but also removes the version info, which has some value.  I'm also concerned that this is "hacky" and may cause problems down the road.
Is there anyway to specify and persist the version number with the workflow in our project, so that we may manually increment it when there are actual changes (ie, a new version of the workflow)?

The closest thing that I can find to documentation is the JCR versioning info, which provides little insight to a solution: http://www.day.com/specs/jcr/2.0/15_Versioning.html

Thanks again!

Scott,

Thanks for responding, but the provided link and video don't seem relevant.  Neither seem to discuss persisting changes to the AEM out-of-the-box workflows, which is the topic of this thread.
 

Thanks again,
Dave

EDIT: corrected Scott's name.

You can package up the workflow and then re-deploy on the upgraded CQ instance. That is the same for all custom pieces of CQ. You need to re-deploy custom solutions  whether they are components, templates or workflows. 

Take a look at this workflow article: 

https://helpx.adobe.com/experience-manager/using/Workflows.html

AT the start of the article - there is a link to Ask the Experts on Workflows. Will - our AEM developer spoke about how to get payload data to persist it and update steps with new data. 

  workItem.getWorkflowData().getMetaDataMap().put(“someKey”, “someValue”);

  workItem.getWorkflowData().getMetaDataMap().get(“someKey”, String.class);

Dave,

As @Will mentioned, that the only option, there is no concept of overlay like component with workflows.

btw, when you make a package as part of your project, why would its version go so high unless you have any changes to it and install the package again !!

Will McGauley wrote...

Hi Dave -

Modifying the OOTB Dam Update Asset workflow will work just fine. When upgrading AEM at a later date you will likely lose your changes and will need to re-apply them.  Shouldn't cause much harm.

Will

 

Thank you for your input, Will.  This is not, however, an appropriate answer.  We made the workflow change for a reason, and it will be problematic if the changes are lost.

I suspect the point of your answer is that the change to the workflow cannot be protected from upgrade/hotfix modifications?  
There is no known way to achieve what I am trying to do?

I hate to do it, but... *bump*.

I have not been able to find documentation that covers persisting changes to OOTB workflows.  Surely there's some knowledge that can be shared.