Persisting Workflow Changes in a Project

[Former Community Member]

We were experiencing issues with the 1280px rendition of DAM assets, and since nobody wanted those renditions, we have decided to modify the Update Asset workflow to remove the "Create Web Enabled Rendition" step.  What is the best way to persist this change as part of our project, so that the change will be applied to any new AEM instances that we launch?

The workflow is stored at /etc/workflow/models/dam/update_asset.  Should we just include this node and its subtree in our project?  Are there any ramifications to this approach, such as side effects if an Adobe hotfix modifies the workflow?
If a future hotfix does modify the workflow, I suspect it would re-add the step that we've removed, and it would remain until our project is re-installed.  Is there any way to avoid that?

Is there a better way to achieve this?  Perhaps we should create a CreateWebEnabledImageProcess component to replace the out-of-the-box component, allowing us to effectively disable that workflow process.  Of course, if any other workflows use that process, we would be disabling it for all of them.

Please advise.  Thanks!

[Will_McGauley]

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

[Former Community Member]

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.

[Former Community Member]

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?

[Lokesh_Shivalingaiah]

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 !!

[smacdonald2008]

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. 

§Can be updated in a step:

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

§Can be retrieved on subsequent steps:

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

[smacdonald2008]

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. 

[Former Community Member]

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.

[Former Community Member]

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!

[Lokesh_Shivalingaiah]

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

[Opkar_Gill]

Dave Hughes wrote...

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.

Hi Dave,

adding the workflow to your codebase and deploying it is a common approach. I understand your concern around future hotfixes or upgrades. Hotfixes should be reviewed on a per case basis to see if they are required, not all hotfixes are mandatory. In which case during the review, you would need to determine if it will affect any OOTB functionality you have modified. I always apply my hotfixes to Dev first, run tests and then promote the hotfix to each environment. I am sure you do the same, so the likelyhood of your changes being overwritten by the time you get to prod, are likely to be very small.

As for upgrades, during your regression testing any such issues are likely to be highlighted and can be fixed well before going live.

The above is not ideal and adds some overhead for you admin/devops team, but with the correct environment and procedures, you can limit the chances of any issues in your production environment.

Regards,

Opkar

[Opkar_Gill · Accepted solution]

Dave Hughes wrote...

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!

Hi Dave,

you could create a separate bundle/package for your workflow, which you only deploy when you make changes.

Regards,

Opkar

[Former Community Member]

Lokesh,

That's exactly what I've done, however that is causing the version auto-increment described in my last post.

[smacdonald2008]

You will have to build a custom step and modify an ootb workflow to persist workflow data. Will talked about how to get workflow data in the webinar. You have to use the WorkFlow APIs. 

http://docs.adobe.com/docs/en/cq/5-6-1/javadoc/com/adobe/granite/workflow/exec/package-summary.html

http://docs.adobe.com/docs/en/cq/5-6-1/javadoc/com/adobe/granite/workflow/exec/WorkItem.html#getWork...()

Then you can persist the data where you want - ie - in the JCR, in a relational database, etc. Assume you want to persist the data in the JCR. Once you have the workflow data in a custom Java step - you can use the JCR API to persist in the data in node props at a certain JCR location. 

[Former Community Member]

No, I am not trying to persist data as part of a workflow.

I am trying to persist the workflow itself.  We have modified the OOTB Update Asset workflow to remove a step.  Now we need to ensure that the workflow step doesn't get reintroduced by a hotfix or deploying a new instance of AEM.

If workflows were like components, we would create an overlay in /apps (which would be used instead of the OOTB workflow), and we would include that overlay in one of our projects so that we could deploy it when we spin up a new instance.  As an overlay, we wouldn't have to worry about Adobe hotfixes, as the hotfix wouldn't touch the overlay in /apps.

I have presented the two possibilities that we've considered:

• Copy /etc/workflow/models/dam/update_asset into one of our projects and hope that we never overwrite important changes made by a future hotfix.
• Create a new CreateWebEnabledImageProcess OSGi component that does nothing, and hope that the Create Web Enabled Image process is never needed elsewhere.

Both approaches seem to have ramifications.  Is one better than the other?  Is there an approach better than both of these?

[smacdonald2008]

Most people create their own based on an existing one. They start with an ootb one and then modify it - similar to components. (when i read  persisting changes to OOTB workflows - i was thinking changes to data). I will also get our AEM developers to look at this as well. 

[Former Community Member]

Thank you again, Scott.  If I understand your last message correctly, I had this thought as well.

I considered cloning the OOTB workflow under a new name (we'll call it "Vendor Asset"), and removing the process step from the clone.  I suspect that would require changing the Launcher configuration to run our custom Vendor Asset workflow.  I believe this has concerns in and of itself, however:

• The Launcher tab of the Workflow console does not contain launchers for the DAM workflows.  Likewise, they aren't defined under the expected /etc/workflow/launcher/config.
• Even if I could find the relevant Launcher configuration, the same problem would exist: we're changing something that is OOTB.  The Launcher configuration change would likely be "safer" to modify and persist than the workflow, as it is less likely to be changed by Adobe, but the risk still exists.

The root of the issue still seems to be that workflows, like all of /etc, deviates from the resource resolution pattern that permits /apps to overlay /libs.

Anyways, I appreciate your bringing the devs in to help with this question.  Could you provide a rough timeframe for when they may be able to weigh in on the topic?  Are we looking at a timescale of hours, days, or weeks?
 

Thanks again,
Dave

EDIT: sorry, Scott.  Not sure where I got Sam from.

[smacdonald2008]

Will and i think the others are off this week - Adobe employees are typically off a week here and there in summer. I will ask WIll to look at this when he is back next week. 

[Former Community Member]

Much appreciated, thank you.