Persisting Workflow Changes in a Project

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

Much appreciated, thank you.

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. 

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.

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. 

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?

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#getWorkflowData()

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. 

Lokesh,

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

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