Custom Workflow Launcher Configurations Per Environment in Source Code

[nesfel_aem]

We're using AEM 6.3.3.2.  Is it possible to customize configurations in our source code for individual workflow launchers on a per environment basis, similar to OSGI configs?  The goal is that each Maven build will apply the custom settings to each workflow on a per environment basis.  We'd like to avoid manually changing settings after deployment.

With OSGI configs, we have various config folders in our ui.apps project that might apply to individual servers (DEV, QA, etc.).  Each server uses custom configurations based on naming conventions used for folder names and the server's run mode(s).  It's easy and works great, but we haven't had any luck figuring out how to do something similar for workflows.

We saved the configuration for a sample AEM Workflow Launcher under this folder in the ui.content project:

ui.content/src/main/content/jcr_root/etc/workflow/launcher/config/my_custom_workflow/.content.xml

It works great, but the same settings apply to all environments.  In the .content.xml file, we want the enabled property set to true in our QA, CERT, and PROD environments, but set to false in our DEV environment and local sandboxes.  We'd like to avoid enabling or disabling all workflow launchers per server, since we have other workflows that we always want enabled in all environments.  Here's what our current .content.xml file looks like.

<?xml version="1.0" encoding="UTF-8"?>

<jcr:root xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"

   jcr:primaryType="cq:WorkflowLauncher"

   condition=""

   conditions="[\0]"

   description=""

   disabledFeatures="[]"

   enabled="{Boolean}true"

   eventType="{Long}16"

   excludeList=""

   features="[]"

   glob="/content/myapp/us/en/mynode/"

   nodetype="nt:base"

   runModes="author"

   workflow="/etc/workflow/models/my_custom_workflow/jcr:content/model"/>

Thanks in advance for any possible solutions you can share, and really appreciate you taking the time to ponder this.

-Nestor

[Gaurav-Behl]

Could you test it with multiple runmodes?

runModes="author,prod"

runModes="[author,prod]"

[nesfel_aem]

Hi gauravb10066713​.  The runModes property only limits where this single configuration gets applied for the specified workflow launcher.  We're trying to use multiple configurations that are selectively applied to different servers.  The runModes property might be part of the solution, but it doesn't help with the multiple configurations piece (unless there's more to it that I'm not seeing).

Thanks very much for your input.

[Gaurav-Behl]

My solution is to use different runmodes per environment along with server type (author/publish). I assume we are on the same page here.

E.g.  java -jar abc.jar -Dsling.run.modes=author, prod, someothercustomrunmode

You could configure different runmodes per environment - dev, qa, prod etc. and that should do the trick.  I remember there is an option which says author+publish in launcher dashboard that means it allows to pass on multiple runmodes in some way.

Now what I'm not aware of is the syntax part that's why I mentioned try with either String or String[] type or check the /libs code regarding how you can pass multiple runmodes to this launcher configuration.

Hope that helps.

[nesfel_aem]

gauravb10066713​, thanks again for commenting.  We do use different runmodes on all our servers.  Unlike regular osgi configs for stuff like com.day.cq.mailer.DefaultMailService.xml, the workflow launcher config is in one folder, and the file is named .content.xml.  For our example workflow, it's:

-ui.content/src/main/content/jcr_root/etc/workflow/launcher/config/my_custom_workflow/.content.xml

It's not that we only want to run it or not run it on certain servers, it's that we'd like different configuration values on each server.  That implies multiple config files.  So runmode matters, but the problem is how do we provide multiple, different values via config files for various properties such as "conditions" or "excludeList"?

It's difficult to succinctly and clearly describe the issue, but hopefully this clarifies it a bit.

[smacdonald2008 · Accepted solution]

YOu are correct - you cannot setup config values for this use case like you can for OSGi bundles as described in this document:

Reading OSGi Configuration Values for Adobe Experience Manager 6.3

[Gaurav-Behl]

check the OOB config folders -

/apps/core/wcm/config

/apps/core/wcm/config.author

/apps/weretail/config.publish

/apps/weretail/config.author

To me, if you would create structure like this, it should work fine -

-ui.content/src/main/content/jcr_root/etc/workflow/launcher/config.author.prod/my_custom_workflow/.content.xml

-ui.content/src/main/content/jcr_root/etc/workflow/launcher/config.publish.prod/my_custom_workflow/.content.xml

-ui.content/src/main/content/jcr_root/etc/workflow/launcher/config.author.dev/my_custom_workflow/.content.xml

-ui.content/src/main/content/jcr_root/etc/workflow/launcher/config.publish.dev/my_custom_workflow/.content.xml

-ui.content/src/main/content/jcr_root/etc/workflow/launcher/config.author.stage/my_custom_workflow/.content.xml

-ui.content/src/main/content/jcr_root/etc/workflow/launcher/config.publish.stage/my_custom_workflow/.content.xml

For prod server, runmodes would be - author, prod and publish, prod

For dev server, runmodes would be - author, dev and publish, dev

In each config file, specify the custom properties/key-value pairs as required.

Would it suffice?

[nesfel_aem]

Very logical idea, and I tried something similar before posting, but no dice.  I even tried it again in case I missed something the first try, both with and without the square brackets for runModes value in .content.xml.  Thanks so much gauravb10066713​ for your awesome suggestions and time.

[nesfel_aem]

As usual, you are right smacdonald2008​.  Thanks very much for answering.

[Gaurav-Behl]

I think I understand the reason why it wouldn't work because it's the same OOB OSGIproperty that you plan to configure with different values. One of the workaround is that you could extend the Launcher handler and register your custom properties/wrapper and pass on the environment specific values to the OOB code from the same approach shared above.

[nesfel_aem]

Appreciate you suggesting a possible alternative gauravb10066713​.  For now, we only have one affected workflow (maybe two), so writing/maintaining additional and possibly unsupported custom workflow code doesn't quite seem worth the trade-off of manually enabling/disabling the workflow launcher.  We still might give your suggestion a shot if we have time, and if so, will let you know how it goes.  Thanks again gauravb10066713​.